similar to: virtio not installing correctly

Zoltan Frombach writes: > Hi, > > I did many physical (Windows) to virtual (kvm) conversions before. The > instructions in general are good here: > http://www.linux-kvm.org/page/Boot_from_virtio_block_device , so yes, you > must add a dummy ("fake") 2nd disk drive to the guest first, boot up the > guest, install the virtio drivers to that 2nd virtual HDD and after

Hi, I did many physical (Windows) to virtual (kvm) conversions before. The instructions in general are good here: http://www.linux-kvm.org/page/Boot_from_virtio_block_device , so yes, you must add a dummy ("fake") 2nd disk drive to the guest first, boot up the guest, install the virtio drivers to that 2nd virtual HDD and after that you can shutdown the guest, remove the dummy drive

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

On 2/2/2016 12:05 PM, isdtor wrote: > Zoltan Frombach writes: >> Hi, >> >> I did many physical (Windows) to virtual (kvm) conversions before. The >> instructions in general are good here: >> http://www.linux-kvm.org/page/Boot_from_virtio_block_device , so yes, you >> must add a dummy ("fake") 2nd disk drive to the guest first, boot up the >>

The test checks that the newly introduced --block-driver option doesn't break conversion. Basically its logic somewhat repeats test-v2v-i-disk.sh and test-v2v-in-place.sh, but with the new option being set. The checks it performs are: 1. Run disk-sourced conversion (-i disk) based on the phony windows.img and check that it completes (i.e. produces converted disk and corresponding

Windows QXL drivers include also qxldd.dll which used to get filtered out and not copied over into the guest. As a result QXL driver failed to install due to a missing file. Correct that, and update the tests accordingly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/fake-virtio-win/drivers/i386/Win7/qxldd.dll | 1 + v2v/test-v2v-in-place.sh | 1 +

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

I am trying to install windows 10 (dreamspark education ISO) into qemu-kvm on Gentoo linux. I got past the cpu problems but am stuck on the image file drivers. The relevant xml is below. It asks for the driver disk which I have, but if I select a driver (either vioscsi or viostor which show as valid it churns away for a few seconds and brings up the cant find driver dialog and cant progress.

On 3/9/23 16:50, Andrey Drobyshev wrote: > On 3/8/23 22:46, Richard W.M. Jones wrote: >> >> The patch series looks generally fine, but it really needs a test ... >> >> We find that having tests prevents unnoticed regressions from >> happening later. >> >> Rich. >> > > Could you please elaborate on how do you imagine such a test case? >

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>

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 https://www.redhat.com/archives/libguestfs/2015-November/msg00065.html Currently the product variant (eg.

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

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

In order to test the copying of virtio-win drivers into the guest during v2v, create a set of fake virtio-win drivers and make use of them in the corresponding v2v tests. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- tests/fake-virtio-win/drivers/i386/Win7/netkvm.cat | 1 + tests/fake-virtio-win/drivers/i386/Win7/netkvm.inf | 1 +

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

In order to test the copying of virtio-win drivers into the guest during v2v, create a set of fake virtio-win drivers and make use of them in the corresponding v2v tests. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- changes since v1: - moved fake-virtio-win under v2v - referred to fake-virtio-win stuff via $PWD in test scripts - updated Makefile to package the newly added files

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

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

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