similar to: virt-v2v: Virtio-Scsi patch

On 15/09/2020 21:08, Richard W.M. Jones wrote: > On Tue, Sep 15, 2020 at 09:54:32AM +0200, Jean-Louis Dupond wrote: >> Hi, >> >> I was trying to migrate some VM's to Virtio-SCSI block devices, as >> this gives some advantages. >> >> While checking the virt-v2v code, I found out that it supported >> Virtio-SCSI, but some bits were missing. >>

Yaniv pointed out in https://bugzilla.redhat.com/show_bug.cgi?id=1438794 that virt-v2v both doesn't install the virtio-rng driver for Windows, and doesn't give the guest a virtio-rng PCI device either. There are two problems here: Firstly the Windows virtio-rng driver isn't included in the exploded tree (/usr/share/virtio-win) so it doesn't get copied into the guest. The solution

v1 was posted here: https://www.redhat.com/archives/libguestfs/2017-April/msg00031.html v1 -> v2: - Add support for -o glance. - Add support for -o qemu. - Fix the -o libvirt support for balloon as pointed out by Dan. - Fix a test failure caused by changing libvirt XML output. Rich.

v1: https://www.redhat.com/archives/libguestfs/2017-April/msg00031.html v2: https://www.redhat.com/archives/libguestfs/2017-April/msg00040.html v2 -> v3: - Fix Xen PV-only kernel detection. Rich.

v1: https://www.redhat.com/archives/libguestfs/2017-April/msg00031.html v2: https://www.redhat.com/archives/libguestfs/2017-April/msg00040.html v3: https://www.redhat.com/archives/libguestfs/2017-April/msg00051.html v3 -> v4: - Properly fix Xen PV-only kernel detection, and test it. Rich.

On Tue, Sep 15, 2020 at 09:54:32AM +0200, Jean-Louis Dupond wrote: > Hi, > > I was trying to migrate some VM's to Virtio-SCSI block devices, as > this gives some advantages. > > While checking the virt-v2v code, I found out that it supported > Virtio-SCSI, but some bits were missing. > In attachment a small patch that adds the missing bits :) This isn't the patch

Since commits b28cd1dc ("Remove requested_guestcaps / rcaps"), f0afc439 ("Remove guestcaps_block_type Virtio_SCSI") support for installing virtio-scsi driver is missing in virt-v2v. AFAIU plans and demands for bringing this feature back have been out there for a while. E.g. I've found a corresponding issue which is still open [1]. The code in b28cd1dc, f0afc439 was

Hi, due to a broken discover_modpath function, and to a wrong block for a match statement, the modprobe options for virtio/SCSI blocks where not written at all. This series provides a small refactor, and the fixes. Thanks, -- Pino Toscano (2): v2v: fix and implify the internal Convert_linux:discover_modpath v2v: fix priority of match in configure_kernel_modules v2v/convert_linux.ml | 34

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

This code is needed to check whether virtio-scsi driver was installed. This reverts commit f0afc439524853508938b2bfc758896f053462e3. --- convert/convert.ml | 2 +- convert/convert_linux.ml | 9 +++++++-- convert/target_bus_assignment.ml | 1 + lib/create_ovf.ml | 1 + lib/types.ml | 3 ++- lib/types.mli

This code is needed to check whether virtio-scsi driver was installed. This reverts commit f0afc439524853508938b2bfc758896f053462e3. --- convert/convert.ml | 2 +- convert/convert_linux.ml | 9 +++++++-- convert/target_bus_assignment.ml | 1 + lib/create_ovf.ml | 1 + lib/types.ml | 3 ++- lib/types.mli

On 3/7/23 20:40, Andrey Drobyshev wrote: > This code is needed to check whether virtio-scsi driver was installed. > > This reverts commit f0afc439524853508938b2bfc758896f053462e3. > --- > convert/convert.ml | 2 +- > convert/convert_linux.ml | 9 +++++++-- > convert/target_bus_assignment.ml | 1 + > lib/create_ovf.ml |

On 3/13/23 10:13, Laszlo Ersek wrote: > On 3/7/23 20:40, Andrey Drobyshev wrote: >> This code is needed to check whether virtio-scsi driver was installed. >> >> This reverts commit f0afc439524853508938b2bfc758896f053462e3. >> --- >> convert/convert.ml | 2 +- >> convert/convert_linux.ml | 9 +++++++-- >>

This is a sort of follow-up to the Linux_bootloaders patch. It turns out all the kernel detection code is nicely self- contained and can therefore be moved to its own module. Rich.

On 3/13/23 09:22, Andrey Drobyshev wrote: > On 3/13/23 10:13, Laszlo Ersek wrote: >> On 3/7/23 20:40, Andrey Drobyshev wrote: >>> This code is needed to check whether virtio-scsi driver was installed. >>> >>> This reverts commit f0afc439524853508938b2bfc758896f053462e3. >>> --- >>> convert/convert.ml | 2 +- >>>

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"

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

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