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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

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.

> Also, just to make sure, this should support multiple images (concurrent snapshot of all of them or a subset).
>    

Yeah, concurrent is a little trickier.  Simple solution is for a 
management tool to just do a stop + multiple snapshots + cont.  It's 
equivalent to what we'd do if we don't do it aio which is probably how 
we'd do the first implementation.

But in the long term, I think the most elegant solution would be to 
expose the freeze api via QMP and let a management tool freeze multiple 
devices, then start taking snapshots, then unfreeze them when all 
snapshots are complete.

Regards,

Anthony Liguori

> Otherwise looks good.
>
>    
>> Regards,
>>
>> Anthony Liguori
>>
>>      
>>>    - 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.
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>