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:
[code] xe vm-disk-resize vm-name=Test disk-name=xvda disk-size=11000[/code]
Now of all, get the right UUIDs from XE:
[code]
# 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/
LV-184bea51-9733-43b0-af02-fa6493235218.xvda]
Shareable: [0]
Virtsize: [11000 MB]
Parent UUID: [1ae909da-1302-45]
State: [0]
Type: [0]
[/code]
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:
[code]
# 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
[/code]
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:
[code]
# losetup /dev/loop99 -o $((63 * 512)) /dev/path/to/xvda
[/code]
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:
[code]
# 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
[/code]
The partition xvda1 is still only 5GB in size however. So, you’ll need to resize the partition using parted
[code]# 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
[/code]
And now, we finally run another fsck and then run resize2fs before tearing down the block device mapping
[code]
# 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
[/code]
Now you can restart the domU, login and check your disk space:
[code]
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 11084028 448004 10636024 5% /
[/code]
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.