[PATCH] vmx: Parse vm.genid

[Daniel P. Berrangé]

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|