[PATCH] vmx: Parse vm.genid

[Richard W.M. Jones]

On Mon, Aug 02, 2021 at 01:14:52PM +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 02, 2021 at 12:26:56PM +0100, Richard W.M. Jones wrote:
> > On Mon, Aug 02, 2021 at 12:12:08PM +0100, Daniel P. Berrangé wrote:
> > > On Mon, Aug 02, 2021 at 12:04:49PM +0100, Richard W.M. Jones wrote:
> > > > On Mon, Aug 02, 2021 at 01:00:15PM +0200, Michal Prívozník wrote:
> > > > > On 7/30/21 2:02 PM, Richard W.M. Jones wrote:
> > > > > > On Thu, Jul 29, 2021 at 10:30:30AM +0200, Michal Privoznik wrote:
> > > > > >> The VMware metadata file contains genid but we are not parsing
> > > > > >> and thus reporting it in domain XML. However, it's not as
> > > > > >> straightforward as one might think. The UUID reported by VMware
> > > > > >> is not in its usual string form, but split into two signed long
> > > > > >> longs. That means, we have to do a bit of trickery when parsing.
> > > > > >> But looking around it's the same magic that libguestfs does:
> > > > > >>
> > > > > >> https://github.com/libguestfs/virt-v2v/blob/master/v2v/input_vmx.ml#L421
> > > > > >>
> > > > > >> It's also explained by Rich on qemu-devel:
> > > > > >>
> > > > > >> https://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg02019.html
> > > > > >>
> > > > > >> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1598348
> > > > > >> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> > > > > >> ---
> > > > > >>
> > > > > >> I've successfully ran vmx2xmltest on an s390x machine which means that
> > > > > >> there shouldn't be any endiandness problem.
> > > > > >>
> > > > > >>  src/vmx/vmx.c                                 | 30 +++++++++++++++++++
> > > > > >>  .../vmx2xml-esx-in-the-wild-10.xml            |  1 +
> > > > > >>  2 files changed, 31 insertions(+)
> > > > > >>
> > > > > 
> > > > > > 
> > > > > > Looked reasonable and seems to match the description here:
> > > > > > 
> > > > > > https://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg02019.html
> > > > > > 
> > > > > > Reviewed-by: Richard W.M. Jones <rjones at redhat.com>
> > > > > 
> > > > > Pushed, thanks.
> > > > > 
> > > > > > 
> > > > > > Out of interest, what is this being consumed by?  I will add this to
> > > > > > virt-v2v when it goes upstream.
> > > > > 
> > > > > I don't recall all the specifics (it was John who implemented it), but
> > > > > IIRC it was needed for Windows guests. Something about identifying them
> > > > > uniquely. John?
> > > > 
> > > > Sure, I understand what it's used for.  I was just wondering if there
> > > > are other consumers who want to pull the genID from VMware VMX files
> > > > using libvirt.  Seems like something quite specific to V2V scenarios.
> > > 
> > > Could there even be a a case to be made for V2V to *not* preserve the
> > > the genID value. eg If you see a genID in the existing config, then
> > > write a /different/ genID value in the new VM, to indicate that this
> > > new VM is a fork of the original VM ?
> > 
> > https://images5.alphacoders.com/405/405572.jpg
> > 
> > Noooo!  Successfully converted VMs are definitely not forks and
> > shouldn't be used that way.
> 
> Are we sure it doesn't end up that way indirectly. eg is there any
> liklihood that people will do this sequence:
> 
>   1. Stop original guest
> 
>   2. Run virt-v2v
> 
>   3. Start converted guest 
> 
>   4. Find something not right
> 
>   5. Stop converted guest
> 
>   6. Start original guest
> 
>   7. Fix <something>
> 
>   8. Goto (1)
> 
> 
> Step 5/6 here is effectively akin to rolling back to a saved snapshot.
> Thus genID ought to change if this is something users are liable todo.

We try to set things up so this never happens.  While it might be fine
for people trying stuff out, in production this could be a disaster if
it's an unintentional roll-back.  Anyhow that would be a management
layer decision, virt-v2v itself preserves the VMgenID when possible.

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