On 10/19/2010 02:58 PM, Dor Laor wrote:
On 10/19/2010 02:55 PM, Avi Kivity wrote:
On 10/19/2010 02:48 PM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quintela@xxxxxxxxxx) 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 image would
be accepted?
- Integration with FS freeze for consistent guest app snapshot
Many apps do not sync their ram state to disk correctly or frequent
enough. Physical world backup software calls fs freeze on xfs and
VSS 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 directly through
virtio-serial or have a mgmt daemon use virtio-serial to
communicate with the guest in addition to QMP messages about the
live snapshot state.
Preferences? The first solution complicates qemu while the second
complicates mgmt.
Third option, make the freeze path management -> qemu -> virtio-blk ->
guest kernel -> file systems. The advantage is that it's easy to
associate file systems with a block device this way.
OTH the userspace freeze path already exist and now you create another
path.
I guess we would still have a userspace daemon; instead of talking to
virtio-serial it talks to virtio-blk. So:
management -> qemu -> virtio-blk -> guest driver -> kernel fs
resolver -> daemon -> apps
Yuck.
What about FS that span over LVM with multiple drives? IDE/SCSI?
Good points.
--
error compiling committee.c: too many arguments to function
--
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
