Bug 1700354
| Summary: | warn if use of secboot UEFI will overwrite machine to q35 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Xiaodai Wang <xiaodwan> | ||||
| Component: | virt-manager | Assignee: | Pavel Hrdina <phrdina> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 8.1 | CC: | crobinso, juzhou, mxie, mzhan, phrdina, tzheng, zili | ||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||
| Target Release: | 8.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | virt-manager-2.2.0-1.el8 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-11-05 21:19:40 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Xiaodai Wang
2019-04-16 11:31:37 UTC
Created attachment 1555490 [details]
virt-install log
Even though i wrote two --machine in the command by mistake, it didn't affect the result. Hi, I was not able to reproduce it on RHEL-8, can you please verify it again? I have the same version of virt-install and it correctly used the second --machine option. (In reply to Pavel Hrdina from comment #3) > Hi, I was not able to reproduce it on RHEL-8, can you please verify it again? > > I have the same version of virt-install and it correctly used the second > --machine option. I think you need a host supported '<machine maxCpus='384'>pc-q35-rhel8.0.0</machine>' and set uefi in command line. As you can see, i passed 'pc-q35-rhel7.6.0', but in set_uefi_path, the value was modified to 'q35' and then passed to libvirt, so libvirt will return the final value depends on it's implementation. (Pdb) b /usr/share/virt-manager/virtinst/guest.py:351 Breakpoint 5 at /usr/share/virt-manager/virtinst/guest.py:351 (Pdb) c [Fri, 31 May 2019 00:10:02 virt-install 24152] DEBUG (cli:200) Launched with command line: /usr/share/virt-manager/virt-install --name t1 --memory 1024 --disk none --debug --os-variant rhel7.6 -l http://download.eng.pek2.redhat.com/pub/rhel/released/RHEL-7/7.6/Server/x86_64/os/ --debug --boot uefi --machine pc-q35-rhel7.6.0 [Fri, 31 May 2019 00:10:02 virt-install 24152] DEBUG (virt-install:243) Distilled --network options: ['default'] [Fri, 31 May 2019 00:10:02 virt-install 24152] DEBUG (virt-install:159) Distilled --disk options: ['none'] [Fri, 31 May 2019 00:10:02 virt-install 24152] DEBUG (cli:214) Requesting libvirt URI default [Fri, 31 May 2019 00:10:02 virt-install 24152] DEBUG (cli:217) Received libvirt URI qemu:///system > /usr/share/virt-manager/virt-install(510)build_guest_instance() -> guest = virtinst.Guest(conn) (Pdb) c > /usr/share/virt-manager/virtinst/guest.py(351)set_uefi_path() -> self.os.loader_ro = True (Pdb) l 346 def set_uefi_path(self, path): 347 """ 348 Configure UEFI for the VM, but only if libvirt is advertising 349 a known UEFI binary path. 350 """ 351 B-> self.os.loader_ro = True 352 self.os.loader_type = "pflash" 353 self.os.loader = path 354 355 # If the firmware name contains "secboot" it is probably build 356 # with SMM feature required so we need to enable that feature, (Pdb) 357 # otherwise the firmware may fail to load. True secure boot is 358 # currently supported only on x86 architecture and with q35 with 359 # SMM feature enabled so change the machine to q35 as well. 360 # To actually enforce the secure boot for the guest if Secure Boot 361 # Mode is configured we need to enable loader secure feature. 362 if (self.os.is_x86() and 363 "secboot" in self.os.loader): 364 self.features.smm = True 365 self.os.loader_secure = True 366 self.os.machine = "q35" 367 (Pdb) self.os.machine 'pc-q35-rhel7.6.0' (Pdb) n > /usr/share/virt-manager/virtinst/guest.py(352)set_uefi_path() -> self.os.loader_type = "pflash" (Pdb) > /usr/share/virt-manager/virtinst/guest.py(353)set_uefi_path() -> self.os.loader = path (Pdb) > /usr/share/virt-manager/virtinst/guest.py(362)set_uefi_path() -> if (self.os.is_x86() and (Pdb) > /usr/share/virt-manager/virtinst/guest.py(363)set_uefi_path() -> "secboot" in self.os.loader): (Pdb) > /usr/share/virt-manager/virtinst/guest.py(364)set_uefi_path() -> self.features.smm = True (Pdb) > /usr/share/virt-manager/virtinst/guest.py(365)set_uefi_path() -> self.os.loader_secure = True (Pdb) > /usr/share/virt-manager/virtinst/guest.py(366)set_uefi_path() -> self.os.machine = "q35" (Pdb) > /usr/share/virt-manager/virtinst/guest.py(369)set_uefi_path() -> if self.osinfo.broken_uefi_with_hyperv(): (Pdb) self.os.machine 'q35' (Pdb) bt /usr/lib64/python3.6/bdb.py(434)run() -> exec(cmd, globals, locals) <string>(1)<module>() /usr/share/virt-manager/virt-install(955)<module>() -> sys.exit(main()) /usr/share/virt-manager/virt-install(943)main() -> guest, installer = build_guest_instance(conn, options) /usr/share/virt-manager/virt-install(527)build_guest_instance() -> cli.parse_option_strings(options, guest, None) /usr/share/virt-manager/virtinst/cli.py(2813)parse_option_strings() -> parseret = parserobj.parse(inst, validate=not update) /usr/share/virt-manager/virtinst/cli.py(1181)parse() -> objs = self._parse(inst or self.guest) /usr/share/virt-manager/virtinst/cli.py(1641)_parse() -> VirtCLIParser._parse(self, inst) /usr/share/virt-manager/virtinst/cli.py(1151)_parse() -> param.parse_param(self, inst, self.support_cb) /usr/share/virt-manager/virtinst/cli.py(866)parse_param() -> self._virtarg.cb(parser, inst, self.val, self) /usr/share/virt-manager/virtinst/cli.py(1606)set_uefi_cb() -> self.guest.set_uefi_path(self.guest.get_uefi_path()) > /usr/share/virt-manager/virtinst/guest.py(369)set_uefi_path() -> if self.osinfo.broken_uefi_with_hyperv(): (Pdb) Interesting that it did not happen to me as I've tried it on RHEL-8. It should not depend on whether some specific machine type is available. Anyway, this is a bug and we should set the q35 only in case no machine type was set by user. It's a little difficult to change this code path to not overwrite the machine type if the user specified one, especially counting the user choosing secboot firmware in the virt-manager UI. I tweaked the logic a bit to not overwrite the machine type unless it doesn't contain 'q35', and to print a warning message when we do overwrite it. I think that's sufficient in the absense of any user complaint
commit 3586d189718a33fcb432109766170f047c7304da
Author: Cole Robinson <crobinso>
Date: Sun Jun 16 18:29:33 2019 -0400
guest: Warn before setting machine=q35 for secboot
I can reproduce this issue with package: virt-manager-2.0.0-5.el8.noarch virt-install-2.0.0-5.el8.noarch Then try to verify this bug with new build: virt-manager-2.2.1-1.el8.noarch virt-install-2.2.1-1.el8.noarch libvirt-4.5.0-24.module+el8.1.0+3205+41ff0a42.x86_64 qemu-kvm-2.12.0-77.module+el8.1.0+3382+49219945.x86_64 python3-libvirt-4.5.0-1.module+el8+2529+a9686a4d.x86_64 Steps: 1. Install a UEFI vm which original machine type is not q35 type. # virt-install --name t1 --memory 1024 --disk none --machine pc-i440fx-rhel7.6.0 --os-variant rhel7.6 -l http://download.eng.pek2.redhat.com/pub/rhel/released/RHEL-7/7.6/Server/x86_64/os/ --boot uefi WARNING Changing machine type from 'pc-i440fx-rhel7.6.0' to 'q35' which is required for UEFI secure boot. ... Result: Warning message is correct when machine type is changed for secure boot, 2. Install a UEFI vm which original machine type is q35 type. # virt-install --name t1 --memory 1024 --disk none --machine pc-q35-rhel7.6.0 --os-variant rhel7.6 -l http://download.eng.pek2.redhat.com/pub/rhel/released/RHEL-7/7.6/Server/x86_64/os/ --boot uefi Starting install... Retrieving file vmlinuz... | 6.3 MB 00:00:00 Retrieving file initrd.img... Result: There is no warning since original machine type is q35 type. So I move this bug from ON_QA to VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:3464 |