Shlrm.org Blag

Was harder than it should’ve been. I got annoyed.

You need to install openssl-devel, zlib-devel, bison, gcc, make, patch, tar, and maybe gcc-c++ (although I don’t think this one is needed).

Go get the latest ruby 1.9 source, as of this writing 1.9-p378, and extract it somewhere. Then go get the patches on this bug, at the specific comment. You will need to apply at least the openssl-build-fix patch, since fedora uses openssl 1.0 and it’s not yet into ruby 1.9. Then follow your typical ./cofnigure, make, and make install stuff. I installed mine into a prefix of /opt/ruby so that it wouldn’t affect any fedora ruby stuff that it might want. I then added ruby’s path to the end of my user’s PATH variable.

That’ll get you a working ruby 1.9 in Fedora.

When I got xm pause working, I was quite excited. However, it doesn’t work in all cases. I’ve done some testing to figure out what combination of things cause it to fail.

All of this is using xen 4.0 hypervisor, the kernel from here, and a pvops domU kernel built by hand.

• Using blktap2 backed disks in the vhd format (vhd-util create -n name -s 1024) xm pause fails. The user-space disk devices are never released, and only a hard reboot will get it to function again.
• Using a different driver for the blktap2, tap:tapdisk:aio, also fails to pause.
• Using phy:/ backed disks, say through LVM works fine. The domU will pause, and resume nicely.

It would seem that there is something not quite ready to be used regarding the blktap2 backend, so I wouldn’t reccomend using it.

I also tried to use the original tap:aio drivers, but I cannot as they don’t seem to exist. I guess I’ll be using the plain old phy:/ drivers for now. That’s not a big deal as I don’t have any second xen machine to do anything fancy that the tap:aio drivers would provide. I guess I should poke on a mailing list or something.

…means I can finally pause/suspend a domU vm again!

Finding this information should’ve been obvious, but for some reason it wasn’t. Maybe I had some silly mental block or something. Anyways, get the kernel source from here. Then build it for your architecture. If you want to build a 32-bit kernel for some 32-bit domUs, and you’re running on 64-bit, it’s as easy as make ARCH=i386 <target>. This does work and I’ve verified it. Had to fool a Fedora domU into beleiving that it really was a 32-bit system.

I’ve found make tarbz2-pkg to be quite handy in packaging up the kernel to be deployed.

I have verified that this works in Xen 3.4.2 on a patched 2.6.29.6 kernel.

On my Xen 4.0 test box, it fails to suspend. I’m using the blktap2 stuff, and perhaps that doesn’t pause well. As far as I understand it, that blktap2 should not affect suspending, but I’m going to test it with some logical volume based vms. I usually use the lvm backed disks anyway, but the blktap2 stuff offers some interesting features, if it were to work. Not being able to pause stuff probably isn’t good, but again, I’m not sure what’s causing it.

Apparently, that is what’s causing it. The domU will pause and unpause just fine when using an lvm backed disk, rather than the blktap2 ones. I should test a couple of other combinations to see if things like tap:aio will behave, as that’s needed for nifty things like remus.

I built these on a recently updated Fedora 12 box. I haven’t yet had an opportunity to test them. If you do use them and they work great, or not, post in the comments please.

• xen-3.4.2-1.fc12.x86_64.rpm
• xen-debuginfo-3.4.2-1.fc12.x86_64.rpm
• xen-devel-3.4.2-1.fc12.x86_64.rpm
• xen-doc-3.4.2-1.fc12.x86_64.rpm
• xen-hypervisor-3.4.2-1.fc12.x86_64.rpm
• xen-libs-3.4.2-1.fc12.x86_64.rpm
• xen-runtime-3.4.2-1.fc12.x86_64.rpm