[Libguestfs] virt-resize: ntfsresize: location outside device

[Richard W.M. Jones]

On Sun, Sep 12, 2010 at 02:19:11PM -0400, sean darcy wrote:
> I have a 15G qcow2 xp vm with only 1 partition:
> -rw-------. 1 root root 10514137088 Sep 12 11:10 XP.img
> 
> I want to resize it to 20G. So I :
> 
> virsh vol-create-as --format raw  windows XP-new-20G.img 20G
> Vol XP-new-20G.img created
> 
> -rw-------. 1 root root 21474836480 Sep 12 13:17 XP-new-20G.img
> 
> But:
> 
> virt-resize --expand /dev/sda1 XP.img XP-new-20G.img
> Summary of changes:
> /dev/sda1: partition will be resized from 14.6G to 20.0G
> /dev/sda1: content will be expanded using the 'ntfsresize' method
> part_add: do_part_add: parted: /dev/vdb: Error: The location 41938815s
> is outside of the device /dev/vdb. at /usr/bin/virt-resize line 1092.

I think this is a bug in virt-resize's calculations of sector
offsets.  Can you run the program with

LIBGUESTFS_DEBUG=1 virt-resize --debug [...other params...]

and post the complete, unedited output in a new bug report @
https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
Then I can take a closer look at it.

> BTW, I originally formatted the new vm as qcow2, but virt-resize
> doesn't recognize it can expand a qcow2 vm:
> 
>  virt-resize --expand /dev/sda1 XP.img XP-new-20G.img
> virt-resize: XP-new-20G.img: file is too small to be a disk image (262144 bytes)

This is also a (different) bug.  For some reason I thought it was a
good idea to look at the file size, rather than using
guestfs_blockdev_getsize64 API.  This bug is filed here:

https://bugzilla.redhat.com/show_bug.cgi?id=633096

> Do I use guestfs to do this?

It's actually a lot more complex than it seems to do this manually,
which I guess is why we wrote virt-resize.  You can copy the data over
easily; see the script at the end of this email.  The hard part is
that this simple-minded script puts the partitions in the wrong place
and doesn't copy over the hidden bootloader which is stuffed somewhere
between the boot sector and the first partition.  So if you try the
script, your new VM won't boot.

If you really want to do it manually you can calculate where you need
to start the first partition by running 'part-list' on the original VM
image, eg:

guestfish --ro -i XP.img <<EOF
  part-list /dev/sda
EOF

which will give you some output like:

[0] = {
  part_num: 1
  part_start: 1048576
  part_end: 105906175
  part_size: 104857600
}

and then you take the 'part_start' value, which is in bytes, divide by
512 (bytes per sector) and use it to manually create the target
partition.  So instead of 'part-disk' in the non-working script below,
you need to use, say:

  part-init /dev/sdb mbr
  part-add /dev/sdb primary 2048 -64

(which creates a partition from byte 1048576 up to 64 sectors from the
end of the disk).

You have to copy over the bootloader data, eg:

  copy-size /dev/sda /dev/sdb 1048576

*before* the part-init and part-add commands, because that trashes the
updated partition table (or you can repeat those commands).

As you can see it's a big load of hassle even for this relatively
simple case (a single partition) and just gets harder once you throw
more partitions into the mix.

Rich.

----------------------------------------------------------------------

# Non-working example script.

qemu-img create --format=qcow2 XP-new.img 20G

guestfish <<EOF

  # Add the existing image, read only, as /dev/sda.
  add-ro XP.img
  # Add the new image, writable, as /dev/sdb.
  add XP-new.img

  # Launch the appliance.
  run

  # Partition the new image, single partition over whole disk.
  part-disk /dev/sdb mbr

  # Copy the data across.
  dd /dev/sda1 /dev/sdb1

  # Resize the target.
  ntfsresize /dev/sdb1

EOF

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top