similar to: [PATCH virt-v2v] v2v: windows: Install both legacy and modern virtio

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: * Drop the logic where default is switched to "vioscsi". Keep virtio-blk as default. * Adapt the patch suggested by Richard: https://listman.redhat.com/archives/libguestfs/2023-March/030974.html This

Discussion on v2: https://listman.redhat.com/archives/libguestfs/2023-March/030989.html v2 -> v3: * Patch 1/4 ("inject_virtio_win: match only vendor/device/revision"): do not omit PCI Revision ID. Adjust commit message accordingly; * Patch 2/4 ("inject_virtio_win: add Virtio_SCSI to block_type"): add non-empty commit message body. * Patch 4/4

From: Roman Kagan <rkagan at virtuozzo.com> Since different hypervisor vendors are allowed to use their own vendor-id as PCI subsystem-vendor-id for virtio devices, during v2v conversion it makes sense to only match the vendor/device/revision and not the full device "path" in the Windows registry. This way the code will remain universal but will work for different hypervisor

From: Roman Kagan <rkagan at virtuozzo.com> Since different hypervisor vendors are allowed to use their own vendor-id as PCI subsystem-vendor-id for virtio devices, during v2v conversion it makes sense to only match the vendor/device and not the full device "path" in the Windows registry. This way the code will remain universal but will work for different hypervisor vendors.

In case when we are injecting virtio-scsi device driver into the guest (rather than the default virtio-blk), make sure we write the right PCI ID value into the Windows guest registry. This is essential for the guest to be bootable afterwards. Originally-by: Roman Kagan <rkagan at virtuozzo.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> ---

On 3/8/23 22:45, Richard W.M. Jones wrote: > On Tue, Mar 07, 2023 at 09:40:26PM +0200, Andrey Drobyshev wrote: >> In case when we are injecting virtio-scsi device driver into the guest >> (rather than the default virtio-blk), make sure we write the right PCI ID >> value into the Windows guest registry. This is essential for the guest >> to be bootable afterwards.

On Tue, Mar 07, 2023 at 09:40:26PM +0200, Andrey Drobyshev wrote: > In case when we are injecting virtio-scsi device driver into the guest > (rather than the default virtio-blk), make sure we write the right PCI ID > value into the Windows guest registry. This is essential for the guest > to be bootable afterwards. > > Originally-by: Roman Kagan <rkagan at virtuozzo.com>

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

In case when we are injecting virtio-scsi device driver into the guest (rather than the default virtio-blk), make sure we write the right PCI ID value into the Windows guest registry. This is essential for the guest to be bootable afterwards. Originally-by: Roman Kagan <rkagan at virtuozzo.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> ---

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

If virtio-scsi is present among the tools for this version of Windows, prefer it over virtio-blk. Originally-by: Roman Kagan <rkagan at virtuozzo.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> --- mlcustomize/inject_virtio_win.ml | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/mlcustomize/inject_virtio_win.ml

Hello, All! virtio-win.iso contains two different Windows drivers. these Windows Server 2012 R2 drivers have different hardware IDs: \vioscsi\2k12R2\amd64\vioscsi.inf "Red Hat VirtIO SCSI pass-through controller" PCI\VEN_1AF4&DEV_1004&SUBSYS_00081AF4&REV_00 PCI\VEN_1AF4&DEV_1048&SUBSYS_11001AF4&REV_01 \viostor\2k12R2\amd64\viostor.inf "Red Hat VirtIO SCSI

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

Le 14/03/2017 ? 19:05, Gena Makhomed a ?crit : > Hello, All! > > virtio-win.iso contains two different Windows drivers. > these Windows Server 2012 R2 drivers have different hardware IDs: > > \vioscsi\2k12R2\amd64\vioscsi.inf > "Red Hat VirtIO SCSI pass-through controller" > PCI\VEN_1AF4&DEV_1004&SUBSYS_00081AF4&REV_00 >

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

Hi there! I know it's been a while since I posted my first version of some patches. But here I have rebased them on top of Roman's work and added a few other ones. Cédric Bosdonnat (11): v2v: also search for windows virtio drivers in symlinks Update packagelist for SLES customize: fix windows firstboot script customize: change windows firstboot path customize: add support for

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

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.

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