On 10/19/2010 08:27 AM, Avi Kivity wrote:
On 10/19/2010 03:22 PM, Anthony Liguori wrote:
I had assumed that this would involve:
qemu -hda windows.img
(qemu) snapshot ide0-disk0 snap0.img
1) create snap0.img internally by doing the equivalent of `qemu-img
create -f qcow2 -b windows.img snap0.img'
2) bdrv_flush('ide0-disk0')
3) bdrv_open(snap0.img)
4) bdrv_close(windows.img)
5) rename('windows.img', 'windows.img.tmp')
6) rename('snap0.img', 'windows.img')
7) rename('windows.img.tmp', 'snap0.img')
Looks reasonable.
Would be interesting to look at this as a use case for the threading
work. We should eventually be able to create a snapshot without
stalling vcpus (stalling I/O of course allowed).
If we had another block-level command, like bdrv_aio_freeze(), that
queued all pending requests until the given callback completed, it would
be very easy to do this entirely asynchronously. For instance:
bdrv_aio_freeze(create_snapshot)
create_snapshot():
bdrv_aio_flush(done_flush)
done_flush():
bdrv_open(...)
bdrv_close(...)
...
Of course, closing a device while it's being frozen is probably a recipe
for disaster but you get the idea :-)
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
