Hey
I had the same problem some time ago. But here is a solution how to do that,
but it's a bit tricky!
REQUIREMENT: THE SYSTEM PARTITION ON THE IMAGE MUST BE THE FIRST PARTITION,
AFTER THAT THERE MUST BE ONLY SWAP PARTITIONS!!!!
This setup would work, there should be no risk at all:
Partition 1 on the image: /
Partition 2 on the image: swap space
This setup WONT'T WORK, YOU LOOSE YOUR DATA:
Partition 1 on the image: /
Partition 2 on the image: swap
Partition 3 on the image: /var or /somethingelse
So what you have to do:
a) create a backup of the diskimage that you want to modify
b) shutdown domU
c) add extra space to the image by entering: dd if=/dev/zero bs=1M count=1024
>> /path/to/diskimage (this would add another 1024M to the DomU image)
d) boot domU
e) disable swap partitions by entering: swapoff /dev/xvda2 (or what corresponds
to your setup)
f) fdisk /dev/xvda (or what corresponds to your setup)
g) press p + enter so see the whole disksetup
h) delete the second swap partition by entering d + enter and then 2 + enter
i) delete the system partion by entering d + enter and then 1+enter
j) recreate the system partition with the same start cylinder than the older
one but an end-cylinder bigger than the old cylinder value. press n <enter> p
<enter> 1 <enter> and then enter the values
k) recreate the swap partition (with n <enter> p <enter> 2 <enter> and
appropriate values
l) chance the partition type of partition 2 to swap by pressing: t <enter> 2
<enter> 82 <enter>
m) exit fdisk by pressing w <enter>
n) execute: mkswap /dev/xvda2 to make the swap space ready
o) reboot domU
p) execute: resize2fs /dev/xvda1
q) report to the list if it worked
this procedure worked fine for me, i hope i didn't forget anything. it only
works to increase disk space, it doesnt work if you want to use less disk
space, since the end cylinder of the fs must be greater than beforehand.
greets,
yours fvh
----- Ursprüngliche Mail ----
Von: Henrik Holmboe <henrik@xxxxxxxxxx>
An: xen-users@xxxxxxxxxxxxxxxxxxx
Gesendet: Mittwoch, den 1. Oktober 2008, 00:54:08 Uhr
Betreff: [Xen-users] Increase size of file-based diskimage (with MBR,
partitions + fs)
Hello all,
I have been struggling with a problem for some time and haven't quite
found a working solution.. Tried to search the mailing list and other
online resources but still got stuck.
What I have: a diskimage stored in the fs on dom0. The image is not
just a filesystem, but contains a full disk presented to the domU.. Thus
it contains an MBR, partition table and a single ext3 filesystem. No
LVM is not used in the domU. Both dom0 and domU is Centos 5.2.
What I want to accomplish: increase the size of this diskimage, resize
the partition and filesystem.
Some basic facts and proof of valid diskimage from dom0:
# Partition table
> sfdisk -l xvda.img
[...]
Disk xvda.img: 195 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
xvda.img1 * 0+ 194 195- 1566306 83 Linux
[...]
# Verify partition table
> losetup /dev/loop15 xvda.img
> sfdisk -V /dev/loop15
/dev/loop15: OK
> losetup -d /dev/loop15
# Verify filesystem
> losetup /dev/loop16 -o `expr 63 \* 512` xvda.img
> e2fsck -f /dev/loop16
e2fsck 1.39 (29-May-2006)
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
/: 32573/391680 files (2.8% non-contiguous), 265879/391576 blocks
> losetup -d /dev/loop16
I can boot this image correctly using pygrub. The configuration is
simple (xvda is the fs, xvdb is the swap):
# /etc/xen/test.cfg
name = "test"
memory = 256
disk = [ 'tap:aio:/var/lib/xen/images/test/xvda.img,xvda,w',
'tap:aio:/var/lib/xen/images/test/xvdb.img,xvdb,w', ]
vif = [ 'mac=00:16:3E:4B:79:7B,bridge=xenbr1', ]
bootloader = "/usr/bin/pygrub"
vcpus = 1
on_reboot = 'restart'
on_crash = 'restart'
Ok, so now on to what I have tried and failed (with a known good image
as verified above):
# Extend the size of diskimage from 1.5GB to 3GB
> ls -la xvda.img
-rw-r--r-- 1 root root 1610612736 Oct 1 00:16 xvda.img
> dd if=/dev/zero of=xvda.img bs=1 count=1 seek=3G conv=notrunc
1+0 records in
1+0 records out
1 byte (1 B) copied, 0.00506 seconds, 0.2 kB/s
> ls -la xvda.img
-rw-r--r-- 1 root root 3221225473 Oct 1 00:25 xvda.img
# Now rewrite the partition table to span the entire disk, also
# make sure that the partition is still bootable
> sfdisk -q --no-reread xvda.img << EOF
,,,*
EOF
> sfdisk -l xvda.img
Disk xvda.img: 391 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
xvda.img1 * 0+ 390 391- 3140707 83 Linux
# Resize the filesystem to span the entire partition, also verify the
# filesystem
> losetup /dev/loop16 -o `expr 63 \* 512` xvda.img
> e2fsck -f /dev/loop16
[...passed]
> resize2fs /dev/loop16
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/loop16 to 786424 (4k) blocks.
The filesystem on /dev/loop16 is now 786424 blocks long.
> e2fsck -f /dev/loop16
[...passed]
> sfdisk -V xvda.img
xvda.img: OK
So far so good! I can mount the filesystem and verify it to be 3GB. Now
on to trying to boot the domU again:
> xm create -c hc24.cfg
Using config file "./test.cfg".
Traceback (most recent call last):
File "/usr/bin/pygrub", line 651, in ?
fs = fsimage.open(file, get_fs_offset(file))
IOError: [Errno 95] Operation not supported
No handlers could be found for logger "xend"
Error: Boot loader didn't return any data!
If I understand this correctly the diskimage does not contain a valid
MBR that satisfies pygrub. I have tried two things to solve this:
TEST1
# Try to copy the MBR from backup to the new diskimage
> dd if=oldxvda.img of=xvda.img count=1 bs=446 conv=notrunc
As I understand it the first 446 bytes contain the MBR, while the first
512 bytes would also copy the old partition table. Trying to boot this
disk image gives the same error message as before.
TEST2
# Try to create a new MBR on the disk, but for whatever reason GRUB
# cannot recognize the filesystem, even though it finds the partition
# type
> losetup /dev/loop15 xvda.img
> grub --batch --device-map=/dev/null
[...]
grub> device (hd0) /dev/loop15
device (hd0) /dev/loop15
grub> root (hd0,0)
Filesystem type unknown, partition type 0x83
grub> setup (hd0)
Error 17: Cannot mount selected partition
grub> quit
> losetup -d /dev/loop15
So this fails miserably and would of course not start either.
Folks, what am I missing?
Thanks,
Henrik
PS. Thanks for reading this whole thing... ;(
--
Henrik Holmboe, Stockholm, Sweden
<http://henrik.holmboe.se/contact/>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home