<div dir="ltr"><div><div>I didn't said it is the right design, i guess that i can get nothing from such bond and you are right, but, <br></div>This is was long discussed a year ago(maybe more) with network DEV when we planed this feature and it was decided to allow to create bond from VFs. <br><br></div>Thanks, <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 6, 2016 at 5:04 PM, Martin Polednik <span dir="ltr"><<a href="mailto:mpolednik@redhat.com" target="_blank">mpolednik@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/12/16 16:58 +0200, Michael Burman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Nathanael<br>
<br>
VFs are regular NICs and can be used as regular NICs.<br>
We are allowing to create bond from them and allowing to attach logical<br>
networks to them, because as long as they are not used by any VM, they can<br>
be used just as any other interfaces on the host.<br>
<br>
When creating bond from 2 VFs you should see the pencil icon, because you<br>
want to able to edit the bond.<br>
Vf is an interface and you can use it just as you use regular interface on<br>
the host.<br>
<br>
* When you create bond from 2 VFs, this VFs are no longer free and you<br>
can't use them to run VM<br>
* The same for attaching a network to VF, this VF is no longer considered<br>
as free VF.<br>
<br>
There is no problem about it, this is exactly how it was designed ) , you<br>
have to remember that as long as the VFs are not used by VM, they can be<br>
used as regular NICs and you can do with them everything you want.<br>
</blockquote>
<br></span>
That doesn't mean we have the right design: there is no problem in<br>
bonding 2 VFs belonging to 2 different PFs; but every sane software<br>
warns you if you try to bond 2 VFs from the same PF together (what do<br>
you get by such bond?) -- this applies to both host and guest.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://www.ovirt.org/develop/release-management/features/engine/sr-iov/" rel="noreferrer" target="_blank">http://www.ovirt.org/develop/r<wbr>elease-management/features/eng<wbr>ine/sr-iov/</a><br>
<br>
Regards,<br>
<br>
<br>
On Tue, Dec 6, 2016 at 4:23 PM, Nathanaël Blanchet <<a href="mailto:blanchet@abes.fr" target="_blank">blanchet@abes.fr</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Le 06/12/2016 à 13:19, Martin Polednik a écrit :<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06/12/16 12:14 +0100, Nathanaël Blanchet wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
My new 10G NICS support now SR-IOV, and I've played with this new<br>
feature as passthrough device, so as to reduce my host CPU consumption.<br>
<br>
At the origin, I set up a bond on both 10G PF nics.<br>
<br>
After many configurations, the only way I manage to use a VF into a VM,<br>
is to get out of the bond one nic.<br>
<br>
So does it mean that it is impossible to run a VM with VF with PF<br>
attached to a bond?<br>
<br>
</blockquote>
<br>
As far as I know, it's not possible to do that. The reason is that the<br>
bond normally creates new (logical) interface, what you are doing is<br>
assigning "part" of the bond directly to a VM and the driver within VM<br>
isn't aware of the bond.<br>
<br>
</blockquote>
This is what I supposed, UI should prevent us to create VFfrom when nic is<br>
attached to a bond. Pencil icon should'nt appear in this case.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Moreover, something strange happens : during the boot of the VM, the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
passthrough device gets an dhcp IP on the native vlan of the bond, and once<br>
finally up, the real vlan used by this device is on the different<br>
predifined vlan. It implies to me to reconfigure the network to ping<br>
something on the wanted vlan. Really crazy.<br>
<br>
</blockquote>
<br>
This could be explained by previous statement: bonding PFs at<br>
hypervisor level and then assigning VFs to a VM can most likely cause<br>
undefined behavior.<br>
<br>
</blockquote>
The issue is the same when the PF is not attached to a bond, so in an<br>
expected working situation.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Other question is : In which case can it be useful to be able to bond 2<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
VF? UI let us to do so, but it is impossible to add any bridge on that<br>
virtual bond.<br>
<br>
</blockquote>
<br>
At hypervisor level? I believe it doesn't make sense.<br>
<br>
</blockquote>
I wonder this because UI allows to do it. The same as above, user<br>
shouldn't be allowed to bond two VFs, and not allowed to add virtual<br>
network to a VF<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you require bond between 2 PFs, you can assign 2 VFs each from<br>
different PF to a VM and bond them within the guest.<br>
<br>
Comparing to a large number of restrictions (migration and others), my<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
opinion is that this feature seems to be very difficult to use in<br>
production...<br>
<br>
</blockquote>
<br>
The use case for SR-IOV is maximum performance at the cost of<br>
convenience while still (somewhat) allowing you to scale.<br>
<br>
--<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nathanaël Blanchet<br>
<br>
Supervision réseau<br>
Pôle Infrastrutures Informatiques<br>
227 avenue Professeur-Jean-Louis-Viala<br>
34193 MONTPELLIER CEDEX 5<br>
Tél. 33 (0)4 67 54 84 55<br>
Fax 33 (0)4 67 54 84 14<br>
<a href="mailto:blanchet@abes.fr" target="_blank">blanchet@abes.fr</a><br>
<br>
<br>
</blockquote>
______________________________<wbr>_________________<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
--<br>
Nathanaël Blanchet<br>
<br>
Supervision réseau<br>
Pôle Infrastrutures Informatiques<br>
227 avenue Professeur-Jean-Louis-Viala<br>
34193 MONTPELLIER CEDEX 5<br>
Tél. 33 (0)4 67 54 84 55<br>
Fax 33 (0)4 67 54 84 14<br>
<a href="mailto:blanchet@abes.fr" target="_blank">blanchet@abes.fr</a><br>
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Michael Burman<br>
RedHat Israel, RHV-M Network QE<br>
<br>
Mobile: 054-5355725<br>
IRC: mburman<br>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Michael Burman<br>RedHat Israel, RHV-M <span>Network </span>QE <br><br>Mobile: 054-5355725<br>IRC: mburman</div></div></div></div>
</div>