search for: current_cli

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

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

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

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,

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

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

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

Parallels proprietary hypervisor uses RDPMC as the hypercall instruction. As this instruction is supported since early P6 family, the drivers didn't even bother to check for the presence of the corresponding feature in CPUID. In QEMU/KVM, however, this instruction triggers #GP unless the VM is run with PMU (performance monitoring unit) enabled, which is often not the case (due to its impact

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

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

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

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

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

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

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

To add this support, two things are needed: * make the existing code searches for either the viostor or the SUSE VMDP (Virtual Machine Driver Pack) files. * add a firstboot script setting up VMDP. Note that 2 firstboot scripts are intentionally added for the VMDP setup. This is due to windows potentially rebooting after loading the virtio block driver. It may happen that this reboot

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

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