similar to: [PATCH] v2v: move virtio_win to windows_virtio

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

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

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,

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

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

On Tue, Feb 09, 2016 at 05:42:00PM +0300, Roman Kagan wrote: > 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. Yup, obviously simplification. > --- a/v2v/windows_virtio.mli > +++ b/v2v/windows_virtio.mli > @@ -19,7 +19,7

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

Changed the function to be more generic and renamed to copy_files. The only change in behavior is in produced debug messages. Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/windows_virtio.ml | 52 ++++++++++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 20 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index

Changed the function to be more generic and renamed. The only change in behavior is in produced debug messages. Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/windows_virtio.ml | 48 ++++++++++++++++++++++++++++--------------- 1 file changed, 31 insertions(+), 17 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 9b45c76f5..da02b6c4e 100644 ---

Changed the function to be more generic and renamed. The only change in behavior is in produced debug messages. Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/windows_virtio.ml | 48 ++++++++++++++++++++++++++++--------------- 1 file changed, 31 insertions(+), 17 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 9b45c76f5..da02b6c4e 100644 ---

On Wed, Nov 07, 2018 at 12:53:18PM +0100, Tomáš Golembiovský wrote: > Changed the function to be more generic and renamed. > The only change in behavior is in produced debug messages. > > Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> > --- > v2v/windows_virtio.ml | 48 ++++++++++++++++++++++++++++--------------- > 1 file changed, 31 insertions(+), 17

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

This makes several changes to the handling of virtio-win drivers: The VIRTIO_WIN_DIR environment variable has been renamed VIRTIO_WIN (but you can still use the old name). You can point the VIRTIO_WIN either at a RHEL virtio-win directory (ie. /usr/share/virtio-win), OR at a loopback-mounted virtio-win ISO, OR at the virtio-win.iso file itself. In the latter case, libguestfs is used to open the

Copy the appropriate driver files from the virtio-win storage into %SYSTEMROOT%\Drivers\VirtIO once they are discovered, and stick to using those copies later on. This way the knowledge of where the drivers come from originally is consolidated in one place, so the lifetime of the associated entities becomes easier to control (to be implemented in followup patches). Signed-off-by: Roman Kagan

This makes several changes to the handling of virtio-win drivers: The VIRTIO_WIN_DIR environment variable has been renamed VIRTIO_WIN (but you can still use the old name). You can point the VIRTIO_WIN either at a RHEL virtio-win directory (ie. /usr/share/virtio-win), OR at a loopback-mounted virtio-win ISO, OR at the virtio-win.iso file itself. In the latter case, libguestfs is used to open the