Restored Windows Server 2003 VM goes black

[Greg Scott]

I tried a P2V migration last week and here might be a better spot to
document the results.  I have an aging physical host running Windows
2003 Server and I want to P2V that host in to a libvirt VM.  The
physical host uses a Compaq Smart Array 532 Controller with a Compaq
Logical Volume SCSI disk device.  The logical volume is a RAID 5 set.  

 

I first tried using the new virt-p2v approach, but haven't been
successful.  So I tried doing it the old-fashioned way.  On a RHEL 6.1
host, I built a libvirt Windows 2003 VM from scratch using a virtio
system drive.  Then, on the physical host, I ran ntbackup and backed up
all the system drive files to a network share viewable from my newly
provisioned VM.  I also backed up the system state.  From the 2003 VM, I
restored the system drive files and system state and rebooted.  

 

When rebooting, the VM flashes a couple of POST SeaBIOS lines, then the
console window goes black.  No BSOD, just black.  Virt-manager shows the
VM is still powered on, but the console window just sits there, black,
until I force the VM to power off.  I tried pressing F8 to see if I
could get to a Windows boot menu, but this never worked.  I have a hunch
something is going on with the new system virtual drive and the driver
for the old system drive.  

 

I can boot the VM from a virtual CD and launch the Windows recovery
console, and from there I can see the Windows installation.  The login
uses the new password, so I think the ntbackup - restores did their
jobs.  I tried a fixboot and fixmbr, but neither of these did any good.
I tried another ntbackup - restore, this time using an IDE system drive
in my VM (the restore took 50 percent more time than with virtio), but
this also made no difference.  

 

I ended up re-enabling the NIC on the physical host again and now I'm
trying to come up with a plan C. Are there any other ideas I'm not
thinking of?

 

Thanks

 

-    Greg Scott

[Greg Scott]

Hisao Taguchi may have found a great idea.  Hisao pointed to this
article:

http://support.microsoft.com/kb/314082

 

It describes a process to proactively load a different IDE driver to a
Windows XP system before moving it to different hardware.   This
absolutely parallels the problem I need to solve - and I gotta believe I
am not alone.  I want to P2V a Windows 2003 Server with an uncooperative
system disk driver.   I've tried virt-p2v, the old-fashioned ntbackup
and restore, and an Acronis trial download.  So far, nothing works - and
the whole challenge comes back to that virtio disk driver not being
present in the source physical machine.  

 

If we could come up with a way to proactively install that virtio driver
into a physical Windows Server host before P2Ving it, maybe we could
solve P2V problems worldwide and it would be a huge step forward.  

 

-          Greg Scott

 

 

From: virt-bounces(a)lists.fedoraproject.org
[mailto:[e-mail]] On Behalf Of Greg Scott
Sent: Monday, October 03, 2011 10:09 AM
To: virt(a)lists.fedoraproject.org
Subject: [fedora-virt] Restored Windows Server 2003 VM goes black

 

I tried a P2V migration last week and here might be a better spot to
document the results.  I have an aging physical host running Windows
2003 Server and I want to P2V that host in to a libvirt VM.  The
physical host uses a Compaq Smart Array 532 Controller with a Compaq
Logical Volume SCSI disk device.  The logical volume is a RAID 5 set.  

 

I first tried using the new virt-p2v approach, but haven't been
successful.  So I tried doing it the old-fashioned way.  On a RHEL 6.1
host, I built a libvirt Windows 2003 VM from scratch using a virtio
system drive.  Then, on the physical host, I ran ntbackup and backed up
all the system drive files to a network share viewable from my newly
provisioned VM.  I also backed up the system state.  From the 2003 VM, I
restored the system drive files and system state and rebooted.  

 

When rebooting, the VM flashes a couple of POST SeaBIOS lines, then the
console window goes black.  No BSOD, just black.  Virt-manager shows the
VM is still powered on, but the console window just sits there, black,
until I force the VM to power off.  I tried pressing F8 to see if I
could get to a Windows boot menu, but this never worked.  I have a hunch
something is going on with the new system virtual drive and the driver
for the old system drive.  

 

I can boot the VM from a virtual CD and launch the Windows recovery
console, and from there I can see the Windows installation.  The login
uses the new password, so I think the ntbackup - restores did their
jobs.  I tried a fixboot and fixmbr, but neither of these did any good.
I tried another ntbackup - restore, this time using an IDE system drive
in my VM (the restore took 50 percent more time than with virtio), but
this also made no difference.  

 

I ended up re-enabling the NIC on the physical host again and now I'm
trying to come up with a plan C. Are there any other ideas I'm not
thinking of?

 

Thanks

 

-    Greg Scott

[Andrew Cathrow]

----- Original Message -----
>  From: "Greg Scott" <GregScott(a)Infrasupport.com&gt;
>  To: virt(a)lists.fedoraproject.org
>  Cc: "Hisao Taguchi" <hisao.taguchi(a)uniadex.co.jp&gt;
>  Sent: Thursday, October 6, 2011 12:23:40 AM
>  Subject: Re: [fedora-virt] Restored Windows Server 2003 VM goes black
>  
>  
>  
>  
>  
>  Hisao Taguchi may have found a great idea. Hisao pointed to this
>  article:
>  
>  http://support.microsoft.com/kb/314082
>  
>  
>  
>  It describes a process to proactively load a different IDE driver to
>  a Windows XP system before moving it to different hardware. This
>  absolutely parallels the problem I need to solve – and I gotta
>  believe I am not alone. I want to P2V a Windows 2003 Server with an
>  uncooperative system disk driver. I’ve tried virt-p2v, the 

What happened when you tried virt-p2v did it produce errors during toe conversion or did
the VM just fail to boot?


>  old-fashioned ntbackup and restore, and an Acronis trial download.
>  So far, nothing works – and the whole challenge comes back to that
>  virtio disk driver not being present in the source physical machine.
>  
>  
>  
>  If we could come up with a way to proactively install that virtio
>  driver into a physical Windows Server host before P2Ving it, maybe
>  we could solve P2V problems worldwide and it would be a huge step
>  forward.
>  
>  
>  
>  - Greg Scott
>  
>  
>  
>  
>  
>  
>  
>  From: virt-bounces(a)lists.fedoraproject.org
>  [mailto:[e-mail]] On Behalf Of Greg
>  Scott
>  Sent: Monday, October 03, 2011 10:09 AM
>  To: virt(a)lists.fedoraproject.org
>  Subject: [fedora-virt] Restored Windows Server 2003 VM goes black
>  
>  
>  
>  I tried a P2V migration last week and here might be a better spot to
>  document the results. I have an aging physical host running Windows
>  2003 Server and I want to P2V that host in to a libvirt VM. The
>  physical host uses a Compaq Smart Array 532 Controller with a Compaq
>  Logical Volume SCSI disk device. The logical volume is a RAID 5 set.
>  
>  
>  
>  I first tried using the new virt-p2v approach, but haven’t been
>  successful. So I tried doing it the old-fashioned way. On a RHEL 6.1
>  host, I built a libvirt Windows 2003 VM from scratch using a virtio
>  system drive. Then, on the physical host, I ran ntbackup and backed
>  up all the system drive files to a network share viewable from my
>  newly provisioned VM. I also backed up the system state. From the
>  2003 VM, I restored the system drive files and system state and
>  rebooted.
>  
>  
>  
>  When rebooting, the VM flashes a couple of POST SeaBIOS lines, then
>  the console window goes black. No BSOD, just black. Virt-manager
>  shows the VM is still powered on, but the console window just sits
>  there, black, until I force the VM to power off. I tried pressing F8
>  to see if I could get to a Windows boot menu, but this never worked.
>  I have a hunch something is going on with the new system virtual
>  drive and the driver for the old system drive.
>  
>  
>  
>  I can boot the VM from a virtual CD and launch the Windows recovery
>  console, and from there I can see the Windows installation. The
>  login uses the new password, so I think the ntbackup – restores did
>  their jobs. I tried a fixboot and fixmbr, but neither of these did
>  any good. I tried another ntbackup – restore, this time using an IDE
>  system drive in my VM (the restore took 50 percent more time than
>  with virtio), but this also made no difference.
>  
>  
>  
>  I ended up re-enabling the NIC on the physical host again and now I’m
>  trying to come up with a plan C. Are there any other ideas I’m not
>  thinking of?
>  
>  
>  
>  Thanks
>  
>  
>  
>  - Greg Scott
>  
>  
>  
>  
>  _______________________________________________
>  virt mailing list
>  virt(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/virt

[Greg Scott]

The virt-p2v blew up with an error and never made it to a conversion.  I posted the
details in the libguestfs mailing list last week.  I'll paste in below, fixing a typo
I just noticed:

- Greg


******************************************************

My use case might be atypical, or maybe bleeding edge.  The system I want to P2V is about
30 miles away and I am accessing it using a KVM over IP switch.  I have a Virt-P2V CD in
its CD drive and I can boot from that CD by playing with the BIOS boot order using the KVM
over IP.  It's a little tricky but works.  And it has to be this way because I can
only do this during off-hours.  

The physical host is a Windows 2003 server.  The conversion P2V server is a Fedora 14
guest VM running under Libvirt in a RHEL 6.1 host.  On the conversion server, I mounted an
NFS mount from the RHEL 6.1 host onto /var/lib/libvirt/images, its (F14 VM) default
libvirt storage pool.  The idea was, put the converted disk images there and then wrap a
guest VM around them from the RHEL 6.1 host.

The first time tonight, I uncommented the "libvirt" paragraph in virt-v2v.conf
on the conversion server.  I booted the 2003 host from the p2V CD.  And waited for a
cursor to finally show up over that KVM over IP.  I selected the "libvirt"
profile, gave the converted VM 1 CPU and 1024 MB of RAM and clicked the
"convert" button.  It immediately failed, complaining that "default"
is not a valid storage pool.  My hunch is, this is probably because I set up an NFS mount
on top of it.  

So I went into virt-manager on my Fedora 14 VM and set up another storage pool named
"MigrateVM" and pointed it to /var/lib/libvirt/images/MigrateVM.  Then I
modified virt-v2v.conf and copied and pasted the "libvirt" paragraph.  I
modified it to look like below:

  <profile name="mmmh-migrate">
    <method>libvirt</method>
    <storage>MigrateVM</storage>
    <network type="default">
      <network type="network" name="default"/>
    </network>
  </profile>

Then I rebooted the 2003 host from the virt-p2v CD.  I logged in to the conversion server,
selected the profile named "mmmh-migrate", 1024 MB of RAM and 1 CPU. When I
clicked "convert", see below:

Virt-p2v has shutdown unexpectedly.  You may:

* Try running it again
* Debug virt-p2v
* Power the machine off

I suppose a definition of insanity is trying the same thing again and expecting different
results - but I tried again anyway and got the same results.  This time I chose debug and
it mentioned a saved file named virt-p2v.log.  So I copied it and am pasting its contents
below.  

(eval): line 75
   Gtk-WARNING **:Could not find the icon 'gtk-dialog-warning'. The
'hicolor' theme was not found either, perhaps you need to install it.
You can get a copy from:
	http://icon-theme.freedesktop.org/releases
/dev/cciss!c0d0: No such file or directory
/usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:138:in `Integer':
invalid value for Integer: ""
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:138:in
`disk'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:72:in
`convert'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:178:in
`call'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:178:in
`iterate'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:74:in
`convert'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:174:in
`call'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:174:in
`iterate'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/connection.rb:143:in
`call'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/connection.rb:143:in
`metadata'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:44:in
`call'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:44:in
`main_with_queue'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:43:in
`each'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:43:in
`main_with_queue'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:42:in
`synchronize'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:42:in
`main_with_queue'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:50:in
`call'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:50:in
`main'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/gtk-queue.rb:50:in
`main_with_queue'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/ui/main.rb:49:in
`main_loop'
	 from /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/bin/virt-p2v:56
	 from /usr/bin/virt-p2v:19:in `load'
	 from /usr/bin/virt-p2v:19

The obvious question - why not forget about NFS and just carve out "local"
storage on an F14 VM and run the conversion that way?  And then copy the converted disk
images where they need to go on the RHEL host.  I can do that if necessary, but sheesh,
what a waste.  That 2003 server uses about 80 GB and I'd like to give the converted VM
about 100 GB or so, so it has plenty of room.  But if this turns out to be the answer, I
guess I may as well just do the migration by building a target 2003 VM and using ntbackup
to backup the physical and restore to the virtual.

[Matthew Booth]

On 06/10/11 07:15, Greg Scott wrote:
>  Then I rebooted the 2003 host from the virt-p2v CD.  I logged in to
>  the conversion server, selected the profile named "mmmh-migrate",
>  1024 MB of RAM and 1 CPU. When I clicked "convert", see below:
>
>  Virt-p2v has shutdown unexpectedly.  You may:
>
>  * Try running it again * Debug virt-p2v * Power the machine off
>
>  I suppose a definition of insanity is trying the same thing again and
>  expecting different results - but I tried again anyway and got the
>  same results.  This time I chose debug and it mentioned a saved file
>  named virt-p2v.log.  So I copied it and am pasting its contents
>  below.
>
>  (eval): line 75 Gtk-WARNING **:Could not find the icon
>  'gtk-dialog-warning'. The 'hicolor' theme was not found either,
>  perhaps you need to install it. You can get a copy from:
>  http://icon-theme.freedesktop.org/releases /dev/cciss!c0d0: No such
>  file or directory
>  /usr/lib/ruby/gems/1.8/gems/virt-p2v-0.8.3/lib/virt-p2v/converter.rb:138:in
>  `Integer': invalid value for Integer: "" from 
You've hit a bug here caused by not handling your smartarray properly. I 
haven't tested against these slightly strange controllers before, so I'm 
not surprised you're hitting bugs. In this specific case, the client 
doesn't like the output of the command:

blockdev --getsize64 /dev/cciss!c0d0

To be honest, I'd expect you to hit more bugs on the server side when 
the conversion code tries to rename all your drives.

I'm aware of how common these controllers are, so handling them properly 
is high on the todo list. I've managed to get some hardware to test this 
on, so hopefully I'll fix it soon.

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

[Greg Scott]

>  You've hit a bug here caused by not handling your smartarray
> properly. 
I'm willing to use this box for testing if you want.  I also have a very
old original Compaq ML370 server here at my place I need to P2V someday
and it has a different old smartarray controller.  And I have another
customer with a Dell RAID controller and I'll be ready to try that one
in a couple weeks.  

- Greg

[Greg Scott]

In the meantime - does anyone have guidance on how to install the virtio
block driver onto the physical host proactively - with the idea being
the migrated virtual server will use it when it boots?  

> > You've hit a bug here caused by not handling your smartarray
properly.

>  I'm willing to use this box for testing if you want.  I also have
> a 
very
>  old original Compaq ML370 server here at my place I need to P2V
someday
>  and it has a different old smartarray controller.  And I have
> another
>  customer with a Dell RAID controller and I'll be ready to try that one
>  in a couple weeks.   
Thanks

- Greg




_______________________________________________
virt mailing list
virt(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/virt

[Matthew Booth]

On 06/10/11 15:46, Greg Scott wrote:
>  In the meantime - does anyone have guidance on how to install the
> virtio
>  block driver onto the physical host proactively - with the idea being
>  the migrated virtual server will use it when it boots? 
It's more than a little awkward! If you can read perl, have a look in 
Windows.pm from virt-v2v. It opens the guest image with libguestfs, 
copies the driver file over and pokes some keys into the registry for 
the driver and its entry in the CDD.

Everything else it does you can do manually after the guest boots.

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

[Greg Scott]

Thanks.  I don't know anything about perl, but how tough can it be?  Is
there a handy download link?

- Greg

-----Original Message-----
From: Matthew Booth [mailto:[e-mail]] 
Sent: Thursday, October 06, 2011 9:55 AM
To: Greg Scott
Cc: virt(a)lists.fedoraproject.org
Subject: Re: [fedora-virt] Restored Windows Server 2003 VM goes black

On 06/10/11 15:46, Greg Scott wrote:
>  In the meantime - does anyone have guidance on how to install the
virtio
>  block driver onto the physical host proactively - with the idea
> being
>  the migrated virtual server will use it when it boots? 
It's more than a little awkward! If you can read perl, have a look in 
Windows.pm from virt-v2v. It opens the guest image with libguestfs, 
copies the driver file over and pokes some keys into the registry for 
the driver and its entry in the CDD.

Everything else it does you can do manually after the guest boots.

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

[Matthew Booth]

On 06/10/11 16:10, Greg Scott wrote:
>  Thanks.  I don't know anything about perl, but how tough can it
> be?  Is
>  there a handy download link? 
Have at look in 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/Windows.pm on a 
machine with virt-v2v installed.

Matt

>  -----Original Message-----
>  From: Matthew Booth [mailto:[e-mail]]
>  Sent: Thursday, October 06, 2011 9:55 AM
>  To: Greg Scott
>  Cc: virt(a)lists.fedoraproject.org
>  Subject: Re: [fedora-virt] Restored Windows Server 2003 VM goes black
>
>  On 06/10/11 15:46, Greg Scott wrote:
> > In the meantime - does anyone have guidance on how to install the
>  virtio
> > block driver onto the physical host proactively - with the idea being
> > the migrated virtual server will use it when it boots?
>
>  It's more than a little awkward! If you can read perl, have a look in
>  Windows.pm from virt-v2v. It opens the guest image with libguestfs,
>  copies the driver file over and pokes some keys into the registry for
>  the driver and its entry in the CDD.
>
>  Everything else it does you can do manually after the guest boots.
>
>  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

[Greg Scott]

This has possibilities.  I just did yum install virt-v2v on a handy
Fedora 14 VM here.  The path is a little different:

[root@p2v32bit Converter]#
[root@p2v32bit Converter]# pwd
/usr/share/perl5/Sys/VirtConvert/Converter
[root@p2v32bit Converter]# ls
RedHat.pm  Windows.pm
[root@p2v32bit Converter]#

Looking over Windows.pm, it looks like it spells out the registry keys
nicely.  Maybe I can put something together to put the files where they
belong and insert those registry keys.  Let me see what I can come up
with and I'll post the results here.

- Greg



-----Original Message-----
From: Matthew Booth [mailto:[e-mail]] 
Sent: Thursday, October 06, 2011 10:50 AM
To: Greg Scott
Cc: virt(a)lists.fedoraproject.org
Subject: Re: [fedora-virt] Restored Windows Server 2003 VM goes black

On 06/10/11 16:10, Greg Scott wrote:
>  Thanks.  I don't know anything about perl, but how tough can it
> be? 
Is
>  there a handy download link? 
Have at look in 
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/Windows.pm on a 
machine with virt-v2v installed.

Matt

>  -----Original Message-----
>  From: Matthew Booth [mailto:[e-mail]]
>  Sent: Thursday, October 06, 2011 9:55 AM
>  To: Greg Scott
>  Cc: virt(a)lists.fedoraproject.org
>  Subject: Re: [fedora-virt] Restored Windows Server 2003 VM goes black
>
>  On 06/10/11 15:46, Greg Scott wrote:
> > In the meantime - does anyone have guidance on how to install the
>  virtio
> > block driver onto the physical host proactively - with the idea being
> > the migrated virtual server will use it when it boots?
>
>  It's more than a little awkward! If you can read perl, have a look in
>  Windows.pm from virt-v2v. It opens the guest image with libguestfs,
>  copies the driver file over and pokes some keys into the registry for
>  the driver and its entry in the CDD.
>
>  Everything else it does you can do manually after the guest boots.
>
>  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

[Greg Scott]

Looking over Windows.pm and viostor.inf, and looking at a Windows 2008R2
VM with the virtio-win drivers installed - it looks like I need to
insert some registry keys in HKLM\SYSTEM\CurrentControlSet.  I see the
CurerntControlSet stuff in Windows.pm and I can handle that in a .reg
file.  It all seems laid out pretty nicely.  

Looking over the registry in my 2008R2 VM, I also see references to
viostor in:

HKLM\Software\Microsoft\CurrentVersion\Setup\PnpLockdownFiles
HKLM\Software\Wow6432Node\Microsoft\CurrentVersion\Setup\PnpLockdownFile
s
HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 2

I'm not sure how these keys get in there - the HARDWARE one probably
because Windows finds the virtual device.  Maybe the driver puts in the
PnpLockdownFiles entries? 

Looks like the only file I need to copy is viostor.sys and it needs to
go into system32\drivers.  There's some code in Windows.pm that looks
like it sets up a special path for all the virtio stuff, but I don't see
any evidence of it in the actual VM - ahh - but my sample 2008R2 VM was
built from scratch, while Windows.pm is for a P2V or V2V, so maybe
that's the difference.  So I can put in the DevicePath registry keys in
my .reg file to handle that.  

One question - is the 2008 viostor.sys different than the 2003 one?  If
so, I can test for the OS version and copy the appropriate flavor.

Thanks

- Greg




-----Original Message-----
From: virt-bounces(a)lists.fedoraproject.org
[mailto:[e-mail]] On Behalf Of Greg Scott
Sent: Thursday, October 06, 2011 11:43 AM
To: Matthew Booth
Cc: virt(a)lists.fedoraproject.org
Subject: Re: [fedora-virt] Restored Windows Server 2003 VM goes black

This has possibilities.  I just did yum install virt-v2v on a handy
Fedora 14 VM here.  The path is a little different:

[root@p2v32bit Converter]#
[root@p2v32bit Converter]# pwd
/usr/share/perl5/Sys/VirtConvert/Converter
[root@p2v32bit Converter]# ls
RedHat.pm  Windows.pm
[root@p2v32bit Converter]#

Looking over Windows.pm, it looks like it spells out the registry keys
nicely.  Maybe I can put something together to put the files where they
belong and insert those registry keys.  Let me see what I can come up
with and I'll post the results here.
- Greg

P2V migration hack when all else fails

[Greg Scott]

Thanks to help from Matthew Booth allowing me to blatantly rip off his
work - we now have a tool to help with P2V migrations when the source
Windows machine has no compatible boot disk driver to run in the target
virtual machine.  The idea is to put the viostor virtio disk driver and
supporting registry keys in the source physical machine first, before
migrating it.  Use this hack when booting from the virt-p2v CD doesn't
work.

I just did this successfully with a Windows 2003 server. I haven't tried
it yet with anything else.  The physical server is an aging HP Proliant
with an HP RAID controller that doesn't get along well with virt-p2v.
The target VM uses a virtio disk for its boot drive.  It also has a
couple of other virtio disks to match the source physical machine, but
these aren't important. 

Borrowing heavily from the Microsoft procedure to restore a Windows
Server from bare metal and Matthew Booth's libguestfs work, here are the
steps to follow for Windows Server 2003:

First, provision a Windows Server 2003 VM in your RHEV or RHEL
environment.  Be sure to use virtio disks, **not** IDE disks.  Also use
a virtio NIC.  Install a fresh copy of Windows Server in the VM.  Do the
simplest, vanilla install possible.  Don't activate with Microsoft yet.
You'll have 30 days.

Get a copy of the latest Windows virtio driver, named viostor.sys.  Save
this file somewhere convenient.  Install the virtio disk and NIC drivers
in your newly provisioned VM.  

Here is the hack.  Save and run a variant of the script below, named
SetupViostor.bat.  Also save a copy of viostor.reg below.  You will want
to change paths to suit your local conditions.  

****Copy and paste SetupViostor.bat below.

@echo on

copy
D:\Installs\virtio-win\virtio-win-prewhql-0.1\extracted\WXp\x86\viostor.
sys c:\windows\system32\drivers\viostor.sys

d:\installs\GregRHEVHack\viostor.reg

****End copy and paste.

Here is a copy of viostor.reg:

************* copy and paste viostor.reg below.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatab
ase\pci#ven_1af4&dev_1001&subsys_00000000]
"Service"="viostor"
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatab
ase\pci#ven_1af4&dev_1001&subsys_00020000]
"Service"="viostor"
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatab
ase\pci#ven_1af4&dev_1001&subsys_00021af4]
"Service"="viostor"
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\viostor]
"Type"=dword:00000001
"Start"=dword:00000000
"Group"="SCSI miniport"
"ErrorControl"=dword:00000001
"ImagePath"="system32\drivers\viostor.sys"
"Tag"=dword:00000021

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\viostor\Parameters
]
"BusType"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\viostor\Parameters
\MaxTransferSize]
"ParamDesc"="Maximum Transfer Size"
"type"="enum"
"default"="0"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\viostor\Parameters
\MaxTransferSize\enum]
"0"="64  KB"
"1"="128 KB"
"2"="256 KB"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\viostor\Parameters
\PnpInterface]
"5"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\viostor\Enum]
"0"="PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\3&13c0b0c5&0&20"
"Count"=dword:00000001
"NextInstance"=dword:00000001
REGEDITS

*************End copy and paste.

Run SetupViostor.bat on the source physical Windows 2003 Server system.
This sets up the viostor disk driver, so the subsequent VM will
recognize the virtio disk driver and boot from it.  

Now the process follows Microsoft's bare metal restore.  

On the source physical Windows Server 2003 system, use ntbackup to make
a backup of your C drive and all other drives on your source physical
server.  Also back up your system state.  Put the savesets someplace
accessible by the target VM you just built.  

> From the target VM, use ntbackup to restore the savesets you just
created earlier.  Restore all data disks first, then the system disk,
then system state, in that order.  

After restoring the system state, disconnect the source physical machine
from the network and reboot the target VM.  It should come up looking
nearly identical to the source physical machine.  It will need a bunch
of drivers for its virtual hardware, but these are easy to add with a
running machine.  

Final step - never connect the old source physical machine to the
network again.