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 593317 - seabios: SMBIOS data is different from that shown in RHEL5, even with -M rhel5.4.0
Summary: seabios: SMBIOS data is different from that shown in RHEL5, even with -M rhel...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: seabios
Version: 6.0
Hardware: All
OS: Linux
urgent
medium
Target Milestone: beta
: ---
Assignee: Eduardo Habkost
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 605522 (view as bug list)
Depends On:
Blocks: 582655 605522 605704 612851
TreeView+ depends on / blocked
 
Reported: 2010-05-18 14:03 UTC by Daniel Berrangé
Modified: 2013-01-08 12:34 UTC (History)
14 users (show)

Fixed In Version: seabios-0.5.1-0.10.20100108git669c991.1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 605704 612851 (view as bug list)
Environment:
Last Closed: 2010-08-02 20:52:04 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
SMBIOS dump from RHEL5 host (2.85 KB, text/plain)
2010-05-18 14:03 UTC, Daniel Berrangé
no flags Details
SMBIOS dump from RHEL6 host (2.84 KB, text/plain)
2010-05-18 14:03 UTC, Daniel Berrangé
no flags Details
RHEL-5.5 guest, dmidecode output (2.49 KB, text/plain)
2010-06-22 11:46 UTC, Milan Zázrivec
no flags Details
dmidecode on rhel5, rhel6 guests after seabios upgrade (5.26 KB, text/plain)
2010-06-22 14:09 UTC, Jiri Kastner
no flags Details
dmidecode output (9.43 KB, image/png)
2010-07-23 21:42 UTC, Subhendu Ghosh
no flags Details

Description Daniel Berrangé 2010-05-18 14:03:03 UTC
Description of problem:
I moved a guest from a RHEL5 host to a RHEL6 host using identical libvirt configuration, in order to check for any guest visible hardware differences.

I noticed that the SMBIOS data on RHEL6 is significantly different, refering to 'Bochs' in many places instead of 'QEMU'. It is also missing the Red Hat manufacturer info and has a different naming scheme for CPUs.

It is unclear if these differences would negatively impact a guest, but the data from RHEL5 QEMU looks a lot better so should probably be fixed in RHEL6 regardless.

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.50 (on RHEL6 host)
kvm-83-164.el5 (on RHEL5 host)

How reproducible:
Always

Steps to Reproduce:
1. Configure a guest on RHEL5, making sure it has a 'rhel-5.4.0' machine type (or similar stable machine type)
2. Copy the guest unchanged to a RHEL6 machine
3. Run 'dmidecode' in both guests, and then compare using diff
  
Actual results:
--- qemu-rhel5.txt      2010-05-18 14:57:22.356761971 +0100
+++ qemu-rhel6.txt      2010-05-18 14:57:27.671884237 +0100
@@ -1,12 +1,12 @@
 # dmidecode 2.9
 SMBIOS 2.4 present.
-11 structures occupying 331 bytes.
-Table at 0x000FBDAF.
+11 structures occupying 308 bytes.
+Table at 0x198FFEC0.
 
 Handle 0x0000, DMI type 0, 24 bytes
 BIOS Information
-       Vendor: QEMU
-       Version: QEMU
+       Vendor: Bochs
+       Version: Bochs
        Release Date: 01/01/2007
        Address: 0xE8000
        Runtime Size: 96 kB
@@ -18,18 +18,18 @@
 
 Handle 0x0100, DMI type 1, 27 bytes
 System Information
-       Manufacturer: Red Hat
-       Product Name: KVM
+       Manufacturer: Bochs
+       Product Name: Bochs
        Version: Not Specified
        Serial Number: Not Specified
        UUID: A29D663E-3083-1096-B8BA-A11C081E77E0
        Wake-up Type: Power Switch
        SKU Number: Not Specified
-       Family: Red Hat Enterprise Linux
+       Family: Not Specified
 
 Handle 0x0300, DMI type 3, 20 bytes
 Chassis Information
-       Manufacturer: RED HAT
+       Manufacturer: Bochs
        Type: Other
        Lock: Not Present
        Version: Not Specified
@@ -43,11 +43,11 @@
 
 Handle 0x0401, DMI type 4, 32 bytes
 Processor Information
-       Socket Designation: CPU 1
+       Socket Designation: CPU01
        Type: Central Processor
        Family: Other
-       Manufacturer: QEMU
-       ID: 63 06 00 00 FD FB 8B 07
+       Manufacturer: Bochs
+       ID: 23 06 00 00 FD FB 8B 07
        Version: Not Specified
        Voltage: Unknown
        External Clock: Unknown
@@ -61,11 +61,11 @@
 
 Handle 0x0402, DMI type 4, 32 bytes
 Processor Information
-       Socket Designation: CPU 2
+       Socket Designation: CPU02
        Type: Central Processor
        Family: Other
-       Manufacturer: QEMU
-       ID: 63 06 00 00 FD FB 8B 07
+       Manufacturer: Bochs
+       ID: 23 06 00 00 FD FB 8B 07
        Version: Not Specified
        Voltage: Unknown
        External Clock: Unknown


Expected results:
No differences

Additional info:

Comment 1 Daniel Berrangé 2010-05-18 14:03:37 UTC
Created attachment 414862 [details]
SMBIOS dump from RHEL5 host

Comment 2 Daniel Berrangé 2010-05-18 14:03:57 UTC
Created attachment 414863 [details]
SMBIOS dump from RHEL6 host

Comment 8 Jes Sorensen 2010-05-31 12:56:00 UTC
Ok so doing a bit more research on this, it looks like at least half the differences are because libvirt doesn't specify the correct options on the command line.

It is likely that these strings may change again in the future, so relying builtin default values just isn't going to cut it. For example after I brought up the issue on the SeaBIOS list, it was suggested to change some of the strings that currently say Bochs to say SeaBIOS.

Adding the following to the QEMU command line eliminates most of the differences:

-smbios type=1,manufacturer="Red Hat" -smbios type=1,product="KVM" -smbios type=1,family="Red Hat Enterprise Linux" -smbios type=0,vendor=QEMU -smbios type=0,version=QEMU

Comment 9 Jes Sorensen 2010-06-08 06:44:26 UTC
Hi,

I brought this up on the QEMU+SeaBIOS lists and the general consensus in the community is not to touch the current state of SMBIOS in SeaBIOS unless we have specific cases where we can document something broke because of this.

The bulk of the SMBIOS strings can be mangled per my previous post, so it's up to libvirt to add those arguments to QEMU.

Beyond that, I recommend we close this as WONTFIX, unless there are strong objections.

Jes

Comment 10 Milan Zázrivec 2010-06-18 12:39:54 UTC
The thing with the values we've seen have changed between rhel-5 and
rhel-6 is that Red Hat Network (hosted) as well as Red Hat Network Satellite
relies on these values when determining whether or not a particular
system registering with RHN / Satellite is a virtual guest
(entitlement consumption thing).

With these values changed, KVM virtual guests will now be recognized
and registered as physical machines. See bug #605522

Comment 11 Jes Sorensen 2010-06-18 13:24:43 UTC
Milan,

Relying on a virtual BIOS that can be replaced with a simple copy, or
most of it by just adding extra arguments to the qemu command line
isn't a good way to do this. Plus it means patching the SeaBIOS code,
diverting it from upstream for this.

The consensus from the discussion I opened with the community about this
is that those SMBIOS strings are likely to change again, and relying on
such changes is going to turn it into an endless patch chase.

If you want to validate RHN access, have the guest RHN talk to a license
server on the host to verify that access is granted instead.

Cheers,
Jes

Comment 22 Dor Laor 2010-06-21 07:17:25 UTC
*** Bug 605522 has been marked as a duplicate of this bug. ***

Comment 31 Milan Zázrivec 2010-06-22 11:46:10 UTC
Created attachment 425895 [details]
RHEL-5.5 guest, dmidecode output

RHEL-6 host, w/ seabios-0.5.1-0.14.20100108git669c991.el6.x86_64

Comment 32 Eduardo Habkost 2010-06-22 12:05:10 UTC
RHEL6 is a different system, with a different BIOS. RHN should check for the RH-specific fields (e.g. System Information vendor/product) instead of bios.vendor.

Comment 33 Jiri Kastner 2010-06-22 14:09:09 UTC
Created attachment 425936 [details]
dmidecode on rhel5, rhel6 guests after seabios upgrade

Comment 43 Subhendu Ghosh 2010-07-23 21:42:59 UTC
Created attachment 434072 [details]
dmidecode output

Comment 44 Subhendu Ghosh 2010-07-23 21:43:46 UTC
# rpm -q seabios
seabios-0.5.1-2.el6.x86_64


Note You need to log in before you can comment on or make changes to this bug.