在使用了Linux 3.9 作为KVM host的内核后，使用Intel igb NIC（如:82576, I350）的SR-IOV，在将VF（igbvf）分配guest使用时，可能会遇到不工作的情况。在guest的dmesg中可以看到如下的错误信息：
|
1 2 3 |
igbvf 0000:00:03.0: irq 26 for MSI/MSI-X igbvf 0000:00:03.0: Invalid MAC Address: 00:00:00:00:00:00 igbvf: probe of 0000:00:03.0 failed with error -5 |
即是，在guest中检测到的igbvf的MAC地址为全0，如kernel（KVM）bugzilla上的这个bug：
https://bugzilla.kernel.org/show_bug.cgi?id=55421
经过分析，出现这个问题的原因是，在最新的igb driver中在igbf使用时，会默认设置其MAC地址为全0，而之前是设置一个随机的MAC，可以看下面的Patch真是去做这件事情的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
[root@jay-linux kvm.git]# git diff 5ac6f91d39e088^ 5ac6f91d39e088 diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c index b81a953..a59e630 100644 --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -5197,7 +5197,7 @@ static int igb_vf_configure(struct igb_adapter *adapter, int vf) { unsigned char mac_addr[ETH_ALEN]; - eth_random_addr(mac_addr); + eth_zero_addr(mac_addr); igb_set_vf_mac(adapter, vf, mac_addr); return 0; @@ -5550,9 +5550,9 @@ static void igb_vf_reset_event(struct igb_adapter *adapter, u32 vf) { unsigned char *vf_mac = adapter->vf_data[vf].vf_mac_addresses; - /* generate a new mac address as we were hotplug removed/added */ + /* clear mac address as we were hotplug removed/added */ if (!(adapter->vf_data[vf].flags & IGB_VF_FLAG_PF_SET_MAC)) - eth_random_addr(vf_mac); + eth_zero_addr(vf_mac); /* process remaining reset events */ igb_vf_reset(adapter, vf); |
至于为什么设置为全0而不使用曾经的随机MAC呢，这主要是因为随机的MAC在guest中与udev不能很好的工作，多次使用VF后会让ethX（X为数字编号）的编号持续增长变化，可能变为eth500、eth666之类的，对用户很不友好。
所以在KVM中，对于igb NIC的SR-IOV操作，需要注意以下两种方法（注意使用其中一种方法即可避免VF的MAC全0的情况）：
1. 在分配VF给客户机之前，需要在host中先设置igbvf的MAC地址，命令如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
[root@jay-linux ~]# ip link set eth0 vf 0 mac 00:1E:67:65:93:01 # eth0为host中PF对应的interface名称，0代表PF的编号为0的VF（即第一个VF） # 如果不清楚PF和VF对应关系，可以用下面的命令你个来查看以便确认 [root@jay-linux ~]# ethtool -i eth0 driver: igb version: 4.1.2-k firmware-version: 1.64, 0x800006fc bus-info: 0000:0a:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no [root@jay-linux ~]# ls -l /sys/bus/pci/devices/0000:0a:00.0/virtfn* lrwxrwxrwx 1 root root 0 Apr 23 15:09 /sys/bus/pci/devices/0000:0a:00.0/virtfn0 -> ../0000:0b:10.0 lrwxrwxrwx 1 root root 0 Apr 23 15:09 /sys/bus/pci/devices/0000:0a:00.0/virtfn1 -> ../0000:0b:10.4 lrwxrwxrwx 1 root root 0 Apr 23 15:09 /sys/bus/pci/devices/0000:0a:00.0/virtfn2 -> ../0000:0b:11.0 lrwxrwxrwx 1 root root 0 Apr 23 15:09 /sys/bus/pci/devices/0000:0a:00.0/virtfn3 -> ../0000:0b:11.4 lrwxrwxrwx 1 root root 0 Apr 23 15:09 /sys/bus/pci/devices/0000:0a:00.0/virtfn4 -> ../0000:0b:12.0 lrwxrwxrwx 1 root root 0 Apr 23 15:09 /sys/bus/pci/devices/0000:0a:00.0/virtfn5 -> ../0000:0b:12.4 lrwxrwxrwx 1 root root 0 Apr 23 15:09 /sys/bus/pci/devices/0000:0a:00.0/virtfn6 -> ../0000:0b:13.0 |
2. 升级guest中的kernel或igbvf driver，发现在升级一个rhel6.4 guest的内核到 Linux 3.9 之后，也可以正常使用igbvf了（尽管没有做第一种方法中在host中手动设置igbvf的MAC)。
这是因为最新的igbvf driver在检测到MAC为全0时，也做了特别处理。