similar to: [PATCH] v2v:windows: prevent Parallels drivers from loading at boot

A very miscellaneous set of cleanups to how we handle the Windows registry in virt-v2v, firstboot, and inspection code. This should all be straightforward non-controversial refactoring. Some highlights: - Add a new mllib Registry module containing various utility functions that are currently scattered all around. - Only compute the software/system hive paths once during inspection, and

Don't remove the Processor and Intelppm nodes since that just breaks the device driver. The only remaining node being removed by the original code was "rhelscsi" (the xenpv-win driver). I changed this so that instead of deleting the whole node, it simply disables that driver. If you look at RHBZ#737600, it's not even clear that deleting nodes was the right fix for anything. I

If a Windows boot fails and the user boots the last known good configuration, ControlSet001 will be marked as failed and no longer used. However, virt-v2v would only install viostor to ControlSet001, meaning it will fail to boot this guest after conversion. This patch looks up the current controlset and always installs registry keys to the correct one. Fixes RHBZ#644254 ---

On Wed, Aug 17, 2016 at 08:59:43PM +0300, Roman Kagan wrote: > It will be used in new code in a followup patch. > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > --- > v2v/convert_windows.ml | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml > index 55bb3ef..751a6ab

There is an issue with removal of parallels disk paravirt driver. Without the patch, the VM being migrated may not boot on the desination with BSOD: 0x7b. The patch is a workaround to prevent the BSOD. Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com> --- v2v/convert_windows.ml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml

Now that all the stuff related to Windows virtio drivers has been moved into a dedicated module, it makes sense to move the definition of virtio_win there, too, and stop passing it around as a parameter. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/convert_windows.ml | 9 +-------- v2v/windows_virtio.ml | 13 ++++++++++--- v2v/windows_virtio.mli | 2 +- 3 files changed, 12

On Tue, Feb 09, 2016 at 05:53:57PM +0300, Roman Kagan wrote: > diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml > index bdce038..8e0430c 100644 > --- a/v2v/windows_virtio.ml > +++ b/v2v/windows_virtio.ml > @@ -33,57 +33,105 @@ let virtio_win = > with Not_found -> > Guestfs_config.datadir // "virtio-win" > > -let rec install_drivers g

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

[Partly using the mailing list as a backup again ...] This commit changes virt-v2v to make registry changes to all ControlSets, not just the CurrentControlSet. Not sure what difference if any this would make. Rich.

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

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 +++

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,

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(+),

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

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

This allows users to see stop errors, so we can get an accurate report when things go wrong. --- v2v/convert_windows.ml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index e37c6b8..c8db860 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -191,6 +191,7 @@ echo uninstalling Xen PV driver if verbose then

Give the caller certain control over what kind of interface to use for virtual disks, network and video cards upon conversion. For that, make convert functions accept additional rcaps parameter containing an object with optional capabilities similar to the ones produced on output, with None indicating that the decision is left to the convert function itself. To facilicate review, this patch

Give the caller certain control over what kind of interface to use for virtual disks, network and video cards upon conversion. For that, make convert functions accept additional rcaps parameter containing an object with optional capabilities similar to the ones produced on output, with None indicating that the decision is left to the convert function itself. To facilicate review, this patch

Wait for driver installations fired by the PnP manager to complete before running firstboot scripts. The first patch is a minor refactoring to pave the way for the second patch. The latter contains the bulk of the changes as well as the description of the idea. Roman Kagan (2): v2v:windows: factor out getting CurrentControlSet v2v:windows: prevent conflicts with PnP on firstboot --- v1

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