|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: KVM call agenda for Oct 19 |
Date: | Tue, 19 Oct 2010 12:09:36 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 |
On 10/19/2010 11:54 AM, Ayal Baron wrote:
----- "Anthony Liguori"<address@hidden> wrote:On 10/19/2010 07:48 AM, Dor Laor wrote:On 10/19/2010 04:11 AM, Chris Wright wrote:* Juan Quintela (address@hidden) wrote:Please send in any agenda items you are interested in covering.- 0.13.X -stable handoff - 0.14 planning - threadlet work - virtfs proposals- Live snapshots - We were asked to add this feature for external qcow2 images. Will simple approach of fsync + tracking each requested backing file (it can be per vDisk) and re-open the new imagewouldbe accepted?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')All the rename logic assumes files, need to take into account devices as well (namely LVs)
Sure, just s/rename/lvrename/g.The renaming step can be optional and a management tool can take care of that. It's really just there for convenience since the user expectation is that when you give a name of a snapshot, that the snapshot is reflected in that name not that the new in-use image is that name.
Also, just to make sure, this should support multiple images (concurrent snapshot of all of them or a subset).
Yeah, concurrent is a little trickier. Simple solution is for a management tool to just do a stop + multiple snapshots + cont. It's equivalent to what we'd do if we don't do it aio which is probably how we'd do the first implementation.
But in the long term, I think the most elegant solution would be to expose the freeze api via QMP and let a management tool freeze multiple devices, then start taking snapshots, then unfreeze them when all snapshots are complete.
Regards, Anthony Liguori
Otherwise looks good.Regards, Anthony Liguori- Integration with FS freeze for consistent guest app snapshot Many apps do not sync their ram state to disk correctly orfrequentenough. Physical world backup software calls fs freeze on xfsandVSS for windows to make the backup consistent. In order to integrated this with live snapshots we need a guest agent to trigger the guest fs freeze. We can either have qemu communicate with the agent directlythroughvirtio-serial or have a mgmt daemon use virtio-serial to communicate with the guest in addition to QMP messages aboutthelive snapshot state. Preferences? The first solution complicates qemu while thesecondcomplicates mgmt. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to address@hidden More majordomo info at http://vger.kernel.org/majordomo-info.html
[Prev in Thread] | Current Thread | [Next in Thread] |