Monthly Archives: July 2007

Resizing domU partitions with Xen Enterprise 3.2

I recently had to resize the root partition of a sarge domU under Xen Enterprise 3.2. The various xe tools and the xen enterprise console let you resize the disk image, but they don’t resize the filesystem for you. If it’s not the root filesystem, you can resize it yourself once you reboot, but you can’t resize a mounted filesystem

There are a couple of XenSource forum posts dealing with this, but they seem to be oriented around Xen Enterprise 3.1, as they don’t work with 3.2. The basic premise is fine – find the device ID relating to the disk image on the Xen Enterprise dom0, and resize it, however the mechanics have changed.

The block devices you get access to under the XE dom0 are actually disk images, with an intact partition table. Attempting to access them directly will fail, because the standard partition resizing tools expect a partition, not a disk image. So you have to use losetup and an offset to bind that partition to a new loopback device, then you can start working on it.

It’s possible there is a much easier way to do this than below, and I’m sure it’s probably changed with the new storage manager codebase under XE 4.0, but I need to document this somewhere.

First up, shutdown the domU, then resize the xvda, either through the XE 3.2 console or via the xe command:

xe vm-disk-resize vm-name=Test disk-name=xvda disk-size=11000

Now of all, get the right UUIDs from XE:

# xe host-vm-list
NAME: Test
uuid: 184bea51-9733-43b0-af02-fa6493235218
state: DOWN

# sm info


——> VDI ID: [184bea51-9733-43b0-af02-fa6493235218.xvda]
Name: [NULL]
Descr: [DESCR]
Device: [/dev/VG_XenStorage-1ae909da-1302-45db-939b-1a2e26e78573/
Shareable: [0]
Virtsize: [11000 MB]
Parent UUID: [1ae909da-1302-45]
State: [0]
Type: [0]

The “Device” path in there gives us the appropriate device on the dom0 host. In order to keep this displaying nicely, I’m going to refer to it us /dev/path/to/xvda from now on. This is a disk image, not a partition image, which we can prove with the following command:

# fdisk /dev/path/to/xvda -ul
Disk /dev/path/to/xvda: 11.5 GB, 11534336000 bytes 255 heads, 63 sectors/track, 1402 cylinders, total 22528000 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/mapper/xvda1 63 10474379 5237158+ 83 Linux

Note that /dev/mapper/xvda1 above is probably a long string with some UUIDs embedded in it. I’ve shorted it for visibility.

This fdisk command showed us that at offset 63, there is a partition, which has 5237158 blocks (or the 5GiB partition configured by default). We can use this offset with the losetup command to bind a device node inside this disk image. I use /dev/loop99 below because I’m sure it’s not already in use. Disk sectors are 512 bytes, and this partition starts at sector 63, so we need to look at offset of 63 * 512 bytes:

# losetup /dev/loop99 -o $((63 * 512)) /dev/path/to/xvda

Done! We now have a device at /dev/loop99 that corresponds to the xvda1 partition inside the xvda block device. We can run a filesystem check on this:

# e2fsck -f /dev/loop99
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop99: 35722/655360 files (0.3% non-contiguous), 132621/1309289 blocks

The partition xvda1 is still only 5GB in size however. So, you’ll need to resize the partition using parted

# parted /dev/path/to/xvda
GNU Parted 1.6.19

Using /dev/path/to/xvda
(parted) print
Disk geometry for /dev/path/to/xvda: 0.000-11000.000 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 5114.443 primary ext3
(parted) resize
Partition number? 1
Start? [0.0308]?
End? [10997.6216]?
(parted) p
Disk geometry for /dev/path/to/xvda: 0.000-11000.000 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 10997.622 primary ext3
(parted) q

And now, we finally run another fsck and then run resize2fs before tearing down the block device mapping

# e2fsck -f /dev/loop99
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop99: 35722/1409024 files (0.3% non-contiguous), 156364/2815383 blocks
# resize2fs /dev/loop99
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/loop99 to 2815992 (4k) blocks.
The filesystem on /dev/loop99 is now 2815992 blocks long.
# losetup -d /dev/loop99

Now you can restart the domU, login and check your disk space:

# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 11084028 448004 10636024 5% /

If you boot the domU and get a fsck failure, and you run fsck and it tells you the filesystem is larger than the partition, make a note of how many blocks fsck things the filesystem should be, destroy the domU, rerun losetup and e2fsck, then run resize2fs again and specify the number of blocks fsck output. Run e2fsck again, losetup -d, then start the domU again.

Xen partially merged into linux kernel

It’s been a long time coming, but the first parts of Xen have been finally merged into upstream codebase for the linux 2.6.23 kernel.  Announcements here, here and here.  Worth reading Simon Crosby’s announcement, as it actually has some information about what is and isn’t being merged. Specifically, this is the merge of the paravirt_ops part of Xen, something that VMWare has had in the mainstream kernel for a while now, and it’s only 32 bit at this stage. From Simon’s blog:

“The effort for XenSource has been led by Jeremy Fitzhardinge, who has tirelessly tracked the developing kernel versions, while adding the Xen guest support for SMP guests, with fast paravirtualized block and network I/O. Next up is 64 bit support, according to Jeremy, who is also working on Dom0 support.”

While this isn’t a full merge of the entire Xen codebase into the kernel, it should still make it a lot easier to build xen-aware kernels.

Also merged into 2.6.23 is lguest, Rusty Russel’s linux-only paravirtualised hypervisor. I’ve been following Rusty’s blog posts on his development of this, although I was never sure of his reasoning for starting work on it. It may just have been a “lets see if I can make one” sort of approach.   Between kvm, lguest, uml and xen, there is now a lot of choice for virtualisation under the linux kernel. Not all approaches are the same – xen and lguest are paravirtualised while kvm is full virtualisation, and UML just runs a new linux kernel in user-space.  Xen and KVM will support windows (and other OS) guests, lguest and UML will only support linux guests. KVM requires VT or AMD-V chips, Xen requires them to install windows (but not linux), and lguest and UML don’t make use of them at all.

Miro – Internet TV

Miro, formerly known as Democracy TV, made its first public release a few days ago.  It’s available at Miro is like a blog aggregator for video sources such as YouTube and Google Video, as well as provider content such as various news  and science tv channels, The Onion.

Installing it was trivial under Ubuntu, although it conflicts with the blackdown JRE. You can install the sun jre instead to get around this.

make-kpkg and recent 2.6 kernels

I keep hitting a bug in make-kpkg when building recent kernels, and I always forget the fix. So, blogging it here for ease of reference

make-kpkg uses version.h to get UTS_RELEASE. UTS_RELEASE has
moved to utsrelease.h.

Right after you get the error, modify

-UTS_RELEASE_VERSION=$(shell if [ -f include/linux/version.h ]; then \
– grep ‘define UTS_RELEASE’ include/linux/version.h | \
+UTS_RELEASE_VERSION=$(shell if [ -f include/linux/utsrelease.h ]; then \
+ grep ‘define UTS_RELEASE’ include/linux/utsrelease.h | \

And rerun your make-kpkg. The above is not a valid patch, you’ll have
to hand change it.


Original post was found at