similar to: [PATCH] v2v: fix identifier

Use the common open_guestfs to open Guestfs handles, so we get debugging, tracing, and other common options set. --- v2v/convert_windows.ml | 4 +--- v2v/input_disk.ml | 2 +- v2v/input_libvirt_other.ml | 2 +- v2v/input_ova.ml | 2 +- v2v/output_glance.ml | 2 +- v2v/output_null.ml | 2 +- v2v/output_rhev.ml | 2 +- v2v/output_vdsm.ml | 2 +-

On Wed, Oct 21, 2015 at 03:53:33PM +0200, Pino Toscano wrote: > Use the common open_guestfs to open Guestfs handles, so we get > debugging, tracing, and other common options set. > --- > v2v/convert_windows.ml | 4 +--- > v2v/input_disk.ml | 2 +- > v2v/input_libvirt_other.ml | 2 +- > v2v/input_ova.ml | 2 +- > v2v/output_glance.ml | 2 +- >

Refactor copying of virtio windows drivers into the guest so that the matching of the drivers to the guest os flavor and copying the files happens one next to the other in a single function, and no guestfs handle (nor any other irrelevant info) is leaked outside. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- changes since v1: - former patch #3 - updated usage of string functions

Libguestfs supports passing an ISO image as a source of virtio windows drivers to v2v. This series attempts to make it simpler and better scoped. Roman Kagan (3): v2v: consolidate virtio-win file copying v2v: copy virtio drivers without guestfs handle leak v2v: drop useless forced gc --- changes since v2: - drop patch 4 (reuse of the master guestfs handle for hot-adding the ISO image)

From: "Richard W.M. Jones" <rjones at redhat.com> If "block_driver" option is set to Virtio_SCSI, prepend the block drivers priority list with "vioscsi" so that we first search for "vioscsi.sys" during the drivers injection phase. Originally-by: Richard W.M. Jones <rjones at redhat.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at

From: "Richard W.M. Jones" <rjones at redhat.com> If "block_driver" option is set to Virtio_SCSI, prepend the block drivers priority list with "vioscsi" so that we first search for "vioscsi.sys" during the drivers injection phase. Originally-by: Richard W.M. Jones <rjones at redhat.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at

Libguestfs supports passing an ISO image as a source of virtio windows drivers to v2v. That support, however, looks too heavy-weight: in order to access those drivers, a separate guestfs handle is created (and thus a new emulator process is started), which runs until v2v completes. This series attempts to make it simpler and lighter-weight, by making the relevant code more local, and by

On Wednesday, 23 May 2018 15:42:42 CEST Tomáš Golembiovský wrote: > On Fri, 18 May 2018 17:42:15 +0200 > Pino Toscano <ptoscano@redhat.com> wrote: > > > If the RHV Setup Tools ISO is installed, open it, and copy RHEV APT from > > there, instead of using (if available) the executable located in the > > virt-tools data directory. > > > > This way, RHV

Extend open_guestfs to take an optional ?identifier parameter. Use this parameter in virt-v2v which is currently the only place where we use the handle identifier. --- mllib/common_utils.ml | 3 ++- mllib/common_utils.mli | 2 +- v2v/output_rhev.ml | 3 +-- v2v/output_vdsm.ml | 3 +-- v2v/v2v.ml | 3 +-- v2v/windows.ml | 3 +-- 6 files changed, 7 insertions(+), 10

On 3/7/23 09:35, Richard W.M. Jones wrote: > On Tue, Mar 07, 2023 at 08:48:56AM +0100, Laszlo Ersek wrote: >> On 3/6/23 17:52, Richard W.M. Jones wrote: >> >>> diff --git a/convert/convert_windows.ml b/convert/convert_windows.ml >>> index 9d8d271d05..f36b486359 100644 >>> --- a/convert/convert_windows.ml >>> +++ b/convert/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

If we're given an ISO image as the source of virtio windows drivers, and the backend supports hot-adding drives, reuse the same guestfs handle that is open for accessing the guest being inspected, rather than creating a new one (which would run another virtual machine instance and is fairly resource-intensive). Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- changes since v1: -

Refactor copying of virtio windows drivers into the guest so that the matching of the drivers to the guest os flavor and copying the files happens one next to the other in a single function, and no guestfs handle (nor any other irrelevant info) is leaked outside. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/convert_windows.ml | 77 ++++++++++------- v2v/utils.ml |

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

The 'may' function is a higher-order function (HOF) that replaces: match x with | None -> () | Some x -> f x with: may f x The idea comes from lablgtk (OCaml Gtk bindings) where it is widely used. If this change is clearer than previous code, then this could be used in many more places. However I previously steered clear from using HOFs like this because they can be

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

If the RHV Setup Tools ISO is installed, open it, and copy RHEV APT from there, instead of using (if available) the executable located in the virt-tools data directory. This way, RHV conversion hosts with the RHV Setup Tools ISO installed will always install the latest version when convering Windows guests, no matter which version is (eventually) shipped as virt-tools. --- v2v/convert_windows.ml

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

Discussion on v2: https://listman.redhat.com/archives/libguestfs/2023-March/030987.html v2 -> v3: * Patch 2/6 ("convert_windows: add Inject_virtio_win.Virtio_SCSI as a possible block type"): omit "Inject_virtio_win." prefix in favor of type inference. Add a short commit message body; * Add tests/test-v2v-block-driver.sh testing the new "--block-driver"

Discussion on v1: https://listman.redhat.com/archives/libguestfs/2023-February/030849.html https://listman.redhat.com/archives/libguestfs/2023-March/030917.html v1 -> v2: * Adapt the patch suggested by Richard, splitting it up into 3: https://listman.redhat.com/archives/libguestfs/2023-March/030975.html Now we have "--block-driver" command line option which regulates the