Libguestfs - Nov 2011 - Possible issue with virt-v2v writing to wrong Windows registry control set

I may have stumbled across a virt-v2v bug.  

 

I just did a successful virt-v2v migration of a Windows 2008 server from
an ESXi host to a RHEV environment.   While the VM was still on the ESXi
side, I removed its VMWare tools and rebooted it just make sure it was
still functional.  Then I shut it down and V2V'd and imported it into
RHEV.  

 

When I first powered up the new RHEV copy, it found and installed the
driver for the Virtio NIC and tried to install the Viostor SCSI driver,
but failed with "Access Denied".  This was strange.  Looking at the
Windows Device Manager, I noticed a SCSI controller without any driver
and an "Unknown Device".  This looked similar to the situation when it
was an ESXi VM.  

 

I tinkered around with drivers a little bit, trying to be the Viostor
stuff to load.  It never did.  So I rebooted the VM, just to make sure
it would come back up while I was there to watch it and I could deal
with its missing 2nd disk drive later.  Good call - it went into a
crash/reboot loop.  Bummer.

 

I caught it and tried "Last Known Good" from the Windows boot menu.
This never works, but I keep trying anyway.  Good thing, because this
time it came right back up.  It also successfully loaded the Viostor
block driver this time and now there are no more SCSI controllers
without drivers and no more Unidentified Devices.  And that VM's second
hard drive also showed up - this was probably the "unknown device"
from
before.  

 

I wonder if virt-v2v wrote its registry updates to the wrong registry
control set and I stumbled across it?  

 

And a tip for anyone else - if your Windows VM crashes after a virt-v2v,
try booting with Last Known Good.

 

-          Greg Scott

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20111116/aa1ef0d2/attachment.htm>

On 16/11/11 16:08, Greg Scott wrote:
> I may have stumbled across a virt-v2v bug.
>
> I just did a successful virt-v2v migration of a Windows 2008 server from
> an ESXi host to a RHEV environment. While the VM was still on the ESXi
> side, I removed its VMWare tools and rebooted it just make sure it was
> still functional. Then I shut it down and V2V?d and imported it into RHEV.
>
> When I first powered up the new RHEV copy, it found and installed the
> driver for the Virtio NIC and tried to install the Viostor SCSI driver,
> but failed with ?Access Denied?. This was strange. Looking at the
> Windows Device Manager, I noticed a SCSI controller without any driver
> and an ?Unknown Device?. This looked similar to the situation when it
> was an ESXi VM.
>
> I tinkered around with drivers a little bit, trying to be the Viostor
> stuff to load. It never did. So I rebooted the VM, just to make sure it
> would come back up while I was there to watch it and I could deal with
> its missing 2^nd disk drive later. Good call ? it went into a
> crash/reboot loop. Bummer.
>
> I caught it and tried ?Last Known Good? from the Windows boot menu. This
> never works, but I keep trying anyway. Good thing, because this time it
> came right back up. It also successfully loaded the Viostor block driver
> this time and now there are no more SCSI controllers without drivers and
> no more Unidentified Devices. And that VM?s second hard drive also
> showed up ? this was probably the ?unknown device? from before.
>
> I wonder if virt-v2v wrote its registry updates to the wrong registry
> control set and I stumbled across it?
>
> And a tip for anyone else ? if your Windows VM crashes after a virt-v2v,
> try booting with Last Known Good.
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.

That isn't to say there isn't something odd going on here...

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490