Bug 669955

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.

Reminds me to go back and look at that spec.

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.

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.

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.

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.

(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

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.

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.

(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.

(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

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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.

(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