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@xxxxxxxxxx> > >> --- > >> 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.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
