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

Alexandre DERUMIER aderumier at odiso.com
Tue Aug 28 10:22:34 CEST 2012


> 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. 

I found a old patch RFC from 2010 for savevm to omit the vmstate
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg00655.html

>>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. 

But indeed, qmp-transaction/snapshot-blkdev-sync seem to be better place.



----- Mail original ----- 

De: "Stefan Hajnoczi" <stefanha at gmail.com> 
À: "Kevin Wolf" <kwolf at redhat.com> 
Cc: "Alexandre DERUMIER" <aderumier at odiso.com>, "Paolo Bonzini" <pbonzini at redhat.com>, "Jeff Cody" <jcody at redhat.com>, "Eric Blake" <eblake at redhat.com>, "qemu-devel" <qemu-devel at nongnu.org> 
Envoyé: Mardi 28 Août 2012 10:11:18 
Objet: Re: [Qemu-devel] qcow2: online snasphots : internal vs external ? 

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



-- 

-- 



	

Alexandre D e rumier 

Ingénieur Systèmes et Réseaux 


Fixe : 03 20 68 88 85 

Fax : 03 20 68 90 88 


45 Bvd du Général Leclerc 59100 Roubaix 
12 rue Marivaux 75002 Paris 


More information about the pve-devel mailing list