You hope that you won’t ever need to, but you may one day need to run fsck on a Linux XenServer VM that won’t boot.. no worries, attach the storage from that VM on another VM and run it from there!
Let’s set it up with VM1 and VM2, where VM1 is the one that you need to run a manual fsck on.
1. Shut down VM1 (if it’s not down already..)
2. Enter the console on the xenserver and list the VMs – grab the vm-uuid of VM2.
1 |
xe vm-list |
3. Now get the vdi-uuid of the vdi you want to access:
1 |
xe vbd-list vm-name-label=VM1 |
4. Create the vbd – it will echo the vbd-uuid after this command:
1 |
xe vbd-create vm-uuid=VM-UUID vdi-uuid=VDI-UUID device=autodetect |
5. Now, ‘plug’ it in to VM1
1 |
xe vbd-plug uuid=VBD-UUID |
You should now see a new partition in /proc/partitions
When you’re done with it, unplug the vbd:
1 |
xe vbd-unplug uuid=VBD-UUID[ |
Then you can destroy the temporary vbd:
1 |
xe vbd-destroy uuid=VBD-UUID |
Added 3/24/2014:
If you’re trying to run fsck on an LVM volume, then you’ll need to activate it first, otherwise you’ll get a bad superblock error.. and it won’t fsck correctly.
First, find out what the name is for your lvm’s volume group:
1 |
lvm vgscan |
Next, activate it:
1 |
lvm lvchange -ay /dev/VolGroup00/LogVol00 |
Next, run fsck on it, automatically fixing the errors:
1 |
e2fsck -y /dev/VolGroup00/LogVol00 |
When finished, deactivate it:
1 |
lvm lvchange -an /dev/VolGroup00/LogVol00 |
Great and detailed guide, thanks! As you said I hope I won’t ever need to do this but if I do I have bookmarked this post just incase.
Yes! This is another one for my server maintenance cheat sheet. Unfortunately, Murphy’s Law is a very active part of my life, so I appreciate having this resource for “just in case”. Thanks!
When I do the listing, I see 2, one saying device: hda and the other devide: hdd (and vdi-uuid: Not in database). So I used the first one, and when I try to plug it, it says that expected the state of the vm to be powered on.