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.
> > ---
> > src/conf/domain_conf.c | 22 +++++++++++++++-------
> > src/qemu/qemu_driver.c | 14 ++++++++++++++
> > src/storage/storage_source.c | 9 ++++++---
> > src/util/virstoragefile.c | 1 +
> > src/util/virstoragefile.h | 1 +
> > 5 files changed, 37 insertions(+), 10 deletions(-)
> >
>
> > +++ b/src/qemu/qemu_driver.c
> > @@ -14442,6 +14442,17 @@ qemuDomainSnapshotDiskDataCollect(virQEMUDriverPtr driver,
> > }
> >
> >
> > +static void
> > +qemuDomainSnapshotUpdateDiskSourcesRenumber(virStorageSourcePtr src)
> > +{
> > + virStorageSourcePtr next;
> > + unsigned int idx = 1;
> > +
> > + for (next = src->backingStore; next; next = next->backingStore)
> > + next->id = idx++;
> > +}
> > +
>
> 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.
>
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
