Bug 1300959 - rhevm should require a virtio-win version that provides win10 drivers within vfd
rhevm should require a virtio-win version that provides win10 drivers within vfd
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.2
Unspecified Unspecified
high Severity high
: ovirt-4.1.0-alpha
: ---
Assigned To: Sandro Bonazzola
Jiri Belka
:
Depends On: 1282348 1304973 1328275
Blocks: 1306586 1379559
  Show dependency treegraph
 
Reported: 2016-01-22 03:35 EST by Jiri Belka
Modified: 2017-04-24 21:11 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
The latest virtio-win release which includes Windows 10 drivers is now required by the Manager to ensure that suitable drivers can be supplied to virtual machines during installation of Windows 10.
Story Points: ---
Clone Of:
: 1304973 1306586 1379559 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Integration
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jiri Belka 2016-01-22 03:35:50 EST
Description of problem:

# rpm -q rhevm ; rpm -qR rhevm | grep virtio-win
rhevm-3.6.2.6-0.1.el6.noarch
virtio-win >= 1.6.6-1

But such old virtio-win doesn't contain drivers for Windows 10 (BZ1249873). Thus an user won't be able to use RHEVM feature to attach vfd with virtio drivers for Windows 10 during installation of the VM.

Version-Release number of selected component (if applicable):
rhevm-3.6.2.6-0.1.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. check rpm -qR rhevm
2.
3.

Actual results:
deps would be met with a virtio-win rpm which does not support Windows 10 virtio-win drivers

Expected results:
rhevm deps should guarantee that virtio-win rpm supports Windows 10 virtio-win drivers

Additional info:
Comment 1 Jiri Belka 2016-01-22 08:48:27 EST
According to https://bugzilla.redhat.com/show_bug.cgi?id=1249873#c17 there's no vfd with virtio drivers for Windows 10.
Comment 2 Sandro Bonazzola 2016-02-03 04:16:11 EST
Jiri, referenced bug #1249873 is on 7.2. I can't see available any virtio-win >= 1.8.0-1 available to RHEL 6 yet.
Comment 3 Sandro Bonazzola 2016-02-03 04:45:30 EST
Changing the request to >= 1.7.4-1 according to https://bugzilla.redhat.com/show_bug.cgi?id=1282348#c8
Comment 4 Sandro Bonazzola 2016-02-03 04:47:17 EST
Dropping dependency on bug #1167941 since nothing there prevent this BZ to be fixed.
Adding dep on bug #1282348 as per comment #3
Comment 5 Jiri Belka 2016-02-04 04:05:40 EST
Windows 10 drivers exist only on iso, they do neither exist on vfd or as "normal" files of the rpm:

$ rpm -qlp virtio-win-1.7.4-1.el6_7.2.noarch.rpm | egrep '/Win[^\/]*$'
/usr/share/virtio-win/drivers/amd64/Win2003
/usr/share/virtio-win/drivers/amd64/Win2008
/usr/share/virtio-win/drivers/amd64/Win2008R2
/usr/share/virtio-win/drivers/amd64/Win2012
/usr/share/virtio-win/drivers/amd64/Win2012R2
/usr/share/virtio-win/drivers/amd64/Win7
/usr/share/virtio-win/drivers/amd64/Win8
/usr/share/virtio-win/drivers/amd64/Win8.1
/usr/share/virtio-win/drivers/i386/Win2003
/usr/share/virtio-win/drivers/i386/Win2008
/usr/share/virtio-win/drivers/i386/Win7
/usr/share/virtio-win/drivers/i386/Win8
/usr/share/virtio-win/drivers/i386/Win8.1
/usr/share/virtio-win/drivers/i386/WinXP

$ rpm -qlp virtio-win-1.7.4-1.el6_7.2.noarch.rpm | egrep '\.(iso|vfd)$'
/usr/share/virtio-win/virtio-win-1.7.4.iso
/usr/share/virtio-win/virtio-win-1.7.4_amd64.vfd
/usr/share/virtio-win/virtio-win-1.7.4_x86.vfd
/usr/share/virtio-win/virtio-win.iso
/usr/share/virtio-win/virtio-win_amd64.vfd
/usr/share/virtio-win/virtio-win_x86.vfd

$ for f in virtio-win-1.7.4.iso virtio-win-1.7.4_amd64.vfd virtio-win-1.7.4_x86.vfd ; do 7z l $f | egrep -i 'w(in)*10$' | while read l ; do echo $f $l ; done ; done 
virtio-win-1.7.4.iso 2015-10-08 20:06:44 D.... Balloon/w10
virtio-win-1.7.4.iso 2015-10-08 20:06:44 D.... NetKVM/w10
virtio-win-1.7.4.iso 2015-10-08 20:06:44 D.... viorng/w10
virtio-win-1.7.4.iso 2015-10-08 20:06:44 D.... vioscsi/w10
virtio-win-1.7.4.iso 2015-10-08 20:06:44 D.... vioserial/w10
virtio-win-1.7.4.iso 2015-10-08 20:06:44 D.... viostor/w10

So again, most users would install Windows 10 with virtio block device witch attaching vfd with drivers.
Comment 6 Sandro Bonazzola 2016-02-05 02:39:33 EST
So marking this as blocked by bug #1304973 since I don't have a virtio-win package to require providing what you're asking.
Comment 7 Cole Robinson 2016-02-09 11:27:06 EST
Hmm. My understanding was that RHEV didn't use the .vfd files? Is the .iso not sufficient for the win10 install case? (honestly I'm not sure, I've never tested it for myself)

We've had perpetual problems with space issues on the .vfd so it might not as simple as just extending the image.
Comment 8 Yaniv Kaul 2016-02-09 11:44:17 EST
(In reply to Cole Robinson from comment #7)
> Hmm. My understanding was that RHEV didn't use the .vfd files? Is the .iso
> not sufficient for the win10 install case? (honestly I'm not sure, I've
> never tested it for myself)
> 
> We've had perpetual problems with space issues on the .vfd so it might not
> as simple as just extending the image.

I remember we used to. I'm not sure how would you install the drivers during OS installation (from a CDROM) without the floppy - eject the installation media, put the virtio cdrom, ... ?
Comment 9 Cole Robinson 2016-02-09 11:48:02 EST
I assume it would mean using a second IDE CDROM device, that should work as described here:

https://rwmj.wordpress.com/2015/04/07/tip-virt-install-windows-with-virtio-device-drivers/

I originally thought the .vfd was only for compat with older windows (I think pre windows 7) that couldn't get disk drivers from a floppy.

So who can answer this for latest RHEV?
Comment 10 Vadim Rozenfeld 2016-02-09 20:27:27 EST
(In reply to Cole Robinson from comment #9)
> I assume it would mean using a second IDE CDROM device, that should work as
> described here:
> 
> https://rwmj.wordpress.com/2015/04/07/tip-virt-install-windows-with-virtio-
> device-drivers/
> 
> I originally thought the .vfd was only for compat with older windows (I
> think pre windows 7) that couldn't get disk drivers from a floppy.

Technically, only WXp and WS2003 require floppy image for installing boot-time viostor (virtio-blk) driver. The rest of the drivers for all kinds of supported platforms were added in response to requests coming from different
teams and people. In any case, having a second IDE CDROM is always good. But if don't have it in the system, then floppy image is the only way to provide virtio-win drivers while installing the OS.
Comment 11 Cole Robinson 2016-02-10 09:57:23 EST
(In reply to Vadim Rozenfeld from comment #10)
> (In reply to Cole Robinson from comment #9)
> > I assume it would mean using a second IDE CDROM device, that should work as
> > described here:
> > 
> > https://rwmj.wordpress.com/2015/04/07/tip-virt-install-windows-with-virtio-
> > device-drivers/
> > 
> > I originally thought the .vfd was only for compat with older windows (I
> > think pre windows 7) that couldn't get disk drivers from a floppy.
> 
> Technically, only WXp and WS2003 require floppy image for installing
> boot-time viostor (virtio-blk) driver. The rest of the drivers for all kinds
> of supported platforms were added in response to requests coming from
> different
> teams and people. In any case, having a second IDE CDROM is always good. But
> if don't have it in the system, then floppy image is the only way to provide
> virtio-win drivers while installing the OS.

Thanks for the info. Though I wonder in what _realistic_ will a windows 10 VM that is installing virtio drivers not be able to provide a second IDE CDROM?

What I'm trying to determine is if the requests to extend the .vfd images are actually a necessity for RHEV. Because it's going to continue to be an issue for every new windows release. Eventually we will run out of space again and need to use a new naming scheme for the vfd images which may require RHEV patches anyways for all I know.

It would be nice to have a plan to wean off of their usage regardless, or have RHEV do something akin to boxes which assembles the .vfd on the fly which is not much work, provided we alter the RPM to start distributing all the drivers in /usr/share.

But I guess the still unanswered bit is how exactly modern RHEV uses these images, if at all.
Comment 12 Michal Skrivanek 2016-02-10 11:58:58 EST
second CDROM would be possible, it's just not there yet for historical reasons. Perhaps we can finally phase out floppy completely as we do not intend to support XP and 2003 anymore
it's too late for such change in 3.6, but it should be doable for next release. Is "vfd on the fly" a viable approach long-term?
Comment 13 Cole Robinson 2016-02-10 12:06:47 EST
(In reply to Michal Skrivanek from comment #12)
> second CDROM would be possible, it's just not there yet for historical
> reasons. 
> Perhaps we can finally phase out floppy completely as we do not
> intend to support XP and 2003 anymore
> it's too late for such change in 3.6, but it should be doable for next
> release. 

Okay. So just to clarify, latest RHEV depends on the .vfd files to install virtio-blk drivers for all windows version installs?

> Is "vfd on the fly" a viable approach long-term?

If you're going to rework things, and are dropping support for winxp and win2003, I'd suggest looking into the second cdrom method instead.

But I think generating the vfd image is viable long term. The logic would basically be:

- Determine the windows version+arch being installed
- Find the associated drivers in /usr/share/virtio-win/*
- Run the correct mkisofs command to generate a .vfd
Comment 14 Michal Skrivanek 2016-02-10 12:38:14 EST
(In reply to Cole Robinson from comment #13)
> Okay. So just to clarify, latest RHEV depends on the .vfd files to install
> virtio-blk drivers for all windows version installs?

yes. there is no other way currently
 
> > Is "vfd on the fly" a viable approach long-term?
> 
> If you're going to rework things, and are dropping support for winxp and
> win2003, I'd suggest looking into the second cdrom method instead.
>
> But I think generating the vfd image is viable long term. The logic would
> basically be:
> 
> - Determine the windows version+arch being installed
> - Find the associated drivers in /usr/share/virtio-win/*
> - Run the correct mkisofs command to generate a .vfd

we have similar code for both, mkisofs for sysprep floppy, 2nd CD for VM payload. 
I guess...if CD has all of them it saves the hassle to pick up only the right version
Comment 15 Cole Robinson 2016-02-10 14:18:05 EST
(In reply to Michal Skrivanek from comment #14)
> 
> we have similar code for both, mkisofs for sysprep floppy, 2nd CD for VM
> payload. 
> I guess...if CD has all of them it saves the hassle to pick up only the
> right version

Oh, so you're already using a custom second CDROM?

FWIW I think boxes/libosinfo puts sysprep + first round of drivers on the generated vfd, then uses a generated iso for firstboot driver installation of drivers that aren't install time essential.
Comment 16 Michal Skrivanek 2016-02-11 06:28:44 EST
well, we do have a concept of 2 CDROMs, it is used in special cases (so the code is not exercised too often) and it was a nightmare to get it working due to plenty historical assumptions around "one cdrom is enough for everyone"

But it should be feasible today. Another reason to get rid of floppy as our delivery method for drivers and sysprep is our plan to support q35 chipset. q35 doesn't have a floppy.

Let me open a follow bug about that and keep this one for figuring out what to do in 3.6 where we have to keep using vfd
Comment 17 Cole Robinson 2016-03-11 11:56:23 EST
FYI the bug michal filed: https://bugzilla.redhat.com/show_bug.cgi?id=1306586
Comment 18 Yaniv Kaul 2016-05-31 03:38:42 EDT
This is unlikely to happen in 3.6.7, or 3.6.8.
1. We need the dep bugs (which are targeted for 7.3) to be done first. Both 3.6.7 and 3.6.8 will be released before that.
2. We need to re-think how we do the VFDs to accommodate for the space needed for the drivers.
Comment 19 Yaniv Lavi (Dary) 2016-06-02 09:22:21 EDT
(In reply to Yaniv Kaul from comment #18)
> This is unlikely to happen in 3.6.7, or 3.6.8.
> 1. We need the dep bugs (which are targeted for 7.3) to be done first. Both
> 3.6.7 and 3.6.8 will be released before that.
> 2. We need to re-think how we do the VFDs to accommodate for the space
> needed for the drivers.

I don't agree, we plan to have this happen for 7.2.z which should fix 3.6 retroactively.
Comment 20 Yaniv Kaul 2016-06-02 10:36:08 EDT
(In reply to Yaniv Dary from comment #19)
> (In reply to Yaniv Kaul from comment #18)
> > This is unlikely to happen in 3.6.7, or 3.6.8.
> > 1. We need the dep bugs (which are targeted for 7.3) to be done first. Both
> > 3.6.7 and 3.6.8 will be released before that.
> > 2. We need to re-think how we do the VFDs to accommodate for the space
> > needed for the drivers.
> 
> I don't agree, we plan to have this happen for 7.2.z which should fix 3.6
> retroactively.

Excellent, but not until it's done for 7.3 - and it has NOT been done there yet.
Comment 22 Sandro Bonazzola 2016-08-04 05:17:14 EDT
(In reply to Yaniv Dary from comment #19)

> I don't agree, we plan to have this happen for 7.2.z which should fix 3.6
> retroactively.

It won't. This bug is about requiring a newer virtio-win version at spec file level. It will require a new rhevm build in order to require it.
Comment 25 Jiri Belka 2017-01-02 04:49:54 EST
ok, rhevm-4.1.0-0.3.beta2.el7.noarch

[root@jbelka-vm4 ~]# rpm -q rhevm ; rpm -qR rhevm | grep virtio-win
rhevm-4.1.0-0.3.beta2.el7.noarch
virtio-win >= 1.8.0
[root@jbelka-vm4 ~]# rpm -q virtio-win ; rpm -ql virtio-win | grep Win10 | head
virtio-win-1.9.0-3.el7.noarch
/usr/share/virtio-win/drivers/amd64/Win10
/usr/share/virtio-win/drivers/amd64/Win10/netkvm.cat
/usr/share/virtio-win/drivers/amd64/Win10/netkvm.inf
/usr/share/virtio-win/drivers/amd64/Win10/netkvm.sys
/usr/share/virtio-win/drivers/amd64/Win10/vioscsi.cat
/usr/share/virtio-win/drivers/amd64/Win10/vioscsi.inf
/usr/share/virtio-win/drivers/amd64/Win10/vioscsi.sys
/usr/share/virtio-win/drivers/amd64/Win10/viostor.cat
/usr/share/virtio-win/drivers/amd64/Win10/viostor.inf
/usr/share/virtio-win/drivers/amd64/Win10/viostor.sys
Comment 26 Yedidyah Bar David 2017-02-06 01:46:17 EST
IIRC nothing in rhv ensures that Windows VMs are upgraded, and even if there was something, that's not the scope of current bug - it's for VFDs ("driver diskette") that you can supply during installation, not for upgrade. So perhaps:

The latest virtio-win release which includes Windows 10 drivers is now required by the Manager to ensure that suitable drivers can be supplied to VMs during installation of Windows 10.

Can be shorter a bit if you want - above also explains the "How", which might not be interesting. E.g.:

Drivers are now installed on the Manager machine to allow installation of Windows 10 on VMs.
Comment 27 Byron Gravenorst 2017-02-08 19:28:46 EST
Thanks Yedidyah,

I implemented your suggestion.

Note You need to log in before you can comment on or make changes to this bug.