tofu.org a big wad of tofu

How to manually migrate a virtual machine from one host to another. The process is roughly: copy the guest config to the destination, create LVs on the destination, dd the LVs across ssh, instantiate and start the guest on the destination.

As I described in a previous post, I dedicate an LV in the host for each guest. The guest then uses LVM to manage the space. In this case the guest is contained in two logical volumes on the host.

I've been writing the Fedora Weekly News Virtualization Beat for several weeks now, and I've recently volunteered to work on the portion of Fedora 10 release notes which cover virtualization features.

I had some trouble removing an dom0 LV used as a domU VG after mounting it to look inside that VG (for background on this setup, see this post). I wasn't sure what steps I had taken, so I decided to reboot the dom0 to clear the decks and did the following experiment.

The goal was to create an LV and stack upon that a VG containing an LV and then remove these devices to get back where we started. And maybe to learn something along the way.

I currently run a Fedora 8 dom0 with Fedora 9 domU's primarily. I'm working on exactly how I wish to configure the disk layout, but here is how to configure each domU on it's own logical volume, configure further logical volumes within that domU, and how to access those logical volumes from the host dom0.

Starting with Fedora 7 if you use Xen you will notice a new subnet and a
bridge automagically being created by libvirt. This is great for desktop experimenting, but if you are running this on a server you probably have an opinion on how your network should be configured.

Here's how to revert to manually controlled network settings.

A Fedora 7 dom0 I have crashes with null pointer dereferences in tcp_tso_segment. After upgrading to F8 this is still happening. This seems to stem from traffic shaping in a busy domU fedora mirror server. Poking around it looks like this bug http://lists.openwall.net/netdev/2007/02/09/16 Well, they fixed that by twiddling net/ipv4/netfilter/ipt_REJECT.c but I think something in my Xen enviro with a combination of a busy bridge and traffic control rules is still tripping up on net/ipv4/tcp.c line 2241 "skb = skb->next;" from what I can decypher.