[libvirt] [PATCH 3/9] util: storage: Store backing chain index in virStorageSource
eblake at redhat.com
Fri Oct 13 13:36:54 UTC 2017
On 10/13/2017 12:43 AM, Peter Krempa wrote:
> On Thu, Oct 12, 2017 at 14:57:36 -0500, Eric Blake wrote:
>> On 10/12/2017 02:07 PM, Peter Krempa wrote:
>>> The backing store indexes were not bound to the storage sources in any
>>> way. To allow us to bind a given alias to a given storage source we need
>>> to save the index in virStorageSource. The backing store ids are now
>>> generated when detecting the backing chain.
>>> Since we don't re-detect the backing chain after snapshots, the
>>> numbering needs to be fixed there.
>> Is renumbering going to affect API?
>> It's the difference between starting with:
>> back <- mid <- active
>> having numbers 3, 2, 1, vs. starting with:
>> back <- mid
>> then creating active via snapshot, and now having numbers 2, 1, 3.
> In case when we will not use blockdev-add, the order will be 1,2,3
> always, since they will be in order. If blockdev add will be used it
> should be 4,1,3, so if you pop out 2 of the chain, it will never appear
>> In other words, do we try to preserve that index 1 is tied to the file
>> we opened first, no matter what order it is currently in the chain, or
>> do we state that our use of "vda" to denote a member of the chain may
>> mean different files at different points in time based on what other
>> chain manipulations have caused renumbering along the way?
> Exactly, but possible only when tracking the full chain.
>> When we were always regenerating the chain on the fly, there wasn't much
>> stability to worry about. But now that we are going to try to preserve
>> the index across domain reboots, we need to make sure we know which way
>> we want things to work.
> I don't really want to go as far as guaranteeing the numbers across
> reboots. I think keeping them across one lifetime should be good enough.
Unless anyone else has strong opinions about disk indices not always
being stable, I can live with this as your design goal. As I mentioned
in 4/9, I didn't see anything wrong with the code itself, so as long as
we don't have a problem with the design implications:
Reviewed-by: Eric Blake <eblake at redhat.com>
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 619 bytes
Desc: OpenPGP digital signature
More information about the libvir-list