qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: chrisw@redhat.com, kvm@vger.kernel.org,
	Juan Quintela <quintela@redhat.com>,
	dlaor@redhat.com, qemu-devel@nongnu.org,
	Chris Wright <chrisw@sous-sol.org>,
	Ayal Baron <abaron@redhat.com>,
	"Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Re: KVM call agenda for Oct 19
Date: Wed, 20 Oct 2010 11:18:00 +0200	[thread overview]
Message-ID: <4CBEB3C8.5070601@redhat.com> (raw)
In-Reply-To: <4CBDD0D0.6050101@codemonkey.ws>

Am 19.10.2010 19:09, schrieb Anthony Liguori:
> On 10/19/2010 11:54 AM, Ayal Baron wrote:
>> ----- "Anthony Liguori"<anthony@codemonkey.ws>  wrote:
>>
>>    
>>> On 10/19/2010 07:48 AM, Dor Laor wrote:
>>>      
>>>> On 10/19/2010 04:11 AM, Chris Wright wrote:
>>>>        
>>>>> * Juan Quintela (quintela@redhat.com) 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.

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

Kevin

  reply	other threads:[~2010-10-20  9:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <314565543.45891287507100965.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
2010-10-19 16:54 ` [Qemu-devel] Re: KVM call agenda for Oct 19 Ayal Baron
2010-10-19 17:09   ` Anthony Liguori
2010-10-20  9:18     ` Kevin Wolf [this message]
2010-10-20  9:41       ` Ayal Baron
2010-10-20 13:05       ` Anthony Liguori
     [not found] <512838278.79671287521779658.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
2010-10-19 20:57 ` Ayal Baron
2010-10-19 21:19   ` Anthony Liguori
2010-10-18 15:43 [Qemu-devel] " Juan Quintela
2010-10-19  2:11 ` [Qemu-devel] " Chris Wright
2010-10-19 12:48   ` Dor Laor
2010-10-19 12:55     ` Avi Kivity
2010-10-19 12:58       ` Dor Laor
2010-10-19 13:03         ` Avi Kivity
2010-10-19 13:18           ` Anthony Liguori
2010-10-19 13:22     ` Anthony Liguori
2010-10-19 13:27       ` Avi Kivity
2010-10-19 13:33         ` Anthony Liguori
2010-10-19 13:38           ` Stefan Hajnoczi
2010-10-19 13:55             ` Avi Kivity
2010-10-19 13:28     ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CBEB3C8.5070601@redhat.com \
    --to=kwolf@redhat.com \
    --cc=abaron@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=chrisw@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=dlaor@redhat.com \
    --cc=jvrao@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).