On Thu, Sep 01, 2011 at 02:27:55PM +0100, Daniel P. Berrange wrote: > We want to support online resize of guest disks in the libvirt API for > QEMU, and had intended to use the fairly recently added 'block_resize' > command: > > commit db97ee6a976bacbb0d18818e951cfc41b39269a7 > Author: Christoph Hellwig <h...@lst.de> > Date: Mon Jan 24 13:32:41 2011 +0100 > > block: tell drivers about an image resize > > commit 6d4a2b3a47959f02e7f307f50396e70e8464f95e > Author: Christoph Hellwig <h...@lst.de> > Date: Mon Jan 24 13:32:33 2011 +0100 > > block: add block_resize monitor command > > There is unfortunately a problem with the design of this monitor command > because it has tied the task of resizing the host backing file for the > virtual disk, together with the task of notifying the guest device of the > block resize. This means that we can only use 'block_resize' for disks > that are backed by image files (raw, qcow2, etc) that QEMU can actually > resize.
One other question too, when creating a qcow2 image via 'qemu-img create' you can specify a 'prealloc' option to require metadata to be allocated at time of creation. Should we have the same control at time of resize too. If the app had originally created the qcow2 image with preallocated metadata, then I'd expect they want to pre-allocate metadata when extending it too, or is there no additional metadata allocation required when extending an image ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
