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 behaviour
Definitely opt-in. Having to add a parameter to the URI forever doesn't sound great. 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