VLAN Trunk interface with OVN provider (ovirt HE 4.2.6.4-1.el7)
Hello; I'm having some hard time getting my oVirt cluster back to work, after the last update to 4.2.6. One thing that does not work anymore is VLAN Trunks; before the update, the cluster was running in OVS mode, and I could define logical networks without VLAN tag; then, networks packets got forwarded to the guest as "tagged". Right now version 4.2.6 won't allow me to assign the (OVS) Logical network to the guest NICs anymore, but it insists that I use a vNIC profile from an external provider. First question: Is this expected? Must I really work with externally provided networks only? Anyway, for the vNIC interfaces that only carry untagged traffic, I was able to define an external OVN network, connect it to the corresponding "Data center Network", and everything works as it did before. But the "trick" does not work for "trunk" interfaces that should carry VLAN tagged traffic. So to the second (main) question? How is this to be solved? Is there a way to define a VLAN trunk under OVN? Or is there a way to pickup a Data Center logical network to attach to the vNIC as we did before? Thanks in advance for your help!
Il giorno ven 21 set 2018 alle ore 12:34 Davide Butti <dbutti194@gmail.com> ha scritto:
Hello; I'm having some hard time getting my oVirt cluster back to work, after the last update to 4.2.6.
One thing that does not work anymore is VLAN Trunks; before the update, the cluster was running in OVS mode, and I could define logical networks without VLAN tag; then, networks packets got forwarded to the guest as "tagged".
Right now version 4.2.6 won't allow me to assign the (OVS) Logical network to the guest NICs anymore, but it insists that I use a vNIC profile from an external provider.
First question: Is this expected? Must I really work with externally provided networks only?
Anyway, for the vNIC interfaces that only carry untagged traffic, I was able to define an external OVN network, connect it to the corresponding "Data center Network", and everything works as it did before. But the "trick" does not work for "trunk" interfaces that should carry VLAN tagged traffic.
So to the second (main) question? How is this to be solved? Is there a way to define a VLAN trunk under OVN? Or is there a way to pickup a Data Center logical network to attach to the vNIC as we did before?
Dominic, can you please have a look?
Thanks in advance for your help! _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4OCWNPMJ442EJ...
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig> <https://www.redhat.com/en/events/red-hat-open-source-day-italia?sc_cid=701f2000000RgRyAAK>
On Fri, 21 Sep 2018 14:17:37 +0200 Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Il giorno ven 21 set 2018 alle ore 12:34 Davide Butti <dbutti194@gmail.com> ha scritto:
Hello; I'm having some hard time getting my oVirt cluster back to work, after the last update to 4.2.6.
One thing that does not work anymore is VLAN Trunks; before the update, the cluster was running in OVS mode, and I could define logical networks without VLAN tag; then, networks packets got forwarded to the guest as "tagged".
Right now version 4.2.6 won't allow me to assign the (OVS) Logical network to the guest NICs anymore, but it insists that I use a vNIC profile from an external provider.
First question: Is this expected? Must I really work with externally provided networks only?
Yes, this way there is a clean separation between VM networks and host networks.
Anyway, for the vNIC interfaces that only carry untagged traffic, I was able to define an external OVN network, connect it to the corresponding "Data center Network", and everything works as it did before. But the "trick" does not work for "trunk" interfaces that should carry VLAN tagged traffic.
So to the second (main) question? How is this to be solved? Is there a way to define a VLAN trunk under OVN?
Trunk is not implemented in ovirt-provider-ovn. If you think that this would be helpful for you, you are welcome to create a bug and explain in short words your motivation.
Or is there a way to pickup a Data Center logical network to attach to the vNIC as we did before?
As it is not working with networks provided by ovirt-provider-ovn, it should work with neutron networks in clusters with OVS switch type, or with oVirt logical networks or neutron networks in clusters with linux-bridge switch type.
Dominic, can you please have a look?
Thanks in advance for your help! _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/P4OCWNPMJ442EJ...
Hi Dominik, thanks for your reply. Of course use cases for VLAN trunks to the guests are not difficult to find, for example when you want to run a virtual router inside the VM, and you don't want to define dozens or hundreds individual VLANs into the router. Anyways, I'll take the time to write a full bug description to try and have this supported. In the meantime I've found another disturbing issue: even when I create a vNIC profile with "no network filter" assigned, the vNIC will only accept incoming network packets with the "correct" destination MAC address, although the VM is also replying to ARP queries for different ones (ARP spoofing, which is needed by many Virtual-IP protocols). What's going on in this case? Is there a "no-mac-spoofing" filter which is applied inadvertently, independent of vNIC profile? Or am I missing something? Do you believe I should post a bug for this issue, too? Thanks again,
On Fri, 21 Sep 2018 16:56:58 -0000 "Davide Butti" <dbutti194@gmail.com> wrote:
Hi Dominik, thanks for your reply. Of course use cases for VLAN trunks to the guests are not difficult to find, for example when you want to run a virtual router inside the VM, and you don't want to
Why does PCI passthrough / SR-IOV does not fit in your case?
define dozens or hundreds individual VLANs into the router. Anyways, I'll take the time to write a full bug description to try and have this supported.
Thanks.
In the meantime I've found another disturbing issue: even when I create a vNIC profile with "no network filter" assigned, the vNIC will only accept incoming network packets with the "correct" destination MAC address, although the VM is also replying to ARP queries for different ones (ARP spoofing, which is needed by many Virtual-IP protocols). What's going on in this case? Is there a "no-mac-spoofing" filter which is applied inadvertently, independent of vNIC profile? Or am I missing something?
You miss nothing, oVirt configures OVN to bind the "correct" MAC address on the VM's port.
Do you believe I should post a bug for this issue, too?
Would be nice if you would post a bug for this, too. It would be helpful if you would give at least one concrete example of a Virtual-IP protocol which should work inside the VM and runs into the issue.
Thanks again,
I have to thank you for the feedback!
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/UPKTZANZ2YEJDS...
Well, I have already two examples taken directly from my cluster: a pair of highly available OpenStack Controllers and a pair of Sophos ASG Security Firewalls rely on the ability to have multiple MAC addresses on the same port. It turns out that virtual MAC addresses are frequently used with HA/clustering protocols, and this is why every virtual network controller should have a way to disable strict MAC address filtering.
participants (3)
-
Davide Butti -
Dominik Holler -
Sandro Bonazzola