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 1705736 - VM with smbios type=host fails at "Don't know how to build fields for SMBIOS type 2".
Summary: VM with smbios type=host fails at "Don't know how to build fields for SMBIOS ...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.9
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: rc
: 7.9
Assignee: Ademar Reis
QA Contact: leidwang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-02 20:33 UTC by Siddhant Rao
Modified: 2023-12-15 16:28 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-22 11:57:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4154791 0 None None None 2019-05-17 16:26:40 UTC

Description Siddhant Rao 2019-05-02 20:33:20 UTC 
Description of problem:
virt-install with --sysinfo mode set to Host will fail with an error "Don't know how to build fields for SMBIOS type 2"

# virt-install --connect qemu:///system --name=abcd --cdrom=/var/lib/libvirt/images/rhel-server-7.6-x86_64-dvd.iso --vcpus=4 --memory=2457 --network bridge=br0,model=virtio --os-type=linux    --noautoconsole    --graphics vnc    --events on_poweroff=preserve,on_crash=preserve --disk /root/test1.qcow2 --sysinfo host
WARNING  No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results.

Starting install...
ERROR    internal error: process exited while connecting to monitor: qemu-kvm: -smbios type=2,manufacturer=Dell Inc.,product=0HJK12,version=A03,serial=..CN779214CK00W1.,asset=Not Specified: Don't know how to build fields for SMBIOS type 2
Domain installation does not appear to have been successful.


Version-Release number of selected component (if applicable):
virt-install-1.4.3-3.el7.noarch
virt-manager-1.4.3-3.el7.noarch
qemu-kvm-1.5.3-160.el7_6.1.x86_64
libvirt-3.9.0-14.el7.x86_64
libvirt-client-3.9.0-14.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Build an OS with virt-install using the --sysinfo flag with mode as host


Actual results:
Installation will fail with an error "Don't know how to build fields for SMBIOS type 2"


Expected results:
Installation should succeed

Additional info:

-> Debug output from the virt-install

# virt-install --connect qemu:///system --name=abcd --cdrom=/var/lib/libvirt/images/rhel-server-7.6-x86_64-dvd.iso --vcpus=4 --memory=2457 --network bridge=br0,model=virtio --os-type=linux    --noautoconsole    --graphics vnc    --events on_poweroff=preserve,on_crash=preserve --disk /root/test1.qcow2 --sysinfo host --debug
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (cli:264) Launched with command line: /usr/share/virt-manager/virt-install --connect qemu:///system --name=abcd --cdrom=/var/lib/libvirt/images/rhel-server-7.6-x86_64-dvd.iso --vcpus=4 --memory=2457 --network bridge=br0,model=virtio --os-type=linux --noautoconsole --graphics vnc --events on_poweroff=preserve,on_crash=preserve --disk /root/test1.qcow2 --sysinfo host --debug
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (cli:278) Requesting libvirt URI qemu:///system
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (cli:281) Received libvirt URI qemu:///system
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (virt-install:358) Requesting virt method 'default', hv type 'default'.
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (virt-install:583) Received virt method 'kvm'
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (virt-install:584) Hypervisor name is 'hvm'
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (virt-install:270) Distilled --network options: ['bridge=br0,model=virtio']
[Fri, 03 May 2019 01:34:28 virt-install 18058] DEBUG (virt-install:183) Distilled --disk options: ['/root/test1.qcow2']
[Fri, 03 May 2019 01:34:29 virt-install 18058] DEBUG (guest:251) Setting Guest.os_variant to 'linux'
[Fri, 03 May 2019 01:34:29 virt-install 18058] WARNING (virt-install:545) No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results.
[Fri, 03 May 2019 01:34:29 virt-install 18058] DEBUG (virt-install:697) Guest.has_install_phase: True

Starting install...
[Fri, 03 May 2019 01:34:29 virt-install 18058] DEBUG (guest:384) Generated install XML: 
<domain type="kvm">
  <name>abcd</name>
  <uuid>140ebeec-008e-41a2-9ae2-fd37b283ee92</uuid>
  <memory>2515968</memory>
  <currentMemory>2515968</currentMemory>
  <vcpu>4</vcpu>
  <os>
    <type arch="x86_64">hvm</type>
    <boot dev="cdrom"/>
    <boot dev="hd"/>
    <smbios mode="host"/>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode="custom" match="exact">
    <model>IvyBridge-IBRS</model>
  </cpu>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
  </clock>
  <on_poweroff>preserve</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>preserve</on_crash>
  <pm>
    <suspend-to-mem enabled="no"/>
    <suspend-to-disk enabled="no"/>
  </pm>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>
      <source file="/root/test1.qcow2"/>
      <target dev="hda" bus="ide"/>
    </disk>
    <disk type="file" device="cdrom">
      <driver name="qemu" type="raw"/>
      <source file="/var/lib/libvirt/images/rhel-server-7.6-x86_64-dvd.iso"/>
      <target dev="hdb" bus="ide"/>
      <readonly/>
    </disk>
    <controller type="usb" index="0" model="ich9-ehci1"/>
    <controller type="usb" index="0" model="ich9-uhci1">
      <master startport="0"/>
    </controller>
    <controller type="usb" index="0" model="ich9-uhci2">
      <master startport="2"/>
    </controller>
    <controller type="usb" index="0" model="ich9-uhci3">
      <master startport="4"/>
    </controller>
    <interface type="bridge">
      <source bridge="br0"/>
      <mac address="52:54:00:03:6f:ff"/>
      <model type="virtio"/>
    </interface>
    <graphics type="vnc" port="-1"/>
    <console type="pty"/>
  </devices>
</domain>

[Fri, 03 May 2019 01:34:29 virt-install 18058] DEBUG (guest:385) Generated boot XML: 
<domain type="kvm">
  <name>abcd</name>
  <uuid>140ebeec-008e-41a2-9ae2-fd37b283ee92</uuid>
  <memory>2515968</memory>
  <currentMemory>2515968</currentMemory>
  <vcpu>4</vcpu>
  <os>
    <type arch="x86_64">hvm</type>
    <boot dev="hd"/>
    <smbios mode="host"/>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode="custom" match="exact">
    <model>IvyBridge-IBRS</model>
  </cpu>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
  </clock>
  <on_poweroff>preserve</on_poweroff>
  <on_crash>preserve</on_crash>
  <pm>
    <suspend-to-mem enabled="no"/>
    <suspend-to-disk enabled="no"/>
  </pm>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>
      <source file="/root/test1.qcow2"/>
      <target dev="hda" bus="ide"/>
    </disk>
    <disk type="file" device="cdrom">
      <target dev="hdb" bus="ide"/>
      <readonly/>
    </disk>
    <controller type="usb" index="0" model="ich9-ehci1"/>
    <controller type="usb" index="0" model="ich9-uhci1">
      <master startport="0"/>
    </controller>
    <controller type="usb" index="0" model="ich9-uhci2">
      <master startport="2"/>
    </controller>
    <controller type="usb" index="0" model="ich9-uhci3">
      <master startport="4"/>
    </controller>
    <interface type="bridge">
      <source bridge="br0"/>
      <mac address="52:54:00:03:6f:ff"/>
      <model type="virtio"/>
    </interface>
    <graphics type="vnc" port="-1"/>
    <console type="pty"/>
  </devices>
</domain>

[Fri, 03 May 2019 01:34:29 virt-install 18058] DEBUG (cli:316)   File "/usr/share/virt-manager/virt-install", line 1008, in <module>
    sys.exit(main())
  File "/usr/share/virt-manager/virt-install", line 1002, in main
    start_install(guest, options)
  File "/usr/share/virt-manager/virt-install", line 728, in start_install
    fail(e, do_exit=False)
  File "/usr/share/virt-manager/virtinst/cli.py", line 316, in fail
    logging.debug("".join(traceback.format_stack()))

[Fri, 03 May 2019 01:34:29 virt-install 18058] ERROR (cli:317) internal error: process exited while connecting to monitor: qemu-kvm: -smbios type=2,manufacturer=Dell Inc.,product=0HJK12,version=A03,serial=..CN779214CK00W1.,asset=Not Specified: Don't know how to build fields for SMBIOS type 2
[Fri, 03 May 2019 01:34:29 virt-install 18058] DEBUG (cli:319) 
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-install", line 707, in start_install
    transient=options.transient)
  File "/usr/share/virt-manager/virtinst/guest.py", line 498, in start_install
    doboot, transient)
  File "/usr/share/virt-manager/virtinst/guest.py", line 434, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3658, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: qemu-kvm: -smbios type=2,manufacturer=Dell Inc.,product=0HJK12,version=A03,serial=..CN779214CK00W1.,asset=Not Specified: Don't know how to build fields for SMBIOS type 2
[Fri, 03 May 2019 01:34:29 virt-install 18058] DEBUG (cli:330) Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///system start abcd
otherwise, please restart your installation.
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///system start abcd
otherwise, please restart your installation.



==============================


There are some other concerns

1) There is no value checking or error checking when using --sysinfo type

For example , the installation will even run with a type=thisdoesnotwork

# virt-install --connect qemu:///system --name=abcd --cdrom=/var/lib/libvirt/images/rhel-server-7.6-x86_64-dvd.iso --vcpus=4 --memory=2457 --network bridge=br0,model=virtio --os-type=linux    --noautoconsole    --graphics vnc    --events on_poweroff=preserve,on_crash=preserve --disk /root/test1.qcow2 --sysinfo type=thisdoesnotwork
WARNING  No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results.

Starting install...
Domain installation still in progress. You can reconnect to 
the console to complete the installation process.


The OS installs as well.
I can pass anything in --type and the VM install's but there is nothing passed via smbios.



2) Manual insertions works as opposed to when used with --sysinfo host

As per https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_deployment_and_administration_guide/index#sect-Operating_system_booting-BIOS_bootloader  in Table 23.2. BIOS boot loader elements

In the <smbios> field it says that when mode is set to host, it copies all of Block 0 and Block 1, except for the UUID, from the host physical machine's SMBIOS values;

As per https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-manipulating_the_domain_xml-smbios_system_information

<bios> is block 0
<system> is block 1


So technically when we set --sysinfo host , it should passthrough contents of block 0 and block 1 , which is <bios> and <system>

When we give virt-install with "--sysinfo host" it fails with the error mentioned in the title.

But when I manually enter these values in the XML of the VM , it start's and install's fine. Also dmidecode inside the VM shows the information.

~~~~

# virsh sysinfo | less

Extract the below content from it and insert it into the XML of the VM.

  <bios>
    <entry name='vendor'>Dell Inc.</entry>
    <entry name='version'>2.5.2</entry>
    <entry name='date'>01/28/2015</entry>
    <entry name='release'>2.5</entry>
  </bios>
  <system>
    <entry name='manufacturer'>Dell Inc.</entry>
    <entry name='product'>PowerEdge R720</entry>
    <entry name='version'>Not Specified</entry>
    <entry name='serial'>H5DR542</entry>
    <entry name='uuid'>4C4C4544-0035-4410-8052-C8C04F353432</entry>
    <entry name='sku'>SKU=NotProvided;ModelName=PowerEdge R720</entry>
    <entry name='family'>Not Specified</entry>
  </system>


# virsh edit abcd

Insert the code which we extracted, therefore the VM XML will look like,

  <sysinfo type='smbios'>
    <bios>
      <entry name='vendor'>Dell Inc.</entry>
      <entry name='version'>2.5.2</entry>
      <entry name='date'>01/28/2015</entry>
      <entry name='release'>2.5</entry>
    </bios>
    <system>
      <entry name='manufacturer'>Dell Inc.</entry>
      <entry name='product'>PowerEdge R720</entry>
      <entry name='version'>Not Specified</entry>
      <entry name='serial'>H5DR542</entry>
      <entry name='uuid'>7a02085a-1012-45b4-8684-057bd7714a70</entry>
      <entry name='sku'>SKU=NotProvided;ModelName=PowerEdge R720</entry>
      <entry name='family'>Not Specified</entry>
    </system>
  </sysinfo>
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
    <boot dev='hd'/>
    <smbios mode='sysinfo'/>
  </os>


-----------

After restarting the VM and starting with this XML , the installation works and the fields are correctly seen in dmidecode.


Ofcourse when I manually insert , the mode is <smbios mode="sysinfo"/> and not <smbios mode="host"/>.

If manual insertions work , then why do we fail at "--sysinfo host"?
Is it because of <smbios mode="sysinfo"/> and not <smbios mode="host"/>. ?.
Comment 2 Siddhant Rao 2019-05-02 20:43:29 UTC 
During the manual insertion , I had changed the UUID as the UUID which is passed through cannot be same.
I removed the UUID "4C4C4544-0035-4410-8052-C8C04F353432" which i had recieved from the "#virsh sysinfo" output and replaced it with "7a02085a-1012-45b4-8684-057bd7714a70"
So the UUID in [1] and [2] are the same.


[1]

<domain type='kvm'>
  <name>abcd</name>
  <uuid>7a02085a-1012-45b4-8684-057bd7714a70</uuid>
  <memory unit='KiB'>2515968</memory>
  <currentMemory unit='KiB'>2515968</currentMemory>



[2]

    <system>
      <entry name='manufacturer'>Dell Inc.</entry>
      <entry name='product'>PowerEdge R720</entry>
      <entry name='version'>Not Specified</entry>
      <entry name='serial'>H5DR542</entry>
      <entry name='uuid'>7a02085a-1012-45b4-8684-057bd7714a70</entry>
      <entry name='sku'>SKU=NotProvided;ModelName=PowerEdge R720</entry>
      <entry name='family'>Not Specified</entry>
    </system>
Comment 3 Pavel Hrdina 2019-05-07 11:51:18 UTC 
So there are two issues:

1) if --sysinfo host is used virt-install creates correct XML with <smbios mode="host"/>,
   however, if this XML element is present libvirt doesn't check if QEMU present in the
   system supports type 0, 1, 2 and 3.  That's the error message, QEMU in RHEL-7
   is old 1.5.3 and it supports only type 0 and 1 so libvirt should not requiest
   type 2 or 3 unconditionally as that will fail with old QEMU.

2) if --sysinfo type=whatever is provided to virt-install it will ignore that non-existing
   type and it will silently change it to smbios, which is wrong and we should generate
   XML containing the non-existing type and libvirt fail with some decent error.

I'll move this bug to libvirt and create a new one for virt-install.
Comment 4 Meina Li 2019-05-08 08:59:37 UTC 
Can reproduce with qemu-kvm but not qemu-kvm-rhev.

Reproduced Version:
libvirt-4.5.0-16.el7.x86_64
qemu-kvm-1.5.3-164.el7.x86_64
virt-install-1.5.0-3.el7.noarch
virt-manager-1.5.0-3.el7.noarch

Reproduced Steps:
1. Prepare a guest with the following xml:
...
 <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
    <boot dev='hd'/>
    <smbios mode='host'/>
  </os>
...
2. Start the guest.
# virsh start guest
error: Failed to start domain guest
error: internal error: process exited while connecting to monitor: qemu-kvm: -smbios type=2,manufacturer=HP,product=802E,version=KBC Version 05.22,serial=PESRKXACY8T05L: Don't know how to build fields for SMBIOS type 2

But can't reproduce it with qemu-kvm-rhev-2.12.0-27.el7.x86_64.
So this may be also a qemu-kvm issue.
Comment 5 Marina Kalinin 2019-06-24 15:30:11 UTC 
The customer has reported that the following workaround fixed the problem and the case is closed now:
~~~
We were able to verify your workaround and we can confirm, that it works for us. At the end we were able to fulfill our needs by using

--sysinfo system_manufacturer=XXX as a option to virt-install
~~~

We should consider it for RHEL8 or close the bug.
Comment 6 Siddhant Rao 2019-06-24 16:44:41 UTC 
Yes the workaround to manually insert the smbios into the XML works , However this should be working out of the Box when we use --sysinfo host

we could target this for RHEL-8 if needed.
We can reduce the severity of the Bug as well if needed.
Comment 7 Jaroslav Suchanek 2019-11-20 13:26:38 UTC 
Per comment 3 there is nothing to be fixed in rhel-8, so I am closing this. If desired it has to be reopened and moved back to rhel-7 product.
Comment 9 Juan Orti 2020-10-15 07:14:19 UTC 
Reopening this bug in RHEL 7.

The issue happens when specifying a baseboard information, which is the block 2 of SMBIOS. This is required by my customer as they run a software that queries the baseboard information, so the proposed workaround is not valid for me.

Tested on versions:
libvirt-4.5.0-36.el7_9.2.x86_64
libvirt-daemon-4.5.0-36.el7_9.2.x86_64
qemu-kvm-1.5.3-175.el7_9.1.x86_64
kernel-3.10.0-1160.2.1.el7.x86_64

Easily reproducible with this XML configuration:

~~~
<domain type='kvm'>
  <uuid>da1f922f-468e-4eba-8f7d-08fd1ae31246</uuid>
  <sysinfo type='smbios'>
    <bios>
      <entry name='vendor'>Dell Inc.</entry>
      <entry name='version'>2.8.0</entry>
      <entry name='date'>04/01/2020</entry>
      <entry name='release'>2.8</entry>
    </bios>
    <system>
      <entry name='manufacturer'>Dell Inc.</entry>
      <entry name='product'>PowerEdge R640</entry>
      <entry name='version'>Not Specified</entry>
      <entry name='serial'>5K1234</entry>
      <entry name='uuid'>da1f922f-468e-4eba-8f7d-08fd1ae31246</entry>
      <entry name='sku'>SKU=1234;ModelName=PowerEdge R640</entry>
      <entry name='family'>PowerEdge</entry>
    </system>
    <baseBoard>
      <entry name='manufacturer'>Dell Inc.</entry>
      <entry name='product'>12NR12</entry>
      <entry name='version'>A02</entry>
      <entry name='serial'>.5KT0B123.ABCDE000000001.</entry>
      <entry name='asset'>Not Specified</entry>
    </baseBoard>
  </sysinfo>
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
    <boot dev='hd'/>
    <smbios mode='sysinfo'/>
  </os>
~~~

libvirt log:

2020-10-15 06:58:54.466+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.2 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2020-07-22-09:25:36, x86-vm-25.build.eng.bos.redhat.com), qemu version: 1.5.3 (qemu-kvm-1.5.3-175.el7_9.1), kernel: 3.10.0-1160.2.1.el7.x86_64, hostname: rhel7.laptop.lab
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
QEMU_AUDIO_DRV=spice \
/usr/libexec/qemu-kvm \
-name win2k19 \
-S \
-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \
-cpu Broadwell-IBRS,+ibpb,+md-clear,+spec-ctrl,+ssbd,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff \
-m 2048 \
-realtime mlock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid da1f922f-468e-4eba-8f7d-08fd1ae31246 \
-smbios 'type=0,vendor=Dell Inc.,version=2.8.0,date=04/01/2020,release=2.8' \
-smbios 'type=1,manufacturer=Dell Inc.,product=PowerEdge R640,version=Not Specified,serial=5K1234,uuid=da1f922f-468e-4eba-8f7d-08fd1ae31246,sku=SKU=1234;ModelName=PowerEdge R640,family=PowerEdge' \
-smbios 'type=2,manufacturer=Dell Inc.,product=12NR12,version=A02,serial=.5KT0B123.ABCDE000000001.,asset=Not Specified' \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win2k19/monitor.sock,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=localtime,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global PIIX4_PM.disable_s3=1 \
-global PIIX4_PM.disable_s4=1 \
-boot strict=on \
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 \
-drive file=/var/lib/libvirt/images/win2k19.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 \
-device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 \
-netdev tap,fd=26,id=hostnet0 \
-device e1000,netdev=hostnet0,id=net0,mac=52:54:00:be:01:16,bus=pci.0,addr=0x3 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev spicevmc,id=charchannel0,name=vdagent \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on \
-vga qxl \
-global qxl-vga.ram_size=67108864 \
-global qxl-vga.vram_size=67108864 \
-global qxl-vga.vgamem_mb=16 \
-global qxl-vga.max_outputs=1 \
-device intel-hda,id=sound0,bus=pci.0,addr=0x4 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-msg timestamp=on
qemu-kvm: -smbios type=2,manufacturer=Dell Inc.,product=12NR12,version=A02,serial=.5KT0B123.ABCDE000000001.,asset=Not Specified: Don't know how to build fields for SMBIOS type 2
2020-10-15 06:58:54.651+0000: shutting down, reason=failed
Comment 11 Pavel Hrdina 2020-10-15 08:42:04 UTC 
Hi, if the customer needs to specify baseboard information the only missing part to make it work is QEMU 1.5.3 not supporting SMBIOS type 2.

Moving to QEMU as the support for SMBIOS type 2 was added in qemu-2.1.0 and there is nothing else to do in libvirt.
Comment 15 leidwang@redhat.com 2020-10-22 02:04:09 UTC 
Reproduce this bz on RHEL-7.9 and RHEL8.3.Not hit it on RHEL8.3 host,
only hit it on RHEL7.9 host.

1. RHEL7.9
host env:

kernel-3.10.0-1160.2.1.el7.x86_64
qemu-kvm-1.5.3-175.el7_9.1.x86_64
seabios-bin-1.11.0-2.el7.noarch

qemu command:

/usr/libexec/qemu-kvm \
-enable-kvm \
-nodefaults \
-machine pc,accel=kvm,usb=off,dump-guest-core=off \
-m 4G \
-smp 2 \
-cpu host \
-enable-kvm \
-smbios 'type=0,vendor=Dell Inc.,version=2.8.0,date=04/01/2020,release=2.8' \
-smbios 'type=1,manufacturer=Dell Inc.,product=PowerEdge R640,version=Not Specified,serial=5K1234,uuid=da1f922f-468e-4eba-8f7d-08fd1ae31246,sku=SKU=1234;ModelName=PowerEdge R640,family=PowerEdge' \
-smbios 'type=2,manufacturer=Dell Inc.,product=12NR12,version=A02,serial=.5KT0B123.ABCDE000000001.,asset=Not Specified' \
-device virtio-scsi-pci,id=scsi0,bus=pci.0 \
-drive file=rhel830-64-virtio-scsi.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,media=disk,cache=none,werror=stop,rerror=stop \
-device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
-netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,queues=4 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:dd:90:e9,bus=pci.0,vectors=10 \
-vnc :9 \
-device VGA \
-monitor stdio \
-qmp tcp:127.0.0.1:4444,server,nowait \

test result:
[root@hp-dl385pg8-04 home]# sh smbios.sh 
qemu-kvm: -smbios type=2,manufacturer=Dell Inc.,product=12NR12,version=A02,serial=.5KT0B123.ABCDE000000001.,asset=Not Specified: Don't know how to build fields for SMBIOS type 2

Additional info:
Test it with qemu-kvm-rhev-2.12.0-48.el7_9.1.x86_64,it works well,the smbios info is the same as we define in qemu command.

2.RHEL8.3

host env:
kernel-4.18.0-240.el8.x86_64
qemu-kvm-5.1.0-13.module+el8.3.0+8382+afc3bbea.x86_64
seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64

qemu command:

/usr/libexec/qemu-kvm \
-enable-kvm \
-nodefaults \
-machine pc,accel=kvm,usb=off,dump-guest-core=off \
-m 4G \
-smp 2 \
-cpu host \
-enable-kvm \
-smbios 'type=0,vendor=Dell Inc.,version=2.8.0,date=04/01/2020,release=2.8' \
-smbios 'type=1,manufacturer=Dell Inc.,product=PowerEdge R640,version=Not Specified,serial=5K1234,uuid=da1f922f-468e-4eba-8f7d-08fd1ae31246,sku=SKU=1234;ModelName=PowerEdge R640,family=PowerEdge' \
-smbios 'type=2,manufacturer=Dell Inc.,product=12NR12,version=A02,serial=.5KT0B123.ABCDE000000001.,asset=Not Specified' \
-device virtio-scsi-pci,id=scsi0,bus=pci.0 \
-drive file=rhel830-64-virtio-scsi.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,media=disk,cache=none,werror=stop,rerror=stop \
-device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
-netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,queues=4 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:dd:90:e9,bus=pci.0,vectors=10 \
-vnc :9 \
-device VGA \
-monitor stdio \
-qmp tcp:127.0.0.1:4444,server,nowait \

test result.
Guest boot succussfuly,and smbios info is the same as we define in qemu command.
Comment 16 Ademar Reis 2020-10-22 11:57:20 UTC 
(In reply to Pavel Hrdina from comment #14)
> (In reply to Ademar Reis from comment #13)
> > (In reply to Pavel Hrdina from comment #11)
> > > Hi, if the customer needs to specify baseboard information the only missing
> > > part to make it work is QEMU 1.5.3 not supporting SMBIOS type 2.
> > > 
> > > Moving to QEMU as the support for SMBIOS type 2 was added in qemu-2.1.0 and
> > > there is nothing else to do in libvirt.
> > 
> > Pavel: can you please give me some pointer to where I can find more about
> > support for SMBIOS type=2 support introduced in QEMU-2.1.0? I couldn't find
> > anything in the release changelogs or anything explicit in git log.
> 
> It was introduced by this patch series [1] and the respective commits are:
> 
> c97294ec1b SMBIOS: Build aggregate smbios tables and entry point
> 2e6e8d7a25 SMBIOS: Use bitmaps to prevent incompatible comand line options
> cb36acb672 SMBIOS: Use macro to set smbios defaults
> e41fca3da7 SMBIOS: Update header file definitions
> e6667f719c SMBIOS: Rename symbols to better reflect future use
> 7bf8ef196e E820: Add interface for accessing e820 table
> 
> [1] <https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg03543.html>


Thanks Pavel.

This confirms that we can't support this in RHEL-7 (EUS already). Customers have to upgrade to RHEL-8 where this feature is present.
Note You need to log in before you can comment on or make changes to this bug.