Instead of using <hostdev>, you should instead try using <interface type='hostdev'>, which will allow you to specify the mac address for the interface directly in the guest's XML config (rather than needing to do it separately). Here's a link to documentation on this feature: http://wiki.libvirt.org/page/Networking#PCI_Passthrough_of_host_network_devices (look down to the section titled "Assignment with <interface type='hostdev'>") Or even better, use <interface type='network'> in your guest config (still put the <mac address='xx:xx:xx:xx:xx:xx'/> element in each one), and define a libvirt network which is a pool of SRIOV VFs - this is described further down the same page. This will not make a difference to the issue you describe below, but it should make managing your guest config and lifecycle much simpler.
I also conducted experiments with these XML configs and, as you said, it didn't make a difference to the issue observed. For most production use, my sample xml block is clearly not convenient.
Define "failed". Do you mean that the cards communicated, but the guests can see each others' traffic? Or do you mean that they see traffic from each other, but can't seem to communicate normally? If the problem is the latter, then make sure the PF (eth0 for you, I guess) has status UP and RUNNING before you start the guests. For the former, I'm not clear on the internal rules of switching of an SRIOV card. I think in most cases, the SRIOV card's internal switch may need to make everything from each VF visible to all other VFs, because the physical switch it's connected to may not mirror back traffic that really does need to go from one guest to the other. 802.1Qbh (which libvirt supports via the <virtualport type='802.1Qbh'> element) does this differently, requiring all traffic to travel out to the switch, with the switch making the decision about what gets mirrored back, but you need an 802.1Qbh-capable switch for that.
What I meant by "failed" was a lack of traffic switching. I thought that the PF driver was responsible for configuring L2 switching on the NIC. Some others manufacturers, such as Emulex, have an internal switch. This is an extract from Emulex Whitepaper:
"I/O’s between VFs on the same PF can be processed by the adapter using an internal Layer 2 switch, eliminating routing through a physical switch"
I doubt that Broadcom has a specific and unsecure behavior for PF/VF communications. Unfortunately, I do not have an Intel or Emulex NIC with SR-IOV feature to check it.
Perhaps, I missed a configuration parameter somewhere or the driver/firmware used is broken... It looks really weird.
-- Université de Nantes - Direction des Systèmes d'Information
begin:vcard fn:Yoann Juet n:Juet;Yoann org;quoted-printable;quoted-printable:Direction des Syst=C3=A8mes d'Information;P=C3=B4le R=C3=A9seau adr;quoted-printable:BP 92208;;2 rue de la Houssini=C3=A8re;Nantes Cedex 3;;44322;France email;internet:yoann.juet@xxxxxxxxxxxxxx tel;work:02.53.48.49.26 tel;fax:02.53.48.49.09 tel;cell:06.73.15.42.19 version:2.1 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
