6:47 a.m.
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
6:47 a.m.
New subject: [PATCH 1/7] v2v: check next free oem%d.inf in /Windows/Inf
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
7:04 a.m.
New subject: [PATCH 1/7] v2v: check next free oem%d.inf in /Windows/Inf
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(a)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
7:24 a.m.
New subject: [PATCH 1/7] v2v: check next free oem%d.inf in /Windows/Inf
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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
7:26 a.m.
New subject: [PATCH 1/7] v2v: check next free oem%d.inf in /Windows/Inf
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
7:13 a.m.
New subject: [PATCH 1/7] v2v: check next free oem%d.inf in /Windows/Inf
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.
7:26 a.m.
New subject: [PATCH 1/7] v2v: check next free oem%d.inf in /Windows/Inf
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
6:47 a.m.
New subject: [PATCH 2/7] v2v: extract controller offset discovery as a function
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
7:16 a.m.
New subject: [PATCH 2/7] v2v: extract controller offset discovery as a function
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(a)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
9:21 a.m.
New subject: [PATCH 2/7] v2v: extract controller offset discovery as a function
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.
6:47 a.m.
New subject: [PATCH 3/7] customize: add support for pvvxsvc
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
7:11 a.m.
New subject: [PATCH 3/7] customize: add support for pvvxsvc
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
7:41 a.m.
New subject: [PATCH 3/7] customize: add support for pvvxsvc
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.
6:47 a.m.
New subject: [PATCH 4/7] v2v: extract reusable parts of viostor regedits
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 "(a)%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
"(a)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
("(a)System32\\drivers\\pci.sys,#65536;PCI bus %1, device %2, function %3;" ^
device_addr);
+ "Mfg", REG_SZ (sprintf "(a)%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
7:16 a.m.
New subject: [PATCH 4/7] v2v: extract reusable parts of viostor regedits
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
6:47 a.m.
New subject: [PATCH 5/7] v2v: adapt the subkey in Enum registry to windows version
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-win...
* 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
7:18 a.m.
New subject: [PATCH 5/7] v2v: adapt the subkey in Enum registry to windows version
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-win...
* 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(a)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
6:47 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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
7:20 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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
9:19 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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.
10:33 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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
10:37 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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(a)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
11:53 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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.
1:08 p.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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.
2:16 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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
2:54 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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.8...
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.
3:13 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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
3:43 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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.
4:24 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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
5:40 a.m.
New subject: [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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.
6:47 a.m.
New subject: [PATCH 7/7] v2v: add support for SUSE VMDP drivers
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-win...
* 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
7:21 a.m.
New subject: [PATCH 7/7] v2v: add support for SUSE VMDP drivers
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-win...
* 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(a)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
7:52 a.m.
New subject: [PATCH 7/7] v2v: add support for SUSE VMDP drivers
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.
8:08 a.m.
New subject: [PATCH 7/7] v2v: add support for SUSE VMDP drivers
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
8:16 a.m.
New subject: [PATCH 7/7] v2v: add support for SUSE VMDP drivers
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.
10:38 a.m.
New subject: [PATCH 7/7] v2v: add support for SUSE VMDP drivers
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
1:31 p.m.
New subject: [PATCH 7/7] v2v: add support for SUSE VMDP drivers
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.
3184
days inactive
3185
days old
36 comments
4 participants
participants (4)
-
Cedric Bosdonnat -
Cédric Bosdonnat
-
Richard W.M. Jones -
Roman Kagan