Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionDaniel 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:
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
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
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
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
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.
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: