Landfill of wisdom

A nice feature in XEN that I miss in KVM is the ability to use a single partition as a disk image. In XEN you can do
disk = [ 'file:/dev/vg0/img_root,sda1,r' ]
and you can also safely mount /dev/vg0/img_root when the virtual machine is not powered on.
With KVM you’re out of luck, or at least my googling returned lots of questions and no solutions.

Well, there is a not so hard way of working around the issue.
Continue reading ‘KVM: virtualize a single partition’ »

So I got XEN working but the network interfaces on my host became a mess and it is somewhat related to my naming conventions.

I like to name my interfaces with easy (at least to me) to understand names. For example, my local interface is named “lan”. The one that my PPPoE connections are running over is “inet”. A third card going to my neighbor is called “nei”. On my desktop where I was testing XEN I only have one interface — lan.

When I start xend, the default network-bridge script is trying to set up some bridges (another option I had to recompile here), and is trying to move the configuration of my physical interface to the new bridge and rename the bridge to have the name of my interface (after renaming the interface itself of course). What happened is that udev kicked in when the new interfaces showed up as it is doing its best to keep my interfaces with consistent names. That pretty much did the mess, except that the network-bridge script itself was not really comfortable handling interfaces whose last symbol is not a digit.

My solution was the following:

Add a new network script called network-null. It does nothing. It’s empty. Use that as the network-script for xend. Then I set up my system network configuration to use a bridge with a single port. And that pretty much did the trick me.

There is also what seems to be a pretty good alternative network script for XEN. It does the XEN magic a little better, it detects the default interface well, and I would recommend it as a good default choice. It also doesn’t seem to want to rename your interfaces, but only copy the configuration over to the bridge.

Next on the to-play-with list: pass some PCI devices to the guest domains.

So, I had some time to see why XEN refused to work last time.

The first obvious problem was that I had not loaded any modules. So far, so good. I quickly loaded all back-related modules, specifically netloop, netbk, blkbk, and xenblktap. Not loading these would give weird errors about a device not being connectable. One would think that XEN can give more understandable error messages. The case is that it would give the same message if you’re missing the module and if the path to the file representing a block device is invalid. So, be careful.

Loaded the modules and “xm create” behaved much better. No errors, but it hang for a long time. I didn’t know how to interpret the output of “xm list”, so I had no clue if the guest domain was running or not. I tried “xm create -c” but it would just bail (after a 30 second wait) with a message that it cannot connect to the console. “netstat -tnlp” did not suggest that anything is listening on a 59xx port, as I was expecting. So I started digging around why an hvm XEN guest would refuse to start vnc.

I actually tried some domains from the XEN demo cd and they worked just fine. So it was something to do with hvm obviously. And it turns out it is, hvm guests need the “tun” module loaded in the host. “modprobe tun” and everything was working.

Now, the last issue I had was with the networking scripts that xen comes with. They are horrible and I’ll go over them in a second post…

I decided once again that it is time to give XEN a try. I decided to try it on a newer Athlon 64 X2 with virtualisation capabilities. That latter is important, as my overall intention is to also try OSes that are “incompatible” with XEN. I know that there are other alternatives but I’ll write on “why XEN” some other time.
Continue reading ‘Giving XEN a try’ »