Bug 1306586 - change Windows drivers and sysprep delivery method to a CDROM
change Windows drivers and sysprep delivery method to a CDROM
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt (Show other bugs)
3.6.2
Unspecified Unspecified
high Severity high (vote)
: ovirt-4.3.0
: ---
Assigned To: Michal Skrivanek
meital avital
:
Depends On: 1282348 1300959 1304973 1328275
Blocks: 1232559 1305900
  Show dependency treegraph
 
Reported: 2016-02-11 06:34 EST by Michal Skrivanek
Modified: 2018-01-12 02:35 EST (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1300959
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tjelinek: ovirt‑4.3?
michal.skrivanek: planning_ack?
michal.skrivanek: devel_ack?
michal.skrivanek: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Michal Skrivanek 2016-02-11 06:34:28 EST
we should change the drivers (and sysprep) delivery method to CDROM instead of the legacy floppy which is causing lots of other issues. We have vmpayload working via a second CDROM so it should not be a big deal...

+++ This bug was initially created as a clone of Bug #1300959 +++

[snip]

--- Additional comment from Cole Robinson on 2016-02-10 15:57:23 CET ---

(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.

--- Additional comment from Michal Skrivanek on 2016-02-10 17:58:58 CET ---

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?

--- Additional comment from Cole Robinson on 2016-02-10 18:06:47 CET ---

(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

--- Additional comment from Michal Skrivanek on 2016-02-10 18:38:14 CET ---

(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

--- Additional comment from Cole Robinson on 2016-02-10 20:18:05 CET ---

(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.

--- Additional comment from Michal Skrivanek on 2016-02-11 12:28:44 CET ---

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 1 Jiri Belka 2016-02-11 06:41:48 EST
does windows installer automatically search on 2nd cdrom for drivers (like it does in case of floppy)?
Comment 2 Yaniv Kaul 2016-02-12 14:55:38 EST
Unless there's not enough room in the floppy for all relevant drivers, I honestly don't see the use specifically for this. However, I do recall a request for multiple CD-ROMs support - something about need the OS in one, the application in another or something like that.
Worth re-reviewing the use of IDE vs. SATA or SCSI CD-ROM.
Comment 3 Shahar Havivi 2016-02-14 02:10:27 EST
This will require a user action inside a guest (we can supply it via our user guide),
When creating a sysprep windows is looking in the first floppy drive for the sysprep.inf/Unattended.xml file unless it overridden via the registry key: HKLM\System\Setup!UnattendFile
There is no issue of room since the file its a small text file.
Comment 4 Lev Veyde 2016-02-17 03:55:25 EST
(In reply to Yaniv Kaul from comment #2)
> Unless there's not enough room in the floppy for all relevant drivers, I
> honestly don't see the use specifically for this. However, I do recall a
> request for multiple CD-ROMs support - something about need the OS in one,
> the application in another or something like that.
> Worth re-reviewing the use of IDE vs. SATA or SCSI CD-ROM.

Or USB CD-ROM.
Comment 5 Yaniv Lavi 2016-02-24 02:58:43 EST
Can we emulate a USB flash drive instead of a second CD? It sound more suitable to pass payloads or the driver.
Comment 6 Michal Skrivanek 2016-02-24 03:15:52 EST
Yes we can. Though not sure we want to. Still investigating, we want to make it automatic if possible, to avoid registry modification
Comment 7 Yaniv Kaul 2016-02-24 03:43:44 EST
I still prefer having it in the floppy (drop XP and 2003) if it fits.
However, if we have other needs for an additional CD-ROM - let's have one. I think USB is a bad idea (I wish we could drop support from USB devices for server VMs - don't see why they'd need this HW and it only has bugs, inc. security bugs and performance implications - at least used to be).
Comment 8 Yaniv Lavi 2016-03-23 04:57:14 EDT
I would push this to 4.0 since VDF drivers will be added 6.8.z and 7.2.z.
Comment 14 Sandro Bonazzola 2016-05-02 06:01:50 EDT
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Comment 15 Yaniv Lavi 2016-05-23 09:17:27 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 16 Yaniv Lavi 2016-05-23 09:21:23 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 17 Michal Skrivanek 2016-05-23 09:28:06 EDT
nothing is planned in 4.0 at this point on oVirt side. Drivers supposedly fit and one can use SATA on q35 which works
Comment 18 Tomas Jelinek 2016-08-11 03:33:51 EDT
Based on comment 17 lowering priority but we would still like to see this in 4.1
Comment 19 Tomas Jelinek 2016-12-14 09:17:29 EST
will not make 4.1 due to capacity
Comment 20 Tomas Jelinek 2017-09-15 04:19:08 EDT
will not make 4.2 due to capacity

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