Xen find VBD id for physical disks

hard drivehotswapvirtualizationxen

I'm starting a xen domU using xm create config.cfg. Within the config file are a number of physical block devices (LVs) which are added to the guest and can be accessed fine when it boots. However, at a point in the future I need to be able to hot unplug one of these disks using the xm block-detach command. This command, however, requires the vbd id of the device to be detached and I can't find a way to find the device id for a particular disk 'plugged in' at start up. Any help is much appreciated!

Best Answer

I'm not aware of any "good" way to correlate the output of xm block-list <dom> to the physical devices in dom0. Possibly the best you can do is parse the DevController entries from xend.log, which detail the VBD's frontend and backend names at the point of creation. It's certainly not foolproof though and should be used with caution.

Related Solutions

Reset root pass on xen guest using physical disk

Shutdown the guest using something like

xm shutdown <guest>

Check so it is shutdown

xm top

That path hints that it's not an LVM, but a physical disk. This is a job for libguestfs. Make sure you have it installed. First you check what filesystems you have in that block device:

virt-filesystems -a /dev/sdb1

Then you mount the root filesystem:

guestmount -a /dev/sdb1 -m /dev/<whateverhappenstoberoot> --rw /mnt

Change root directory:

chroot /mnt/

Update your passwords

passwd root

And then you restore everything

logout
unmount /mnt/
xm create /etc/xen/vm/<guest>

Linux HA cluster w/Xen, Heartbeat, Pacemaker. domU does not failover to secondary node

I figured it out, after a bit more trial and error. I was getting iSCSI errors going back up the stack too rapidly, as mentioned in this post on ServerFault.

In addition to changing the variables outlined in the post above, I also traced some network cables and discovered that node #2 was on a 100Mb link, while node #1 was on a Gig link, along with the SAN. After some careful shuffling, all the network connections are now running at Gig speeds.

Finally, I changed the MTU on the Linux interfaces to 9000 from 1500, which seems to also have sped things up a bit.

The final result is a working cluster with the domU booting even quicker than before on node #1.

Cheers,

Kendall

Best Answer

Related Solutions

Reset root pass on xen guest using physical disk

Linux HA cluster w/Xen, Heartbeat, Pacemaker. domU does not failover to secondary node

Related Topic