[libvirt] [PATCH 12/13] util: storage: Store PR manager alias in the definition

Peter Krempa pkrempa at redhat.com
Tue May 15 16:00:23 UTC 2018


On Mon, May 14, 2018 at 18:03:00 -0400, John Ferlan wrote:
> 
> 
> On 05/14/2018 11:19 AM, Michal Privoznik wrote:
> > On 05/14/2018 12:45 PM, Peter Krempa wrote:
> >> Rather than always re-generating the alias store it in the definition
> >> and in the status XML.
> >>
> >> Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> >> ---
> >>  src/qemu/qemu_command.c                   | 23 +++------------------
> >>  src/qemu/qemu_command.h                   |  3 +--
> >>  src/qemu/qemu_domain.c                    | 16 +++++++++++++--
> >>  src/qemu/qemu_hotplug.c                   | 34 ++++++++++---------------------
> >>  src/util/virstoragefile.c                 |  1 +
> >>  src/util/virstoragefile.h                 |  3 +++
> >>  tests/qemustatusxml2xmldata/modern-in.xml |  4 ++++
> >>  7 files changed, 37 insertions(+), 47 deletions(-)
> > 
> > Yes, this makes sense to me. I've kept alias in status XML for all the
> > versions until the very last one. You have my ACK, but since John was
> > opposed maybe we should ask for his opinion too (so that we don't go
> > behind his back).
> > 
> 
> I still see no purpose for an alias to be saved since it's static, but I
> seem to be alone in that thinking. Just as much as I was alone in the
> thinking that qemuDomainGetManagedPRAlias is unnecessary and that a
> constant static string would work just the same. I'm also not convinced
> that a non managed system should be supported, but I recall Michal
> noting something during one of the reviews that it was useful for some
> future work.

The point of storing the aliases in the XML is that it records the state
as we've used when we've created the object in qemu. If we will need to
change the naming scheme for some reason we'd require to add a lot of
code which will use the old/new alias depending on which would be
originally used. By storing it into the status XML you are relieved of
all this by just using what was used before.

The future work referenced by Michal is the blockdev work, where the
hot-remove code paths for disks will need to use the correct alias for
the individual layer of the backing chain rather than the disk.

I'll need to tweak this for the Authentication/encryption/TLS secrets as
well, since they can't all share the same alias even when they
correspond to the same disk.

> Shouldn't at the very least the formatting of the path and alias only
> occur for !(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)... Would mean
> passing @flags to virStoragePRDefFormat.  At the very least it'll make
> it obvious about it's only being formatted for the active/status guest.

The alias is formatted in the <privateData> section of the
virStorageSource which is only formatted when the XML is active. That is
handled by the global storage source private data formatter.
-------------- 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/20180515/cfd572aa/attachment-0001.sig>


More information about the libvir-list mailing list