HowTo: Resize (expand) QEMU qcow/qcow2/raw disk images

[IntuitiveNipple]

This article explains how to reliably enlarge a QEMU qcow or raw image that contains an NTFS or FAT32 bootable partition.

Like a lot of other people I needed to increase the size of a QCOW disk image to 10GB from the original maximum size of 5GB, I searched all over and could only find three web pages that described methods of doing it, each of which was imperfect and not totally reliable. There were tens of pages discussing how it is impossible.

My scenario is QEMU 0.9 running on Ubuntu 7.04 Feisty (kernel 2.6.20-16) with Windows XP in a 5GB qcow disk image.

After trying the various suggestions for how to resize the image I always got the dreaded:

Code: Select all

A disk read error occurred
Press Ctrl+Alt+Del to restart

I read of a suggestion by fabrice that it was to do with "CHS translation" but no one seemed to have taken it further.

If you just want the solution rather than reading the technical details skip to "How to enlarge a QEMU qcow or raw image that contains an NTFS bootable partition" further down.

Discovering why it fails

First I converted the qcow image to raw:

Code: Select all

$ qemu-img convert -f qcow hda.qcow -O raw hda.raw

We are going to require super-user (root) privileges for most of the following operations so lets switch to super-user:

Code: Select all

$ sudo su
Password:
root $

Using the loopback device in Linux I attached the raw image:

Code: Select all

$ losetup /dev/loop1 hda.raw

Then I inspected the Master Boot Record (MBR) using fdisk:

Code: Select all

$ fdisk -u /dev/loop1

Command (m for help): p

Disk /dev/loop1: 4194 MB, 4194816000 bytes
128 heads, 63 sectors/track, 1015 cylinders, total 8193000 sectors
Units = sectors of 1 * 512 = 512 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/loop1p1   *          63     8176895     4088416+   7  HPFS/NTFS

Command (m for help): q   


Notice that fdisk reports the disk has 128 (0x80) heads.

Now lets examine the NTFS partition's boot sector. To do this we need to detach the 'physical' disk:

Code: Select all

$ losetup -d /dev/loop1

and attach the 'logical' disk contained in partition 1. This starts at sector offset 63 (0x3F) according to fdisk, which is 32256 bytes (63 x 512) into the image file:

Code: Select all

$ losetup -o32256 /dev/loop1 hda.raw

Just to prove this is an NTFS partition we have attached lets check it:

Code: Select all

$ ntfsresize -i /dev/loop1
ntfsresize v1.13.1 (libntfs 9:0:0)
Device name        : /dev/loop1
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 4186538496 bytes (4187 MB)
Current device size: 4194783744 bytes (4195 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use       : 3265 MB (78.0%)
Collecting resizing constraints ...
You might resize at 3264757760 bytes or 3265 MB (freeing 922 MB).
Please make a test run using both the -n and -s options before real resizing!


Now let's examine the BIOS Parameter Block (BPB) of the partition's boot sector:

Code: Select all

$ dd if=/dev/loop1 of=bootsector.bin bs=512 count=1
$ losetup -d /dev/loop1

I use hexdump to examine the data statically:

Code: Select all

$ hexdump -C bootsector.bin

The BPB bytes we are interested in are the ones describing the geometry of the drive:

Code: Select all

Offset        Purpose
0x18           Sectors per track
0x1A           Heads (tracks per cylinder)


So here is the fragment that shows these:

Code: Select all

00000000  eb 52 90 4e 54 46 53 20  20 20 20 00 02 08 00 00  |.R.NTFS    .....|
00000010  00 00 00 00 00 f8 00 00  3f 00 80 00 3f 00 00 00  |........?...?...|


You can see at offset 0x18 "3f 00" (63) and at 0x1A "80 00" (128).

When a disk image is resized by a considerable margin the number of heads reported for the entire disk image is likely to increase, but QEMU doesn't know the embedded Operating System (in this case Windows XP) has stored the disk geometry in its BPB.

As a result when the QEMU BIOS tries to load the OS it gets the correct disk geometry from the MBR but when the MBR passed execution to the boot sector code in the partition, the BPB causes the boot-code to get confused and the system fails to boot.

So the solution is to edit the single byte in the BPB that describes the number of heads (offset 0x1A) so it matches whatever fdisk reports.

How to enlarge a QEMU qcow or raw image that contains an NTFS bootable partition

Make sure you have plenty of disk space for the following operations. Adjust paths to point to alternative disks that have space if necessary.

Note: If you are pressed for disk space or don't want to wait a long time when the file-system is copied from the original image to the new image, read the next post in this thread for how you can enlarge the original file directly. It is more dangerous since it is changing your only copy of the original.

Convert the compressed qcow image to raw:

Code: Select all

$ qemu-img convert -f qcow hda.qcow -O raw hda.raw

Most of the commands will require super-user privileges so switch now to save using sudo for every command:

Code: Select all

$ sudo su

Create the new raw disk image. If you are working on ext2 or ext3 this will create a sparse image (disk space won't actually be used until non-zero data is written to the file). The value after seek= is the size of the new disk in sectors. In this case 20971520 x 512 = 10GB:

Code: Select all

$ dd if=/dev/zero of=hdb.raw bs=512 count=0 seek=20971520
$ ls -l hdb.raw
-rw-r--r-- 1 root root 10737418240 2007-06-14 15:14 hdb.raw

Attach the new drive:

Code: Select all

$ losetup /dev/loop0 hdb.raw

Use fdisk to create the new, larger, NTFS partition table entry:

Code: Select all

$ fdisk -u /dev/loop0
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help):

Create a new partition (press n p 1 <enter> <enter> ):

Code: Select all

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (63-20971519, default 63):
Using default value 63
Last sector or +size or +sizeM or +sizeK (63-20971519, default 20971519):
Using default value 20971519

Set the partition type to NTFS (press t 7):

Code: Select all

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 7
Changed system type of partition 1 to 7 (HPFS/NTFS)

Set the partition to be bootable aka active (press a 1):

Code: Select all

Command (m for help): a
Partition number (1-4): 1

Display aka print the new configuration (press p):

Code: Select all

Command (m for help): p

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63    20971519    10485728+   7  HPFS/NTFS

Notice the number of heads is 255? This is the value we will have to patch into the NTFS BPB in the partition boot sector later.

Now write the changes to the disk (press w):

Code: Select all

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 22: Invalid argument.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

We now have a bootable disk image with a partition table, but no Operating System to boot.

Detach the disk image:

Code: Select all

$ losetup -d /dev/loop0

Re-attach the image so the Linux kernel will read the new partition table, and then check it with fdisk:

Code: Select all

$ losetup /dev/loop0 hdb.raw
$  fdisk -ul /dev/loop0

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63    20971519    10485728+   7  HPFS/NTFS

Copy just the MBR boot-code into the new disk's MBR:

Code: Select all

$ dd if=hda.raw of=/dev/loop0 bs=1 count=446

This is the code the BIOS boot-loader executes when the system boots from this disk device. It is also what a Windows/DOS fdisk /mbr installs.

Now copy the NTFS partition from the original image into the new image. Remember, the file-system partitions start at sector offset 63 according to fdisk for both images:

Code: Select all

$ dd if=hda.raw of=/dev/loop0 bs=512 skip=63 seek=63

Detach the disk image:

Code: Select all

$ losetup -d /dev/loop0

Attach just the file-system partition. It starts at sector 63, which is offset 63 x 512 = 32256:

Code: Select all

$ losetup -o32256 /dev/loop0 hdb.raw

Confirm it is a valid NTFS partition:

Code: Select all

$ ntfsresize -i /dev/loop0
ntfsresize v1.13.1 (libntfs 9:0:0)
Device name        : /dev/loop0
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 4186538496 bytes (4187 MB)
Current device size: 10737385984 bytes (10738 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use       : 3265 MB (78.0%)
Collecting resizing constraints ...
You might resize at 3264757760 bytes or 3265 MB (freeing 922 MB).
Please make a test run using both the -n and -s options before real resizing!

Now it is time to edit the NTFS BPB. I use the tool hexedit which you may need to install:

Code: Select all

$ apt-get install hexedit

Load the new disk image into hexedit:

Code: Select all

$ hexedit hdb.raw

Skip to sector 63, which is offset 0x7E00 (press <Enter> 7E00 <Enter>):

Code: Select all

00007E00   EB 52 90 4E  54 46 53 20  20 20 20 00  02 08 00 00  .R.NTFS    .....
00007E10   00 00 00 00  00 F8 00 00  3F 00 80 00  3F 00 00 00  ........?...?...


Move the cursor to the BPB's offset 0x1A, which is 0x7E00 + 0x1A = 0x7E1A here.

You can now over-type the hex-value 80 (128) with the correct number of heads, which in this case is FF (255):

Code: Select all

00007E10   00 00 00 00  00 F8 00 00  3F 00 FF 00  3F 00 00 00  ........?...?...

Save the change by pressing Ctrl-X and then 'y' to confirm the write.

The image is now ready for QEMU.

Code: Select all

$ qemu -boot c -snapshot -m 512 -hda 'hdb.raw' -net nic,vlan=0 -net user,vlan=0 -localtime -soundhw es1370 -kernel-kqemu

If that boots successfully we can now resize the NTFS file-system:

Code: Select all

$ ntfsresize /dev/loop0
ntfsresize v1.13.1 (libntfs 9:0:0)
Device name        : /dev/loop0
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 4186538496 bytes (4187 MB)
Current device size: 10737385984 bytes (10738 MB)
New volume size    : 10737381888 bytes (10738 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use       : 3263 MB (77.9%)
Collecting resizing constraints ...
WARNING: Every sanity check passed and only the dangerous operations left.
Make sure that important data has been backed up! Power outage or computer
crash may result major data loss!
Are you sure you want to proceed (y/[n])? y
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device '/dev/loop0'.

If you get the error:

Code: Select all

$ ntfsresize /dev/loop0
ntfsresize v1.13.1 (libntfs 9:0:0)
ERROR(95): Opening '/dev/loop0' as NTFS failed: Operation not supported
The NTFS journal file is unclean. Please shutdown Windows properly before
using this software! Note, if you have run chkdsk previously then boot
Windows again which will automatically initialize the journal correctly.

you should do a complete startup/shutdown sequence of Windows so the disk is marked clean:

Code: Select all

$ losetup -d /dev/loop0
$ qemu -boot c -m 512 -hda 'hdb.raw' -net nic,vlan=0 -net user,vlan=0 -localtime -soundhw es1370 -kernel-kqemu

All that is left to do is detach it:

Code: Select all

$ losetup -d /dev/loop0

and convert the raw image back to a compressed qcow image. I usually explicitly make it qcow2, the later version:

Code: Select all

$ qemu-img convert -f raw hdb.raw -O qcow2 hdb.qcow2

Make sure the qcow image boots:

Code: Select all

$ qemu -boot c -snapshot -m 512 -hda 'hdb.qcow2' -net nic,vlan=0 -net user,vlan=0 -localtime -soundhw es1370 -kernel-kqemu

Delete the large raw images and the original qcow image:

Code: Select all

$ rm hdb.raw hda.raw hda.qcow

The final step is to set the owner to your regular user, because the file was created as root, and exit super-user:

Code: Select all

$ chown <username>:<username> hdb.qcow2
$ exit

I hope this helps - it took a while to perfect the process

[IntuitiveNipple]

How to enlarge a QEMU qcow or raw image that contains an NTFS bootable partition without using twice the disk space

This method is an alternative to the one described in the previous post. It is intended for more confident users, where you are pressed for disk space or don't want to wait a long time when the file-system is copied from the original image to the new image. It is more dangerous since it is changing your only copy of the original.

Convert the compressed qcow image to raw:

Code: Select all

$ qemu-img convert -f qcow hda.qcow -O raw hda.raw

Most of the commands will require super-user privileges so switch now to save using sudo for every command:

Code: Select all

$ sudo su

Enlarge the existing raw disk image. If you are working on ext2 or ext3 this will create a sparse image (disk space won't actually be used until non-zero data is written to the file). The value after seek= is the size of the new disk in sectors. In this case 20971520 x 512 = 10GB:

Code: Select all

$ dd if=/dev/zero of=hda.raw bs=512 count=0 seek=20971520
$ ls -l hda.raw
-rw-r--r-- 1 root root 10737418240 2007-06-18 12:10 hda.raw

Attach the enlarged drive image:

Code: Select all

$ losetup /dev/loop0 hda.raw

Use fdisk to check how many heads the disk is using:

Code: Select all

$ fdisk -ul /dev/loop0

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/loop1p1   *          63     8176895     4088416+   7  HPFS/NTFS

Notice the number of heads is 255? This is the value we will have to patch into the NTFS BPB in the partition boot sector later.

Detach the drive image:

Code: Select all

$ losetup -d /dev/loop0

Attach just the file-system partition. It starts at sector 63, which is offset 63 x 512 = 32256:

Code: Select all

$ losetup -o32256 /dev/loop0 hda.raw

Confirm it is a valid NTFS partition:

Code: Select all

$ ntfsresize -i /dev/loop0
ntfsresize v1.13.1 (libntfs 9:0:0)
Device name        : /dev/loop0
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 4186538496 bytes (4187 MB)
Current device size: 10737385984 bytes (10738 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use       : 3265 MB (78.0%)
Collecting resizing constraints ...
You might resize at 3264757760 bytes or 3265 MB (freeing 922 MB).
Please make a test run using both the -n and -s options before real resizing!

Now it is time to edit the NTFS BPB. I use the tool hexedit which you may need to install:

Code: Select all

$ apt-get install hexedit

Load the new disk image into hexedit:

Code: Select all

$ hexedit hda.raw

Skip to sector 63, which is offset 0x7E00 (press <Enter> 7E00 <Enter>):

Code: Select all

00007E00   EB 52 90 4E  54 46 53 20  20 20 20 00  02 08 00 00  .R.NTFS    .....
00007E10   00 00 00 00  00 F8 00 00  3F 00 80 00  3F 00 00 00  ........?...?...


Move the cursor to the BPB's offset 0x1A, which is 0x7E00 + 0x1A = 0x7E1A here.

You can now over-type the hex-value 80 (128) with the correct number of heads, which in this case is FF (255):

Code: Select all

00007E10   00 00 00 00  00 F8 00 00  3F 00 FF 00  3F 00 00 00  ........?...?...

Save the change by pressing Ctrl-X and then 'y' to confirm the write.

Detach the drive image:

Code: Select all

$ losetup -d /dev/loop0

The image is now ready for QEMU.

Code: Select all

$ qemu -boot c -snapshot -m 512 -hda 'hda.raw' -net nic,vlan=0 -net user,vlan=0 -localtime -soundhw es1370 -kernel-kqemu

If that boots successfully we can now resize the NTFS file-system:

Attach the file-system image:

Code: Select all

$ losetup -o32256 /dev/loop0 hda.raw

Resize to fill the drive-image:

Code: Select all

$ ntfsresize /dev/loop0
ntfsresize v1.13.1 (libntfs 9:0:0)
Device name        : /dev/loop0
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 4186538496 bytes (4187 MB)
Current device size: 10737385984 bytes (10738 MB)
New volume size    : 10737381888 bytes (10738 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use       : 3263 MB (77.9%)
Collecting resizing constraints ...
WARNING: Every sanity check passed and only the dangerous operations left.
Make sure that important data has been backed up! Power outage or computer
crash may result major data loss!
Are you sure you want to proceed (y/[n])? y
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device '/dev/loop0'.

If you get the error:

Code: Select all

$ ntfsresize /dev/loop0
ntfsresize v1.13.1 (libntfs 9:0:0)
ERROR(95): Opening '/dev/loop0' as NTFS failed: Operation not supported
The NTFS journal file is unclean. Please shutdown Windows properly before
using this software! Note, if you have run chkdsk previously then boot
Windows again which will automatically initialize the journal correctly.

you should do a complete startup/shutdown sequence of Windows so the disk is marked clean:

Code: Select all

$ losetup -d /dev/loop0
$ qemu -boot c -m 512 -hda 'hda.raw' -net nic,vlan=0 -net user,vlan=0 -localtime -soundhw es1370 -kernel-kqemu

All that is left to do is detach it:

Code: Select all

$ losetup -d /dev/loop0

and convert the raw image back to a compressed qcow image. I usually explicitly make it qcow2, the later version:

Code: Select all

$ qemu-img convert -f raw hda.raw -O qcow2 hda.qcow2

Make sure the qcow image boots:

Code: Select all

$ qemu -boot c -snapshot -m 512 -hda 'hda.qcow2' -net nic,vlan=0 -net user,vlan=0 -localtime -soundhw es1370 -kernel-kqemu

Delete the large raw image and the original qcow image:

Code: Select all

$ rm hda.raw hda.qcow

The final step is to set the owner to your regular user, because the file was created as root, and exit super-user:

Code: Select all

$ chown <username>:<username> hda.qcow2
$ exit

[vf.valent]

Fantastic post. Thanks IntuitiveNipple.

[xucaen]

Wow, great tutorial! But it made me realize I should just start over with a new disk image. I'll never be able to follow all of that!

Jim

[CapJo]

Thank you for this very helpful tutorial!

I followed the instructions in

"How to enlarge a QEMU qcow or raw image that contains an NTFS bootable partition without using twice the disk space"

and noticed that my fdisk shows on my pc a wrong number of heads. It shows 128 heads instead of 255 like in your example. Windows will only boot if (BPB) is set to 255 heads.

What is the reason for the different behavior of fdisk?

Code: Select all

# fdisk -v
fdisk (util-linux 2.13-pre7)

# fdisk -ul /dev/loop0

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
128 heads, 63 sectors/track, 2600 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63     4185215     2092576+   7  HPFS/NTFS

sfdisk shows the correct number of heads

Code: Select all

# sfdisk -l /dev/loop0
Disk /dev/loop0: cannot get geometry

Disk /dev/loop0: 1305 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
  for C/H/S=*/128/63 (instead of 1305/255/63).
For this listing I'll assume that geometry.
Units = cylinders of 4128768 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/loop0p1   *      0+    518     519-   2092576+   7  HPFS/NTFS
/dev/loop0p2          0       -       0          0    0  Empty
/dev/loop0p3          0       -       0          0    0  Empty
/dev/loop0p4          0       -       0          0    0  Empty


I'm using fedora 7 with a XEN kernel.

Code: Select all

# uname -a
Linux localhost.localdomain 2.6.20-2936.fc7xen #1 SMP Fri Sep 21 12:07:35 EDT 2007 i686 i686 i386 GNU/Linux

[dan_b]

Thanks, that was really useful.

Couple of notes:
1) I had not quite the same problem: although the number of heads matched in MBR and BPB, the NT bootloader still refused to recognise it until I set it to 255 (this was a 40GB image resized from 2GB). gparted and fdisk both wanted to use 64 heads, I had to use sfdisk to get the right layout

Try sfdisk -l -uS /dev/loop0 to read the existing table, then sfdisk -f -uS -H255 /dev/loop0 to recreate it. -uS says to measure the layout in sectors instead of cylinders, so you can be sure your new partition starts in exactly the same place as the old one did even if the cylinder boundaries don't match

2) you can save some of the mucking around with losetup and calculating offsets by using kpartx

$ sudo kpartx /home/dan/xp.raw -av
add map loop0p1 (254:1): 0 83875302 linear /dev/loop0 63

and now you have the whole disk on /dev/loop0 and the partitions under /dev/mapper/loop0p1,/dev/mapper/loop0p2 etc

[tenzin]

thanks, it's very helpful. cheers

[tenzin]

hi all, been googling for previous releases of kqemu, specifically versions
kqemu-1.3.0pre10.tar.gz
kqemu-1.3.0pre9.tar.gz

the one tht i hv is kqemu-1.3.0pre11.tar.gz, this module keep freezing/crashing the host system.

appreciate if anyone can mail it to me. cheers.

[jserink]

First off, great post. There is buckets of info there that would have taken weeks to figure out, outstanding.
Two tricks for new players I ran into:
1. DON'T USE KHEXEDIT to edit the 0x7e1a location in the BSB. When you save the file back it will be a different size for some reason. This took me ~3 hours to figure out. Install hexedit and follow the post above.
2. I had to instruct fdisk to use 255 heads with the -H switch else it always showed 128 heads and nothing worked.

once I did the above 2 things, everything worked.

cheers,
John

[benstokes]

Hello, thanks for posting this information in so much detail, very informative and exactly what I needed.

I followed your instructions to the letter as I was also resizing from 5Gb to 10Gb. Just thought I would let you know when I loaded up the hex editer, my value was already set to FF so I did not need to make any changes. The only difference from your setup was image was already in raw format so I skipped the convert process in step 1 - perhaps that is the reason for this?

[doxola]

I too, would like to say thanks for posting this HowTo.

I was a bit put-off by how many steps were involved to accomplish the task at hand, I must admit.

Like the OP, I wanted to resize a 5GB qcow2 HD image to something larger (10GB). However, my host OS is OSX 10.4.11 (PPC), and the guest OS is XP SP2 formatted with NTFS.

To make a long story short (and the process, as well), you can use Norton Ghost (v7.0) and Q (0.9.1d118) to get it done in a relatively short period of time--took me 7 mins.

Pretty much, I used Q to create a new qcow2 image (the size I wanted to upgrade/expand to). Then I configured the guest to boot to CD, use the original HD image, and also added the newly created qcow2 image as an extra HD. The key here is having a bootable CD that you can use to run Ghost (or, theoretically whatever disk imaging program that can perform the same function).

Once I ran Ghost, I used the disk to disk clone, making sure I chose the original HD as the source, and the new one as the destination (easy to tell because of the size reported). That took about 6 and a half minutes.

Once that was done, I exited the guest OS and changed the boot device to the new qcow2 HD. After it loads up, at some point, XP will indicate that it has found new hardware (the larger HD, I would imagine) and will need to restart. I did a restart (after I confirmed the change in HD space), and it appeared to take longer than usual. After a few minutes, I restarted the guest OS--this time I was met with the "Windows didn't start properly before" message. I told it to start normally, and all was well after that point. Now, I can backup the original qcow2 image file for safekeeping, then delete, if need be.

Actually, it has taken me more time to compose this post than it did to resize the qcow2 HD image.

Hope someone else is able to put this info to good use.

[bap]

Thanks doxola I have put the above info to good use!
I wanted to grow a 5G XP disk using FreeBSD 8 host, but did not fancy attempting to translate for nullfs.

I just replaced Ghost with clonezilla and gparted, which are both free

1. download clonezilla live iso from http://clonezilla.org/download/sourceforge/
2. download the gparted livecd from http://gparted.sourceforge.net/download.php
3. create a new larger image with qemu-img create
4. run qemu with clonezilla iso in the cdrom, hda set to the original image, hdb set to the new larger image and set to boot from d (cdrom)
5. perform a local disk to local disk clone (device to device)
6. run qemu with gparted iso in the cdrom, hda set to the new large image and boot from d
7. drag the hda1 partition all the way to the right and click apply
8. run qemu with the new image as hda, XP checkdisk may kick in and should complete succesfully, then windows loads with all the space you wanted

Simples

[shayx]

I guess we could also attach the new (big) disk image to a loopback device and run gparted on it