On Mon, Aug 27, 2012 at 5:12 PM, Kevin Wolf <kw...@redhat.com> wrote: > Am 27.08.2012 11:04, schrieb Stefan Hajnoczi: >> On Sun, Aug 26, 2012 at 10:56 AM, Alexandre DERUMIER >> <aderum...@odiso.com> wrote: >>> It is possible to achieve the same behaviour with external snapshot ? (I >>> would like to do it online) >>> I don't see how I can rollback to the point of time of the snapshot. >> >> The snapshot only captures the contents of the disk. Rollback does >> not make sense without shutting down the guest. The OS/file system >> would be very confused if the disk contents changed underneath it. >> >> Existing hotplug can be used. For example, if we have an external >> snapshot of a virtio-blk drive, we can use hotplug to remove the >> drive, choose the snapshot file and attach it again. This only works >> for "data" drives, the root file system usually cannot be changed >> while the guest is running. >> >> You may also wish to look at libvirt for higher level snapshot primitives. >> >>> Also I see that snapshot_blkdev qmp command give in his description: >>> "Otherwise the snapshot will be internal! (currently unsupported)." >>> >>> is Live internal snapshots on the roadmap ? >> >> I'm not aware of anyone working on adding internal snapshot in the >> near future. Patches are welcome. > > I wonder why nobody mentioned the savevm/loadvm monitor commands, which > do take an internal snapshot of a running VM. They just aren't live, and > when writing out the whole VM state this matters indeed. > > However, if a disk-only snapshot is enough (this is what qemu-img > snapshot -c would produce), it would be a trivial patch to add a savevm > option to omit the VM state - and even though the snapshot is then still > not really performed in the background, it should be quick enough to be > workable.
The change to qmp-transaction or snapshot-blkdev-sync should be similarly small. I think savevm/loadvm isn't the right place to add disk-only snapshots since we already have qmp-transaction/snapshot-blkdev-sync for that. Stefan
