We would like to enable Windows Update for the virtio-win drivers on Win10 VMs. The Windows Update service is based on HW-IDs which are based on sub-sets of SMBIOS strings to build an ID that can identify specific HW (or Virt HW) types. Based on a discussion we had, we have decided to use HardwareID-6 which uses SMBIOS System (Type 1) and Base Board (Type 2) tables, and matches on the following strings: System Manufacturer = Red Hat System SKU Number = (e.g. 8.2.0) Baseboard Manufacturer = Red Hat Baseboard Product = RHEL-AV HardwareID-6 was chosen so that we can have defaults in qemu for Windows Update enablement, that don't clash with fields currently used by layered products for their own identifying information. This BZ is for qemu in RHEL-AV to set these strings in its defaults. Layered products are expected to use the following strings on top (without touching the strings mentioned above, which will be set by qemu) System Product = (e.g. Red Hat Open Stack Platform) System Version = (e.g. 15.0) The SKU Number will be updated on each RHEL-AV release which has a new virtio-win version. Generally, this is expected to be on each minor release and each app-stream release version, e.g. 8.2.0, 8.2.1, 8.3.0, 8.3.1 etc.
Some clarifications for the bug description. With the old SMBIOS scheme, QEMU would report: System Manufacturer: Red Hat System Product Name: KVM System Version: RHEL-8.1.0 PC (Q35 + ICH9, 2009) System Family: Red Hat Enterprise Linux It would also report the Manufactor/Version in several other tables, but they're not changing in this bug, so I'll ignore mostly them. With the new SMBIOS scheme, QEMU needs to report: System Manufacturer = Red Hat System SKU Number = (e.g. 8.2.0) Baseboard Manufacturer = Red Hat Baseboard Product = RHEL-AV The new SMBIOS information from the bug description will only be set for machine types with 8.2.0 version or newer. The old SMBIOS information that QEMU reported in older RHEL version will still be reported, EXCEPT, where it conflicts with the new required information. Layered products must *NEVER* override the 4 fields used by the new SMBIOS scheme. Aside from that, they are free to override any of the other fields in SMBIOS, even those used by the old SMBIOS scheme. All pre-existing machine types will be unchanged. IOW, pc-q35-rhel-8.0.0, pc-q35-rhel-8.1.0 and pc-i440fx-rhel-* machine types will report the *old* style information only. Note that since we do *NOT* add new machine types for minor updates, there will *NEVER* be a "System SKU Number = 8.2.1" - it will only ever be .0 for the last digital 8.2.0, 8.3.0, 8.4.0, etc For testing, with the pc-q35-rhel8.2.0 machine type, dmidecode should report: $ dmidecode -t 1 # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Red Hat Product Name: KVM Version: RHEL-8.2.0 PC (Q35 + ICH9, 2009) Serial Number: Not Specified UUID: b669dec8-ea4f-4ee5-9d45-26c03fe4b71b Wake-up Type: Power Switch SKU Number: 8.2.0 Family: Red Hat Enterprise Linux $ dmidecode -t 2 # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x0200, DMI type 2, 15 bytes Base Board Information Manufacturer: Red Hat Product Name: RHEL-AV Version: RHEL-8.2.0 PC (Q35 + ICH9, 2009) Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0300 Type: Motherboard Contained Object Handles: 0 For testing, with the pc-q35-rhel8.1.0 machine type, dmidecode should report: $ dmidecode -t 1 # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Red Hat Product Name: KVM Version: RHEL-8.1.0 PC (Q35 + ICH9, 2009) Serial Number: Not Specified UUID: b669dec8-ea4f-4ee5-9d45-26c03fe4b71b Wake-up Type: Power Switch SKU Number: Not Specified Family: Red Hat Enterprise Linux $ dmidecode -t 2 # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. This example with pc-q35-rhel-8.1.0 should be *identical* to what qemu-kvm-4.1.0-23.el8 currently reports. All other SMBIOS data tables should be unchanged from what was previously reported.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Test win10-64 with qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64 1. with both pc and q35: pc RHEL 7.6.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.6.0) q35 RHEL-8.2.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel8.2.0) SMBIOS System (Type 1) and Base Board (Type 2) info are: System Name DESKTOP-MF382J5 System Manufacturer Red Hat System Model KVM System Type x64-based PC System SKU Processor AMD EPYC Processor, 2196 Mhz, 4 Core(s), 4 Logical Processor(s) BIOS Version/Date SeaBIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab, 4/1/2014 SMBIOS Version 2.8 Embedded Controller Version 255.255 BIOS Mode Legacy Test with qemu-kvm-4.2.0-14.module+el8.2.0+5995+d02a4eeb.x86_64 1. with pc RHEL 7.6.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.6.0) SMBIOS System (Type 1) and Base Board (Type 2) info are: System Name DESKTOP-MF382J5 System Manufacturer Red Hat System Model KVM System Type x64-based PC System SKU Processor AMD EPYC Processor, 2196 Mhz, 4 Core(s), 4 Logical Processor(s) BIOS Version/Date SeaBIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab, 4/1/2014 SMBIOS Version 2.8 Embedded Controller Version 255.255 BIOS Mode Legacy 2. with q35 RHEL-8.2.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel8.2.0) SMBIOS System (Type 1) and Base Board (Type 2) info are: System Name DESKTOP-MF382J5 System Manufacturer Red Hat System Model KVM System Type x64-based PC System SKU 8.2.0 Processor AMD EPYC Processor, 2196 Mhz, 16 Core(s), 16 Logical Processor(s) Processor AMD EPYC Processor, 2196 Mhz, 16 Core(s), 16 Logical Processor(s) BIOS Version/Date SeaBIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab, 4/1/2014 SMBIOS Version 2.8 Embedded Controller Version 255.255 BIOS Mode Legacy BaseBoard Manufacturer Red Hat BaseBoard Product RHEL-AV BaseBoard Version RHEL-8.2.0 PC (Q35 + ICH9, 2009) Conclusion: With fixed qemu and q35 machine type, we can get the expected info in guests. So change status to verified. qemu cli I use: /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox on \ -machine q35 \ -device pcie-root-port,id=pcie-root-port-0,multifunction=on,bus=pcie.0,addr=0x1,chassis=1 \ -device pcie-pci-bridge,id=pcie-pci-bridge-0,addr=0x0,bus=pcie-root-port-0 \ -nodefaults \ -device VGA,bus=pcie.0,addr=0x2 \ -m 30720 \ -smp 32,maxcpus=32,cores=16,threads=1,dies=1,sockets=2 \ -cpu 'EPYC',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv-tlbflush,+kvm_pv_unhalt \ -device pvpanic,ioport=0x505,id=idjzeh0O \ -device pcie-root-port,id=pcie-root-port-1,port=0x1,addr=0x1.0x1,bus=pcie.0,chassis=2 \ -device qemu-xhci,id=usb1,bus=pcie-root-port-1,addr=0x0 \ -device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie-root-port-2,addr=0x0 \ -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/win10-64-virtio-scsi.qcow2 \ -device scsi-hd,id=image1,drive=drive_image1 \ -device pcie-root-port,id=pcie-root-port-3,port=0x3,addr=0x1.0x3,bus=pcie.0,chassis=4 \ -device virtio-net-pci,mac=9a:0b:36:ce:6c:df,id=id7bpY6c,netdev=idvlBo10,bus=pcie-root-port-3,addr=0x0 \ -netdev tap,id=idvlBo10,vhost=on,script=/etc/qemu-ifup \ -drive id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/windows/winutils.iso \ -device scsi-cd,id=cd1,drive=drive_cd1 \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -vnc :0 \ -monitor stdio \ -rtc base=localtime,clock=host,driftfix=slew \ -boot menu=off,order=cdn,once=c,strict=off \ -enable-kvm \ -device pcie-root-port,id=pcie_extra_root_port_0,multifunction=on,bus=pcie.0,addr=0x3,chassis=5
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/RHBA-2020:2017