[libvirt] [RFC v2] external (pull) backup API

John Snow jsnow at redhat.com
Fri Apr 20 18:24:55 UTC 2018



On 04/20/2018 08:22 AM, Nikolay Shirokovskiy wrote:
> 
> 
> On 19.04.2018 20:28, John Snow wrote:
>>
>>
>> On 04/16/2018 06:20 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>
>>> So my point is: if we are going to implement something complicated,
>>> let's implement entirely what we want, not a semi-solution. Otherwise,
>>> implement a minimal and simple thing, to just make it all work (my
>>> current solution).
>>
>> So basically:
>>
>> (1) Using bitmap names: It's a hack, but it works; and
>> (2) Adding parentage information to QEMU bitmaps is also a hack, but a
>> more permanent commitment to the hack.
>>
>> And further, both (1) and (2) leave the same problem that if a third
>> party utility deletes the bitmap, they are checkpoint-unaware and will
>> ruin the metadata.
>>
>> (Though QEMU could be taught to disallow the deleting of bitmaps with
>> parents/children, unless you specify --force or --mergeleft or
>> --mergeright or some such. That's not an option with the
>> name-as-metadata strategy.)
>>
>> Why is option 3 unworkable, exactly?:
>>
>> (3) Checkpoints exist as structures only with libvirt. They are saved
>> and remembered in the XML entirely.
>>
>> Or put another way:
>>
>> Can you explain to me why it's important for libvirt to be able to
>> reconstruct checkpoint information from a qcow2 file?
>>
> 
> In short it take extra effort for metadata to be consistent when 
> libvirtd crashes occurs. See for more detailed explanation 
> in [1] starting from words "Yes it is possible".
> 
> [1] https://www.redhat.com/archives/libvir-list/2018-April/msg01001.html
> 
> Nikolay
> 

OK; I can't speak to the XML design (I'll leave that to Eric and other
libvirt engineers) but the data consistency issues make sense.

ATM I am concerned that by shifting the snapshots into bitmap names that
you still leave yourself open for data corruption if these bitmaps are
modified outside of libvirt -- these third party tools can't possibly
understand the schema that they were created under.

(Though I suppose very simply that if a bitmap is missing you'd be able
to detect that in libvirt and signal an error, but it's not very nice.)

I'll pick up discussion with Eric and Vladimir in the other portion of
this thread where we're discussing a checkpoints API and we'll pick this
up on QEMU list if need be.

Thank you,
--John




More information about the libvir-list mailing list