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

[Anthony Liguori <anthony@codemonkey.ws>]

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

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
>