On Wed, Sep 29, 2021 at 10:33:43AM +0100, Daniel P. Berrangé wrote: > On Wed, Sep 29, 2021 at 10:20:44AM +0100, Richard W.M. Jones wrote: > > On Wed, Sep 29, 2021 at 10:01:55AM +0200, Michal Privoznik wrote: > > > Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it > > > was brought up in a private thread that libvirt doesn't report correct > > > UUIDs. For instance for the following input: > > > > > > vm.genid = "-8536691797830587195" > > > vm.genidX = "-1723453263670062919" > > > > (The two lines above come from a VMware .vmx file) > > > > The only thing that really matters is what the guest sees. I ran > > VMGENID.EXE (https://bugzilla.redhat.com/show_bug.cgi?id=1598350#c3 > > https://docs.microsoft.com/en-gb/windows/win32/hyperv_v2/virtual-machine-generation-identifier) > > inside the guest and it showed: > > > > 8987940a09512cc5:e81510634ff550b9 > > > > Note these numbers are the hex equivalents of the VMware .vmx numbers: > > > > >>> print("%x" % (2**64-8536691797830587195)) > > 8987940a09512cc5 > > >>> print("%x" % (2**64-1723453263670062919)) > > e81510634ff550b9 > > > > > Libvirt would report: > > > > > > <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid> > > > > > > while virt-v2v would report: > > > > > > <genid>09512cc5-940a-8987-b950-f54f631015e8</genid> > > > > After thinking about this a bit more, IMHO the real problem is > > with qemu. If you pass this to qemu: > > > > -device vmgenid,guid=8987940a-0951-2cc5-e815-10634ff550b9,id=vmgenid0 > > > > then inside the guest VMGENID shows 2cc509518987940a:b950f54f631015e8 (wrong) > > > > If you pass this to qemu: > > > > ...guid=09512cc5-940a-8987-b950-f54f631015e8... > > > > then inside the guest it sees 8987940a09512cc5:e81510634ff550b9 > > (the correct values, matching VMware). > > > > This is the reason why virt-v2v mangles the GUID, in order to trick > > libvirt into passing a mangled GUID which gets mangled again by qemu > > which is the same as unmangling it. > > > > So another way to fix this could be for us to fix qemu. We could just > > pass the two numbers to qemu instead of using GUIDs, eg: > > > > -device vmgenid,low=0x8987940a09512cc5,high=0xe81510634ff550b9,id=vmgenid0 > > > > and then we'd fix the implementation in qemu so that the low/high > > values match what is seen by VMGENID.EXE in the guest. > > > > Or we could have libvirt use the current GUID in <genid> but to do the > > mangling when it gets passed through to qemu (instead of virt-v2v > > doing the mangling). > > On the libvirt side, the #1 most important thing is that a given > XML string > > <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid> > > results in the same value being exposed to the guest OS, for both > the QEMU and VMWare drivers. Whehter the guest sees the bytes in > the same order is not essential, but it would be less of a surprise > if it did match. I don't know why we decided to use a GUID for this. The feature itself (https://go.microsoft.com/fwlink/?LinkId=260709) defines it as an 128 bit / 8 byte number. The only connection to GUIDs is the size. > Ultimately as long as the mapping from libvirt XML to guest visible > string is consistent across drivers, that's sufficient. > > > Adding qemu-devel because I'm interesting to see if the qemu > > developers would prefer to fix this properly in qemu. > > No matter what order QEMU accepts the data in, it can be said to be > functionally correct. If the order is "unusual" though, it ought to > at least be documented how the QEMU order corresponds to guest visible > order. > > Incidentally I wonder how much to trust VMGENID.EXE and whether that > actally reports what it gets out of guest memory "as is", or whether > it has done any byte re-ordering. > > I'm curious what Linux kernel sees for the genid on Vmware vs KVM > hosts, as probably I'd trust that data more ? As far as I can tell no driver has successfully made it upstream, although there have been a few attempts: https://lkml.org/lkml/2018/3/1/498 Here's a more recent one from 10 months ago: https://lore.kernel.org/linux-doc/3E05451B-A9CD-4719-99D0-72750A304044@xxxxxxxxxx/ If I have time I'll patch a Linux kernel with the second patch and see how it relates to the VMware and KVM parameters, but it probably won't be today. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
