Bug 669955

Summary: Implement support for SMBIOS Type 41 structures
Product: [Fedora] Fedora Reporter: Jon Masters <jcm>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: alex.williamson, amit.shah, berrange, crobinso, dwmw2, ehabkost, fdeutsch, itamar, jaswinder, jcm, Jes.Sorensen, jforbes, knoel, linux-bugs, matt_domsch, narendra_k, ondrejj, rjones, scottt.tw, tburke, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=831668
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-14 19:15:45 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jon Masters 2011-01-15 23:04:32 EST
Description of problem:

Please extend the existing support for SMBIOS in qemu to add a capability to provide "Onboard Devices Extended Information" (Type 41). Not only is this replacing one of the existing types, but it also provides a mapping between devices and physical system chassis locations. But there is no physical chassis! Right. However, this doesn't mean you don't want to tell the guest OS which virtual (e.g. network) interface is which. You can do that, if you implement this extension that is already going into real hardware, and likely other VMs too.

Ping me for details. See also page 117 of the v2.7 of the SMBIOS spec.

Jon.
Comment 1 Matt Domsch 2011-01-16 13:40:28 EST
FWIW, VMware ESX and Workstation expose their PCI NICs in the PCI IRQ Routing Table.  Kind of odd the first time you see it with biosdevname, as your NIC becomes pci3#1, but that's "correct" from a BIOS perspective. :-)  I'd be happy to have these strings exposed in SMBIOS Type 41, and eventually via the ACPI _DSM in the PCI Firmware Spec 3.1 released a couple weeks ago.
Comment 2 Jon Masters 2011-01-18 15:54:54 EST
Reminds me to go back and look at that spec.
Comment 3 Matt Domsch 2011-02-01 11:28:51 EST
KVM is exposing the first PCI device type NIC in the PCI IRQ Routing Table as being in Slot 2, so biosdevname suggests the name 'pci2#1' for it.  However, it does not provide information for the second PCI device type NIC, so that does not get renamed by biosdevname.

If you have a virtio NIC instead, there's no PCI bus, and biosdevname does not suggest a different name, so it remains 'eth0' also.

This is confusing.

For the near term, we're going to have biosdevname (or udev, not clear where the test will go) not rename devices inside a virtual machine.  It's too confusing and arbitrary at the moment.
Comment 4 Alex Williamson 2011-02-01 12:27:54 EST
Type 41 is meant for onboard devices:

"... this structure defines the attributes of devices that are onboard (soldered onto) a system element..."

"In general, an entry in this table implies that the BIOS has some level of control over the enabling of the associated device for use by the system."

Everything is hotpluggable (aside from maybe vga) in qemu and seabios has no control over enabling devices, so I'm not sure how this particular table is appropriate.
Comment 5 Richard W.M. Jones 2011-02-01 13:57:45 EST
I suggested to Matt over IRC that he has a look at virt-what:

http://people.redhat.com/~rjones/virt-what/
http://git.annexia.org/?p=virt-what.git;a=summary

Now because it depends on dmidecode, it's not directly very useful,
but it would be a good idea to see how virt-what detects KVM
and possibly reuse some of the code.
Comment 6 Jon Masters 2011-02-04 02:52:28 EST
My concern is more generic than just Linux. We should have SMBIOS support for other OS environments too. Windows, whatever, should get useful 41 structs.

Jon.
Comment 7 Narendra K 2011-02-08 10:58:09 EST
(In reply to comment #5)
> I suggested to Matt over IRC that he has a look at virt-what:
> 
> http://people.redhat.com/~rjones/virt-what/
> http://git.annexia.org/?p=virt-what.git;a=summary
> 
> Now because it depends on dmidecode, it's not directly very useful,
> but it would be a good idea to see how virt-what detects KVM
> and possibly reuse some of the code.

I explored virt-what on Fedora 14 kvm guest. I added the following line to the /lib/udev/rules.d/71-biosdevname.rules

SUBSYSTEM!="net", GOTO="netdevicename_end"
KERNEL!="eth*",   GOTO="netdevicename_end"
ACTION!="add",    GOTO="netdevicename_end"
NAME=="?*",       GOTO="netdevicename_end"

+ PROGRAM="/usr/local/sbin/virt-what", RESULT=="?*", GOTO="netdevicename_end"

This worked as expected. Biosdevname skipped suggesting a name because RESULT is kvm.

It would be great to know your view on using virt-what this way in biosdevname.

Also, i observed one more thing. 'virt-what' seems to exit with a code '0' even when it detects the environment as 'kvm'. Is this as expected or should it exit with something other than '0' when it detects kvm guest ?

[root@f14-guest ~] virt-what
Kvm

[root@f14-guest ~] echo $?
0
Comment 8 Daniel Berrange 2011-02-09 05:18:09 EST
IIUC, those udev rules will match on *far* more than just KVM. virt-what also knows about VMWare, Xen, Hyper-V, and all the various hardware partitioning virt platforms too.  So if you want to skip just KVM, IIUC, you need to filter more finely.
Comment 9 Jon Masters 2011-02-16 03:20:19 EST
We are talking about two different things in this bug I think. I opened the bug to get generic support for Type 41 structs in KVM (for even non-Linux OS environments). I think it's fair to (for now) disable network device renaming on KVM guests, but perhaps a separate bug is needed for that discussion.
Comment 10 Richard W.M. Jones 2011-03-02 02:32:50 EST
(In reply to comment #7)
> It would be great to know your view on using virt-what this way in biosdevname.

Using virt-what is going to be a bit heavyweight because it
will make udev depend on dmidecode.  Additionally Daniel's
comment 8 is right in that you're not parsing the output of
virt-what correctly.  Read the virt-what(1) man page to see
how you should do it.

That said you probably want to either use virt-what-cpuid-helper
or take the code from there, in order to reliably and minimally
detect KVM.

> Also, i observed one more thing. 'virt-what' seems to exit with a code '0' even
> when it detects the environment as 'kvm'. Is this as expected or should it exit
> with something other than '0' when it detects kvm guest ?
> 
> [root@f14-guest ~] virt-what
> Kvm
> 
> [root@f14-guest ~] echo $?
> 0

This is correct behaviour.  I've updated the man page upstream
so that it documents the return code.
Comment 11 Richard W.M. Jones 2011-03-02 02:43:14 EST
(In reply to comment #10)
> This is correct behaviour.  I've updated the man page upstream
> so that it documents the return code.

http://git.annexia.org/?p=virt-what.git;a=commitdiff;h=5453cf333745418a641374e19fd968519fd7de30
Comment 12 Fedora Admin XMLRPC Client 2012-03-15 13:58:52 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fabian Deutsch 2012-06-19 09:46:22 EDT
What is actual state of this bug? Are there intentions to implement this structure or not?

I ran into cases where the NIC names changed in a Fedora 17 guest, because it also uses fedora-readonly service it's not so easy to persist 70-persistent-net.rules, so afaiu this could help in such a case.
Comment 14 Cole Robinson 2012-12-14 19:15:45 EST

(In reply to comment #13)
> What is actual state of this bug? Are there intentions to implement this
> structure or not?
> 
> I ran into cases where the NIC names changed in a Fedora 17 guest, because
> it also uses fedora-readonly service it's not so easy to persist
> 70-persistent-net.rules, so afaiu this could help in such a case.

Fabian, I don't think anyone is actively working on it, and TBH I don't think there's much to gain from tracking this in the fedora tracker, so I've moved it to the upstream qemu tracker:

https://bugs.launchpad.net/qemu/+bug/1090604