src/esx/esx_driver.c | 8 ++++---- src/esx/esx_vi.c | 16 ++++++++++++++-- src/vmx/vmx.c | 10 +++++++--- tests/vmx2xmldata/esx-in-the-wild-10.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-11.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-12.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-13.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-14.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-15.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-16.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-17.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-5.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-6.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-7.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-8.xml | 2 +- tests/vmx2xmldata/esx-in-the-wild-9.xml | 2 +- 16 files changed, 38 insertions(+), 22 deletions(-)
From: Martin Kletzander <mkletzan@redhat.com>
The difference is that the usual UUID is supposed to be unique per host
and instanceUuid should be unique across the whole cluster. One could
think of them as HUID and CUID (as the first "U" does apparently mean
something else in the Broadcom world). That _would_ be fine for our
scenario. However, that piece of information turns out to be false as
well and the UUID we were using (`config.uuid`, or in VMX the
`uuid.bios`) can be the same in two machines on the same host.
Fortunately the `FindByUuid()` function can also search for VMs based on
their `instanceUuid`, dictated by the so far omitted third parameter.
Unfortunately that parameter is not parsed (or at least properly) before
vSphere API 4.0 (the documentation says 2.0, but we are not using that
namespace and 4.0 is the lowest we can target), which we are not
specifying in the server returns a 500 HTTP error if we use the
`instanceUuid` parameter.
So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL
requests which makes that `FindByUuid()` function work even with the
`instanceUuid` set, but without any extra labor.
After that this patch also changes all UUIDs to be parsed from the
`config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback
to the old `uuid.bios`) and adjusts tests accordingly.
Last, but not least it changes the parameter to aforementioned function
to be always true and henceforth all searching ought to be done with the
more unique ID.
Resolves: https://redhat.atlassian.net/browse/RHEL-174300
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
---
src/esx/esx_driver.c | 8 ++++----
src/esx/esx_vi.c | 16 ++++++++++++++--
src/vmx/vmx.c | 10 +++++++---
tests/vmx2xmldata/esx-in-the-wild-10.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-11.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-12.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-13.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-14.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-15.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-16.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-17.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-5.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-6.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-7.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-8.xml | 2 +-
tests/vmx2xmldata/esx-in-the-wild-9.xml | 2 +-
16 files changed, 38 insertions(+), 22 deletions(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index 010c62b8e880..7cc54af69239 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -1419,7 +1419,7 @@ esxDomainLookupByID(virConnectPtr conn, int id)
"configStatus\0"
"name\0"
"runtime.powerState\0"
- "config.uuid\0") < 0 ||
+ "config.instanceUuid\0") < 0 ||
esxVI_LookupVirtualMachineList(priv->primary, propertyNameList,
&virtualMachineList) < 0) {
goto cleanup;
@@ -1522,7 +1522,7 @@ esxDomainLookupByName(virConnectPtr conn, const char *name)
if (esxVI_String_AppendValueListToList(&propertyNameList,
"configStatus\0"
"runtime.powerState\0"
- "config.uuid\0") < 0 ||
+ "config.instanceUuid\0") < 0 ||
esxVI_LookupVirtualMachineByName(priv->primary, name, propertyNameList,
&virtualMachine,
esxVI_Occurrence_RequiredItem) < 0) {
@@ -4788,7 +4788,7 @@ esxConnectListAllDomains(virConnectPtr conn,
if (esxVI_String_AppendValueListToList(&propertyNameList,
"configStatus\0"
"name\0"
- "config.uuid\0") < 0) {
+ "config.instanceUuid\0") < 0) {
goto cleanup;
}
}
@@ -4970,7 +4970,7 @@ esxDomainHasManagedSaveImage(virDomainPtr domain, unsigned int flags)
if (esxVI_FindByUuid(priv->primary, priv->primary->datacenter->_reference,
uuid_string, esxVI_Boolean_True,
- esxVI_Boolean_Undefined,
+ esxVI_Boolean_True,
&managedObjectReference) < 0) {
return -1;
}
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c
index db006ed16f40..55d5d1478586 100644
--- a/src/esx/esx_vi.c
+++ b/src/esx/esx_vi.c
@@ -300,6 +300,17 @@ esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri *parsedUri)
curl->headers = curl_slist_append(curl->headers,
"Content-Type: text/xml; charset=UTF-8");
+ /*
+ * Testing showed that the 4.0 version is most close to our current types in
+ * esx_vi_generator.input data. We could update the version if new method
+ * parameters or object properties are needed.
+ *
+ * The other option is to drop the "/x.y" suffix completely once
+ * https://gitlab.com/libvirt/libvirt/-/work_items/878 is implemented since
+ * that will not limit the version at all.
+ */
+ curl->headers = curl_slist_append(curl->headers, "SOAPAction: urn:vim25/4.0");
+
/*
* Add an empty expect header to stop CURL from waiting for a response code
* 100 (Continue) from the server before continuing the POST operation.
@@ -2452,7 +2463,8 @@ esxVI_GetVirtualMachineIdentity(esxVI_ObjectContent *virtualMachine,
for (dynamicProperty = virtualMachine->propSet;
dynamicProperty;
dynamicProperty = dynamicProperty->_next) {
- if (STREQ(dynamicProperty->name, "config.uuid")) {
+
+ if (STREQ(dynamicProperty->name, "config.instanceUuid")) {
if (esxVI_AnyType_ExpectType(dynamicProperty->val,
esxVI_Type_String) < 0) {
goto failure;
@@ -2682,7 +2694,7 @@ esxVI_LookupVirtualMachineByUuid(esxVI_Context *ctx, const unsigned char *uuid,
virUUIDFormat(uuid, uuid_string);
if (esxVI_FindByUuid(ctx, ctx->datacenter->_reference, uuid_string,
- esxVI_Boolean_True, esxVI_Boolean_Undefined,
+ esxVI_Boolean_True, esxVI_Boolean_True,
&managedObjectReference) < 0) {
return -1;
}
diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c
index 084b4154427f..a2422c37355c 100644
--- a/src/vmx/vmx.c
+++ b/src/vmx/vmx.c
@@ -1492,9 +1492,13 @@ virVMXParseConfig(virVMXContext *ctx,
def->scsiBusMaxUnit = SCSI_SUPER_WIDE_BUS_MAX_CONT_UNIT;
}
- /* vmx:uuid.bios -> def:uuid */
- /* FIXME: Need to handle 'uuid.action = "create"' */
- if (virVMXGetConfigUUID(conf, "uuid.bios", def->uuid, true) < 0)
+ /* vmx:vc.uuid (fallback to uuid.bios) -> def:uuid */
+ if (virVMXGetConfigUUID(conf, "vc.uuid", def->uuid, true) < 0)
+ goto cleanup;
+
+ /* FIXME: Need to handle 'uuid.action = "create"' ? */
+ if (!virUUIDIsValid(def->uuid) &&
+ virVMXGetConfigUUID(conf, "uuid.bios", def->uuid, true) < 0)
goto cleanup;
/* vmx:displayName -> def:name */
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>
<genid>13c67c91-9f47-526f-b0d6-e4dd2e4bb4f9</genid>
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-11.xml b/tests/vmx2xmldata/esx-in-the-wild-11.xml
index 0dd297af43f0..6398e50c5c6c 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-11.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-11.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>esx6.7-rhel7.7-x86_64</name>
- <uuid>422c0152-63ab-cd03-9650-4301ae77aefd</uuid>
+ <uuid>502ca229-12eb-24f6-0c37-c025ff5da005</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>1</vcpu>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-12.xml b/tests/vmx2xmldata/esx-in-the-wild-12.xml
index ac83982b9b88..d505ff58d12d 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-12.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-12.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>Auto-esx8.0-rhell9.3-efi-with-empty-cdrom</name>
- <uuid>4220fca7-11dd-d67e-19cc-fcad0a37c342</uuid>
+ <uuid>5020ca5b-7ac1-5c44-cfa1-9e762e2f933b</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>1</vcpu>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-13.xml b/tests/vmx2xmldata/esx-in-the-wild-13.xml
index cef9fd4e48c9..2bea51a087eb 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-13.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-13.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>Test-Mig-VM-1 (01ce57d0-4e20-41a5-8b6c-bcbf49a032ec)</name>
- <uuid>421eb458-5448-fc12-2074-83d5e419e138</uuid>
+ <uuid>01ce57d0-4e20-41a5-8b6c-bcbf49a032ec</uuid>
<description>name:Test-Mig-VM-1
userid:962314ba515c48388a0e95c0961709ff
username:admin
diff --git a/tests/vmx2xmldata/esx-in-the-wild-14.xml b/tests/vmx2xmldata/esx-in-the-wild-14.xml
index f10707d1d412..574dd2097455 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-14.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-14.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>wild14</name>
- <uuid>421b223a-f2c1-c7c9-a399-34d2d9fde26d</uuid>
+ <uuid>501b831e-75d8-15f8-36fa-b9e225f395aa</uuid>
<description>execution env sandbox automation platform</description>
<memory unit='KiB'>33554432</memory>
<currentMemory unit='KiB'>33554432</currentMemory>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-15.xml b/tests/vmx2xmldata/esx-in-the-wild-15.xml
index 78d15e1538e6..4c753f87e2ea 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-15.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-15.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>dokuwiki</name>
- <uuid>420338bd-1c9e-ad50-99a2-59e92ddda8b6</uuid>
+ <uuid>500341d5-fe23-ac46-8cb3-77a8e5a1143d</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>2</vcpu>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-16.xml b/tests/vmx2xmldata/esx-in-the-wild-16.xml
index 51746dd77ef0..8c5bc7f43513 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-16.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-16.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>Auto-esx8.0-rhel9.4-efi-nvme-disk</name>
- <uuid>4220df89-e3a8-8513-f611-ad252bfd7047</uuid>
+ <uuid>5020196e-c5c8-7310-fcdb-d2933d0c4b2f</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>1</vcpu>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-17.xml b/tests/vmx2xmldata/esx-in-the-wild-17.xml
index 725f21bdf601..506e08fc54ec 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-17.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-17.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>esx8.0-win11-with-second-disk-in-subfolder</name>
- <uuid>42256ec1-e066-9364-3dd1-36a0b75263dd</uuid>
+ <uuid>50250f27-538b-5091-a43b-a50ce95f2382</uuid>
<genid>3191ed70-eb21-9c71-2478-373fb27fed9b</genid>
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-5.xml b/tests/vmx2xmldata/esx-in-the-wild-5.xml
index c88e60bdc070..a86119508c70 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-5.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-5.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>vmtest.local</name>
- <uuid>423e94a9-a1c7-b31d-7161-76c7586c830e</uuid>
+ <uuid>503e06db-f8d5-458e-a2fb-f9820253a7be</uuid>
<description>Centos 5.5 64bit Server</description>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-6.xml b/tests/vmx2xmldata/esx-in-the-wild-6.xml
index 805f03356129..f252304f9796 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-6.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-6.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>el6-test</name>
- <uuid>564d15d4-d062-fe9a-80f5-eb8e1a2c3afc</uuid>
+ <uuid>5200b69b-8d88-7bdf-a14a-02705d653772</uuid>
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>1</vcpu>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-7.xml b/tests/vmx2xmldata/esx-in-the-wild-7.xml
index b641574776b6..076655f37ac2 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-7.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-7.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>esx-rhel6-mini-with-scsi-device</name>
- <uuid>564d9176-621f-0239-f5ad-3a002371953b</uuid>
+ <uuid>52409533-33a2-56c5-36ce-80d605f8ecf4</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>1</vcpu>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-8.xml b/tests/vmx2xmldata/esx-in-the-wild-8.xml
index f13e6f744880..2ef609e87bdb 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-8.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-8.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>RHEL7_10_NICs</name>
- <uuid>42359420-99dc-4261-5264-ba58ddae20e4</uuid>
+ <uuid>50351de6-7d56-29ab-9d72-c7f9ea3fcfd0</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>8</vcpu>
diff --git a/tests/vmx2xmldata/esx-in-the-wild-9.xml b/tests/vmx2xmldata/esx-in-the-wild-9.xml
index 6b4d878ab18a..4fbe141f6c47 100644
--- a/tests/vmx2xmldata/esx-in-the-wild-9.xml
+++ b/tests/vmx2xmldata/esx-in-the-wild-9.xml
@@ -1,6 +1,6 @@
<domain type='vmware'>
<name>v2v-windows-kkulkarn</name>
- <uuid>42009372-17da-be73-779d-007ccf1bd228</uuid>
+ <uuid>5000d2b0-616e-6129-8c06-82b07440a871</uuid>
<description>MIQ GUID=b55c806d-99b9-4fa5-bbcc-a4de04f822e5</description>
<memory unit='KiB'>16777216</memory>
<currentMemory unit='KiB'>16777216</currentMemory>
--
2.54.0On Tue, May 12, 2026 at 06:23:30PM +0200, Martin Kletzander via Devel wrote:
> From: Martin Kletzander <mkletzan@redhat.com>
>
> The difference is that the usual UUID is supposed to be unique per host
> and instanceUuid should be unique across the whole cluster. One could
> think of them as HUID and CUID (as the first "U" does apparently mean
> something else in the Broadcom world). That _would_ be fine for our
> scenario. However, that piece of information turns out to be false as
> well and the UUID we were using (`config.uuid`, or in VMX the
> `uuid.bios`) can be the same in two machines on the same host.
>
> Fortunately the `FindByUuid()` function can also search for VMs based on
> their `instanceUuid`, dictated by the so far omitted third parameter.
> Unfortunately that parameter is not parsed (or at least properly) before
> vSphere API 4.0 (the documentation says 2.0, but we are not using that
> namespace and 4.0 is the lowest we can target), which we are not
> specifying in the server returns a 500 HTTP error if we use the
> `instanceUuid` parameter.
>
> So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL
> requests which makes that `FindByUuid()` function work even with the
> `instanceUuid` set, but without any extra labor.
>
> After that this patch also changes all UUIDs to be parsed from the
> `config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback
> to the old `uuid.bios`) and adjusts tests accordingly.
>
> Last, but not least it changes the parameter to aforementioned function
> to be always true and henceforth all searching ought to be done with the
> more unique ID.
>
> Resolves: https://redhat.atlassian.net/browse/RHEL-174300
> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
> ---
> src/esx/esx_driver.c | 8 ++++----
> src/esx/esx_vi.c | 16 ++++++++++++++--
> src/vmx/vmx.c | 10 +++++++---
> tests/vmx2xmldata/esx-in-the-wild-10.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-11.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-12.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-13.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-14.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-15.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-16.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-17.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-5.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-6.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-7.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-8.xml | 2 +-
> tests/vmx2xmldata/esx-in-the-wild-9.xml | 2 +-
> 16 files changed, 38 insertions(+), 22 deletions(-)
>
> diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
> index 010c62b8e880..7cc54af69239 100644
> --- a/src/esx/esx_driver.c
> +++ b/src/esx/esx_driver.c
> @@ -1419,7 +1419,7 @@ esxDomainLookupByID(virConnectPtr conn, int id)
> "configStatus\0"
> "name\0"
> "runtime.powerState\0"
> - "config.uuid\0") < 0 ||
> + "config.instanceUuid\0") < 0 ||
> esxVI_LookupVirtualMachineList(priv->primary, propertyNameList,
> &virtualMachineList) < 0) {
> goto cleanup;
> @@ -1522,7 +1522,7 @@ esxDomainLookupByName(virConnectPtr conn, const char *name)
> if (esxVI_String_AppendValueListToList(&propertyNameList,
> "configStatus\0"
> "runtime.powerState\0"
> - "config.uuid\0") < 0 ||
> + "config.instanceUuid\0") < 0 ||
> esxVI_LookupVirtualMachineByName(priv->primary, name, propertyNameList,
> &virtualMachine,
> esxVI_Occurrence_RequiredItem) < 0) {
> @@ -4788,7 +4788,7 @@ esxConnectListAllDomains(virConnectPtr conn,
> if (esxVI_String_AppendValueListToList(&propertyNameList,
> "configStatus\0"
> "name\0"
> - "config.uuid\0") < 0) {
> + "config.instanceUuid\0") < 0) {
> goto cleanup;
> }
> }
> @@ -4970,7 +4970,7 @@ esxDomainHasManagedSaveImage(virDomainPtr domain, unsigned int flags)
>
> if (esxVI_FindByUuid(priv->primary, priv->primary->datacenter->_reference,
> uuid_string, esxVI_Boolean_True,
> - esxVI_Boolean_Undefined,
> + esxVI_Boolean_True,
> &managedObjectReference) < 0) {
> return -1;
> }
> diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c
> index db006ed16f40..55d5d1478586 100644
> --- a/src/esx/esx_vi.c
> +++ b/src/esx/esx_vi.c
> @@ -300,6 +300,17 @@ esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri *parsedUri)
> curl->headers = curl_slist_append(curl->headers,
> "Content-Type: text/xml; charset=UTF-8");
>
> + /*
> + * Testing showed that the 4.0 version is most close to our current types in
> + * esx_vi_generator.input data. We could update the version if new method
> + * parameters or object properties are needed.
> + *
> + * The other option is to drop the "/x.y" suffix completely once
> + * https://gitlab.com/libvirt/libvirt/-/work_items/878 is implemented since
> + * that will not limit the version at all.
> + */
> + curl->headers = curl_slist_append(curl->headers, "SOAPAction: urn:vim25/4.0");
> +
> /*
> * Add an empty expect header to stop CURL from waiting for a response code
> * 100 (Continue) from the server before continuing the POST operation.
> @@ -2452,7 +2463,8 @@ esxVI_GetVirtualMachineIdentity(esxVI_ObjectContent *virtualMachine,
> for (dynamicProperty = virtualMachine->propSet;
> dynamicProperty;
> dynamicProperty = dynamicProperty->_next) {
> - if (STREQ(dynamicProperty->name, "config.uuid")) {
> +
> + if (STREQ(dynamicProperty->name, "config.instanceUuid")) {
> if (esxVI_AnyType_ExpectType(dynamicProperty->val,
> esxVI_Type_String) < 0) {
> goto failure;
> @@ -2682,7 +2694,7 @@ esxVI_LookupVirtualMachineByUuid(esxVI_Context *ctx, const unsigned char *uuid,
> virUUIDFormat(uuid, uuid_string);
>
> if (esxVI_FindByUuid(ctx, ctx->datacenter->_reference, uuid_string,
> - esxVI_Boolean_True, esxVI_Boolean_Undefined,
> + esxVI_Boolean_True, esxVI_Boolean_True,
> &managedObjectReference) < 0) {
> return -1;
> }
> diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c
> index 084b4154427f..a2422c37355c 100644
> --- a/src/vmx/vmx.c
> +++ b/src/vmx/vmx.c
> @@ -1492,9 +1492,13 @@ virVMXParseConfig(virVMXContext *ctx,
> def->scsiBusMaxUnit = SCSI_SUPER_WIDE_BUS_MAX_CONT_UNIT;
> }
>
> - /* vmx:uuid.bios -> def:uuid */
> - /* FIXME: Need to handle 'uuid.action = "create"' */
> - if (virVMXGetConfigUUID(conf, "uuid.bios", def->uuid, true) < 0)
> + /* vmx:vc.uuid (fallback to uuid.bios) -> def:uuid */
> + if (virVMXGetConfigUUID(conf, "vc.uuid", def->uuid, true) < 0)
> + goto cleanup;
> +
> + /* FIXME: Need to handle 'uuid.action = "create"' ? */
> + if (!virUUIDIsValid(def->uuid) &&
> + virVMXGetConfigUUID(conf, "uuid.bios", def->uuid, true) < 0)
> goto cleanup;
>
> /* vmx:displayName -> def:name */
> 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>
> <genid>13c67c91-9f47-526f-b0d6-e4dd2e4bb4f9</genid>
> <memory unit='KiB'>4194304</memory>
> <currentMemory unit='KiB'>4194304</currentMemory>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-11.xml b/tests/vmx2xmldata/esx-in-the-wild-11.xml
> index 0dd297af43f0..6398e50c5c6c 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-11.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-11.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>esx6.7-rhel7.7-x86_64</name>
> - <uuid>422c0152-63ab-cd03-9650-4301ae77aefd</uuid>
> + <uuid>502ca229-12eb-24f6-0c37-c025ff5da005</uuid>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> <vcpu placement='static'>1</vcpu>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-12.xml b/tests/vmx2xmldata/esx-in-the-wild-12.xml
> index ac83982b9b88..d505ff58d12d 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-12.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-12.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>Auto-esx8.0-rhell9.3-efi-with-empty-cdrom</name>
> - <uuid>4220fca7-11dd-d67e-19cc-fcad0a37c342</uuid>
> + <uuid>5020ca5b-7ac1-5c44-cfa1-9e762e2f933b</uuid>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> <vcpu placement='static'>1</vcpu>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-13.xml b/tests/vmx2xmldata/esx-in-the-wild-13.xml
> index cef9fd4e48c9..2bea51a087eb 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-13.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-13.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>Test-Mig-VM-1 (01ce57d0-4e20-41a5-8b6c-bcbf49a032ec)</name>
> - <uuid>421eb458-5448-fc12-2074-83d5e419e138</uuid>
> + <uuid>01ce57d0-4e20-41a5-8b6c-bcbf49a032ec</uuid>
> <description>name:Test-Mig-VM-1
> userid:962314ba515c48388a0e95c0961709ff
> username:admin
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-14.xml b/tests/vmx2xmldata/esx-in-the-wild-14.xml
> index f10707d1d412..574dd2097455 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-14.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-14.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>wild14</name>
> - <uuid>421b223a-f2c1-c7c9-a399-34d2d9fde26d</uuid>
> + <uuid>501b831e-75d8-15f8-36fa-b9e225f395aa</uuid>
> <description>execution env sandbox automation platform</description>
> <memory unit='KiB'>33554432</memory>
> <currentMemory unit='KiB'>33554432</currentMemory>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-15.xml b/tests/vmx2xmldata/esx-in-the-wild-15.xml
> index 78d15e1538e6..4c753f87e2ea 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-15.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-15.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>dokuwiki</name>
> - <uuid>420338bd-1c9e-ad50-99a2-59e92ddda8b6</uuid>
> + <uuid>500341d5-fe23-ac46-8cb3-77a8e5a1143d</uuid>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> <vcpu placement='static'>2</vcpu>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-16.xml b/tests/vmx2xmldata/esx-in-the-wild-16.xml
> index 51746dd77ef0..8c5bc7f43513 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-16.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-16.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>Auto-esx8.0-rhel9.4-efi-nvme-disk</name>
> - <uuid>4220df89-e3a8-8513-f611-ad252bfd7047</uuid>
> + <uuid>5020196e-c5c8-7310-fcdb-d2933d0c4b2f</uuid>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> <vcpu placement='static'>1</vcpu>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-17.xml b/tests/vmx2xmldata/esx-in-the-wild-17.xml
> index 725f21bdf601..506e08fc54ec 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-17.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-17.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>esx8.0-win11-with-second-disk-in-subfolder</name>
> - <uuid>42256ec1-e066-9364-3dd1-36a0b75263dd</uuid>
> + <uuid>50250f27-538b-5091-a43b-a50ce95f2382</uuid>
> <genid>3191ed70-eb21-9c71-2478-373fb27fed9b</genid>
> <memory unit='KiB'>4194304</memory>
> <currentMemory unit='KiB'>4194304</currentMemory>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-5.xml b/tests/vmx2xmldata/esx-in-the-wild-5.xml
> index c88e60bdc070..a86119508c70 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-5.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-5.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>vmtest.local</name>
> - <uuid>423e94a9-a1c7-b31d-7161-76c7586c830e</uuid>
> + <uuid>503e06db-f8d5-458e-a2fb-f9820253a7be</uuid>
> <description>Centos 5.5 64bit Server</description>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-6.xml b/tests/vmx2xmldata/esx-in-the-wild-6.xml
> index 805f03356129..f252304f9796 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-6.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-6.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>el6-test</name>
> - <uuid>564d15d4-d062-fe9a-80f5-eb8e1a2c3afc</uuid>
> + <uuid>5200b69b-8d88-7bdf-a14a-02705d653772</uuid>
> <memory unit='KiB'>1048576</memory>
> <currentMemory unit='KiB'>1048576</currentMemory>
> <vcpu placement='static'>1</vcpu>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-7.xml b/tests/vmx2xmldata/esx-in-the-wild-7.xml
> index b641574776b6..076655f37ac2 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-7.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-7.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>esx-rhel6-mini-with-scsi-device</name>
> - <uuid>564d9176-621f-0239-f5ad-3a002371953b</uuid>
> + <uuid>52409533-33a2-56c5-36ce-80d605f8ecf4</uuid>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> <vcpu placement='static'>1</vcpu>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-8.xml b/tests/vmx2xmldata/esx-in-the-wild-8.xml
> index f13e6f744880..2ef609e87bdb 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-8.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-8.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>RHEL7_10_NICs</name>
> - <uuid>42359420-99dc-4261-5264-ba58ddae20e4</uuid>
> + <uuid>50351de6-7d56-29ab-9d72-c7f9ea3fcfd0</uuid>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> <vcpu placement='static'>8</vcpu>
> diff --git a/tests/vmx2xmldata/esx-in-the-wild-9.xml b/tests/vmx2xmldata/esx-in-the-wild-9.xml
> index 6b4d878ab18a..4fbe141f6c47 100644
> --- a/tests/vmx2xmldata/esx-in-the-wild-9.xml
> +++ b/tests/vmx2xmldata/esx-in-the-wild-9.xml
> @@ -1,6 +1,6 @@
> <domain type='vmware'>
> <name>v2v-windows-kkulkarn</name>
> - <uuid>42009372-17da-be73-779d-007ccf1bd228</uuid>
> + <uuid>5000d2b0-616e-6129-8c06-82b07440a871</uuid>
> <description>MIQ GUID=b55c806d-99b9-4fa5-bbcc-a4de04f822e5</description>
> <memory unit='KiB'>16777216</memory>
> <currentMemory unit='KiB'>16777216</currentMemory>
> --
> 2.54.0
I tested this on vSphere 8 & 9 (ESXi and vCenter) and it seems to work
fine.
The <uuid/> field changed (as expected), and I saw new fields for
<nvram/> amd <tpm/> which have been added in the latest libvirt
compared to the one installed on Fedora 43. All looks good, so:
Tested-by: Richard W.M. Jones <rjones@redhat.com>
One thing I did notice (unrelated to this patch) is that tab-
completion in virsh seems to hang. I'm unable to recover even with ^C ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
On Wed, May 13, 2026 at 09:47:55AM +0100, Richard W.M. Jones wrote: >On Tue, May 12, 2026 at 06:23:30PM +0200, Martin Kletzander via Devel wrote: >> From: Martin Kletzander <mkletzan@redhat.com> >> >> The difference is that the usual UUID is supposed to be unique per host >> and instanceUuid should be unique across the whole cluster. One could >> think of them as HUID and CUID (as the first "U" does apparently mean >> something else in the Broadcom world). That _would_ be fine for our >> scenario. However, that piece of information turns out to be false as >> well and the UUID we were using (`config.uuid`, or in VMX the >> `uuid.bios`) can be the same in two machines on the same host. >> >> Fortunately the `FindByUuid()` function can also search for VMs based on >> their `instanceUuid`, dictated by the so far omitted third parameter. >> Unfortunately that parameter is not parsed (or at least properly) before >> vSphere API 4.0 (the documentation says 2.0, but we are not using that >> namespace and 4.0 is the lowest we can target), which we are not >> specifying in the server returns a 500 HTTP error if we use the >> `instanceUuid` parameter. >> >> So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL >> requests which makes that `FindByUuid()` function work even with the >> `instanceUuid` set, but without any extra labor. >> >> After that this patch also changes all UUIDs to be parsed from the >> `config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback >> to the old `uuid.bios`) and adjusts tests accordingly. >> >> Last, but not least it changes the parameter to aforementioned function >> to be always true and henceforth all searching ought to be done with the >> more unique ID. >> >> Resolves: https://redhat.atlassian.net/browse/RHEL-174300 >> Signed-off-by: Martin Kletzander <mkletzan@redhat.com> >> --- [...] > >I tested this on vSphere 8 & 9 (ESXi and vCenter) and it seems to work >fine. > >The <uuid/> field changed (as expected), and I saw new fields for ><nvram/> amd <tpm/> which have been added in the latest libvirt >compared to the one installed on Fedora 43. All looks good, so: > >Tested-by: Richard W.M. Jones <rjones@redhat.com> > >One thing I did notice (unrelated to this patch) is that tab- >completion in virsh seems to hang. I'm unable to recover even with ^C ... > I understand that it happened even before this patch, since it's unrelated, right? I cannot reproduce it. I tried completing domain names and block devices etc. and even when it took a lot longer I was still able to kill it with Ctrl-C. Then I tried it in interactive virsh instead of bash and there are some inconsistencies. When trying to complete something that needs to fetch data from the server then Ctrl-C does nothing until the completion hits, and then it kills the shell. But I haven't been able to find anything that would take so long it felt blocked or even something that would actually block. >Rich. > >-- >Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones >Read my programming and virtualization blog: http://rwmj.wordpress.com >nbdkit - Flexible, fast NBD server with plugins >https://gitlab.com/nbdkit/nbdkit >
On Wed, May 13, 2026 at 03:36:44PM +0200, Martin Kletzander wrote: > On Wed, May 13, 2026 at 09:47:55AM +0100, Richard W.M. Jones wrote: > >One thing I did notice (unrelated to this patch) is that tab- > >completion in virsh seems to hang. I'm unable to recover even with ^C ... > > > > I understand that it happened even before this patch, since it's > unrelated, right? I cannot reproduce it. I tried completing domain > names and block devices etc. and even when it took a lot longer I was > still able to kill it with Ctrl-C. Definitely this is hanging for me, on a second machine as well. However only when I use a valid esx://... URI. For example: $ virsh -c esx://root@[redacted]/?no_verify=1 <TAB> hangs. ^C doesn't do anything, and more interestingly nothing seems to be taking any CPU. I will let it run for a bit to see if it ever recovers, and file a bug soon. > Then I tried it in interactive virsh instead of bash and there are some > inconsistencies. When trying to complete something that needs to fetch > data from the server then Ctrl-C does nothing until the completion hits, > and then it kills the shell. But I haven't been able to find anything > that would take so long it felt blocked or even something that would > actually block. Did you try with an esx:// URI? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
I filed this bug about the tab completion issue: https://gitlab.com/libvirt/libvirt/-/work_items/879 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Thu, May 14, 2026 at 08:30:35AM +0100, Richard W.M. Jones wrote: >On Wed, May 13, 2026 at 03:36:44PM +0200, Martin Kletzander wrote: >> On Wed, May 13, 2026 at 09:47:55AM +0100, Richard W.M. Jones wrote: >> >One thing I did notice (unrelated to this patch) is that tab- >> >completion in virsh seems to hang. I'm unable to recover even with ^C ... >> > >> >> I understand that it happened even before this patch, since it's >> unrelated, right? I cannot reproduce it. I tried completing domain >> names and block devices etc. and even when it took a lot longer I was >> still able to kill it with Ctrl-C. > >Definitely this is hanging for me, on a second machine as well. >However only when I use a valid esx://... URI. > >For example: > >$ virsh -c esx://root@[redacted]/?no_verify=1 <TAB> > >hangs. ^C doesn't do anything, and more interestingly nothing seems >to be taking any CPU. > >I will let it run for a bit to see if it ever recovers, and file >a bug soon. > >> Then I tried it in interactive virsh instead of bash and there are some >> inconsistencies. When trying to complete something that needs to fetch >> data from the server then Ctrl-C does nothing until the completion hits, >> and then it kills the shell. But I haven't been able to find anything >> that would take so long it felt blocked or even something that would >> actually block. > >Did you try with an esx:// URI? > No, only vpx://, feel free to give me an example off-list and we might figure it out. @Michal (Cc'd) is back as well and he is the (not only bash-)completion master around here, so he might know a thing or two as well. >Rich. > >-- >Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones >Read my programming and virtualization blog: http://rwmj.wordpress.com >virt-p2v converts physical machines to virtual machines. Boot with a >live CD or over the network (PXE) and turn machines into KVM guests. >http://libguestfs.org/virt-v2v >
On Tue, May 12, 2026 at 06:23:30PM +0200, Martin Kletzander via Devel wrote: > From: Martin Kletzander <mkletzan@redhat.com> > > The difference is that the usual UUID is supposed to be unique per host > and instanceUuid should be unique across the whole cluster. One could > think of them as HUID and CUID (as the first "U" does apparently mean > something else in the Broadcom world). That _would_ be fine for our > scenario. However, that piece of information turns out to be false as > well and the UUID we were using (`config.uuid`, or in VMX the > `uuid.bios`) can be the same in two machines on the same host. WTF is the normal "UUID" used for ? Is that being exposed to the guest OS as the SMBIOS UUID, while instanceUuid is used for host side tracking ? Since fairly recently we do have a <hwuuid> field now which can be used in the case of the SMBIOS UUID being different from the host side UUID. Possibly we should include <hwuuid> in ESX if this can differ. > > Fortunately the `FindByUuid()` function can also search for VMs based on > their `instanceUuid`, dictated by the so far omitted third parameter. > Unfortunately that parameter is not parsed (or at least properly) before > vSphere API 4.0 (the documentation says 2.0, but we are not using that > namespace and 4.0 is the lowest we can target), which we are not > specifying in the server returns a 500 HTTP error if we use the > `instanceUuid` parameter. > > So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL > requests which makes that `FindByUuid()` function work even with the > `instanceUuid` set, but without any extra labor. > > After that this patch also changes all UUIDs to be parsed from the > `config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback > to the old `uuid.bios`) and adjusts tests accordingly. > > Last, but not least it changes the parameter to aforementioned function > to be always true and henceforth all searching ought to be done with the > more unique ID. > 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. 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 > <genid>13c67c91-9f47-526f-b0d6-e4dd2e4bb4f9</genid> > <memory unit='KiB'>4194304</memory> > <currentMemory unit='KiB'>4194304</currentMemory> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-11.xml b/tests/vmx2xmldata/esx-in-the-wild-11.xml > index 0dd297af43f0..6398e50c5c6c 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-11.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-11.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>esx6.7-rhel7.7-x86_64</name> > - <uuid>422c0152-63ab-cd03-9650-4301ae77aefd</uuid> > + <uuid>502ca229-12eb-24f6-0c37-c025ff5da005</uuid> > <memory unit='KiB'>2097152</memory> > <currentMemory unit='KiB'>2097152</currentMemory> > <vcpu placement='static'>1</vcpu> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-12.xml b/tests/vmx2xmldata/esx-in-the-wild-12.xml > index ac83982b9b88..d505ff58d12d 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-12.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-12.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>Auto-esx8.0-rhell9.3-efi-with-empty-cdrom</name> > - <uuid>4220fca7-11dd-d67e-19cc-fcad0a37c342</uuid> > + <uuid>5020ca5b-7ac1-5c44-cfa1-9e762e2f933b</uuid> > <memory unit='KiB'>2097152</memory> > <currentMemory unit='KiB'>2097152</currentMemory> > <vcpu placement='static'>1</vcpu> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-13.xml b/tests/vmx2xmldata/esx-in-the-wild-13.xml > index cef9fd4e48c9..2bea51a087eb 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-13.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-13.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>Test-Mig-VM-1 (01ce57d0-4e20-41a5-8b6c-bcbf49a032ec)</name> > - <uuid>421eb458-5448-fc12-2074-83d5e419e138</uuid> > + <uuid>01ce57d0-4e20-41a5-8b6c-bcbf49a032ec</uuid> > <description>name:Test-Mig-VM-1 > userid:962314ba515c48388a0e95c0961709ff > username:admin > diff --git a/tests/vmx2xmldata/esx-in-the-wild-14.xml b/tests/vmx2xmldata/esx-in-the-wild-14.xml > index f10707d1d412..574dd2097455 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-14.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-14.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>wild14</name> > - <uuid>421b223a-f2c1-c7c9-a399-34d2d9fde26d</uuid> > + <uuid>501b831e-75d8-15f8-36fa-b9e225f395aa</uuid> > <description>execution env sandbox automation platform</description> > <memory unit='KiB'>33554432</memory> > <currentMemory unit='KiB'>33554432</currentMemory> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-15.xml b/tests/vmx2xmldata/esx-in-the-wild-15.xml > index 78d15e1538e6..4c753f87e2ea 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-15.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-15.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>dokuwiki</name> > - <uuid>420338bd-1c9e-ad50-99a2-59e92ddda8b6</uuid> > + <uuid>500341d5-fe23-ac46-8cb3-77a8e5a1143d</uuid> > <memory unit='KiB'>2097152</memory> > <currentMemory unit='KiB'>2097152</currentMemory> > <vcpu placement='static'>2</vcpu> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-16.xml b/tests/vmx2xmldata/esx-in-the-wild-16.xml > index 51746dd77ef0..8c5bc7f43513 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-16.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-16.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>Auto-esx8.0-rhel9.4-efi-nvme-disk</name> > - <uuid>4220df89-e3a8-8513-f611-ad252bfd7047</uuid> > + <uuid>5020196e-c5c8-7310-fcdb-d2933d0c4b2f</uuid> > <memory unit='KiB'>2097152</memory> > <currentMemory unit='KiB'>2097152</currentMemory> > <vcpu placement='static'>1</vcpu> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-17.xml b/tests/vmx2xmldata/esx-in-the-wild-17.xml > index 725f21bdf601..506e08fc54ec 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-17.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-17.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>esx8.0-win11-with-second-disk-in-subfolder</name> > - <uuid>42256ec1-e066-9364-3dd1-36a0b75263dd</uuid> > + <uuid>50250f27-538b-5091-a43b-a50ce95f2382</uuid> > <genid>3191ed70-eb21-9c71-2478-373fb27fed9b</genid> > <memory unit='KiB'>4194304</memory> > <currentMemory unit='KiB'>4194304</currentMemory> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-5.xml b/tests/vmx2xmldata/esx-in-the-wild-5.xml > index c88e60bdc070..a86119508c70 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-5.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-5.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>vmtest.local</name> > - <uuid>423e94a9-a1c7-b31d-7161-76c7586c830e</uuid> > + <uuid>503e06db-f8d5-458e-a2fb-f9820253a7be</uuid> > <description>Centos 5.5 64bit Server</description> > <memory unit='KiB'>2097152</memory> > <currentMemory unit='KiB'>2097152</currentMemory> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-6.xml b/tests/vmx2xmldata/esx-in-the-wild-6.xml > index 805f03356129..f252304f9796 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-6.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-6.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>el6-test</name> > - <uuid>564d15d4-d062-fe9a-80f5-eb8e1a2c3afc</uuid> > + <uuid>5200b69b-8d88-7bdf-a14a-02705d653772</uuid> > <memory unit='KiB'>1048576</memory> > <currentMemory unit='KiB'>1048576</currentMemory> > <vcpu placement='static'>1</vcpu> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-7.xml b/tests/vmx2xmldata/esx-in-the-wild-7.xml > index b641574776b6..076655f37ac2 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-7.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-7.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>esx-rhel6-mini-with-scsi-device</name> > - <uuid>564d9176-621f-0239-f5ad-3a002371953b</uuid> > + <uuid>52409533-33a2-56c5-36ce-80d605f8ecf4</uuid> > <memory unit='KiB'>2097152</memory> > <currentMemory unit='KiB'>2097152</currentMemory> > <vcpu placement='static'>1</vcpu> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-8.xml b/tests/vmx2xmldata/esx-in-the-wild-8.xml > index f13e6f744880..2ef609e87bdb 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-8.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-8.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>RHEL7_10_NICs</name> > - <uuid>42359420-99dc-4261-5264-ba58ddae20e4</uuid> > + <uuid>50351de6-7d56-29ab-9d72-c7f9ea3fcfd0</uuid> > <memory unit='KiB'>2097152</memory> > <currentMemory unit='KiB'>2097152</currentMemory> > <vcpu placement='static'>8</vcpu> > diff --git a/tests/vmx2xmldata/esx-in-the-wild-9.xml b/tests/vmx2xmldata/esx-in-the-wild-9.xml > index 6b4d878ab18a..4fbe141f6c47 100644 > --- a/tests/vmx2xmldata/esx-in-the-wild-9.xml > +++ b/tests/vmx2xmldata/esx-in-the-wild-9.xml > @@ -1,6 +1,6 @@ > <domain type='vmware'> > <name>v2v-windows-kkulkarn</name> > - <uuid>42009372-17da-be73-779d-007ccf1bd228</uuid> > + <uuid>5000d2b0-616e-6129-8c06-82b07440a871</uuid> > <description>MIQ GUID=b55c806d-99b9-4fa5-bbcc-a4de04f822e5</description> > <memory unit='KiB'>16777216</memory> > <currentMemory unit='KiB'>16777216</currentMemory> > -- > 2.54.0 > With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
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
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 behaviour > >Definitely 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 >
© 2016 - 2026 Red Hat, Inc.