[PATCH 0/7] Add support for SUSE virtio windows drivers
Hi there, SUSE ships Virtual Machine Driver Pack for the virtio windows drivers. Get v2v and customize to discover them and use them if available. Cédric Bosdonnat (7): v2v: check next free oem%d.inf in /Windows/Inf v2v: extract controller offset discovery as a function customize: add support for pvvxsvc v2v: extract reusable parts of viostor regedits v2v: adapt the subkey in Enum registry to windows version v2v: quiet virtio net and balloon devices wizards v2v: add support for SUSE VMDP drivers builder/virt-builder.pod | 13 +- customize/firstboot.ml | 169 ++++++++------- customize/virt-customize.pod | 6 + sysprep/virt-sysprep.pod | 6 + v2v/convert_windows.ml | 59 ++++-- v2v/virt-v2v.pod | 6 + v2v/windows_virtio.ml | 493 +++++++++++++++++++++++++++---------------- 7 files changed, 476 insertions(+), 276 deletions(-) -- 2.6.2
It seems that checking for oem%d.inf in the DeviceIds registry entry doesn't always list all oemXX.inf files. For example we may have oem1.inf free in the registry key, but used in another one. Also extract this into a separate function for later use to setup another driver. --- v2v/windows_virtio.ml | 52 ++++++++++++++++++++++++++------------------------- 1 file changed, 27 insertions(+), 25 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index f538b36..b0d9d08 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -82,7 +82,7 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = let target = sprintf "%s/system32/drivers/viostor.sys" systemroot in let target = g#case_sensitive_path target in g#cp source target; - add_viostor_to_registry g inspect root current_cs; + add_viostor_to_registry g inspect root current_cs driverdir; Virtio_blk | Some IDE, _ -> @@ -133,11 +133,11 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = (block, net, video) ) -and add_viostor_to_registry g inspect root current_cs = +and add_viostor_to_registry g inspect root current_cs driverdir = let { i_major_version = major; i_minor_version = minor; i_arch = arch } = inspect in if (major == 6 && minor >= 2) || major >= 7 then (* Windows >= 8 *) - add_viostor_to_driver_database g root arch current_cs + add_viostor_to_driver_database g root arch current_cs driverdir else (* Windows <= 7 *) add_viostor_to_critical_device_database g root current_cs @@ -195,7 +195,7 @@ and add_viostor_to_critical_device_database g root current_cs = reg_import g root regedits -and add_viostor_to_driver_database g root arch current_cs = +and add_viostor_to_driver_database g root arch current_cs driverdir = (* Windows >= 8 doesn't use the CriticalDeviceDatabase. Instead * one must add keys into the DriverDatabase. *) @@ -213,27 +213,7 @@ and add_viostor_to_driver_database g root arch current_cs = sprintf "viostor.inf_%s_%s" arch "c86329aaeb0a7904" in let scsi_adapter_guid = "{4d36e97b-e325-11ce-bfc1-08002be10318}" in - (* There should be a key - * HKLM\SYSTEM\DriverDatabase\DeviceIds\<scsi_adapter_guid> - * We want to add: - * "oem1.inf"=hex(0): - * but if we find "oem1.inf" we'll add "oem2.inf" (etc). - *) - let oem_inf = - let path = [ "DriverDatabase"; "DeviceIds"; scsi_adapter_guid ] in - match Windows.get_node g root path with - | None -> - error (f_"cannot find HKLM\\SYSTEM\\DriverDatabase\\DeviceIds\\%s in the guest registry") scsi_adapter_guid - | Some node -> - let rec loop node i = - let oem_inf = sprintf "oem%d.inf" i in - let value = g#hivex_node_get_value node oem_inf in - if value = 0_L then oem_inf else loop node (i+1) - in - let oem_inf = loop node 1 in - (* Create the key. *) - g#hivex_node_set_value node oem_inf (* REG_NONE *) 0_L ""; - oem_inf in + let oem_inf = set_free_oem_inf g root scsi_adapter_guid "viostor.inf" driverdir in (* There should be a key * HKLM\SYSTEM\ControlSet001\Control\Class\<scsi_adapter_guid> @@ -398,6 +378,28 @@ and add_viostor_to_driver_database g root arch current_cs = @=hex(ffff0012):6f,00,65,00,6d,00,31,00,2e,00,69,00,6e,00,66,00,00,00 *) +(* There should be a key + * HKLM\SYSTEM\DriverDatabase\DeviceIds\<guid> + * We want to add: + * "oem1.inf"=hex(0): + * but if we find "oem1.inf" we'll add "oem2.inf" (etc). + *) +and set_free_oem_inf g root guid driver_inf driverdir = + let path = [ "DriverDatabase"; "DeviceIds"; guid ] in + match Windows.get_node g root path with + | None -> + error (f_"cannot find HKLM\\SYSTEM\\DriverDatabase\\DeviceIds\\%s in the guest registry") guid + | Some node -> + let rec loop i = + let oem_inf = sprintf "oem%d.inf" i in + if not (g#exists ("/Windows/Inf/" ^ oem_inf)) then oem_inf else loop (i+1) + in + let oem_inf = loop 1 in + (* Create the key. *) + g#hivex_node_set_value node oem_inf (* REG_NONE *) 0_L ""; + g#cp (driverdir // driver_inf) ("/Windows/Inf/" ^ oem_inf); + oem_inf + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
On Tue, Apr 05, 2016 at 01:47:27PM +0200, Cédric Bosdonnat wrote:
+ let oem_inf = set_free_oem_inf g root scsi_adapter_guid "viostor.inf" driverdir in
Seems better if it was called *get_next*_free_oem_inf?
(* There should be a key * HKLM\SYSTEM\ControlSet001\Control\Class\<scsi_adapter_guid> @@ -398,6 +378,28 @@ and add_viostor_to_driver_database g root arch current_cs = @=hex(ffff0012):6f,00,65,00,6d,00,31,00,2e,00,69,00,6e,00,66,00,00,00 *)
+(* There should be a key + * HKLM\SYSTEM\DriverDatabase\DeviceIds\<guid> + * We want to add: + * "oem1.inf"=hex(0): + * but if we find "oem1.inf" we'll add "oem2.inf" (etc). + *) +and set_free_oem_inf g root guid driver_inf driverdir = + let path = [ "DriverDatabase"; "DeviceIds"; guid ] in + match Windows.get_node g root path with + | None -> + error (f_"cannot find HKLM\\SYSTEM\\DriverDatabase\\DeviceIds\\%s in the guest registry") guid + | Some node -> + let rec loop i = + let oem_inf = sprintf "oem%d.inf" i in + if not (g#exists ("/Windows/Inf/" ^ oem_inf)) then oem_inf else loop (i+1) + in
This bit doesn't match what is described in the comment. It's also incorrect for a few reasons: - It should use windows_systemroot, instead of "/Windows" - It doesn't handle case sensitive path stuff Do we still need to check for the registry key? (I have no idea)
+ let oem_inf = loop 1 in + (* Create the key. *) + g#hivex_node_set_value node oem_inf (* REG_NONE *) 0_L ""; + g#cp (driverdir // driver_inf) ("/Windows/Inf/" ^ oem_inf);
And this line seems like a bit of a hack. We have a place where drivers are copied into the driverdir. I think it would be better if we returned oem_inf from add_viostor_to_registry. But ... Do we actually need to do this copy at all? The Red Hat drivers don't require this, in order to boot (note that with the Red Hat drivers we only half install them, they are properly installed when Windows boots). Rich.
+ oem_inf + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Tue, 2016-04-05 at 13:04 +0100, Richard W.M. Jones wrote:
On Tue, Apr 05, 2016 at 01:47:27PM +0200, Cédric Bosdonnat wrote:
+ let oem_inf = set_free_oem_inf g root scsi_adapter_guid "viostor.inf" driverdir in
Seems better if it was called *get_next*_free_oem_inf?
Yes, sounds better.
(* There should be a key * HKLM\SYSTEM\ControlSet001\Control\Class\<scsi_adapter_guid> @@ -398,6 +378,28 @@ and add_viostor_to_driver_database g root arch current_cs =
@=hex(ffff0012):6f,00,65,00,6d,00,31,00,2e,00,69,00,6e,00,66,00,00 ,00 *)
+(* There should be a key + * HKLM\SYSTEM\DriverDatabase\DeviceIds\<guid> + * We want to add: + * "oem1.inf"=hex(0): + * but if we find "oem1.inf" we'll add "oem2.inf" (etc). + *) +and set_free_oem_inf g root guid driver_inf driverdir = + let path = [ "DriverDatabase"; "DeviceIds"; guid ] in + match Windows.get_node g root path with + | None -> + error (f_"cannot find HKLM\\SYSTEM\\DriverDatabase\\DeviceIds\\%s in the guest registry") guid + | Some node -> + let rec loop i = + let oem_inf = sprintf "oem%d.inf" i in + if not (g#exists ("/Windows/Inf/" ^ oem_inf)) then oem_inf else loop (i+1) + in
This bit doesn't match what is described in the comment. It's also incorrect for a few reasons:
May be I should add to the comment that it searches for the next available oem%d.inf in the Windows\Inf folder?
- It should use windows_systemroot, instead of "/Windows"
- It doesn't handle case sensitive path stuff
Indeed, I'll need to fix those
Do we still need to check for the registry key? (I have no idea)
As we add the key just a few lines below, we need to check for it
+ let oem_inf = loop 1 in + (* Create the key. *) + g#hivex_node_set_value node oem_inf (* REG_NONE *) 0_L ""; + g#cp (driverdir // driver_inf) ("/Windows/Inf/" ^ oem_inf);
And this line seems like a bit of a hack. We have a place where drivers are copied into the driverdir. I think it would be better if we returned oem_inf from add_viostor_to_registry. But ...
It's not exactly in driverdir, it's in a subfolder of it. The problem is that it seems that Windows gets the next available oem%d.inf from the files in /Windows/Inf... if we aren't copying them manually while we reserve it, we end up with conflicts when we have more than one driver to add. I don't see why you say you'ld see oem_inf returned from add_viostor_to_registry: we don't need it outside that function, right?
Do we actually need to do this copy at all? The Red Hat drivers don't require this, in order to boot (note that with the Red Hat drivers we only half install them, they are properly installed when Windows boots).
The virtio block driver from SUSE VMDP has a dependency on the balloon driver. That's why we need to half install these two before the first boot. The situation is cleaned up at first boot and the other drivers are installed at that time too. -- Cedric
Rich.
+ oem_inf + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
On Tue, Apr 05, 2016 at 02:24:33PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 13:04 +0100, Richard W.M. Jones wrote:
On Tue, Apr 05, 2016 at 01:47:27PM +0200, Cédric Bosdonnat wrote:
+ let oem_inf = set_free_oem_inf g root scsi_adapter_guid "viostor.inf" driverdir in
Seems better if it was called *get_next*_free_oem_inf?
Yes, sounds better.
(* There should be a key * HKLM\SYSTEM\ControlSet001\Control\Class\<scsi_adapter_guid> @@ -398,6 +378,28 @@ and add_viostor_to_driver_database g root arch current_cs =
@=hex(ffff0012):6f,00,65,00,6d,00,31,00,2e,00,69,00,6e,00,66,00,00 ,00 *)
+(* There should be a key + * HKLM\SYSTEM\DriverDatabase\DeviceIds\<guid> + * We want to add: + * "oem1.inf"=hex(0): + * but if we find "oem1.inf" we'll add "oem2.inf" (etc). + *) +and set_free_oem_inf g root guid driver_inf driverdir = + let path = [ "DriverDatabase"; "DeviceIds"; guid ] in + match Windows.get_node g root path with + | None -> + error (f_"cannot find HKLM\\SYSTEM\\DriverDatabase\\DeviceIds\\%s in the guest registry") guid + | Some node -> + let rec loop i = + let oem_inf = sprintf "oem%d.inf" i in + if not (g#exists ("/Windows/Inf/" ^ oem_inf)) then oem_inf else loop (i+1) + in
This bit doesn't match what is described in the comment. It's also incorrect for a few reasons:
May be I should add to the comment that it searches for the next available oem%d.inf in the Windows\Inf folder?
That would seem to be more accurate. On the other points, I'd like to see what Roman suggests. Maybe we can just make up a random name instead of using oemNN.inf? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Tue, Apr 05, 2016 at 01:47:27PM +0200, Cédric Bosdonnat wrote:
It seems that checking for oem%d.inf in the DeviceIds registry entry doesn't always list all oemXX.inf files. For example we may have oem1.inf free in the registry key, but used in another one.
In my experiments this name doesn't have to bear any sense, so there's no point doing anything smart about it. FWIW I've been working on an alternative apporoach (mostly about reducing the amount of regedits) and was about to submit the patches today. I guess it'd accomodate SUSE driver suite just as well. Roman.
On Tue, 2016-04-05 at 15:13 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:27PM +0200, Cédric Bosdonnat wrote:
It seems that checking for oem%d.inf in the DeviceIds registry entry doesn't always list all oemXX.inf files. For example we may have oem1.inf free in the registry key, but used in another one.
In my experiments this name doesn't have to bear any sense, so there's no point doing anything smart about it.
What I did was not a strictly scientific approach, rather trying to mimic what seemed to happen ;)
FWIW I've been working on an alternative apporoach (mostly about reducing the amount of regedits) and was about to submit the patches today. I guess it'd accomodate SUSE driver suite just as well.
Cool, I'ld be happy to test your patches together with mines ;) -- Cedric
This function is needed for other drivers, move the code in order to help sharing it later. --- v2v/windows_virtio.ml | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index b0d9d08..14ffc51 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -226,18 +226,7 @@ and add_viostor_to_driver_database g root arch current_cs driverdir = *) let controller_path = [ current_cs; "Control"; "Class"; scsi_adapter_guid ] in - let controller_offset = - match Windows.get_node g root controller_path with - | None -> - error (f_"cannot find HKLM\\SYSTEM\\%s in the guest registry") - (String.concat "\\" controller_path) - | Some node -> - let rec loop node i = - let controller_offset = sprintf "%04d" i in - let child = g#hivex_node_get_child node controller_offset in - if child = 0_L then controller_offset else loop node (i+1) - in - loop node 0 in + let controller_offset = get_controller_offset g root controller_path in let regedits = [ controller_path @ [ controller_offset ], @@ -400,6 +389,19 @@ and set_free_oem_inf g root guid driver_inf driverdir = g#cp (driverdir // driver_inf) ("/Windows/Inf/" ^ oem_inf); oem_inf +and get_controller_offset g root controller_path = + match Windows.get_node g root controller_path with + | None -> + error (f_"cannot find HKLM\\SYSTEM\\%s in the guest registry") + (String.concat "\\" controller_path) + | Some node -> + let rec loop node i = + let controller_offset = sprintf "%04d" i in + let child = g#hivex_node_get_child node controller_offset in + if child = 0_L then controller_offset else loop node (i+1) + in + loop node 0 + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
On Tue, Apr 05, 2016 at 01:47:28PM +0200, Cédric Bosdonnat wrote:
This function is needed for other drivers, move the code in order to help sharing it later.
Simple refactoring, looks fine. Rich.
v2v/windows_virtio.ml | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index b0d9d08..14ffc51 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -226,18 +226,7 @@ and add_viostor_to_driver_database g root arch current_cs driverdir = *) let controller_path = [ current_cs; "Control"; "Class"; scsi_adapter_guid ] in - let controller_offset = - match Windows.get_node g root controller_path with - | None -> - error (f_"cannot find HKLM\\SYSTEM\\%s in the guest registry") - (String.concat "\\" controller_path) - | Some node -> - let rec loop node i = - let controller_offset = sprintf "%04d" i in - let child = g#hivex_node_get_child node controller_offset in - if child = 0_L then controller_offset else loop node (i+1) - in - loop node 0 in + let controller_offset = get_controller_offset g root controller_path in
let regedits = [ controller_path @ [ controller_offset ], @@ -400,6 +389,19 @@ and set_free_oem_inf g root guid driver_inf driverdir = g#cp (driverdir // driver_inf) ("/Windows/Inf/" ^ oem_inf); oem_inf
+and get_controller_offset g root controller_path = + match Windows.get_node g root controller_path with + | None -> + error (f_"cannot find HKLM\\SYSTEM\\%s in the guest registry") + (String.concat "\\" controller_path) + | Some node -> + let rec loop node i = + let controller_offset = sprintf "%04d" i in + let child = g#hivex_node_get_child node controller_offset in + if child = 0_L then controller_offset else loop node (i+1) + in + loop node 0 + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Tue, Apr 05, 2016 at 01:47:28PM +0200, Cédric Bosdonnat wrote:
This function is needed for other drivers, move the code in order to help sharing it later.
In my experiments this key isn't necessary at all, so I was about to nuke it altogether. Roman.
SUSE VMDP comes with a replacement for rhsrvany.exe named pvvxsvc.exe. Check for either one of them instead of only rhsrvany. --- builder/virt-builder.pod | 13 +++- customize/firstboot.ml | 169 +++++++++++++++++++++++-------------------- customize/virt-customize.pod | 6 ++ sysprep/virt-sysprep.pod | 6 ++ v2v/virt-v2v.pod | 6 ++ 5 files changed, 117 insertions(+), 83 deletions(-) diff --git a/builder/virt-builder.pod b/builder/virt-builder.pod index 9a49138..be5b568 100644 --- a/builder/virt-builder.pod +++ b/builder/virt-builder.pod @@ -840,16 +840,17 @@ F<~root/virt-sysprep-firstboot.log>. =item Windows F<rhsrvany.exe>, available from sources at -L<https://github.com/rwmjones/rhsrvany>, is installed to run the +L<https://github.com/rwmjones/rhsrvany>, or F<pvvxsvc.exe>, available +with SUSE VMDP is installed to run the first boot scripts. It is required, and the setup of first boot scripts will fail if it is not present. -F<rhsrvany.exe> is copied from the location pointed to by the +F<rhsrvany.exe> or F<pvvxsvc.exe> is copied from the location pointed to by the C<VIRT_TOOLS_DATA_DIR> environment variable; if not set, a compiled-in default will be used (something like F</usr/share/virt-tools>). The output of the first boot scripts is available in the guest as -F<C:\Program Files\Red Hat\Firstboot\log.txt>. +F<C:\Program Files\Guestfs\Firstboot\log.txt>. =back @@ -1820,6 +1821,12 @@ I<--firstboot> or I<--firstboot-command> options with Windows guests. See also: C<https://github.com/rwmjones/rhsrvany> +=item F<pvvxsvc.exe> + +This is a Windows binary shipped with SUSE VMDP, used to install a "firstboot" +script in Windows guests. It is required if you intend to use the +I<--firstboot> or I<--firstboot-command> options with Windows guests. + =back =item C<XDG_CACHE_HOME> diff --git a/customize/firstboot.ml b/customize/firstboot.ml index aa5b694..d7d791c 100644 --- a/customize/firstboot.ml +++ b/customize/firstboot.ml @@ -185,44 +185,52 @@ module Windows = struct try Sys.getenv "VIRT_TOOLS_DATA_DIR" with Not_found -> Guestfs_config.datadir // "virt-tools" in - (* rhsrvany.exe must exist. + (* either rhsrvany.exe or pvvxsvc.exe must exist. * * (Check also that it's not a dangling symlink but a real file). *) - let rhsrvany_exe = virt_tools_data_dir // "rhsrvany.exe" in - (try - let chan = open_in rhsrvany_exe in - close_in chan - with - Sys_error msg -> - error (f_"'%s' is missing. This file is required in order to install Windows firstboot scripts. You can get it by building rhsrvany (https://github.com/rwmjones/rhsrvany). Original error: %s") - rhsrvany_exe msg - ); - - (* Create a directory for firstboot files in the guest. *) - let firstboot_dir, firstboot_dir_win = - let rec loop firstboot_dir firstboot_dir_win = function - | [] -> firstboot_dir, firstboot_dir_win - | dir :: path -> - let firstboot_dir = - if firstboot_dir = "" then "/" ^ dir else firstboot_dir // dir in - let firstboot_dir_win = firstboot_dir_win ^ "\\" ^ dir in - let firstboot_dir = g#case_sensitive_path firstboot_dir in - g#mkdir_p firstboot_dir; - loop firstboot_dir firstboot_dir_win path - in - loop "" "C:" ["Program Files"; "Red Hat"; "Firstboot"] in - - g#mkdir_p (firstboot_dir // "scripts"); - - (* Copy rhsrvany to the guest. *) - g#upload rhsrvany_exe (firstboot_dir // "rhsrvany.exe"); - - (* Write a firstboot.bat control script which just runs the other - * scripts in the directory. Note we need to use CRLF line endings - * in this script. - *) - let firstboot_script = sprintf "\ + let services = ["rhsrvany.exe"; "pvvxsvc.exe"] in + let srvany = ( + try + List.find ( + fun service -> ( + try + let chan = open_in (virt_tools_data_dir // service) in + close_in chan; + true + with _ -> + false + ) + ) services + with Not_found -> + error (f_"One of rhsrvany.exe or pvvxsvc.exe is missing in %s. One of them is required in order to install Windows firstboot scripts. You can get one by building rhsrvany (https://github.com/rwmjones/rhsrvany)") + virt_tools_data_dir + ) in ( + + (* Create a directory for firstboot files in the guest. *) + let firstboot_dir, firstboot_dir_win = + let rec loop firstboot_dir firstboot_dir_win = function + | [] -> firstboot_dir, firstboot_dir_win + | dir :: path -> + let firstboot_dir = + if firstboot_dir = "" then "/" ^ dir else firstboot_dir // dir in + let firstboot_dir_win = firstboot_dir_win ^ "\\" ^ dir in + let firstboot_dir = g#case_sensitive_path firstboot_dir in + g#mkdir_p firstboot_dir; + loop firstboot_dir firstboot_dir_win path + in + loop "" "C:" ["Program Files"; "Guestfs"; "Firstboot"] in + + g#mkdir_p (firstboot_dir // "scripts"); + + (* Copy pvvxsvc or rhsrvany to the guest. *) + g#upload (virt_tools_data_dir // srvany) (firstboot_dir // srvany); + + (* Write a firstboot.bat control script which just runs the other + * scripts in the directory. Note we need to use CRLF line endings + * in this script. + *) + let firstboot_script = sprintf "\ @echo off setlocal EnableDelayedExpansion @@ -253,51 +261,52 @@ for %%%%f in (\"%%scripts%%\"\\*.bat) do ( ) echo uninstalling firstboot service -rhsrvany.exe -s firstboot uninstall -" firstboot_dir_win in - - g#write (firstboot_dir // "firstboot.bat") (unix2dos firstboot_script); - - (* Open the SYSTEM hive. *) - let systemroot = g#inspect_get_windows_systemroot root in - let filename = sprintf "%s/system32/config/SYSTEM" systemroot in - let filename = g#case_sensitive_path filename in - g#hivex_open ~write:true filename; - - let root_node = g#hivex_root () in - - (* Find the 'Current' ControlSet. *) - let current_cs = - let select = g#hivex_node_get_child root_node "Select" in - let valueh = g#hivex_node_get_value select "Current" in - let value = int_of_le32 (g#hivex_value_value valueh) in - sprintf "ControlSet%03Ld" value in - - (* Add a new rhsrvany service to the system registry to execute firstboot. - * NB: All these edits are in the HKLM\SYSTEM hive. No other - * hive may be modified here. - *) - let regedits = [ - [ current_cs; "services"; "firstboot" ], - [ "Type", REG_DWORD 0x10_l; - "Start", REG_DWORD 0x2_l; - "ErrorControl", REG_DWORD 0x1_l; - "ImagePath", - REG_SZ (firstboot_dir_win ^ "\\rhsrvany.exe -s firstboot"); - "DisplayName", REG_SZ "Virt tools firstboot service"; - "ObjectName", REG_SZ "LocalSystem" ]; - - [ current_cs; "services"; "firstboot"; "Parameters" ], - [ "CommandLine", - REG_SZ ("cmd /c \"" ^ firstboot_dir_win ^ "\\firstboot.bat\""); - "PWD", REG_SZ firstboot_dir_win ]; - ] in - reg_import g root_node regedits; - - g#hivex_commit None; - g#hivex_close (); - - firstboot_dir +%s -s firstboot uninstall +" firstboot_dir_win srvany in + + g#write (firstboot_dir // "firstboot.bat") (unix2dos firstboot_script); + + (* Open the SYSTEM hive. *) + let systemroot = g#inspect_get_windows_systemroot root in + let filename = sprintf "%s/system32/config/SYSTEM" systemroot in + let filename = g#case_sensitive_path filename in + g#hivex_open ~write:true filename; + + let root_node = g#hivex_root () in + + (* Find the 'Current' ControlSet. *) + let current_cs = + let select = g#hivex_node_get_child root_node "Select" in + let valueh = g#hivex_node_get_value select "Current" in + let value = int_of_le32 (g#hivex_value_value valueh) in + sprintf "ControlSet%03Ld" value in + + (* Add a new rhsrvany service to the system registry to execute firstboot. + * NB: All these edits are in the HKLM\SYSTEM hive. No other + * hive may be modified here. + *) + let regedits = [ + [ current_cs; "services"; "firstboot" ], + [ "Type", REG_DWORD 0x10_l; + "Start", REG_DWORD 0x2_l; + "ErrorControl", REG_DWORD 0x1_l; + "ImagePath", + REG_SZ (sprintf "%s\\%s -s firstboot" firstboot_dir_win srvany); + "DisplayName", REG_SZ "Virt tools firstboot service"; + "ObjectName", REG_SZ "LocalSystem" ]; + + [ current_cs; "services"; "firstboot"; "Parameters" ], + [ "CommandLine", + REG_SZ ("cmd /c \"" ^ firstboot_dir_win ^ "\\firstboot.bat\""); + "PWD", REG_SZ firstboot_dir_win ]; + ] in + reg_import g root_node regedits; + + g#hivex_commit None; + g#hivex_close (); + + firstboot_dir + ) end diff --git a/customize/virt-customize.pod b/customize/virt-customize.pod index 8fb9931..7654fee 100644 --- a/customize/virt-customize.pod +++ b/customize/virt-customize.pod @@ -250,6 +250,12 @@ I<--firstboot> or I<--firstboot-command> options with Windows guests. See also: C<https://github.com/rwmjones/rhsrvany> +=item F<pvvxsvc.exe> + +This is a Windows binary shipped with SUSE VMDP, used to install a "firstboot" +script in Windows guests. It is required if you intend to use the +I<--firstboot> or I<--firstboot-command> options with Windows guests. + =back =back diff --git a/sysprep/virt-sysprep.pod b/sysprep/virt-sysprep.pod index 4bbba9a..d86b1e4 100644 --- a/sysprep/virt-sysprep.pod +++ b/sysprep/virt-sysprep.pod @@ -550,6 +550,12 @@ I<--firstboot> or I<--firstboot-command> options with Windows guests. See also: C<https://github.com/rwmjones/rhsrvany> +=item F<pvvxsvc.exe> + +This is a Windows binary shipped with SUSE VMDP, used to install a "firstboot" +script in Windows guests. It is required if you intend to use the +I<--firstboot> or I<--firstboot-command> options with Windows guests. + =back =back diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index bce79c1..894f5ac 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1879,6 +1879,12 @@ script in the guest during conversion of Windows guests. See also: C<https://github.com/rwmjones/rhsrvany> +=item F<pvvxsvc.exe> + +This is a Windows binary shipped with SUSE VMDP, used to install a "firstboot" +script in Windows guests. It is required if you intend to use the +I<--firstboot> or I<--firstboot-command> options with Windows guests. + =item F<rhev-apt.exe> (Optional) -- 2.6.2
On Tue, Apr 05, 2016 at 01:47:29PM +0200, Cédric Bosdonnat wrote:
The output of the first boot scripts is available in the guest as -F<C:\Program Files\Red Hat\Firstboot\log.txt>. +F<C:\Program Files\Guestfs\Firstboot\log.txt>.
Changing this path is fine, but let's split it into a separate patch.
+ let services = ["rhsrvany.exe"; "pvvxsvc.exe"] in + let srvany = ( + try + List.find ( + fun service -> ( + try + let chan = open_in (virt_tools_data_dir // service) in + close_in chan; + true + with _ -> + false + ) + ) services + with Not_found -> + error (f_"One of rhsrvany.exe or pvvxsvc.exe is missing in %s. One of them is required in order to install Windows firstboot scripts. You can get one by building rhsrvany (https://github.com/rwmjones/rhsrvany)") + virt_tools_data_dir + ) in (
There's a stray ( here, and lots of code gets reindented for reasons I don't understand but may be connected to that stray (.
+ g#hivex_commit None; + g#hivex_close (); + + firstboot_dir + )
End of the stray ) and reformatting. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Tue, 2016-04-05 at 13:11 +0100, Richard W.M. Jones wrote:
On Tue, Apr 05, 2016 at 01:47:29PM +0200, Cédric Bosdonnat wrote:
The output of the first boot scripts is available in the guest as -F<C:\Program Files\Red Hat\Firstboot\log.txt>. +F<C:\Program Files\Guestfs\Firstboot\log.txt>.
Changing this path is fine, but let's split it into a separate patch.
Ok, I'll split that one.
+ let services = ["rhsrvany.exe"; "pvvxsvc.exe"] in + let srvany = ( + try + List.find ( + fun service -> ( + try + let chan = open_in (virt_tools_data_dir // service) in + close_in chan; + true + with _ -> + false + ) + ) services + with Not_found -> + error (f_"One of rhsrvany.exe or pvvxsvc.exe is missing in %s. One of them is required in order to install Windows firstboot scripts. You can get one by building rhsrvany ( https://github.com/rwmjones/rhsrvany)") + virt_tools_data_dir + ) in (
There's a stray ( here, and lots of code gets reindented for reasons I don't understand but may be connected to that stray (.
Oh, I think that's an ocaml-beginner problem of mine ;) I'll fix it. -- Cedric
+ g#hivex_commit None; + g#hivex_close (); + + firstboot_dir + )
End of the stray ) and reformatting.
Rich.
There are registry entries that are needed to add some other drivers. Extracting them into a function will help adding SUSE VMDP support. --- v2v/windows_virtio.ml | 311 ++++++++++++++++++++++++++++---------------------- 1 file changed, 176 insertions(+), 135 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 14ffc51..8a0b529 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -146,48 +146,50 @@ and add_viostor_to_critical_device_database g root current_cs = * NB: All these edits are in the HKLM\SYSTEM hive. No other * hive may be modified here. *) + let driver = "viostor.sys" in + let driver_name = Filename.chop_extension driver in let regedits = [ [ current_cs; "Control"; "CriticalDeviceDatabase"; "pci#ven_1af4&dev_1001&subsys_00000000" ], - [ "Service", REG_SZ "viostor"; + [ "Service", REG_SZ driver_name; "ClassGUID", REG_SZ "{4D36E97B-E325-11CE-BFC1-08002BE10318}" ]; [ current_cs; "Control"; "CriticalDeviceDatabase"; "pci#ven_1af4&dev_1001&subsys_00020000" ], - [ "Service", REG_SZ "viostor"; + [ "Service", REG_SZ driver_name; "ClassGUID", REG_SZ "{4D36E97B-E325-11CE-BFC1-08002BE10318}" ]; [ current_cs; "Control"; "CriticalDeviceDatabase"; "pci#ven_1af4&dev_1001&subsys_00021af4" ], - [ "Service", REG_SZ "viostor"; + [ "Service", REG_SZ driver_name; "ClassGUID", REG_SZ "{4D36E97B-E325-11CE-BFC1-08002BE10318}" ]; [ current_cs; "Control"; "CriticalDeviceDatabase"; "pci#ven_1af4&dev_1001&subsys_00021af4&rev_00" ], - [ "Service", REG_SZ "viostor"; + [ "Service", REG_SZ driver_name; "ClassGUID", REG_SZ "{4D36E97B-E325-11CE-BFC1-08002BE10318}" ]; - [ current_cs; "Services"; "viostor" ], + [ current_cs; "Services"; driver_name ], [ "Type", REG_DWORD 0x1_l; "Start", REG_DWORD 0x0_l; "Group", REG_SZ "SCSI miniport"; "ErrorControl", REG_DWORD 0x1_l; - "ImagePath", REG_EXPAND_SZ "system32\\drivers\\viostor.sys"; + "ImagePath", REG_EXPAND_SZ ("system32\\drivers\\" ^ driver); "Tag", REG_DWORD 0x21_l ]; - [ current_cs; "Services"; "viostor"; "Parameters" ], + [ current_cs; "Services"; driver_name; "Parameters" ], [ "BusType", REG_DWORD 0x1_l ]; - [ current_cs; "Services"; "viostor"; "Parameters"; "MaxTransferSize" ], + [ current_cs; "Services"; driver_name; "Parameters"; "MaxTransferSize" ], [ "ParamDesc", REG_SZ "Maximum Transfer Size"; "type", REG_SZ "enum"; "default", REG_SZ "0" ]; - [ current_cs; "Services"; "viostor"; "Parameters"; "MaxTransferSize"; "enum" ], + [ current_cs; "Services"; driver_name; "Parameters"; "MaxTransferSize"; "enum" ], [ "0", REG_SZ "64 KB"; "1", REG_SZ "128 KB"; "2", REG_SZ "256 KB" ]; - [ current_cs; "Services"; "viostor"; "Parameters"; "PnpInterface" ], + [ current_cs; "Services"; driver_name; "Parameters"; "PnpInterface" ], [ "5", REG_DWORD 0x1_l ]; - [ current_cs; "Services"; "viostor"; "Enum" ], + [ current_cs; "Services"; driver_name; "Enum" ], [ "0", REG_SZ "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\3&13c0b0c5&0&20"; "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; @@ -199,8 +201,10 @@ and add_viostor_to_driver_database g root arch current_cs driverdir = (* Windows >= 8 doesn't use the CriticalDeviceDatabase. Instead * one must add keys into the DriverDatabase. *) + let driver = "viostor.sys" in + let driver_name = Filename.chop_extension driver in - let viostor_inf = + let inf_full = let arch = match arch with | "x86_64" -> "amd64" @@ -210,145 +214,39 @@ and add_viostor_to_driver_database g root arch current_cs driverdir = (* XXX I don't know what the significance of the c863.. string is. It * may even be random. *) - sprintf "viostor.inf_%s_%s" arch "c86329aaeb0a7904" in + sprintf "%s.inf_%s_%s" driver_name arch "c86329aaeb0a7904" in let scsi_adapter_guid = "{4d36e97b-e325-11ce-bfc1-08002be10318}" in - let oem_inf = set_free_oem_inf g root scsi_adapter_guid "viostor.inf" driverdir in - (* There should be a key - * HKLM\SYSTEM\ControlSet001\Control\Class\<scsi_adapter_guid> - * There may be subkey(s) of this called "0000", "0001" etc. We want - * to create the next free subkey. MSFT covers the key here: - * https://technet.microsoft.com/en-us/library/cc957341.aspx - * That page incorrectly states that the key has the form "000n". - * In fact we observed from real registries that the key is a - * decimal number that goes 0009 -> 0010 etc. - *) - let controller_path = - [ current_cs; "Control"; "Class"; scsi_adapter_guid ] in - let controller_offset = get_controller_offset g root controller_path in + let driverdesc = "Red Hat VirtIO SCSI controller" in + let provider = "Red Hat, Inc." in - let regedits = [ - controller_path @ [ controller_offset ], - [ "DriverDate", REG_SZ "6-4-2014"; - "DriverDateData", REG_BINARY "\x00\x40\x90\xed\x87\x7f\xcf\x01"; - "DriverDesc", REG_SZ "Red Hat VirtIO SCSI controller"; - "DriverVersion", REG_SZ "62.71.104.8600" (* XXX *); - "InfPath", REG_SZ oem_inf; - "InfSection", REG_SZ "rhelscsi_inst"; - "MatchingDeviceId", REG_SZ "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; - "ProviderName", REG_SZ "Red Hat, Inc." ]; - - [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\3&13c0b0c5&0&38" ], - [ "Capabilities", REG_DWORD 0x6_l; - "ClassGUID", REG_SZ scsi_adapter_guid; - "CompatibleIDs", REG_MULTI_SZ [ - "PCI\\VEN_1AF4&DEV_1001&REV_00"; - "PCI\\VEN_1AF4&DEV_1001"; - "PCI\\VEN_1AF4&CC_010000"; - "PCI\\VEN_1AF4&CC_0100"; - "PCI\\VEN_1AF4"; - "PCI\\CC_010000"; - "PCI\\CC_0100"; - ]; - "ConfigFlags", REG_DWORD 0_l; - "ContainerID", REG_SZ "{00000000-0000-0000-ffff-ffffffffffff}"; - "DeviceDesc", REG_SZ (sprintf "@%s,%%rhelscsi.devicedesc%%;Red Hat VirtIO SCSI controller" oem_inf); - "Driver", REG_SZ (sprintf "%s\\%s" scsi_adapter_guid controller_offset); - "HardwareID", REG_MULTI_SZ [ - "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; - "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4"; - "PCI\\VEN_1AF4&DEV_1001&CC_010000"; - "PCI\\VEN_1AF4&DEV_1001&CC_0100"; - ]; - "LocationInformation", REG_SZ "@System32\\drivers\\pci.sys,#65536;PCI bus %1, device %2, function %3;(0,7,0)"; - "Mfg", REG_SZ (sprintf "@%s,%%rhel%%;Red Hat, Inc." oem_inf); - "ParentIdPrefix", REG_SZ "4&87f7bfb&0"; - "Service", REG_SZ "viostor"; - "UINumber", REG_DWORD 0x7_l ]; - - [ current_cs; "Services"; "viostor" ], - [ "ErrorControl", REG_DWORD 0x1_l; - "Group", REG_SZ "SCSI miniport"; - "ImagePath", REG_EXPAND_SZ "system32\\drivers\\viostor.sys"; - "Owners", REG_MULTI_SZ [ oem_inf ]; - "Start", REG_DWORD 0x0_l; - "Tag", REG_DWORD 0x58_l; - "Type", REG_DWORD 0x1_l ]; - - [ current_cs; "Services"; "viostor"; "Parameters" ], - [ "BusType", REG_DWORD 0x1_l ]; + let driver_inst = (sprintf "%s_inst" driver_name) in - [ current_cs; "Services"; "viostor"; "Parameters"; "PnpInterface" ], - [ "5", REG_DWORD 0x1_l ]; + let device_id = "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00" in + let device_subkey = "3&13c0b0c5&0&38" in + let device_alt = "CC_010000" in - [ "DriverDatabase"; "DriverInfFiles"; oem_inf ], - [ "", REG_MULTI_SZ [ viostor_inf ]; - "Active", REG_SZ viostor_inf; - "Configurations", REG_MULTI_SZ [ "rhelscsi_inst" ] - ]; - - [ "DriverDatabase"; "DeviceIds"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00" ], - [ oem_inf, REG_BINARY "\x01\xff\x00\x00" ]; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf ], - [ "", REG_SZ oem_inf; - "F6", REG_DWORD 0x1_l; - "InfName", REG_SZ "viostor.inf"; - "OemPath", REG_SZ ("X:\\windows\\System32\\DriverStore\\FileRepository\\" ^ viostor_inf); - "Provider", REG_SZ "Red Hat, Inc."; - "SignerName", REG_SZ "Microsoft Windows Hardware Compatibility Publisher"; - "SignerScore", REG_DWORD 0x0d000005_l; - "StatusFlags", REG_DWORD 0x00000012_l; - (* NB: scsi_adapter_guid appears inside this string. *) - "Version", REG_BINARY "\x00\xff\x09\x00\x00\x00\x00\x00\x7b\xe9\x36\x4d\x25\xe3\xce\x11\xbf\xc1\x08\x00\x2b\xe1\x03\x18\x00\x40\x90\xed\x87\x7f\xcf\x01\x98\x21\x68\x00\x47\x00\x3e\x00\x00\x00\x00\x00\x00\x00\x00\x00" ]; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations" ], - []; + let service_group = "SCSI miniport" in + (* NB: scsi_adapter_guid appears inside this string. *) + let driver_version = "\x00\xff\x09\x00\x00\x00\x00\x00\x7b\xe9\x36\x4d\x25\xe3\xce\x11\xbf\xc1\x08\x00\x2b\xe1\x03\x18\x00\x40\x90\xed\x87\x7f\xcf\x01\x98\x21\x68\x00\x47\x00\x3e\x00\x00\x00\x00\x00\x00\x00\x00\x00" in + let device_addr = "(0,7,0)" in - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst" ], - [ "ConfigFlags", REG_DWORD 0_l; - "Service", REG_SZ "viostor" ]; + let common_regedits = get_common_regedits g root current_cs scsi_adapter_guid driverdir driver driverdesc driver_version service_group inf_full device_id device_subkey device_alt device_addr provider in - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Device" ], + let regedits = common_regedits @ [ + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Device" ], []; - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Device"; "Interrupt Management" ], + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Device"; "Interrupt Management" ], []; - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Device"; "Interrupt Management"; "Affinity Policy" ], + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Device"; "Interrupt Management"; "Affinity Policy" ], [ "DevicePolicy", REG_DWORD 0x00000005_l ]; - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Device"; "Interrupt Management"; "MessageSignaledInterruptProperties" ], + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Device"; "Interrupt Management"; "MessageSignaledInterruptProperties" ], [ "MSISupported", REG_DWORD 0x00000001_l; "MessageNumberLimit", REG_DWORD 0x00000002_l ]; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Services" ], - []; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Services"; "viostor" ], - []; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Services"; "viostor"; "Parameters" ], - [ "BusType", REG_DWORD 0x00000001_l ]; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Configurations"; "rhelscsi_inst"; "Services"; "viostor"; "Parameters"; "PnpInterface" ], - [ "5", REG_DWORD 0x00000001_l ]; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Descriptors" ], - []; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Descriptors"; "PCI" ], - []; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Descriptors"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00" ], - [ "Configuration", REG_SZ "rhelscsi_inst"; - "Description", REG_SZ "%rhelscsi.devicedesc%"; - "Manufacturer", REG_SZ "%rhel%" ]; - - [ "DriverDatabase"; "DriverPackages"; viostor_inf; "Strings" ], - [ "rhel", REG_SZ "Red Hat, Inc."; - "rhelscsi.devicedesc", REG_SZ "Red Hat VirtIO SCSI controller" ]; ] in reg_import g root regedits; @@ -402,6 +300,149 @@ and get_controller_offset g root controller_path = in loop node 0 +and get_common_regedits g root current_cs adapter_guid driverdir driver driverdesc driver_version service_group inf_full device_id device_subkey device_alt device_addr provider = + + let driver_name = Filename.chop_extension driver in + let driver_inf = sprintf "%s.inf" driver_name in + + let driverdesc_key = (sprintf "%s.devicedesc" driver_name) in + let driver_inst = (sprintf "%s_inst" driver_name) in + + let device_parts = Str.split (Str.regexp "&") device_id in + let get_device_part_n n = try + List.nth device_parts n + with _ -> + error (f_"Code problem: badly formed device id") in + let device_id0 = get_device_part_n 0 in + let device_id1 = get_device_part_n 1 in + let device_id2 = get_device_part_n 2 in + let device_id3 = get_device_part_n 3 in + + let device_alt_short = String.sub device_alt 0 7 in + + + let oem_inf = set_free_oem_inf g root adapter_guid driver_inf driverdir in + + (* There should be a key + * HKLM\SYSTEM\ControlSet001\Control\Class\<scsi_adapter_guid> + * There may be subkey(s) of this called "0000", "0001" etc. We want + * to create the next free subkey. MSFT covers the key here: + * https://technet.microsoft.com/en-us/library/cc957341.aspx + * That page incorrectly states that the key has the form "000n". + * In fact we observed from real registries that the key is a + * decimal number that goes 0009 -> 0010 etc. + *) + let controller_path = + [ current_cs; "Control"; "Class"; adapter_guid ] in + let controller_offset = get_controller_offset g root controller_path in + + [ controller_path @ [ controller_offset ], + [ "DriverDate", REG_SZ "6-4-2014"; + "DriverDateData", REG_BINARY "\x00\x40\x90\xed\x87\x7f\xcf\x01"; + "DriverDesc", REG_SZ driverdesc; + "DriverVersion", REG_SZ "62.71.104.8600" (* XXX *); + "InfPath", REG_SZ oem_inf; + "InfSection", REG_SZ driver_inst; + "MatchingDeviceId", REG_SZ ("PCI\\" ^ device_id); + "ProviderName", REG_SZ provider ]; + + [ current_cs; "Enum"; "PCI"; device_id; device_subkey ], + [ "Capabilities", REG_DWORD 0x6_l; + "ClassGUID", REG_SZ adapter_guid; + "CompatibleIDs", REG_MULTI_SZ [ + sprintf "PCI\\%s&%s&%s" device_id0 device_id1 device_id3; + sprintf "PCI\\%s&%s" device_id0 device_id1; + sprintf "PCI\\%s&%s" device_id0 device_alt; + sprintf "PCI\\%s&%s" device_id0 device_alt_short; + "PCI\\" ^ device_id0; + "PCI\\" ^ device_alt; + "PCI\\" ^ device_alt_short; + ]; + "ConfigFlags", REG_DWORD 0_l; + "ContainerID", REG_SZ "{00000000-0000-0000-ffff-ffffffffffff}"; + "DeviceDesc", REG_SZ (sprintf "@%s,%%%s%%;%s" oem_inf driverdesc_key driverdesc); + "Driver", REG_SZ (sprintf "%s\\%s" adapter_guid controller_offset); + "HardwareID", REG_MULTI_SZ [ + "PCI\\" ^ device_id; + sprintf "PCI\\%s&%s&%s" device_id0 device_id1 device_id2; + sprintf "PCI\\%s&%s&%s" device_id0 device_id1 device_alt; + sprintf "PCI\\%s&%s&%s" device_id0 device_id1 device_alt_short; + ]; + "LocationInformation", REG_SZ ("@System32\\drivers\\pci.sys,#65536;PCI bus %1, device %2, function %3;" ^ device_addr); + "Mfg", REG_SZ (sprintf "@%s,%%provider.desc%%;%s" oem_inf provider); + "Service", REG_SZ driver_name; + "UINumber", REG_DWORD 0x7_l ]; + + [ current_cs; "Services"; driver_name ], + [ "ErrorControl", REG_DWORD 0x1_l; + "Group", REG_SZ service_group; + "ImagePath", REG_EXPAND_SZ (sprintf "system32\\drivers\\%s" driver); + "Owners", REG_MULTI_SZ [ oem_inf ]; + "Start", REG_DWORD 0x0_l; + "Tag", REG_DWORD 0x58_l; + "Type", REG_DWORD 0x1_l ]; + + [ current_cs; "Services"; driver_name; "Parameters" ], + [ "BusType", REG_DWORD 0x1_l ]; + + [ current_cs; "Services"; driver_name; "Parameters"; "PnpInterface" ], + [ "5", REG_DWORD 0x1_l ]; + + [ "DriverDatabase"; "DriverInfFiles"; oem_inf ], + [ "", REG_MULTI_SZ [ inf_full ]; + "Active", REG_SZ inf_full; + "Configurations", REG_MULTI_SZ [ driver_inst ] + ]; + + [ "DriverDatabase"; "DeviceIds"; "PCI"; device_id ], + [ oem_inf, REG_BINARY "\x01\xff\x00\x00" ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full ], + [ "", REG_SZ oem_inf; + "F6", REG_DWORD 0x1_l; + "InfName", REG_SZ driver_inf; + "OemPath", REG_SZ ("X:\\windows\\System32\\DriverStore\\FileRepository\\" ^ inf_full); + "Provider", REG_SZ provider; + "SignerName", REG_SZ "Microsoft Windows Hardware Compatibility Publisher"; + "SignerScore", REG_DWORD 0x0d000005_l; + "StatusFlags", REG_DWORD 0x00000012_l; + "Version", REG_BINARY driver_version ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations" ], + []; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst ], + [ "ConfigFlags", REG_DWORD 0_l; + "Service", REG_SZ driver_name ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Services" ], + []; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Services"; driver_name ], + []; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Services"; driver_name; "Parameters" ], + [ "BusType", REG_DWORD 0x00000001_l ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Services"; driver_name; "Parameters"; "PnpInterface" ], + [ "5", REG_DWORD 0x00000001_l ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Descriptors" ], + []; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Descriptors"; "PCI" ], + []; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Descriptors"; "PCI"; device_id ], + [ "Configuration", REG_SZ driver_inst; + "Description", REG_SZ (sprintf "%%%s%%" driverdesc_key); + "Manufacturer", REG_SZ "%provider.desc%" ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Strings" ], + [ "provider.desc", REG_SZ provider; + driverdesc_key, REG_SZ driverdesc ]; + ] + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
On Tue, Apr 05, 2016 at 01:47:30PM +0200, Cédric Bosdonnat wrote:
There are registry entries that are needed to add some other drivers. Extracting them into a function will help adding SUSE VMDP support.
I didn't check this one in detail yet, but it seems reasonable. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
We need to adapt the Services\viostor\Enum\PCI\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00 subkey to what windows actually uses. --- v2v/windows_virtio.ml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 8a0b529..dfb7b71 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -139,15 +139,18 @@ and add_viostor_to_registry g inspect root current_cs driverdir = if (major == 6 && minor >= 2) || major >= 7 then (* Windows >= 8 *) add_viostor_to_driver_database g root arch current_cs driverdir else (* Windows <= 7 *) - add_viostor_to_critical_device_database g root current_cs + add_viostor_to_critical_device_database g root current_cs major -and add_viostor_to_critical_device_database g root current_cs = +and add_viostor_to_critical_device_database g root current_cs major = (* See http://rwmj.wordpress.com/2010/04/30/tip-install-a-device-driver-in-a-window... * NB: All these edits are in the HKLM\SYSTEM hive. No other * hive may be modified here. *) let driver = "viostor.sys" in let driver_name = Filename.chop_extension driver in + (* Windows 2k3 uses '&0&', windows 2k8 '&2&' *) + let subkey = + if (major == 5) then "3&13c0b0c5&0" else "3&13c0b0c5&2" in let regedits = [ [ current_cs; "Control"; "CriticalDeviceDatabase"; "pci#ven_1af4&dev_1001&subsys_00000000" ], [ "Service", REG_SZ driver_name; @@ -190,7 +193,7 @@ and add_viostor_to_critical_device_database g root current_cs = [ "5", REG_DWORD 0x1_l ]; [ current_cs; "Services"; driver_name; "Enum" ], - [ "0", REG_SZ "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\3&13c0b0c5&0&20"; + [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; ] in -- 2.6.2
On Tue, Apr 05, 2016 at 01:47:31PM +0200, Cédric Bosdonnat wrote:
We need to adapt the Services\viostor\Enum\PCI\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00 subkey to what windows actually uses. --- v2v/windows_virtio.ml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 8a0b529..dfb7b71 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -139,15 +139,18 @@ and add_viostor_to_registry g inspect root current_cs driverdir = if (major == 6 && minor >= 2) || major >= 7 then (* Windows >= 8 *) add_viostor_to_driver_database g root arch current_cs driverdir else (* Windows <= 7 *) - add_viostor_to_critical_device_database g root current_cs + add_viostor_to_critical_device_database g root current_cs major
This is OK, but maybe we can just pass the 'inspect' struct down into add_viostor_to_critical_device_database (between g & root parameters)? Maybe we'll need to use other inspection data in future. We really ought to collect all these parameters into a struct :-) Rich.
-and add_viostor_to_critical_device_database g root current_cs = +and add_viostor_to_critical_device_database g root current_cs major = (* See http://rwmj.wordpress.com/2010/04/30/tip-install-a-device-driver-in-a-window... * NB: All these edits are in the HKLM\SYSTEM hive. No other * hive may be modified here. *) let driver = "viostor.sys" in let driver_name = Filename.chop_extension driver in + (* Windows 2k3 uses '&0&', windows 2k8 '&2&' *) + let subkey = + if (major == 5) then "3&13c0b0c5&0" else "3&13c0b0c5&2" in let regedits = [ [ current_cs; "Control"; "CriticalDeviceDatabase"; "pci#ven_1af4&dev_1001&subsys_00000000" ], [ "Service", REG_SZ driver_name; @@ -190,7 +193,7 @@ and add_viostor_to_critical_device_database g root current_cs = [ "5", REG_DWORD 0x1_l ];
[ current_cs; "Services"; driver_name; "Enum" ], - [ "0", REG_SZ "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\3&13c0b0c5&0&20"; + [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; ] in -- 2.6.2
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
Setting the ConfigFlags to 0x40 for those will make windows quiet at the first boot about those new devices. The wizard must not be presented to the user since the needed drivers will automatically be installed at firstboot... or worse, the wizard can even block the installer. --- v2v/windows_virtio.ml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index dfb7b71..22e3e31 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -196,6 +196,14 @@ and add_viostor_to_critical_device_database g root current_cs major = [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; + + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00"; subkey ^ "&18" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; subkey ^ "&20" ], + [ "ConfigFlags", REG_DWORD 0x0_l; + "Service", REG_SZ driver_name ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00"; subkey ^ "&28" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; ] in reg_import g root regedits -- 2.6.2
On Tue, Apr 05, 2016 at 01:47:32PM +0200, Cédric Bosdonnat wrote:
Setting the ConfigFlags to 0x40 for those will make windows quiet at the first boot about those new devices. The wizard must not be presented to the user since the needed drivers will automatically be installed at firstboot... or worse, the wizard can even block the installer. --- v2v/windows_virtio.ml | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index dfb7b71..22e3e31 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -196,6 +196,14 @@ and add_viostor_to_critical_device_database g root current_cs major = [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; + + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00"; subkey ^ "&18" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; subkey ^ "&20" ], + [ "ConfigFlags", REG_DWORD 0x0_l; + "Service", REG_SZ driver_name ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00"; subkey ^ "&28" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; ] in
Seems reasonable. We can probably pull this patch earlier so we can apply it now - however it needs driver_name changed back to "viostor". Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Tue, Apr 05, 2016 at 01:47:32PM +0200, Cédric Bosdonnat wrote:
Setting the ConfigFlags to 0x40 for those will make windows quiet at the first boot about those new devices. The wizard must not be presented to the user since the needed drivers will automatically be installed at firstboot... or worse, the wizard can even block the installer.
What installer? You're trying circumvent the usual PnP process people are used to. I'm not sure it's worth adding yet more unreliable hacks (yes, basically the whole v2v/windows_virtio.ml is a hack).
--- v2v/windows_virtio.ml | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index dfb7b71..22e3e31 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -196,6 +196,14 @@ and add_viostor_to_critical_device_database g root current_cs major = [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; + + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00"; subkey ^ "&18" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; subkey ^ "&20" ], + [ "ConfigFlags", REG_DWORD 0x0_l; + "Service", REG_SZ driver_name ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00"; subkey ^ "&28" ], + [ "ConfigFlags", REG_DWORD 0x40_l ];
I'm curious how reliable those keys are; what are the chances that the devices get assigned different instance ids? I couldn't find any sources indicating that those instance ids are assigned in any predictable manner. Roman.
On Tue, 2016-04-05 at 17:19 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:32PM +0200, Cédric Bosdonnat wrote:
Setting the ConfigFlags to 0x40 for those will make windows quiet at the first boot about those new devices. The wizard must not be presented to the user since the needed drivers will automatically be installed at firstboot... or worse, the wizard can even block the installer.
What installer?
At least the VMDP installer running at firstboot is blocked by these wizards.
You're trying circumvent the usual PnP process people are used to. I'm not sure it's worth adding yet more unreliable hacks (yes, basically the whole v2v/windows_virtio.ml is a hack).
Setting those keys forces windows to ignore the virtio net and balloon devices for the first boot time. Running the VMDP installer (or the RH equivalent one) will install the needed drivers and all will be fine after that.
--- v2v/windows_virtio.ml | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index dfb7b71..22e3e31 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -196,6 +196,14 @@ and add_viostor_to_critical_device_database g root current_cs major = [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; + + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00"; subkey ^ "&18" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; subkey ^ "&20" ], + [ "ConfigFlags", REG_DWORD 0x0_l; + "Service", REG_SZ driver_name ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00"; subkey ^ "&28" ], + [ "ConfigFlags", REG_DWORD 0x40_l ];
I'm curious how reliable those keys are; what are the chances that the devices get assigned different instance ids? I couldn't find any sources indicating that those instance ids are assigned in any predictable manner.
I have no idea how they are computed, but they are common accross all windows versions except for the subkey that changes with windows versions. I tried to get rid of those subkeys, but then windows keeps showing the wizards without those. -- Cedric
On Tue, Apr 05, 2016 at 05:33:28PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 17:19 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:32PM +0200, Cédric Bosdonnat wrote:
Setting the ConfigFlags to 0x40 for those will make windows quiet at the first boot about those new devices. The wizard must not be presented to the user since the needed drivers will automatically be installed at firstboot... or worse, the wizard can even block the installer.
What installer?
At least the VMDP installer running at firstboot is blocked by these wizards.
You're trying circumvent the usual PnP process people are used to. I'm not sure it's worth adding yet more unreliable hacks (yes, basically the whole v2v/windows_virtio.ml is a hack).
Setting those keys forces windows to ignore the virtio net and balloon devices for the first boot time. Running the VMDP installer (or the RH equivalent one) will install the needed drivers and all will be fine after that.
IIUC, adding these keys should be conditional on _not_ running the VMDP installer? Rich.
--- v2v/windows_virtio.ml | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index dfb7b71..22e3e31 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -196,6 +196,14 @@ and add_viostor_to_critical_device_database g root current_cs major = [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; + + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00"; subkey ^ "&18" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; subkey ^ "&20" ], + [ "ConfigFlags", REG_DWORD 0x0_l; + "Service", REG_SZ driver_name ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00"; subkey ^ "&28" ], + [ "ConfigFlags", REG_DWORD 0x40_l ];
I'm curious how reliable those keys are; what are the chances that the devices get assigned different instance ids? I couldn't find any sources indicating that those instance ids are assigned in any predictable manner.
I have no idea how they are computed, but they are common accross all windows versions except for the subkey that changes with windows versions.
I tried to get rid of those subkeys, but then windows keeps showing the wizards without those.
-- Cedric
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Tue, Apr 05, 2016 at 05:33:28PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 17:19 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:32PM +0200, Cédric Bosdonnat wrote:
Setting the ConfigFlags to 0x40 for those will make windows quiet at the first boot about those new devices. The wizard must not be presented to the user since the needed drivers will automatically be installed at firstboot... or worse, the wizard can even block the installer.
What installer?
At least the VMDP installer running at firstboot is blocked by these wizards.
I see. Perhaps this needs to be fixed in that installer, then (no, I have no idea how or whether it's possible at all)?
You're trying circumvent the usual PnP process people are used to. I'm not sure it's worth adding yet more unreliable hacks (yes, basically the whole v2v/windows_virtio.ml is a hack).
Setting those keys forces windows to ignore the virtio net and balloon devices for the first boot time. Running the VMDP installer (or the RH equivalent one) will install the needed drivers and all will be fine after that.
I'll talk to our guys doing similar things. I wonder what they do -- they must have similar problems.
@@ -196,6 +196,14 @@ and add_viostor_to_critical_device_database g root current_cs major = [ "0", REG_SZ (sprintf "PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey); "Count", REG_DWORD 0x1_l; "NextInstance", REG_DWORD 0x1_l ]; + + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00"; subkey ^ "&18" ], + [ "ConfigFlags", REG_DWORD 0x40_l ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; subkey ^ "&20" ], + [ "ConfigFlags", REG_DWORD 0x0_l; + "Service", REG_SZ driver_name ]; + [ current_cs; "Enum"; "PCI"; "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00"; subkey ^ "&28" ], + [ "ConfigFlags", REG_DWORD 0x40_l ];
I'm curious how reliable those keys are; what are the chances that the devices get assigned different instance ids? I couldn't find any sources indicating that those instance ids are assigned in any predictable manner.
I have no idea how they are computed, but they are common accross all windows versions except for the subkey that changes with windows versions.
OK I just added another network adapter, and it got &38 at the end. So this doesn't look like a reliable procedure, and you need to figure out a better approach. Roman.
On Tue, Apr 05, 2016 at 07:53:16PM +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 05:33:28PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 17:19 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:32PM +0200, Cédric Bosdonnat wrote:
Setting the ConfigFlags to 0x40 for those will make windows quiet at the first boot about those new devices. The wizard must not be presented to the user since the needed drivers will automatically be installed at firstboot... or worse, the wizard can even block the installer.
What installer?
At least the VMDP installer running at firstboot is blocked by these wizards.
I see. Perhaps this needs to be fixed in that installer, then (no, I have no idea how or whether it's possible at all)?
You're trying circumvent the usual PnP process people are used to. I'm not sure it's worth adding yet more unreliable hacks (yes, basically the whole v2v/windows_virtio.ml is a hack).
Setting those keys forces windows to ignore the virtio net and balloon devices for the first boot time. Running the VMDP installer (or the RH equivalent one) will install the needed drivers and all will be fine after that.
I'll talk to our guys doing similar things. I wonder what they do -- they must have similar problems.
Indeed they do. The solution we're considering ATM is 1) make the installer support running on a system where the drivers are already installed 2) make sure firstboot scripts aren't run before PnP is complete This should resolve the conflict you wrote about, by making the drivers brought in by v2v fully installed via standard Windows PnP manager first, and running the installer afterwards. Item (2) is also useful to avoid similar conflicts with other firstboot scripts, because PnP often requires a reboot, and those firstboot scripts may not tolerate a reboot in the middle of execution. Will this work for you? Roman.
On Tue, 2016-04-05 at 21:08 +0300, Roman Kagan wrote:
I'll talk to our guys doing similar things. I wonder what they do -- they must have similar problems.
Indeed they do. The solution we're considering ATM is
1) make the installer support running on a system where the drivers are already installed
Our installer is already able to handle this case.
2) make sure firstboot scripts aren't run before PnP is complete
This should resolve the conflict you wrote about, by making the drivers brought in by v2v fully installed via standard Windows PnP manager first, and running the installer afterwards.
I think it can't hurt to get the firstboot script run before PnP... but I have no idea how to do that, but may be you have one ;)
Item (2) is also useful to avoid similar conflicts with other firstboot scripts, because PnP often requires a reboot, and those firstboot scripts may not tolerate a reboot in the middle of execution.
Will this work for you?
Sure. If we manage to run the first boot before PnP this hack is no longer needed. -- Cedric
On Wed, Apr 06, 2016 at 09:16:16AM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 21:08 +0300, Roman Kagan wrote:
I'll talk to our guys doing similar things. I wonder what they do -- they must have similar problems.
Indeed they do. The solution we're considering ATM is
1) make the installer support running on a system where the drivers are already installed
Our installer is already able to handle this case.
2) make sure firstboot scripts aren't run before PnP is complete
This should resolve the conflict you wrote about, by making the drivers brought in by v2v fully installed via standard Windows PnP manager first, and running the installer afterwards.
I think it can't hurt to get the firstboot script run before PnP... but I have no idea how to do that, but may be you have one ;)
I meant vice versa: run firstboot strcitly *after* PnP completes (including reboots if necessary). And yes Windows provides a way to wait until it's over: https://msdn.microsoft.com/en-us/library/windows/hardware/ff537916(v=vs.85).... I think we'll cook up a patch to rhsrvany to make use of that; as I said this will also benefit other firstboot scripts which then won't be interrupted by reboots caused by PnP driver installation; you should be able to do the same with your tool, too.
Item (2) is also useful to avoid similar conflicts with other firstboot scripts, because PnP often requires a reboot, and those firstboot scripts may not tolerate a reboot in the middle of execution.
Will this work for you?
Sure. If we manage to run the first boot before PnP this hack is no longer needed.
According to your comment to item (1), the other way around (firstboot after PnP) should also be OK, shouldn't it? Thanks, Roman.
On Wed, 2016-04-06 at 10:54 +0300, Roman Kagan wrote:
On Wed, Apr 06, 2016 at 09:16:16AM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 21:08 +0300, Roman Kagan wrote:
I'll talk to our guys doing similar things. I wonder what they do -- they must have similar problems.
Indeed they do. The solution we're considering ATM is
1) make the installer support running on a system where the drivers are already installed
Our installer is already able to handle this case.
2) make sure firstboot scripts aren't run before PnP is complete
This should resolve the conflict you wrote about, by making the drivers brought in by v2v fully installed via standard Windows PnP manager first, and running the installer afterwards.
I think it can't hurt to get the firstboot script run before PnP... but I have no idea how to do that, but may be you have one ;)
I meant vice versa: run firstboot strcitly *after* PnP completes (including reboots if necessary). And yes Windows provides a way to wait until it's over: https://msdn.microsoft.com/en-us/library/windows/hardware/ff537916(v= vs.85).aspx
I think we'll cook up a patch to rhsrvany to make use of that; as I said this will also benefit other firstboot scripts which then won't be interrupted by reboots caused by PnP driver installation; you should be able to do the same with your tool, too.
The problem with running after the PnP is that user will be prompted for installation of virtio-net and virtio-balloon drivers... which doesn't make sense as we are going to install them automatically anyway.
Item (2) is also useful to avoid similar conflicts with other firstboot scripts, because PnP often requires a reboot, and those firstboot scripts may not tolerate a reboot in the middle of execution.
Will this work for you?
Sure. If we manage to run the first boot before PnP this hack is no longer needed.
According to your comment to item (1), the other way around (firstboot after PnP) should also be OK, shouldn't it?
Some versions of windows (2008 IIRC) are explicitly waiting for user input in the PnP wizard: the best it not to show the PnP dialogs for the virtio devices to the user at all. -- Cedric
On Wed, Apr 06, 2016 at 10:13:35AM +0200, Cedric Bosdonnat wrote:
The problem with running after the PnP is that user will be prompted for installation of virtio-net and virtio-balloon drivers... which doesn't make sense as we are going to install them automatically anyway. [...] Some versions of windows (2008 IIRC) are explicitly waiting for user input in the PnP wizard: the best it not to show the PnP dialogs for the virtio devices to the user at all.
I tend to agree that not prompting the user here provides better user experience; however I don't feel like this is a major issue. Regardless of the severity of the problem, the solution you propose -- disabling the prompts for specific device instance IDs -- is IMO way too unreliable and PnP manager will still want to interact in a number of common cases: - if the devices get enumerated differently and Windows assigns different instance IDs to them - if there's more than one device of any kind - if there are new devices beyond those you handle (e.g. virtio-serial) I think this would be better addressed if you could disable PnP manager prompts globally during v2v, and reset it back in a firstboot script after your installer had been run. Roman.
On Wed, 2016-04-06 at 11:43 +0300, Roman Kagan wrote:
On Wed, Apr 06, 2016 at 10:13:35AM +0200, Cedric Bosdonnat wrote:
The problem with running after the PnP is that user will be prompted for installation of virtio-net and virtio-balloon drivers... which doesn't make sense as we are going to install them automatically anyway. [...] Some versions of windows (2008 IIRC) are explicitly waiting for user input in the PnP wizard: the best it not to show the PnP dialogs for the virtio devices to the user at all.
I tend to agree that not prompting the user here provides better user experience; however I don't feel like this is a major issue.
Regardless of the severity of the problem, the solution you propose - - disabling the prompts for specific device instance IDs -- is IMO way too unreliable and PnP manager will still want to interact in a number of common cases:
- if the devices get enumerated differently and Windows assigns different instance IDs to them
- if there's more than one device of any kind
- if there are new devices beyond those you handle (e.g. virtio -serial)
Hum, I fear you're right.
I think this would be better addressed if you could disable PnP manager prompts globally during v2v, and reset it back in a firstboot script after your installer had been run.
Any idea how to do that? -- Cedric
On Wed, Apr 06, 2016 at 11:24:03AM +0200, Cedric Bosdonnat wrote:
On Wed, 2016-04-06 at 11:43 +0300, Roman Kagan wrote:
I think this would be better addressed if you could disable PnP manager prompts globally during v2v, and reset it back in a firstboot script after your installer had been run.
Any idea how to do that?
None off the top of my head :( Gonna ask local Windows experts here... Roman.
To add this support, the existing code searches for either the viostor or the VMDP (Virtual Machine Driver Pack) files and updates the registry accordingly. Note that VMDP's block driver pvvxblk depends on the ballooning driver pvvxbn. --- v2v/convert_windows.ml | 59 ++++++++++++++++++++------ v2v/windows_virtio.ml | 113 +++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 141 insertions(+), 31 deletions(-) diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index 5daae6c..cb936ec 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -43,18 +43,25 @@ let convert ~keep_serial_console (g : G.guestfs) inspect source rcaps = try Sys.getenv "VIRT_TOOLS_DATA_DIR" with Not_found -> Guestfs_config.datadir // "virt-tools" in - (* Check if RHEV-APT exists. This is optional. *) - let rhev_apt_exe = virt_tools_data_dir // "rhev-apt.exe" in - let rhev_apt_exe = + (* Check if either RHEV-APT or VMDP exists. This is optional. *) + let tools = ["rhev-apt.exe"; "vmdp.exe"] in + let installer = try - let chan = open_in rhev_apt_exe in - close_in chan; - Some rhev_apt_exe - with - Sys_error msg -> - warning (f_"'%s' is missing. Unable to install RHEV-APT (RHEV guest agent). Original error: %s") - rhev_apt_exe msg; - None in + let tool = List.find ( + fun item -> + try ( + let exe_path = virt_tools_data_dir // item in + let chan = open_in exe_path in + close_in chan; + true + ) with _ -> + false + ) tools in + Some (virt_tools_data_dir // tool) + with Not_found -> ( + warning (f_"Neither rhev-apt.exe nor vmdp.exe can be found. Unable to install one of them."); + None + ) in (* Get the Windows %systemroot%. *) let systemroot = g#inspect_get_windows_systemroot inspect.i_root in @@ -211,7 +218,14 @@ let convert ~keep_serial_console (g : G.guestfs) inspect source rcaps = (* Perform the conversion of the Windows guest. *) let rec configure_firstboot () = - configure_rhev_apt (); + match installer with + | None -> info (f_"No firstboot installer to configure") + | Some installer_path -> + let installer_name = Filename.basename installer_path in + match installer_name with + | "rhev-apt.exe" -> configure_rhev_apt () + | "vmdp.exe" -> configure_vmdp () + | _ -> info (f_"No setup function for installer '%s'") installer_path; unconfigure_xenpv (); unconfigure_prltools () @@ -219,7 +233,7 @@ let convert ~keep_serial_console (g : G.guestfs) inspect source rcaps = (* Configure RHEV-APT (the RHEV guest agent). However if it doesn't * exist just warn about it and continue. *) - match rhev_apt_exe with + match installer with | None -> () | Some rhev_apt_exe -> g#upload rhev_apt_exe "/rhev-apt.exe"; (* XXX *) @@ -236,6 +250,25 @@ net start rhev-apt Firstboot.add_firstboot_script g inspect.i_root "configure rhev-apt" fb_script + and configure_vmdp () = + (* Configure VMDP if possible *) + match installer with + | None -> () + | Some vmdp_exe -> + g#upload vmdp_exe "/vmdp.exe"; + + let fb_script = "\ +echo V2V first boot script started +echo Decompressing VMDP installer +\"\\vmdp.exe\" +cd \"VMDP-WIN*\" +echo Installing VMDP +setup.exe /eula_accepted /auto_reboot +cd .. +" in + Firstboot.add_firstboot_script g inspect.i_root + "configure vmdp" fb_script + and unconfigure_xenpv () = match xenpv_uninst with | None -> () (* nothing to be uninstalled *) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 22e3e31..87e39e6 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -62,15 +62,23 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = else ( (* Can we install the block driver? *) let block : guestcaps_block_type = - let has_viostor = g#exists (driverdir // "viostor.inf") in + let filenames = ["pvvxblk.sys"; "virtio_blk.sys"; "vrtioblk.sys"; "viostor.sys"] in + let driver_name = try ( + List.find ( + fun driver_file -> + let source = driverdir // driver_file in + g#exists source + ) filenames + ) with Not_found -> "" in + let has_viostor = not (driver_name = "") in match rcaps.rcaps_block_bus, has_viostor with | Some Virtio_blk, false -> - error (f_"there is no viostor (virtio block device) driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") + error (f_"there is no virtio block device driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") inspect.i_major_version inspect.i_minor_version inspect.i_arch virtio_win | None, false -> - warning (f_"there is no viostor (virtio block device) driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") + warning (f_"there is no virtio block device driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") inspect.i_major_version inspect.i_minor_version inspect.i_arch virtio_win; IDE @@ -78,11 +86,17 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = | (Some Virtio_blk | None), true -> (* Block driver needs tweaks to allow booting; the rest is set up by PnP * manager *) - let source = driverdir // "viostor.sys" in - let target = sprintf "%s/system32/drivers/viostor.sys" systemroot in + let source = driverdir // driver_name in + let targetdir = systemroot ^ "/system32/drivers/" in + let target = targetdir // driver_name in let target = g#case_sensitive_path target in g#cp source target; - add_viostor_to_registry g inspect root current_cs driverdir; + if (driver_name = "pvvxblk.sys") then ( + let target = targetdir // "pvvxbn.sys" in + let target = g#case_sensitive_path target in + g#cp (driverdir // "pvvxbn.sys") target + ); + add_viostor_to_registry g inspect root current_cs driverdir driver_name; Virtio_blk | Some IDE, _ -> @@ -90,7 +104,8 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = (* Can we install the virtio-net driver? *) let net : guestcaps_net_type = - let has_netkvm = g#exists (driverdir // "netkvm.inf") in + let filenames = ["pvvxnet.inf"; "virtio_net.inf"; "netkvm.inf"] in + let has_netkvm = List.exists (fun driver_file -> g#exists (driverdir // driver_file)) filenames in match rcaps.rcaps_net_bus, has_netkvm with | Some Virtio_net, false -> error (f_"there is no virtio network driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s") @@ -133,20 +148,19 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = (block, net, video) ) -and add_viostor_to_registry g inspect root current_cs driverdir = +and add_viostor_to_registry g inspect root current_cs driverdir driver_name = let { i_major_version = major; i_minor_version = minor; i_arch = arch } = inspect in if (major == 6 && minor >= 2) || major >= 7 then (* Windows >= 8 *) - add_viostor_to_driver_database g root arch current_cs driverdir + add_viostor_to_driver_database g root arch current_cs driverdir driver_name else (* Windows <= 7 *) - add_viostor_to_critical_device_database g root current_cs major + add_viostor_to_critical_device_database g root current_cs major driver_name -and add_viostor_to_critical_device_database g root current_cs major = +and add_viostor_to_critical_device_database g root current_cs major driver = (* See http://rwmj.wordpress.com/2010/04/30/tip-install-a-device-driver-in-a-window... * NB: All these edits are in the HKLM\SYSTEM hive. No other * hive may be modified here. *) - let driver = "viostor.sys" in let driver_name = Filename.chop_extension driver in (* Windows 2k3 uses '&0&', windows 2k8 '&2&' *) let subkey = @@ -208,11 +222,10 @@ and add_viostor_to_critical_device_database g root current_cs major = reg_import g root regedits -and add_viostor_to_driver_database g root arch current_cs driverdir = +and add_viostor_to_driver_database g root arch current_cs driverdir driver = (* Windows >= 8 doesn't use the CriticalDeviceDatabase. Instead * one must add keys into the DriverDatabase. *) - let driver = "viostor.sys" in let driver_name = Filename.chop_extension driver in let inf_full = @@ -229,8 +242,12 @@ and add_viostor_to_driver_database g root arch current_cs driverdir = let scsi_adapter_guid = "{4d36e97b-e325-11ce-bfc1-08002be10318}" in - let driverdesc = "Red Hat VirtIO SCSI controller" in - let provider = "Red Hat, Inc." in + let driverdesc = if (driver_name = "pvvxblk") + then "SUSE Block Driver for Windows" + else "Red Hat VirtIO SCSI controller" in + + let provider = if (driver_name = "pvvxblk") then "SUSE" else "Red Hat, Inc." in + let msi_supported = if (driver_name = "pvvxblk") then 0x0_l else 0x1_l in let driver_inst = (sprintf "%s_inst" driver_name) in @@ -256,11 +273,14 @@ and add_viostor_to_driver_database g root arch current_cs driverdir = [ "DevicePolicy", REG_DWORD 0x00000005_l ]; [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Device"; "Interrupt Management"; "MessageSignaledInterruptProperties" ], - [ "MSISupported", REG_DWORD 0x00000001_l; + [ "MSISupported", REG_DWORD msi_supported; "MessageNumberLimit", REG_DWORD 0x00000002_l ]; ] in - reg_import g root regedits; + (reg_import g root regedits; + if (driver_name = "pvvxblk") then + add_pvvxbn_to_driver_database g root arch current_cs driverdir + ); (* A few more keys which we don't add above. Note that "oem1.inf" == @@ -454,6 +474,63 @@ and get_common_regedits g root current_cs adapter_guid driverdir driver driverde driverdesc_key, REG_SZ driverdesc ]; ] +and add_pvvxbn_to_driver_database g root arch current_cs driverdir = + + let driver_name = "pvvxbn" in + + let inf_full = + let arch = + match arch with + | "x86_64" -> "amd64" + | "i386" | "i486" | "i585" | "i686" -> "x86" + | _ -> + error (f_"when adding pvvxbn to the DriverDatabase, unknown architecture: %s") arch in + sprintf "%s.inf_%s_%s" driver_name arch "9b414b949945d17b" in + + let driverdesc = "SUSE Bus/Balloon Driver for Windows" in + let driver_inst = "pvvxbn_inst" in + let provider = "SUSE" in + + let device_id = "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00" in + let device_subkey = "3&13c0b0c5&0&20" in + let device_alt = "CC_00FF00" in + + let balloon_bus_guid = "{4d36e97d-e325-11ce-bfc1-08002be10318}" in + + let class_guid = "{9fae43c0-44bf-465e-90c9-3da1c30ed68b}" in + + let service_group = "Boot Bus Extender" in + (* NB: balloon_bus_guid appears inside this string. *) + let driver_version = "\x00\xff\x09\x00\x00\x00\x00\x00\x7d\xe9\x36\x4d\x25\xe3\xce\x11\xbf\xc1\x08\x00\x2b\xe1\x03\x18\x00\x40\x7f\x1d\xdc\xfb\xd0\x01\x13\x00\x01\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00" in + let device_addr = "(0,4,0)" in + + let common_regedits = get_common_regedits g root current_cs balloon_bus_guid driverdir "pvvxbn.sys" driverdesc driver_version service_group inf_full device_id device_subkey device_alt device_addr provider in + + let regedits = common_regedits @ [ + [ current_cs; "Control"; "DeviceClasses"; class_guid ], + []; + + [ current_cs; "Control"; "DeviceClasses"; class_guid; + sprintf "##?#PCI#%s#%s#%s" device_id device_subkey class_guid ], + [ "DeviceInstance", REG_SZ (sprintf "PCI\\%s\\%s" device_id device_subkey) ]; + + [ current_cs; "Control"; "DeviceClasses"; class_guid; + sprintf "##?#PCI#%s#%s#%s" device_id device_subkey class_guid; "#" ], + []; + + [ current_cs; "Services"; driver_name; "Parameters"; "Device" ], + [ "grant_frames", REG_DWORD 0xA_l; + "pvctrl_flags", REG_DWORD 0x5_l; + "shutdown_notification", REG_DWORD 0x1_l; + "use_pv_drivers", REG_DWORD 0x1c0003_l ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Services"; driver_name; "Parameters"; "Device" ], + [ "dbg_print_mask", REG_DWORD 0x7_l ]; + + ] in + + reg_import g root regedits; + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
On Tue, Apr 05, 2016 at 01:47:33PM +0200, Cédric Bosdonnat wrote:
To add this support, the existing code searches for either the viostor or the VMDP (Virtual Machine Driver Pack) files and updates the registry accordingly.
Note that VMDP's block driver pvvxblk depends on the ballooning driver pvvxbn.
I didn't check this in detail, but it seems reasonable. Rich.
v2v/convert_windows.ml | 59 ++++++++++++++++++++------ v2v/windows_virtio.ml | 113 +++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 141 insertions(+), 31 deletions(-)
diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index 5daae6c..cb936ec 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -43,18 +43,25 @@ let convert ~keep_serial_console (g : G.guestfs) inspect source rcaps = try Sys.getenv "VIRT_TOOLS_DATA_DIR" with Not_found -> Guestfs_config.datadir // "virt-tools" in
- (* Check if RHEV-APT exists. This is optional. *) - let rhev_apt_exe = virt_tools_data_dir // "rhev-apt.exe" in - let rhev_apt_exe = + (* Check if either RHEV-APT or VMDP exists. This is optional. *) + let tools = ["rhev-apt.exe"; "vmdp.exe"] in + let installer = try - let chan = open_in rhev_apt_exe in - close_in chan; - Some rhev_apt_exe - with - Sys_error msg -> - warning (f_"'%s' is missing. Unable to install RHEV-APT (RHEV guest agent). Original error: %s") - rhev_apt_exe msg; - None in + let tool = List.find ( + fun item -> + try ( + let exe_path = virt_tools_data_dir // item in + let chan = open_in exe_path in + close_in chan; + true + ) with _ -> + false + ) tools in + Some (virt_tools_data_dir // tool) + with Not_found -> ( + warning (f_"Neither rhev-apt.exe nor vmdp.exe can be found. Unable to install one of them."); + None + ) in
(* Get the Windows %systemroot%. *) let systemroot = g#inspect_get_windows_systemroot inspect.i_root in @@ -211,7 +218,14 @@ let convert ~keep_serial_console (g : G.guestfs) inspect source rcaps = (* Perform the conversion of the Windows guest. *)
let rec configure_firstboot () = - configure_rhev_apt (); + match installer with + | None -> info (f_"No firstboot installer to configure") + | Some installer_path -> + let installer_name = Filename.basename installer_path in + match installer_name with + | "rhev-apt.exe" -> configure_rhev_apt () + | "vmdp.exe" -> configure_vmdp () + | _ -> info (f_"No setup function for installer '%s'") installer_path; unconfigure_xenpv (); unconfigure_prltools ()
@@ -219,7 +233,7 @@ let convert ~keep_serial_console (g : G.guestfs) inspect source rcaps = (* Configure RHEV-APT (the RHEV guest agent). However if it doesn't * exist just warn about it and continue. *) - match rhev_apt_exe with + match installer with | None -> () | Some rhev_apt_exe -> g#upload rhev_apt_exe "/rhev-apt.exe"; (* XXX *) @@ -236,6 +250,25 @@ net start rhev-apt Firstboot.add_firstboot_script g inspect.i_root "configure rhev-apt" fb_script
+ and configure_vmdp () = + (* Configure VMDP if possible *) + match installer with + | None -> () + | Some vmdp_exe -> + g#upload vmdp_exe "/vmdp.exe"; + + let fb_script = "\ +echo V2V first boot script started +echo Decompressing VMDP installer +\"\\vmdp.exe\" +cd \"VMDP-WIN*\" +echo Installing VMDP +setup.exe /eula_accepted /auto_reboot +cd .. +" in + Firstboot.add_firstboot_script g inspect.i_root + "configure vmdp" fb_script + and unconfigure_xenpv () = match xenpv_uninst with | None -> () (* nothing to be uninstalled *) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 22e3e31..87e39e6 100644 --- a/v2v/windows_virtio.ml +++ b/v2v/windows_virtio.ml @@ -62,15 +62,23 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = else ( (* Can we install the block driver? *) let block : guestcaps_block_type = - let has_viostor = g#exists (driverdir // "viostor.inf") in + let filenames = ["pvvxblk.sys"; "virtio_blk.sys"; "vrtioblk.sys"; "viostor.sys"] in + let driver_name = try ( + List.find ( + fun driver_file -> + let source = driverdir // driver_file in + g#exists source + ) filenames + ) with Not_found -> "" in + let has_viostor = not (driver_name = "") in match rcaps.rcaps_block_bus, has_viostor with | Some Virtio_blk, false -> - error (f_"there is no viostor (virtio block device) driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") + error (f_"there is no virtio block device driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") inspect.i_major_version inspect.i_minor_version inspect.i_arch virtio_win
| None, false -> - warning (f_"there is no viostor (virtio block device) driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") + warning (f_"there is no virtio block device driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s\n\nThe guest will be configured to use a slower emulated device.") inspect.i_major_version inspect.i_minor_version inspect.i_arch virtio_win; IDE @@ -78,11 +86,17 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = | (Some Virtio_blk | None), true -> (* Block driver needs tweaks to allow booting; the rest is set up by PnP * manager *) - let source = driverdir // "viostor.sys" in - let target = sprintf "%s/system32/drivers/viostor.sys" systemroot in + let source = driverdir // driver_name in + let targetdir = systemroot ^ "/system32/drivers/" in + let target = targetdir // driver_name in let target = g#case_sensitive_path target in g#cp source target; - add_viostor_to_registry g inspect root current_cs driverdir; + if (driver_name = "pvvxblk.sys") then ( + let target = targetdir // "pvvxbn.sys" in + let target = g#case_sensitive_path target in + g#cp (driverdir // "pvvxbn.sys") target + ); + add_viostor_to_registry g inspect root current_cs driverdir driver_name; Virtio_blk
| Some IDE, _ -> @@ -90,7 +104,8 @@ let rec install_drivers g inspect systemroot root current_cs rcaps =
(* Can we install the virtio-net driver? *) let net : guestcaps_net_type = - let has_netkvm = g#exists (driverdir // "netkvm.inf") in + let filenames = ["pvvxnet.inf"; "virtio_net.inf"; "netkvm.inf"] in + let has_netkvm = List.exists (fun driver_file -> g#exists (driverdir // driver_file)) filenames in match rcaps.rcaps_net_bus, has_netkvm with | Some Virtio_net, false -> error (f_"there is no virtio network driver for this version of Windows (%d.%d %s). virt-v2v looks for this driver in %s") @@ -133,20 +148,19 @@ let rec install_drivers g inspect systemroot root current_cs rcaps = (block, net, video) )
-and add_viostor_to_registry g inspect root current_cs driverdir = +and add_viostor_to_registry g inspect root current_cs driverdir driver_name = let { i_major_version = major; i_minor_version = minor; i_arch = arch } = inspect in if (major == 6 && minor >= 2) || major >= 7 then (* Windows >= 8 *) - add_viostor_to_driver_database g root arch current_cs driverdir + add_viostor_to_driver_database g root arch current_cs driverdir driver_name else (* Windows <= 7 *) - add_viostor_to_critical_device_database g root current_cs major + add_viostor_to_critical_device_database g root current_cs major driver_name
-and add_viostor_to_critical_device_database g root current_cs major = +and add_viostor_to_critical_device_database g root current_cs major driver = (* See http://rwmj.wordpress.com/2010/04/30/tip-install-a-device-driver-in-a-window... * NB: All these edits are in the HKLM\SYSTEM hive. No other * hive may be modified here. *) - let driver = "viostor.sys" in let driver_name = Filename.chop_extension driver in (* Windows 2k3 uses '&0&', windows 2k8 '&2&' *) let subkey = @@ -208,11 +222,10 @@ and add_viostor_to_critical_device_database g root current_cs major =
reg_import g root regedits
-and add_viostor_to_driver_database g root arch current_cs driverdir = +and add_viostor_to_driver_database g root arch current_cs driverdir driver = (* Windows >= 8 doesn't use the CriticalDeviceDatabase. Instead * one must add keys into the DriverDatabase. *) - let driver = "viostor.sys" in let driver_name = Filename.chop_extension driver in
let inf_full = @@ -229,8 +242,12 @@ and add_viostor_to_driver_database g root arch current_cs driverdir =
let scsi_adapter_guid = "{4d36e97b-e325-11ce-bfc1-08002be10318}" in
- let driverdesc = "Red Hat VirtIO SCSI controller" in - let provider = "Red Hat, Inc." in + let driverdesc = if (driver_name = "pvvxblk") + then "SUSE Block Driver for Windows" + else "Red Hat VirtIO SCSI controller" in + + let provider = if (driver_name = "pvvxblk") then "SUSE" else "Red Hat, Inc." in + let msi_supported = if (driver_name = "pvvxblk") then 0x0_l else 0x1_l in
let driver_inst = (sprintf "%s_inst" driver_name) in
@@ -256,11 +273,14 @@ and add_viostor_to_driver_database g root arch current_cs driverdir = [ "DevicePolicy", REG_DWORD 0x00000005_l ];
[ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Device"; "Interrupt Management"; "MessageSignaledInterruptProperties" ], - [ "MSISupported", REG_DWORD 0x00000001_l; + [ "MSISupported", REG_DWORD msi_supported; "MessageNumberLimit", REG_DWORD 0x00000002_l ]; ] in
- reg_import g root regedits; + (reg_import g root regedits; + if (driver_name = "pvvxblk") then + add_pvvxbn_to_driver_database g root arch current_cs driverdir + );
(* A few more keys which we don't add above. Note that "oem1.inf" == @@ -454,6 +474,63 @@ and get_common_regedits g root current_cs adapter_guid driverdir driver driverde driverdesc_key, REG_SZ driverdesc ]; ]
+and add_pvvxbn_to_driver_database g root arch current_cs driverdir = + + let driver_name = "pvvxbn" in + + let inf_full = + let arch = + match arch with + | "x86_64" -> "amd64" + | "i386" | "i486" | "i585" | "i686" -> "x86" + | _ -> + error (f_"when adding pvvxbn to the DriverDatabase, unknown architecture: %s") arch in + sprintf "%s.inf_%s_%s" driver_name arch "9b414b949945d17b" in + + let driverdesc = "SUSE Bus/Balloon Driver for Windows" in + let driver_inst = "pvvxbn_inst" in + let provider = "SUSE" in + + let device_id = "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00" in + let device_subkey = "3&13c0b0c5&0&20" in + let device_alt = "CC_00FF00" in + + let balloon_bus_guid = "{4d36e97d-e325-11ce-bfc1-08002be10318}" in + + let class_guid = "{9fae43c0-44bf-465e-90c9-3da1c30ed68b}" in + + let service_group = "Boot Bus Extender" in + (* NB: balloon_bus_guid appears inside this string. *) + let driver_version = "\x00\xff\x09\x00\x00\x00\x00\x00\x7d\xe9\x36\x4d\x25\xe3\xce\x11\xbf\xc1\x08\x00\x2b\xe1\x03\x18\x00\x40\x7f\x1d\xdc\xfb\xd0\x01\x13\x00\x01\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00" in + let device_addr = "(0,4,0)" in + + let common_regedits = get_common_regedits g root current_cs balloon_bus_guid driverdir "pvvxbn.sys" driverdesc driver_version service_group inf_full device_id device_subkey device_alt device_addr provider in + + let regedits = common_regedits @ [ + [ current_cs; "Control"; "DeviceClasses"; class_guid ], + []; + + [ current_cs; "Control"; "DeviceClasses"; class_guid; + sprintf "##?#PCI#%s#%s#%s" device_id device_subkey class_guid ], + [ "DeviceInstance", REG_SZ (sprintf "PCI\\%s\\%s" device_id device_subkey) ]; + + [ current_cs; "Control"; "DeviceClasses"; class_guid; + sprintf "##?#PCI#%s#%s#%s" device_id device_subkey class_guid; "#" ], + []; + + [ current_cs; "Services"; driver_name; "Parameters"; "Device" ], + [ "grant_frames", REG_DWORD 0xA_l; + "pvctrl_flags", REG_DWORD 0x5_l; + "shutdown_notification", REG_DWORD 0x1_l; + "use_pv_drivers", REG_DWORD 0x1c0003_l ]; + + [ "DriverDatabase"; "DriverPackages"; inf_full; "Configurations"; driver_inst; "Services"; driver_name; "Parameters"; "Device" ], + [ "dbg_print_mask", REG_DWORD 0x7_l ]; + + ] in + + reg_import g root regedits; + (* Copy the matching drivers to the driverdir; return true if any have * been copied. *) -- 2.6.2
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Tue, Apr 05, 2016 at 01:47:33PM +0200, Cédric Bosdonnat wrote:
To add this support, the existing code searches for either the viostor or the VMDP (Virtual Machine Driver Pack) files and updates the registry accordingly.
Note that VMDP's block driver pvvxblk depends on the ballooning driver pvvxbn.
Can you please elaborate on this? Is the balloon driver *used* by the storage driver so that the latter won't work without the former? What will happen if the virtio-balloon device isn't configured in the VM? Or is it just a matter of ordering of the balloon driver within the driver start sequence, so that it can get its hands on the system as early as possible for its own purposes, and the storage driver doesn't require balloon's presence? Thanks, Roman.
On Tue, 2016-04-05 at 15:52 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:33PM +0200, Cédric Bosdonnat wrote:
To add this support, the existing code searches for either the viostor or the VMDP (Virtual Machine Driver Pack) files and updates the registry accordingly.
Note that VMDP's block driver pvvxblk depends on the ballooning driver pvvxbn.
Can you please elaborate on this? Is the balloon driver *used* by the storage driver so that the latter won't work without the former? What will happen if the virtio-balloon device isn't configured in the VM?
It's just that without the virtio balloon driver installed, the virtio block one won't start properly, resulting in the famous 0x7B error.
Or is it just a matter of ordering of the balloon driver within the driver start sequence, so that it can get its hands on the system as early as possible for its own purposes, and the storage driver doesn't require balloon's presence?
It's not ordering, it really requires it. -- Cedric
On Tue, Apr 05, 2016 at 03:08:48PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 15:52 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:33PM +0200, Cédric Bosdonnat wrote:
Note that VMDP's block driver pvvxblk depends on the ballooning driver pvvxbn.
Can you please elaborate on this? Is the balloon driver *used* by the storage driver so that the latter won't work without the former? What will happen if the virtio-balloon device isn't configured in the VM?
It's just that without the virtio balloon driver installed, the virtio block one won't start properly, resulting in the famous 0x7B error.
Does it also require the presence of the balloon device? Roman.
Here are the answers from our VMDP expert: On Tue, 2016-04-05 at 16:16 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 03:08:48PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 15:52 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:33PM +0200, Cédric Bosdonnat wrote:
Note that VMDP's block driver pvvxblk depends on the ballooning driver pvvxbn.
Can you please elaborate on this? Is the balloon driver *used* by the storage driver so that the latter won't work without the former?
That's correct. The current design requires that the balloon driver be loaded. The pvvxblk driver is a single binary that runs on both KVM and Xen. It determines at runtime which environment it is running on and acts accordingly. The dependency is required for Xen. This also creates the dependency for KVM.
What will happen if the virtio-balloon device isn't configured in the VM?
The balloon driver will not load and hence the block driver will not load.
It's just that without the virtio balloon driver installed, the virtio block one won't start properly, resulting in the famous 0x7B error.
Does it also require the presence of the balloon device?
Yes. This the default installation. The only way to remove the balloon device is to launch the vm by constructing a manually configured command line. Weather the balloon device is present or not, the user is able to set the current and maximum memory allocations differently. If different and the balloon device/driver is not present, the vm will undoubtedly crash at some point. -- Cedric
On Tue, Apr 05, 2016 at 05:38:40PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 16:16 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 03:08:48PM +0200, Cedric Bosdonnat wrote:
On Tue, 2016-04-05 at 15:52 +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 01:47:33PM +0200, Cédric Bosdonnat wrote:
Note that VMDP's block driver pvvxblk depends on the ballooning driver pvvxbn.
Can you please elaborate on this? Is the balloon driver *used* by the storage driver so that the latter won't work without the former?
That's correct. The current design requires that the balloon driver be loaded. The pvvxblk driver is a single binary that runs on both KVM and Xen. It determines at runtime which environment it is running on and acts accordingly. The dependency is required for Xen. This also creates the dependency for KVM.
What will happen if the virtio-balloon device isn't configured in the VM?
The balloon driver will not load and hence the block driver will not load.
It's just that without the virtio balloon driver installed, the virtio block one won't start properly, resulting in the famous 0x7B error.
Does it also require the presence of the balloon device?
Yes. This the default installation. The only way to remove the balloon device is to launch the vm by constructing a manually configured command line.
I don't know what management software you use on top of qemu; in libvirt it's certainly possible to remove a balloon device.
Weather the balloon device is present or not, the user is able to set the current and maximum memory allocations differently. If different and the balloon device/driver is not present, the vm will undoubtedly crash at some point.
I see no reason for that, but that's out of scope of this discussion. I got your point. Looks like the patchset to cut down the amount of regedits which I was about to post (I'm finishing testing it on various Windows versions) won't work for you as is because it assumes only single-file no-dependency storage drivers. I'll post it anyway; we'll see if it can be adjusted to cover your case, too. Roman.
participants (4)
-
Cedric Bosdonnat -
Cédric Bosdonnat
-
Richard W.M. Jones -
Roman Kagan