Re: [libvirt] [RFC v2] external (pull) backup API
On 04/13/2018 05:47 AM, Nikolay Shirokovskiy wrote:
>> However as we use chain of disabled bitmaps with one active
bitmap on tip
>> of the chain and qemu does not track their order we need to do it in
>> libvirt.
>>
> Well, you seem to be tracking it in *qemu*, by using the name field.
> Should we not make a commitment to whether or not we store this lineage
> information in either qemu OR libvirt, but not distributed across both...?
>
I don't know actual use cases to decide. A commitment that this meta is stored
in disks like proposed can be useful IMHO so that mgmt can expect that dumb reinserting
disks to a different domain (recreated for example) keep all checkpoints.
What I am asking rather indirectly is if it would be useful to elevate
this to a *real* metadata field in QEMU so that you don't have to hack
it by using the name field,
OR
cease using the name field for this purpose and store the data entirely
within libvirt.
It sounds like you want the flexibility of the first option. I think
Vladimir had an argument against this though, I need to go back and read it.
--js