Hi,
> Do you have this problem with mac addresses when max_vfs is set
to an
even lower number?
No,
When max_fs=10, macs in VM are OK.
Phisical interfaces:
ifconfig eth0
eth0 Link encap:Ethernet HWaddr
b8:ca:3a:5b:a6:38
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
ifconfig eth1
eth1 Link encap:Ethernet HWaddr
b8:ca:3a:5b:a6:38
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
> Hmm. ixgbe. I just got a report yesterday that setting of the
vlan tag
> for ixgbe vfs was not working properly (although it works fine for igb
> devices)
Domain config:
<interface type="network">
<alias name="hostdev0"/>
<source network="vnet0"/>
<mac address="52:54:0a:b1:48:fc"/>
</interface>
<interface type="network">
<alias name="hostdev1"/>
<source network="vnet1"/>
<mac address="52:54:0a:b1:48:fc"/>
</interface>
Networks defined:
<network>
<name>vnet0</name>
<uuid>ec49896a-a0b5-4944-a81f-9f0cdf578871</uuid>
<forward mode='hostdev' managed='yes'>
<pf dev='eth0'/>
</forward>
</network>
<network>
<name>vnet1</name>
<uuid>6c8319e8-8b53-4382-9f4e-2400819b00a9</uuid>
<forward mode='hostdev' managed='yes'>
<pf dev='eth1'/>
</forward>
</network>
Regards
Dominik
2013/5/24 Laine Stump <laine(a)laine.org>:
On 05/24/2013 04:45 AM, Dominik Mostowiec wrote:
> Hi,
> I have libnl3, kernel 3.8.8, os ubuntu 12.04, net:intel10G.
> Upgrade libnl to 3.2.16 not helps,
>
> I don't know - this is probably another problem, when I have set
> max_vfs=35,35 VF is attaching to VM but mac in VM is not set
> propertly.
Do you have this problem with mac addresses when max_vfs is set to an
even lower number?
Ah, another thing - did you "ifconfig up" the PF before you started the
guest?
> Libvirt probably set this macs because in syslog:
> May 23 14:48:59 on-10-177-32-62 kernel: [12574.171792] ixgbe
Hmm. ixgbe. I just got a report yesterday that setting of the vlan tag
for ixgbe vfs was not working properly (although it works fine for igb
devices)
> 0000:01:00.0: setting MAC 52:54:0a:b1:48:f7 on VF 0
> May 23 14:48:59 on-10-177-32-62 kernel: [12574.171799] ixgbe
> 0000:01:00.0: Reload the VF driver to make this change effective.
> May 23 14:48:59 on-10-177-32-62 kernel: [12574.175054] ixgbe
> 0000:01:00.1: setting MAC 52:54:0a:b1:48:f7 on VF 0
> May 23 14:48:59 on-10-177-32-62 kernel: [12574.175060] ixgbe
> 0000:01:00.1: Reload the VF driver to make this change effective.
> May 23 14:48:59 on-10-177-32-62 kernel: [12574.307172] pci-stub
> 0000:01:12.4: enabling device (0000 -> 0002)
> May 23 14:49:00 on-10-177-32-62 kernel: [12575.662890] assign device 0:1:12.4
> May 23 14:49:00 on-10-177-32-62 kernel: [12575.665210] pci-stub
> 0000:01:12.5: enabling device (0000 -> 0002)
> May 23 14:49:00 on-10-177-32-62 kernel: [12575.765609] assign device 0:1:12.5
> But in VM i have another macs probably old from VF.
>
> ---
> Regards
> Dominik
>
>
>
> 2013/5/24 Laine Stump <laine(a)laine.org>:
>> On 05/22/2013 06:32 PM, Dominik Mostowiec wrote:
>>> I tested on 1.0.5 patched version and vm with 2 vfs working fine.
>>>
>>> I have another problem
>>> When i set max_vfs=63:
>>> internal error missing IFLA_VF_INFO in netlink response
>>>
>>> Its working when max_vfs=31
>>>
>> What is the platform, kernel version, and what version of libnl are you
>> using (libnl 1 or libnl3?)
>>
>> There have been multiple bugs recently filed and fixed in this area on
>> RHEL6/CentOS6. In particular, there was a problem with max_vfs > 50 that
>> had exactly this symptom. It was solved by a patch to libnl-1.1. If your
>> platform uses libnl-1.1, this could be the source of the problem. It is
>> fixed in the upstream libnl-1.1.4 maintenance release.
>>
>> I unfortunately am not sure where the libnl-1.1 git is (I only have the
>> git tree for libnl3), so I can't give you the exact commit message, but
>> in short the problem was that libnl was using too small of a buffer for
>> the netlink socket, so when there were a lot of vfs, the netlink message
>> containing vf info was truncated.
>>
>>
>>> --
>>> Dominik
>>>
>>> 21 maj 2013 15:19, "Dominik Mostowiec"
<dominikmostowiec(a)gmail.com
>>> <mailto:dominikmostowiec@gmail.com>> napisał(a):
>>>
>>> Hmm,
>>> It seems to be working (after only simple tests).
>>>
>>> --
>>> Dominik
>>>
>>>
>>> 2013/5/21 Ján Tomko <jtomko(a)redhat.com
<mailto:jtomko@redhat.com>>
>>>
>>> On 05/21/2013 01:37 PM, Laine Stump wrote:
>>> > On 05/21/2013 04:03 AM, Ján Tomko wrote:
>>> >> On 05/21/2013 09:32 AM, Dominik Mostowiec wrote:
>>> >>> hi,
>>> >>> I try to add 2 VF by "hostdev".
>>> >>> Networks (vnet0, vnet1) with:
>>> >>> <forward mode='hostdev'
managed='yes'>
>>> >>> <pf dev='eth1'/>
>>> >>> .....
>>> >>>
>>> >>> Domain:
>>> >>> <interface type="network">
>>> >>> <source network="vnet0"/>
>>> >>> ....
>>> >>> <interface type="network">
>>> >>> <source network="vnet1"/>
>>> >>> ....
>>> >>>
>>> >>> virsh create error:
>>> >>> "error: internal error process exited while
connecting to
>>> monitor: kvm:
>>> >>> -device
>>> pci-assign,configfd=25,host=01:10.1,id=hostdev0,bus=pci.0,addr=0x4:
>>> >>> Duplicate ID 'hostdev0' for device"
>>> >>>
>>> >> Hi,
>>> >>
>>> >> it seems we have been assigning the same id to all network
>>> hostdevs until this
>>> >> recent commit (not yet released):
>>> >>
>>> >>
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=6597cc25
>>> >
>>> >
>>> > If that patch has such an effect, it's purely accidental.
>>> Have you
>>> > tested this? (I plan to test a before and after as soon as
>>> I've had
>>> > breakfast)
>>> >
>>>
>>> I haven't tested it and looking at the code again, I
might've
>>> been wrong :(
>>>
>>> Sorry about that.
>>>
>>> Jan
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Pozdrawiam
>>> Dominik
>>>
>
>
--
Pozdrawiam
Dominik