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 <[email protected]>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 <[email protected]> ---
[...]
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 <[email protected]> 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
signature.asc
Description: PGP signature
