[Libguestfs] Possible issue with virt-v2v writing to wrong Windows registry control set

[Greg Scott]

> Can you reproduce this? Windows shouldn't be able to boot at all
unless 
> viostor is both installed and configured in the CDD of the correct 
> control set. That is, afaict, the only way 'Last Known Good' would be 
> bootable is if virt-v2v made it that way.

Reproducing the same conditions will be very difficult.  The V2V'd VM is
a member server in a Windows domain.  It's now up and running and in
production in the RHEV environment.  But I can probably get permission
and get my hands on the raw materials to set it up in a lab.  This won't
be easy;  To reproduce it, we'd need an ESXi host, a RHEV environment
complete with shared storage, and we'd need to copy the ESXi .VMDK files
and provision a 40+ GB VM on the ESXi host and fire up a new V2V.  It
can be done but the logistics are very challenging and time consuming.  

I still have a copy of the V2V'd VM sitting in the export domain and I
might be able to send over its virtual disks.  I also have the ESXi
.VMDK files I started from. This one came at the tail-end of a scenario
that stumped lots of people - it's all documented in support case number
00560510.

While still reasonably fresh in my head - here's the sequence of events
to V2V this VM:

1 - The original ESXi VM had a bunch of snapshots and these need to
collapse.  So in the VMWare vSphere client, edit this VM and find the
names of its .VMDK files.  Now go to storage...browse datastore.  Note
that the original VM shows a bunch of .VMDK files because of the
snapshots from a long time ago.  Create a new directory and then copy
and paste the old .VMDK files into this new directory.  This creates 2
complete .VMDK files (Windows C and D drives in this VM), collapsing all
the snapshots into these 2 new files.

2 - Provision a new ESXi VM using the new .VMDK files in the new
directory - essentially a copy of the original ESXi VM but without
snapshots.  
3 - Boot the new VM, log on,  and remove VMware tools from it.  Shut the
VM down.
4 - V2V it into the RHEV Export domain.
5 - Import it into the RHEV datacenter.  

I still have copies of all the various files left over along the way.
But the ESXi stuff will disappear very soon because I have to repurpose
that old ESXi host as a RHEV host tomorrow.  

- Greg