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

Peter Krempa pkrempa at redhat.com
Fri Oct 13 05:43:16 UTC 2017


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
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171013/94a405ec/attachment-0001.sig>


More information about the libvir-list mailing list