Jump to content
Welcome to our new Citrix community!
  • 0

Xenserver 7.0 - Guide to plug in Storage Repo after OS Failure resulted in Storage Repo Becoming Inaccessible

Cameron Fillers


The server hardware we use allows for a standalone OS drive, and then a hardware raid 10 for the Storage repo. Our OS drive went into read only mode, so we perform a clean install on a fresh drive. We pretty much followed this guide...




so that we could plug in the SR after the OS re-install was complete. We performed all steps, except for step 9, as that looked to be dangerous. Additionally, we skipped Step 9, since when running pvscan, it was able to detect the SR. Everything looked to be fine, but we were not able to plug in to the SR, and kept receiving errors when attempting to do so.  After doing google searches for about a hour to see why the SR would not plugin, we went back to Step 9, performed this step, and rebooted. After rebooting, pvscan displays no information at all.


# pvscan
  No matching physical volumes found


We also did  a comparison between similar server types, and noticed that this server now shows the following


Disk /dev/sda: 1998.2 GB, 1998233534464 bytes, 3902799872 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt

#         Start          End    Size  Type            Name
 1         2048   3902799838    1.8T  Linux LVM       Linux LVM




while other, similarly setup servers show as such...




Disk /dev/sda: 1999.3 GB, 1999307276288 bytes, 3904897024 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


Disk /dev/mapper/XSLocalEXT--ba6f8721--af26--dce9--b5e5--99d3b45b551f-ba6f8721--af26--dce9--b5e5--99d3b45b551f: 1954.7 GB, 1954730213376 bytes, 3817832448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


as no data has been written to /dev/sda, except for changing the partition table, I am hoping that I may still be able to revert the partition table, and extract the VHD files off of the server, or perhaps run a DD command and copy the VHD's somewhere else, so that I can at least save the data of some production servers.


I have other xenserver 7.0 instances running, and have tried to use sfdisk/gdisk/parted to inspect and try and inspect the partition table of the other servers, but so far I have not found anything that would help. Before I do anymore damage, I decided to post here for help.

Link to comment

2 answers to this question

Recommended Posts

  • 0

Thanks for the tip. I ran the command


vgchange -ay


and the results so far for a few hours is...


# vgscan
  Reading all physical volumes.  This may take a while...


So I'm guessing that it found nothing, and that the partition table is incorrect


as for backups, no. I did do a "xe vm-list > output.txt" when the server went into read-only mode while I still could, but nothing in regards to metadata backups.


as for archives...


# pwd
[root@xenserver archive]# ls -l
total 0


looks like nothing is in there. That's not a big deal. I could recreate things based on the data that I have, if I can get access to the VHD's. I just need to figure out how to mount the Storage Repo, even if it isn't mounted in xenserver, as I can transfer the VHD's to another server, and recreate. A bit time consuming, but all in all, not a big deal

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...