Archive for November 7th, 2011
Just upgraded a domU to Fedora 15 from F14. As part of the upgrade, init essentially dies, and you have to hard reboot the VM. So I thought “Oh hey, why not use the Magic Sysrq keys to trigger a reboot. After all, I just learnt about xm sysrq.”
The first command,
xm sysrq 0 r went ok. People who know the syntax for xm/xl commands will know what I did wrong there. 0. I sent the sysrq command to dom0, the VM host!
I didn’t think about this. I got used to just typing in 0 after the command because I was fooling around with block-attack/detach/list. So I didn’t notice what I’d done. Until I typed in
xm sysrq 0 e and took down my SSH session, along with virtually all the daemons on the dom0.
Surprisingly, my domUs were still up. Mostly. Jumping over to the dom0 console, I brought sshd, xend, xenstored and xenconsoled back up. None of the xm commands were giving anything, so I restarted xend. I suppose that brought the domUs down, because none of my domUs were accessible by SSH.
Tried init 3 to see if that’d bring the daemons back up. No dice. Ok… init 5, and back to init 3. “Oh wait, it’s frozen now.”
So I had to reset the dom0 to get stuff back up. At least this is giving my startup scripts a good workout!
Originally, I exported one block device to each VM, then partitioned it. No fuss, everything self-contained in the one file/logical volume.
Then I had a few incidences where the VM crashed, and I needed to get a file or two off the virtual drive. It was a complicated process, as detailed in one of my earlier posts. So I get fed up and gave each VM 4 virtual disks – boot, root, home & swap, so I could shuffle the respective disks around when necessary.
Now I’ve discovered an easier way to use a single logical volume with each VM:
xl block-attach 0 phy:/dev/domU/fedora13pv.1 xvda w
Simply put, xl block-attach (and xm block-attach) creates a new virtual block device in the specified domain. There’s no man page for xl (yet), but it’s supposed to be a drop-in replacement for xm block-attach, which does have a manual entry. That command up there attached a domU’s logical volume to my dom0, where
pvs shows the new physical volume appearing as /dev/xvda2, and the domU’s volume group appearing, ready to be mounted.
Using xl block-attach
Usage: xl [-v] block-attach <Domain> <BackDev> <FrontDev> [<Mode>] [BackDomain]
Points to note about using block-attach:
domainshould be the domain ID, get it from xl list
backdevneeds to include ‘phy:’ or ‘file:’ if you use LVM/raw partitions or disk images respectively
frontdevdoesn’t appear to need /dev, like the config file
modeshould be ‘w’ or ‘r’
Essentially, block-attach uses the VM config file syntax – does
disk = [ "phy:/dev/domU/fedora13pv.1,xvda,w" ] look familiar?
Using xl block-detach
block-attach to recover data (or running fsck on a disk) is simple. Detaching the drive from your VM? Yeah… easier said than done, unfortunately. Trying
xl block-detach to get the syntax gives you this:
Usage: xl [-v] block-detach <Domain> <DevId>
xl block-detach 0 xvda, since we attached the block device to the domain’s
Error: Device xvda not connected. Oops.
Turns out, DevId doesn’t mean the front end or back end device names. What it needs is something from
xl block-list. Running
xl block-list 0 (since I want the block devices attached to dom0) gave me this output:
Vdev BE handle state evt-ch ring-ref BE-path
51712 0 0 1 -1 -1 /local/domain/0/backend/vbd/0/51712
Look at the Vdev number. That’s what you want.
Substitute it into the command to get
xl block-detach 0 51712, run it, and your block device is detached.
As a point of note, it doesn’t print any message on success though.
And I’m prefix this last bit with saying that this is unconfirmed in that I haven’t investigated why, but
xm block-detach doesn’t like the Vdev number when you try to use it. I don’t know if it’s just something up with xm, or my install.
I’d bet my install.