Bug 1306586
Summary: | change Windows drivers and sysprep delivery method to a CDROM | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Michal Skrivanek <michal.skrivanek> |
Component: | BLL.Virt | Assignee: | Steven Rosenberg <srosenbe> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Beni Pelled <bpelled> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 3.6.2 | CC: | ailan, armbru, bpelled, bugs, crobinso, dfediuck, didi, eedri, emarcus, gshereme, jen, lijin, lsurette, lveyde, mgoldboi, michal.skrivanek, mkalinin, pstehlik, sbonazzo, srevivo, srosenbe, tjelinek, vrozenfe |
Target Milestone: | ovirt-4.4.0 | Keywords: | Regression |
Target Release: | --- | Flags: | pm-rhel:
ovirt-4.4?
pm-rhel: blocker? michal.skrivanek: planning_ack? pm-rhel: devel_ack+ pm-rhel: testing_ack+ |
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | rhv-4.4.0-35 | Doc Type: | Enhancement |
Doc Text: |
The floppy device has been replaced by a CDROM device for sysprep installation of Compatibility Versions 4.4 and later.
|
Story Points: | --- |
Clone Of: | 1300959 | Environment: | |
Last Closed: | 2020-08-05 06:10:01 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: | |||
Bug Blocks: | 1232559, 1305900, 1533540 | ||
Attachments: |
Description
Michal Skrivanek
2016-02-11 11:34:28 UTC
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. 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. |