RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1700354 - warn if use of secboot UEFI will overwrite machine to q35
Summary: warn if use of secboot UEFI will overwrite machine to q35
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virt-manager
Version: 8.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.0
Assignee: Pavel Hrdina
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-16 11:31 UTC by Xiaodai Wang
Modified: 2020-11-14 13:47 UTC (History)
7 users (show)

Fixed In Version: virt-manager-2.2.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 21:19:40 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
virt-install log (25.53 KB, text/plain)
2019-04-16 11:32 UTC, Xiaodai Wang 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3464 0 None None None 2019-11-05 21:20:05 UTC

Description Xiaodai Wang 2019-04-16 11:31:37 UTC 
Description of problem:
machine type is different from the one which user set

Version-Release number of selected component (if applicable):
virt-install-2.0.0-5.el8.noarch

How reproducible:
100%

Steps to Reproduce:
1. Run virt-install command with '-boot uefi --machine pc-q35-rhel7.6.0'
# virt-install --name t1 --memory 1024 --disk none --machine pc-i440fx-rhel7.6.0 --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
2. Check the xml of the guest.

Actual results:
  <os>
    <type arch='x86_64' machine='pc-q35-rhel8.0.0'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/t1_VARS.fd</nvram>
    <kernel>/var/lib/libvirt/boot/virtinst-vmlinuz._1ahvt8u</kernel>
    <initrd>/var/lib/libvirt/boot/virtinst-initrd.img.tg__2ypg</initrd>
    <cmdline>inst.repo=http://download.eng.pek2.redhat.com/pub/rhel/released/RHEL-7/7.6/Server/x86_64/os/</cmdline>
    <boot dev='hd'/>
  </os>

Expected results:
os.machine should be same as the one which user set in command line.

Additional info:
Comment 1 Xiaodai Wang 2019-04-16 11:32:11 UTC 
Created attachment 1555490 [details]
virt-install log
Comment 2 Xiaodai Wang 2019-04-17 03:39:54 UTC 
Even though i wrote two --machine in the command by mistake, it didn't affect the result.
Comment 3 Pavel Hrdina 2019-05-30 17:26:39 UTC 
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.
Comment 4 Xiaodai Wang 2019-05-31 04:14:33 UTC 
(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)
Comment 5 Pavel Hrdina 2019-05-31 13:39:58 UTC 
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.
Comment 6 Cole Robinson 2019-06-16 23:30:17 UTC 
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
Comment 8 zhoujunqin 2019-07-15 08:43:35 UTC 
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.
Comment 10 errata-xmlrpc 2019-11-05 21:19:40 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.