On Tue, May 12, 2026 at 07:16:07PM +0100, Richard W.M. Jones wrote:
About the patch itself, I would like to test it this week. Don't let that stop you from pushing it if you get the required approvals however. I scanned the patch and it looked fine. More below ...On Tue, May 12, 2026 at 05:47:48PM +0100, Daniel P. Berrangé via Devel wrote:On Tue, May 12, 2026 at 06:23:30PM +0200, Martin Kletzander via Devel wrote: > diff --git a/tests/vmx2xmldata/esx-in-the-wild-10.xml b/tests/vmx2xmldata/esx-in-the-wild-10.xml > index 1b1fdf06623f..3a8bb20140a1 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-10.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-10.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>w2019biosvmware</name> > - <uuid>421a6177-5aa9-abb7-5924-fc376c18a1b4</uuid> > + <uuid>501af9f2-6d29-1c76-19a9-b208ede5f374</uuid> Hmmm, seeing this indicates that this change is effectively a semantic incompatibility across the libvirt upgrade path. Any management application which is using the libvirt reported UUID for tracking / correlating will effectively see all their VMs disappear and an entirely new set appear with different UUIDs.Are there management applications which use libvirt with VMware? Red Hat has a couple of programs using libvirt to access VMware, but we only use it for converting VMs off VMware, and we don't care if the UUIDs change.This is the kind of upgrade incompatibility that libvirt promises not to impose on applications. What options do we have for mitigation ? Given that we don't have /etc/libvirt config files for stateless drivers, I feel like we need to at minimum have a URI parameter to allow the toggle of old/new UUID representations. A strict view would be for the old behaviour to be the default, but on the other hand the old behaviour violates our API semantics by not actually being unique. So that could lean me towards accepting the compat break, in order to get better API compliance, as long as we have the URI param to opt-in to the original behaviourDefinitely opt-in. Having to add a parameter to the URI forever doesn't sound great.
Yeah, and figuring out that's what everyone needs to do just so that their `virsh destroy my_temp_vm` does not kill their beloved_pet_vm would be a PITA. I'll add an opt-in to the old behaviour via a URI param to v2.
Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
signature.asc
Description: PGP signature
