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

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.