Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1362186

Summary:	Import KVM guest image: virtio-win drivers are not injected to Windows VM during import process (leads to BSOD).
Product:	[oVirt] ovirt-engine	Reporter:	Nisim Simsolo <nsimsolo>
Component:	BLL.Virt	Assignee:	Tomáš Golembiovský <tgolembi>
Status:	CLOSED WONTFIX	QA Contact:	Nisim Simsolo <nsimsolo>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	4.0.2.2	CC:	bugs, michal.skrivanek, mkalinin, nsimsolo, tgolembi, tjelinek
Target Milestone:	---	Flags:	sbonazzo: ovirt-4.2-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1374589 (view as bug list)		Environment:
Last Closed:	2017-08-21 21:07:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1374589
Bug Blocks:

Description Nisim Simsolo 2016-08-01 13:21:37 UTC

Description of problem:
When importing Windows VM from RHEL KVM environment, virtio-win drivers are not injected to VM during the import process (when using virt-v2v for example, virtio-win inject is done during import process).
This behavior leads to Windows BSOD when trying to run imported VM.

Version-Release number of selected component (if applicable):
rhevm-4.0.2.2-0.1.el7ev
vdsm-4.18.9-1.el7ev.x86_64
libvirt-client-1.2.17-13.el7_2.5.x86_64
qemu-kvm-rhev-2.3.0-31.el7_2.20.x86_64
sanlock-3.2.4-3.el7_2.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Browse webadmin and using import dialog, import Windows VM from KVM source with attached VirtIO ISO.
2. Run imported VM.

Actual results:
VM failed to run -> BSOD.
It is possible to change VM disk from VirtIO to IDE as a workaround, but in such case, the VM will run with IDE disk and without the other VirtIO-win drivers (such as network, display, RNG etc.)

Expected results:
virtio-win drivers should be injected to Windows VM during the import process.

Additional info:

Comment 1 Michal Skrivanek 2016-08-02 04:44:45 UTC

What devices was the VM using before import?

Comment 2 Nisim Simsolo 2016-08-02 06:39:29 UTC

IDE disk with IDE controller, NIC rtl8139, Serial device pty, video QXL, controller VirtIO serial.

Comment 3 Michal Skrivanek 2016-08-02 06:58:26 UTC

(In reply to Nisim Simsolo from comment #2)
> IDE disk with IDE controller, NIC rtl8139, Serial device pty, video QXL,
> controller VirtIO serial.

alright, so the problem is that after the import the VM has virtio set up, right? We probably should do some kind of simple mapping of known/supported devices and leave them intact, only change those oVirt doesn't support (similar to e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1324723#c16)

Comment 4 Michal Skrivanek 2016-08-02 11:34:07 UTC

another minor fix is to actually remove the virtio drivers drop down as it is not relevant to kvm imports. It just increases the confusion

Comment 5 Tomáš Golembiovský 2016-08-25 13:59:50 UTC

(In reply to Michal Skrivanek from comment #3)
> (In reply to Nisim Simsolo from comment #2)
> > IDE disk with IDE controller, NIC rtl8139, Serial device pty, video QXL,
> > controller VirtIO serial.
> 
> alright, so the problem is that after the import the VM has virtio set up,
> right? We probably should do some kind of simple mapping of known/supported
> devices and leave them intact, only change those oVirt doesn't support
> (similar to e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1324723#c16)

Yes, this would make sense probably not only for Windows guests, but also for
Linux too unless we're certain the virtio drivers are present in the kernel.

For NIC this already happens, for video and serial this can be also done.

For disk/controller it's not completely straightforward, because we don't
report the bus not controller from VDSM to engine. We do report the device hit
from libvirt, but the mapping is not unambiguous:

    hdX -> IDE
    vdX -> virtio
    sdX -> all the others? SCSI/SATA/USB/SD/...

And serial device is not reported from VDSM at all.

(In reply to Michal Skrivanek from comment #4)
> another minor fix is to actually remove the virtio drivers drop down as it
> is not relevant to kvm imports. It just increases the confusion

Aggreed.

Comment 6 Tomáš Golembiovský 2016-08-25 14:01:36 UTC

(In reply to Tomáš Golembiovský from comment #5)
> [...], for video and serial this can be also done.

Whops, typo! Not for serial, only for video.

Comment 7 Michal Skrivanek 2016-09-07 14:07:12 UTC

not sure if it's worth the effort at all

Comment 8 Michal Skrivanek 2016-09-09 07:33:50 UTC

let's:
improve reporting to add device type
remove the drop down (bug 1374589)

Comment 9 Yaniv Kaul 2016-11-30 08:57:07 UTC

I'm inclined to CLOSE-WONTFIX. I'm surprised anyone would run Windows on direct KVM - without virtio drivers.

Comment 10 Tomáš Golembiovský 2016-11-30 10:44:15 UTC

(In reply to Yaniv Kaul from comment #9)
> I'm inclined to CLOSE-WONTFIX. I'm surprised anyone would run Windows on
> direct KVM - without virtio drivers.

In that case it has to be stressed in documentation that virtio drivers have to be installed prior the import. We probably don't want to install the drivers (as virt-v2v does) in our KVM import tool.

Comment 11 Yaniv Kaul 2017-02-06 08:22:06 UTC

(In reply to Tomáš Golembiovský from comment #10)
> (In reply to Yaniv Kaul from comment #9)
> > I'm inclined to CLOSE-WONTFIX. I'm surprised anyone would run Windows on
> > direct KVM - without virtio drivers.
> 
> In that case it has to be stressed in documentation that virtio drivers have
> to be installed prior the import. We probably don't want to install the
> drivers (as virt-v2v does) in our KVM import tool.

Please open a separate bugs on docs for this.

Comment 12 Tomáš Golembiovský 2017-08-21 21:07:13 UTC

(In reply to Yaniv Kaul from comment #11)
> (In reply to Tomáš Golembiovský from comment #10)
> > (In reply to Yaniv Kaul from comment #9)
> > > I'm inclined to CLOSE-WONTFIX. I'm surprised anyone would run Windows on
> > > direct KVM - without virtio drivers.
> > 
> > In that case it has to be stressed in documentation that virtio drivers have
> > to be installed prior the import. We probably don't want to install the
> > drivers (as virt-v2v does) in our KVM import tool.
> 
> Please open a separate bugs on docs for this.

I have opened bug 1483580 for downstream docs and submitted pull request with documentation for upstream.

I'm closing this bug as WONTFIX then.