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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux