Re: [ovirt-users] feedback and questions about SR-IOV feature

Le 06/12/2016 à 13:19, Martin Polednik a écrit : >On 06/12/16 12:14 +0100, Nathanaël Blanchet wrote: >>Hello, >> >>My new 10G NICS support now SR-IOV, and I've played with this new >>feature as passthrough device, so as to reduce my host CPU >>consumption. >> >>At the origin, I set up a bond on both 10G PF nics. >> >>After many configurations, the only way I manage to use a VF into >>a VM, is to get out of the bond one nic. >> >>So does it mean that it is impossible to run a VM with VF with PF >>attached to a bond? > >As far as I know, it's not possible to do that. The reason is that the >bond normally creates new (logical) interface, what you are doing is >assigning "part" of the bond directly to a VM and the driver within VM >isn't aware of the bond. This is what I supposed, UI should prevent us to create VFfrom when nic is attached to a bond. Pencil icon should'nt appear in this case.

> >>Moreover, something strange happens : during the boot of the VM, >>the passthrough device gets an dhcp IP on the native vlan of the >>bond, and once finally up, the real vlan used by this device is on >>the different predifined vlan. It implies to me to reconfigure the >>network to ping something on the wanted vlan. Really crazy. > >This could be explained by previous statement: bonding PFs at >hypervisor level and then assigning VFs to a VM can most likely cause >undefined behavior. The issue is the same when the PF is not attached to a bond, so in an expected working situation.

> >>Other question is : In which case can it be useful to be able to >>bond 2 VF? UI let us to do so, but it is impossible to add any >>bridge on that virtual bond. > >At hypervisor level? I believe it doesn't make sense. I wonder this because UI allows to do it. The same as above, user shouldn't be allowed to bond two VFs, and not allowed to add virtual network to a VF

> >If you require bond between 2 PFs, you can assign 2 VFs each from >different PF to a VM and bond them within the guest. > >>Comparing to a large number of restrictions (migration and >>others), my opinion is that this feature seems to be very >>difficult to use in production... > >The use case for SR-IOV is maximum performance at the cost of >convenience while still (somewhat) allowing you to scale. > >>-- >>Nathanaël Blanchet >> >>Supervision réseau >>Pôle Infrastrutures Informatiques >>227 avenue Professeur-Jean-Louis-Viala >>34193 MONTPELLIER CEDEX 5 >>Tél. 33 (0)4 67 54 84 55 >>Fax 33 (0)4 67 54 84 14 >>blanchet(a)abes.fr >> > >>_______________________________________________ >>Users mailing list >>Users(a)ovirt.org >>http://lists.ovirt.org/mailman/listinfo/users > -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr