qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?
Date: Tue, 28 Aug 2012 09:11:18 +0100

On Mon, Aug 27, 2012 at 5:12 PM, Kevin Wolf <address@hidden> wrote:
> Am 27.08.2012 11:04, schrieb Stefan Hajnoczi:
>> On Sun, Aug 26, 2012 at 10:56 AM, Alexandre DERUMIER
>> <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]