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
