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
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@lists.fedoraproject.org [mailto:virt-bounces@lists.fedoraproject.org] On Behalf Of Greg Scott Sent: Monday, October 03, 2011 10:09 AM To: virt@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
----- Original Message -----
From: "Greg Scott" GregScott@Infrasupport.com To: virt@lists.fedoraproject.org Cc: "Hisao Taguchi" hisao.taguchi@uniadex.co.jp 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@lists.fedoraproject.org [mailto:virt-bounces@lists.fedoraproject.org] On Behalf Of Greg Scott Sent: Monday, October 03, 2011 10:09 AM To: virt@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/virt
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.
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
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/virt
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
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:mbooth@redhat.com] Sent: Thursday, October 06, 2011 9:55 AM To: Greg Scott Cc: virt@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
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:mbooth@redhat.com] Sent: Thursday, October 06, 2011 9:55 AM To: Greg Scott Cc: virt@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
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:mbooth@redhat.com] Sent: Thursday, October 06, 2011 10:50 AM To: Greg Scott Cc: virt@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:mbooth@redhat.com] Sent: Thursday, October 06, 2011 9:55 AM To: Greg Scott Cc: virt@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
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@lists.fedoraproject.org [mailto:virt-bounces@lists.fedoraproject.org] On Behalf Of Greg Scott Sent: Thursday, October 06, 2011 11:43 AM To: Matthew Booth Cc: virt@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
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.