Steps
1. Inject VirtIO drivers
1.1 Windows Server 2012
Since Windows Server 2012 and Windows 8.0, the driver store is protected
by Windows. It is very hard to inject drivers in an offline Windows
disk. Windows Server 2012 does not boot from VirtIO hardware by default.
So, I took these next steps to install the VirtIO drivers into Windows.
Note that these steps should work for all tested Windows versions
(2003/2008/2012).
- Create a new KVM instance. Make sure the Windows vmdk disk is
created as IDE disk! The network card should be a VirtIO device. - Add an extra VirtIO disk, so Windows can install the VirtIO drivers.
- Off course you should add a VirtIO ISO or floppy drive which
contains the drivers. You could also inject the driver files with
virt-copy-in and inject the necessary registry settings (see
paragraph 4.4) for automatic installation of the drivers. - Start the virtual machine and give Windows about two minutes to find
the new VirtIO hardware. Install the drivers for all newly
found hardware. Verify that there are no devices that have no
driver installed. - Shutdown the system and remove the extra VirtIO disk.
- Redefine the Windows vmdk disk as VirtIO disk (this was IDE) and
start the instance. It should now boot without problems. Shut down
the virtual machine.
1.4 Windows Server 2008 (and older versions); deprecated
For Windows versions prior to 2012 you could also use these steps to
insert the drivers (the steps in 4.1 should also work for Windows
2003/2008).
- Copy all VirtIO driver files (from the downloaded VirtIO drivers) of
the corresponding Windows version and architecture to C:Drivers.
You can use the tool virt-copy-in to copy files and folders into the
virtual disk. - Copy *.sys files to %WINDIR%system32drivers (you may want to
use virt-ls to look for the correct directory. Note that Windows is
not very consistent with lower and upper case characters). You can
use the tool virt-copy-in to copy files and folders into the
virtual disk. - The Windows registry should combine the hardware ID’s and drivers,
but there are no VirtIO drivers installed in Windows by default. So
we need to do this by ourselves. You could inject the registry file
with virt-win-reg. If you choose to copy all VirtIO drivers to an
other location than C:Drivers, you must change the “DevicePath”
variable in the last line (the most easy way is to change it in some
Windows machine and then export the registry file, and use
that line).
Registry file (I called the file mergeviostor.reg, as it holds the
VirtIO storage information only):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESYSTEMControlSet001ControlCriticalDeviceDatabasepci#ven_1af4&dev_1001&subsys_00000000]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"
[HKEY_LOCAL_MACHINESYSTEMControlSet001ControlCriticalDeviceDatabasepci#ven_1af4&dev_1001&subsys_00020000]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"
[HKEY_LOCAL_MACHINESYSTEMControlSet001ControlCriticalDeviceDatabasepci#ven_1af4&dev_1001&subsys_00021AF4]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"
[HKEY_LOCAL_MACHINESYSTEMControlSet001ControlCriticalDeviceDatabasepci#ven_1af4&dev_1001&subsys_00021AF4&rev_00]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"
[HKEY_LOCAL_MACHINESYSTEMControlSet001ControlCriticalDeviceDatabasepci#ven_1af4&dev_1004&subsys_00081af&rev_00]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"Service"="viostor"
[HKEY_LOCAL_MACHINESYSTEMControlSet001Servicesviostor]
"ErrorControl"=dword:00000001
"Group"="SCSI miniport"
"Start"=dword:00000000
"Tag"=dword:00000021
"Type"=dword:00000001
"ImagePath"="system32driversviostor.sys"
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion]
"DevicePath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,00,5c,00,69,00,6e,00,66,00,3b,00,63,00,3a,00,5c,00,44,00,72,00,69,00,76,00,65,00,72,00,73,00,00,00
When these steps have been executed, Windows should boot from VirtIO
disks without BSOD. Also all other drivers (network, balloon etc.)
should install automatically when Windows boots.
See: https://support.microsoft.com/en-us/kb/314082 (written for
Windows XP, but it is still usable for Windows 2003 and 2008).
See also: http://libguestfs.org/virt-copy-in.1.html and
http://libguestfs.org/virt-win-reg.1.html
3.2 Automatically start scripts in Windows
I choose the RunOnce method to start scripts at Windows boot as it works
on all versions of Windows that I had to migrate. You can put a script
in the RunOnce by injecting a registry file. RunOnce scripts are only
run when a user has logged in. So, you should also inject a Windows
administrator UserName, Password and set AutoAdminLogon to ‘1’. When
Windows starts, it will automatically log in as the defined user. Make
sure to shut down the virtual machine when done.
Example registry file to auto login into Windows (with user
‘Administrator’ and password ‘Password’) and start the
C:StartupWinScript.vbs.:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce]
"Script"="cscript C:StartupWinScript.vbs"
"Parameters"=""
[HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogon]
"AutoAdminLogon"="1"
"UserName"="Administrator"
"Password"="Password"
5. Convert VMDK to Ceph
As soon as the Cinder volumes are created, we can convert the VMDK disk
files to RBD blocks (Ceph). But first we need to remove the actual Ceph
disk. Make sure you remove the correct Ceph block device!
In the first place you should know in which Ceph pool the disk resides.
Then remove the volume from Ceph (the volume-id is the volume id that
you noted in the previous step ‘Create Cinder volumes’):
rbd -p <ceph_pool> rm volume-<volume-id>
Next step is to convert the VMDK file into the volume on Ceph (all
ceph* arguments will result in better performance. The
vmdk_disk_file variable is the complete path to the vmdk file. The
volume-id is the ID that you noted before).
qemu-img convert -p <vmdk_disk_file> -O rbd rbd:<ceph_pool>/volume-<volume-id>
Do this for all virtual disks of the virtual machine.
Be careful! The rbd command is VERY powerful (you could destroy more
data on Ceph than intended)!
First, you have to export your VM. The simplest way to do so is by exporting an OVA using vCenter UI ( OVA is the standard format for packaging VMs ). Second, the VM needs to be converted KVM – this means converting the volumes, the metadata and replacing drivers inside the guest VMs. The entire conversion can be done by using virt-v2v. Virt-v2v converts guests from a foreign hypervisor to run on KVM. It can can read Linux and Windows guests running on VMware, Xen, Hyper-V and some other hypervisors, and convert them to KVM managed by OpenStack, or several other targets.
Link to Manual
virt-v2v