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

Eric Blake eblake at redhat.com
Thu Oct 12 19:57:36 UTC 2017


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 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?

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.


-- 
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/20171012/73da8474/attachment-0001.sig>


More information about the libvir-list mailing list