qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: KVM call agenda for Oct 19


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: KVM call agenda for Oct 19
Date: Wed, 20 Oct 2010 08:05:58 -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/20/2010 04:18 AM, Kevin Wolf wrote:
Am 19.10.2010 19:09, schrieb Anthony Liguori:
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 image

would

      be 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.
That would mean that you need to have both backing file and new COW
image on LVs.

Yeah, I guess there are two options. You could force a user to create the new leaf image or you could make the command take a blockdev spec excluding the backing_file and automatically insert the backing_file attribute into the spec before creating the bs.

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.
I think that depends on the terminology you use.

If you call it doing a snapshot, then probably people expect that the
snapshot is a new file and they continue to work on the same file (and
they may not understand that removing the snapshot destroys the "main"
image).

If you call it something like creating a new branch, they will expect
that the old file stays as it is and they create something new on top of
that.

So maybe we shouldn't start doing renames (which we cannot do for
anything but files anyway, consider not only LVs, but also nbd or http
backends), but rather think of a good name for the operation.

Yeah, that's a reasonable point.

Regards,

Anthony Liguori

Kevin




reply via email to

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