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
does windows installer automatically search on 2nd cdrom for drivers (like it does in case of floppy)?
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.
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.
(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.
Can we emulate a USB flash drive instead of a second CD? It sound more suitable to pass payloads or the driver.
Yes we can. Though not sure we want to. Still investigating, we want to make it automatic if possible, to avoid registry modification
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).
I would push this to 4.0 since VDF drivers will be added 6.8.z and 7.2.z.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
oVirt 4.0 beta has been released, moving to RC milestone.
nothing is planned in 4.0 at this point on oVirt side. Drivers supposedly fit and one can use SATA on q35 which works
Based on comment 17 lowering priority but we would still like to see this in 4.1
will not make 4.1 due to capacity
will not make 4.2 due to capacity
I recently tried to install Windows in a new VM. I couldn't figure out how to use the floppy or the ISO. Old and new documentation was pointing me in different directions. Which leads me to the question, can this be automagic? Why does the user need to bother with all the intermediate steps to load the drivers? We know we want them to use the virtio driver for the hard drive. It should be as easy as possible / just show up as an option.
(In reply to Greg Sheremeta from comment #22) > I recently tried to install Windows in a new VM. I couldn't figure out how > to use the floppy or the ISO. Old and new documentation was pointing me in > different directions. > > Which leads me to the question, can this be automagic? > > Why does the user need to bother with all the intermediate steps to load the > drivers? We know we want them to use the virtio driver for the hard drive. > It should be as easy as possible / just show up as an option. There's a bug tracking changing the directory structure which will help windows automatically find the drivers, at least partly https://bugzilla.redhat.com/show_bug.cgi?id=1223668
Please be aware that virtio-win package has dropped floppy files from rhel8.0 according to bz1533540
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
Created attachment 1611519 [details] Changes for sysprep
Created attachment 1612313 [details] Current changes for Run Once with the Additional CD
Created attachment 1613185 [details] Current changes for Run Once Referencing only sysprep
Created attachment 1613187 [details] Current changes for Run Once Referencing only sysprep
Note: Windows setup for installations requires the unattended file to be called Autounattend.xml for Windows Vista and later. For sealing the OS, the sysprep tool may still require the unattend file to be called Unattend.xml for auto-detection, although the tool does support the "/unattend:<file_name>" command line option. Therefore validation and documentation should reflect these issues accordingly.
I wish I can tag this bug with "need knowledge transfer". Maybe I can - by adding a keyword.
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Update: The problem seems to be somewhere around renaming the Sysprep file from Unattend.xml to Autounattend.xml, Sysprep works when the filename is called Unattend.xml and doesn't work when the filename is Autounattend.xml - checked by the following steps: 1. Add the following line to the /etc/ovirt-engine/osinfo.conf.d/00-defaults.properties (and restart ovirt-engine) os.windows_2012R2x64.sysprepFileName.value = Unattend.xml 2. Start a 'Windows 2012R2 X64' VM' (make sure the OS type is 'Windows 2012R2 X64') 3. On the VM, set the TZ to UTC London and run 'C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown' 4. At this point, a sealing process is running - wait for the process to finish and the VM to shut down. 5. Re-run the VM as run-once and under 'Initial Run > Use Sysprep' set VM Hostname=WinTestSysprep and Time Zone=+2 Israel Result: - Hostname and TZ settings are injected as expected (WinTestSysprep, +2 Israel) - Sysprep file is called Unattend.xml (under the CDROM drive) The same flow without adding the sysprepFileName.value to the 00-defaults.properties cause the filename to be Autounattend.xml (as expected) and the settings are not injected. In summary, the transition from Floppy to CDROM does work but right now it's with WA - this issue can be tracked here or in a new bug.
(In reply to Beni Pelled from comment #43) > Update: > The problem seems to be somewhere around renaming the Sysprep file from > Unattend.xml to Autounattend.xml, > Sysprep works when the filename is called Unattend.xml and doesn't work when > the filename is Autounattend.xml - checked by the following steps: > > 1. Add the following line to the > /etc/ovirt-engine/osinfo.conf.d/00-defaults.properties (and restart > ovirt-engine) > os.windows_2012R2x64.sysprepFileName.value = Unattend.xml > 2. Start a 'Windows 2012R2 X64' VM' (make sure the OS type is 'Windows > 2012R2 X64') > 3. On the VM, set the TZ to UTC London and run > 'C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown' > 4. At this point, a sealing process is running - wait for the process to > finish and the VM to shut down. > 5. Re-run the VM as run-once and under 'Initial Run > Use Sysprep' set VM > Hostname=WinTestSysprep and Time Zone=+2 Israel > > Result: > - Hostname and TZ settings are injected as expected (WinTestSysprep, +2 > Israel) > - Sysprep file is called Unattend.xml (under the CDROM drive) > > The same flow without adding the sysprepFileName.value to the > 00-defaults.properties cause the > filename to be Autounattend.xml (as expected) and the settings are not > injected. > > In summary, the transition from Floppy to CDROM does work but right now it's > with WA > - this issue can be tracked here or in a new bug. OK, but we were supposed to try it with the audit command [1] when we have the Autounattend.xml. Maybe we can try that. [1] C:\Windows\System32\Sysprep\sysprep.exe /audit /reboot /unattend:D:\Autounattend.xml
We really need it to work automatically the same way it did in 4.3 rather than asking administrators to sysprep in a specific way. No need to check the audit command
Verified with: - ovirt-engine-4.4.1.1-0.5.el8ev.noarch - libvirt-6.0.0-17.module+el8.2.0+6257+0d066c28.x86_64 - vdsm-4.40.18-1.el8ev.x86_64 Verification steps: 2. Start a 'Windows 2012R2 X64' VM' 3. On the VM, set the TZ to UTC London and run 'C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown' (At this point, a sealing process is running - wait for the process to finish and the VM to shutdown) 4. Re-run the VM as run-once and under 'Initial Run > Use Sysprep' set VM Hostname=WinSysprep and Time Zone=+2 Israel Result: - VM is up and running with HOSTNAME=WinSysprep and TZ=Israel
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.