search for: add_viostor_to_registri

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

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,

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

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

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

On Tue, Feb 09, 2016 at 07:02:06PM +0000, Richard W.M. Jones wrote: > 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

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

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

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

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

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