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

[Ayal Baron]

----- "Kevin Wolf" <address@hidden> 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.

That is indeed the way we work (LVs all the way) and you are correct that qemu 
should not assume this, but as Anthony said, the rename bit should be optional 
(and we would opt to go without) if at all.

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