search for: add_viostor_to_registry

...o.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...

...ers/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 + ); + ad...

...de_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...

...(* 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 tha...

...if block = Virtio_blk then ( > + let source = driverdir // "viostor.sys" in > 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; > - Virtio_blk > - ) else ( > - 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.&quo...

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

...then ( > > + let source = driverdir // "viostor.sys" in > > 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; > > - Virtio_blk > > - ) else ( > > - 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 emula...

...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 ro...

...PnP + * manager *) + if block = Virtio_blk then ( + let source = driverdir // "viostor.sys" in 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; - Virtio_blk - ) else ( - 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.") -...

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

The way we patch the Windows registry in order to allow it to boot off a virtio-blk drive was initially conceived by comparing the state with virtio-blk driver properly installed, to that without. However, we don't want to replicate the Windows PnP system; rather we need to apply just enough edits to make the system boot, and then let the Windows PnP manager figure out the rest. This series

...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 target = g#case_sensitive_path target in g#cp source target; add_viostor_to_registry g inspect root current_cs; Virtio_blk - ) else ( - 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.") -...

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset