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:
According to https://bugzilla.redhat.com/show_bug.cgi?id=1249873#c17 there's no vfd with virtio drivers for Windows 10.
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.
Changing the request to >= 1.7.4-1 according to https://bugzilla.redhat.com/show_bug.cgi?id=1282348#c8
Dropping dependency on bug #1167941 since nothing there prevent this BZ to be fixed. Adding dep on bug #1282348 as per comment #3
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.
So marking this as blocked by bug #1304973 since I don't have a virtio-win package to require providing what you're asking.
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.
(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, ... ?
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?
(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.
(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.
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?
(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
(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
(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.
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
FYI the bug michal filed: https://bugzilla.redhat.com/show_bug.cgi?id=1306586
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.
(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.
(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.
(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.
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
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.
Thanks Yedidyah, I implemented your suggestion.