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: Kevin Wolf
Subject: Re: [Qemu-devel] Re: KVM call agenda for Oct 19
Date: Wed, 20 Oct 2010 11:18:00 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7

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.

> 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 via email to

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