tofu.org a big wad of tofu

I have a guest which has a 10G root disk as /dev/vda, and I would like to expand the root disk from 10G to 15G to offer more room to the /var filesystem.

The typical method would be the following:

1. shutdown the guest
2. find the backing store on the host (in this case it's a LVM logical volume)
3. copy the LV for backup (lvcreate --name LVNew --size=10G; dd if=LVOld of=LVNew;)
4. expand the LV (lvresize --size=+5G LVOld;)
5. use kpartx on the host (or start the guest) and use parted to expand the guest disk parition
6. expand the guest physical volumes (pvresize /dev/vda2), logical volumes (lvresize), and filesystems (resize2fs)

But this can be both automated and generalized with libvirt and libguestfs-tools. These tools provide a common vocabulary across many different storage back-ends such as LVM, iSCSI, file, NFS, etc. Let's see how that works.

The state of virtualization on Fedora moves fast. The following is based on a Fedora 13 host running libvirt-0.8.2-1.fc13.x86_64 and libguestfs-tools-1.6.2-1.fc13.4.x86_64.

A revolutionary new feature of Fedora 12 is "Network Interface Management" via a library called netcf. With this library as the facilitator, it becomes possible for any tool, not just NetworkManager, to reliably and methodically configure network interfaces. The original impetus for this feature was to enable tools like oVirt and libvirt to manipulate the networks on the hosts which underlie virtual machines, and that's what I'll discuss below.

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.