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@xxxxxxxxx>: >> 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@xxxxxxxxx >>> <mailto:dominikmostowiec@xxxxxxxxx>> napisał(a): >>> >>> Hmm, >>> It seems to be working (after only simple tests). >>> >>> -- >>> Dominik >>> >>> >>> 2013/5/21 Ján Tomko <jtomko@xxxxxxxxxx <mailto:jtomko@xxxxxxxxxx>> >>> >>> 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 >>> > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list