similar to: Red Hat VirtIO SCSI pass-through controller

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 >

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

There are registry entries that are needed to add some other drivers. Extracting them into a function will help adding SUSE VMDP support. --- v2v/windows_virtio.ml | 311 ++++++++++++++++++++++++++++---------------------- 1 file changed, 176 insertions(+), 135 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 14ffc51..8a0b529 100644 --- a/v2v/windows_virtio.ml +++

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

Hello Roman, We have a bug with Windows 8 UEFI conversions failing with the usual 0x7B error: https://bugzilla.redhat.com/show_bug.cgi?id=1431579 There is a seemingly plausible theory that this happens because for UEFI we use a qemu Q35 machine type. Q35 machine type implies all-modern PCI-e devices, which implies the use of virtio-1.0 and disabling of virtio legacy. Virtio-1.0 uses

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

[Partly using the mailing list as a backup again ...] This commit changes virt-v2v to make registry changes to all ControlSets, not just the CurrentControlSet. Not sure what difference if any this would make. Rich.

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

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

https://github.com/rwmjones/libguestfs/tree/rewrite-virtio-copy-drivers Instead of trying to split and parse elements from virtio-win paths, use the '*.inf' files supplied with the drivers to control how Windows drivers are installed. The following emails best explain how this works: https://www.redhat.com/archives/libguestfs/2015-October/msg00352.html

if it works thank god for notepad2 (If it's not then be patience, I am just a windows user). Amos. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-use-single-registry-change-for-all-supported-windows.patch Type: application/octet-stream Size: 10635 bytes Desc: not available URL:

Patch 1 moves the v2v/fake-virtio-win and v2v/fake-virt-tools directories to the recently created test-data/ hierarchy. This is just refactoring with no functional change at all. Patches 2-4 then extend the available (fake) virtio-win drivers: - Patch 2 adds all of the drivers from the virtio-win RPM. - Patch 3 adds all of the drivers from the virtio-win ISO (which are different from the

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.

On Tue, Jun 23, 2015 at 09:18:01AM +0300, Shahar Havivi wrote: > On 22.06.15 15:33, Richard W.M. Jones wrote: > > 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

Since v1: - Fix a bug in the calculation of lc_basename. By luck this doesn't affect anything given the contents of the current ISO. - Don't copy the WdfCoInstaller*.dll files. Rich.

This series makes several enhancements to tests for v2v conversion of Windows guests. Specifically, it - adds a number of files which imitate the stuff that is supposed to be present on the host when the actual conversion is performed, but may not be there when the tests are run. This includes certain tools and virtio drivers - fixes the test for windows conversion to actually

When injecting virtio-win drivers, allow the list of block drivers that we search to be modified. --- mlcustomize/inject_virtio_win.ml | 12 +++++++++--- mlcustomize/inject_virtio_win.mli | 10 ++++++++++ 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/mlcustomize/inject_virtio_win.ml b/mlcustomize/inject_virtio_win.ml index 4e977b3..2a7c742 100644 ---

If a Windows boot fails and the user boots the last known good configuration, ControlSet001 will be marked as failed and no longer used. However, virt-v2v would only install viostor to ControlSet001, meaning it will fail to boot this guest after conversion. This patch looks up the current controlset and always installs registry keys to the correct one. Fixes RHBZ#644254 ---

On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > On Wed, 2015-10-28 at 14:53 +0300, Roman Kagan wrote: > > 1) tell which devices can be configured > Not sure that I fully understated your question. but if you are going to > create some sort of off-line automatic virtio-win drivers update > utility, then it shouldn't be too complicated. Firs of all you will

v2 -> v3 - Don't make a special case for WdfCoInstaller* files. There is a difference of opinion about whether copying these is necessary, but it seems like it is not harmful. Rich.