Archive for November, 2011
So, I’ve wiped my test system with the intention of doing a tutorial on installing F16 + Xen. As part of this, I looked into installing a F16 domU with virt-install. When I tried it previously, I ran into this bug, and I ended up having to vnc into the dom0 and use virt-viewer to do the install.
Recently, there was some activity on the bug, centering around using “
rd_NO_PLYMOUTH” to bypass the plymouth boot screen (the progress bar that scrolls across the screen, apparently – though why it’s in the installer I have no clue).
In any case, it seems to work – my revised install command of
virt-install -p -r 1024 -n rawhide -f /dev/domU/rawhide -l http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/16/Fedora/x86_64/os/ -x "ks=\"http://hydrogen/~kyl191/ks/ks.php?hostname=rawhide\" rd_NO_PLYMOUTH serial" seems to do the trick – it gets into the console, at the very least.
That said, I get a nasty error using the partitioning scheme in my Kickstart file – grub2 wants a BIOS boot partition, a 1MB partition for storing files, and installation fails.
So, either I add the extra partition to the kickstart partitioning stanza, or I pass the installer an extra
nogpt option when installing.
Guess which I chose. The BIOS boot partition makes no sense for Xen, because we’re booting with pygrub – we only care about grub.cfg, not what GRUB files are present or even if the bootloader is installed (which leads me to a question – can we get away with not specifying a bootloader to be installed in anaconda? I imagine not, since that probably means grub2 won’t be installed, but it might be something to look into.)
Though, it does seem to have completely fallen over – pygrub’s not returning any data on a (F14) Xen 4.0.2 system. xm create rawhide.cfg just returns an unhelpful “Error: Boot loader didn’t return any data!”, but trying pygrub directly gives a bit more detail – “RuntimeError: couldn’t find bootloader config file in the image provided.”
Trying with my F16 testbed now…
Also, apparently, radeontool, yum-pluginfastestmirror & ntpdate aren’t present in the F16 repos, so I have to remove them from my Kickstart file.
I’m trying out F16 as a dom0 from the beginning. No upgrades from F15 this time. So far, it’s generally ok.
The install (from the netinstall ISO) was straightforward. Only issue was that F16 strongly recommends that a BIOS boot partition be present. (Read: Requires it unless you pass a
nogpt option to the kernel boot line when installing.) Unlike in the F16 domU, I need grub2 to be working so I can boot, so I added the partition.
However, it’s subject to some strict size limits – between 1-2MB. 1MB is recommended, though I put 2MB and it seems to boot fine. If you try anything larger though, you get this error: (Why it says allowable size between 0MB-2MB is a mystery though. 1MB is the minimum size for all partitions.)
So, other than that install issue, there was nothing of note. Now, in the working system, I did a
yum install xen, and yum pulled down xen & the dependencies and installed them. As part of the install, it also regenerated grub.cfg. So don’t press Ctrl+C even though it looks like yum’s frozen. It isn’t.
One annoyance: The generated file is filled with Xen entries. You can either ignore them, and select Xen 4.1.2, or patch GRUB2 as specified here to get rid of the spurious entries. (No idea when the patched version will go into the repos.)
Next is networking. On my desktop, I have a strange Ethernet driver – it shows up as p34p1. No clue why, and it’s given me no end of trouble, particularly where NetworkManager attempts to seize control despite being specified as “NM_CONTROLLED=NO”.
But that’s neither here nor there. On the testbed, getting networking is trivial, just a matter of creating the bridge definition, and modifying the existing network adapter definition.
In /etc/sysconfig/network-scripts/, the existing file is named ifcfg-<network_adaptor>. (The one other than ifcfg-lo.) In my case, it was
ifcfg-em1. If you have special requirements, I’d recommend Google (which threw up this as the first result, and it seems pretty good), but if you’re using DHCP (if you don’t know what you’re using, chances are you are using DHCP), you just need to add the following to the new file
ifcfg-br0 with your favourite text editor:
DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0 NM_CONTROLLED=NO
BRIDGE=br0 to your respective network adaptor definition file (i.e.
ifcfg-em1). (With Vim or echo >> file, it doesn’t matter.)
Reboot, and the system seems to be up and running Xen. (Verify with a
I could have sworn I did this a while ago. But I got the error “‘Out of memory’, “xc_dom_boot_mem_init: can’t allocate low memory for domain\n “” when I tried to do a virt-install today.
The problem? I was installing a 64bit domU on a 32bit dom0. Which is a no-no.
Didn’t realise until I found this post on someone else’s blog detailing the error.
Now hopefully I don’t repeat this again…
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.
One issue with my shiny new WSUS toy that I did find was that, in theory, only Windows editions with access to Group Policy (namely, those editions labelled Professional and higher) can have the Windows Update server URL set.
Of course, in practical use, people have found a way. Whether it’s manually creating registry keys based on MS’s own documentation, or using a program that writes those registry values for you, there are ways around the Professional restriction.
Next thing is to get that annoying Java Update installed. Or Java uninstalled. Most likely the latter.
Also, upgrade my Linux VMs to F16, and then (finally) set up the common update repo. Yay!
So I got WinSrv2008R2 free, courtesy of Dreamspark, and I’ve been messing around with it. I was thinking of creating a few Win7 VMs to mess around with Domains, Group Policy and the like, and one of the things that I found was some functionality called Windows Server Update Services.
Turns out WSUS is a program which acts as a LAN-sized Windows Update In A Box. I like the idea of optimizing bandwidth used, AND it seems to give me nice pretty graphs of updates that were applied to my laptop when I tried it out. I’m hooking it up to my desktop too, just for the fun of it – mainly because my laptop’s 32 bit while my desktop’s 64 bit, so any architecture specific files need to be downloaded for both.
And then I thought, “Hmm. Why not expand it to the rest of the systems in the house?” All the systems that are actively used are Microsoft-based:
- Study computer? Windows XP (going to upgrade it before I leave for Canada)
- Dad & bro’s laptops? Cheap Acers running Vista Home Premium
- TV computer? Windows 7 Home Premium
- Mum’s laptop? (which she may or may not be leaving in Canada permanently) Windows 7 Home Premium too.
So, clearly, there’s some way to use WSUS at home. I used to go to each of them to manually click the ‘update’ button before giving up and setting Windows Update to automatically update all of them.
Right now the setup I have works. But WSUS is shiny new, so I’m going to mess around with it. It might not last, and I might let it sit there and run, but it’ll be fun to mess around with.