[libvirt] [PATCH 3/9] util: storage: Store backing chain index in virStorageSource

[Eric Blake]

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
> back.
> 
>>
>> 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[1]" 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...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171013/82faa4b4/attachment-0001.sig>