+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1009608 +++ ====================================================================== Description of problem: Support for private virtual local area networks (PVLAN) allowing to 'sub-partition' a VLAN by restricting switch ports to only communicate with a given 'uplink' - avoiding 'per-to per' communication (extension to the VLAN standard). Private VLAN works when assigning IP to interface directly on RHEL KVM hypervisor server...but when creating a bridge using same interface and assign network to VM..it does not work. (Originally by Allan Voss)
RFE: Red Hat Virtualization Manager Administration portal Existing: Navigate to any network N under a datacenter. Open the associated vNIC profile. The 'Network Filter' shows a drop down list of only the built-in network filters. Requirement: A way to create a new network filter and associate it with a vNIC profile from the administration portal. (Originally by fnanushr)
(In reply to fnanushr from comment #18) > RFE: > > A way to create a new network filter and associate it with a vNIC profile > from the administration portal. bug 1544666 is all about letting Engine select a non-built-in nwfilter, that is already deployed to all hosts. Here you request a way to deploy nwfilter to all hosts, which I believe is better done by Ansible, possibly triggered by ovirt-host-deploy. If you think differently, please file an independent RFE. (Originally by danken)
We will look to add the network filter into libvirt and gateway option in RHV to enable this use case. (Originally by ylavi)
We agreed to remove RFEs component from Bugzilla, if you feel the component has been renamed incorrectly please reach out. (Originally by Sarah Power)
Upstream patch is going well and we will ask to add the filter to a coming RHEL release. (Originally by ylavi)
In my opinion it safe enough to introduce this to 4.2.7 which is going to support el7.6 which is going to have this filter.
The new filter is called "clean-traffic-gateway" and can be chosen in vnic profiles. Then for every vm nic, with this vnic, the "GATEWAY_MAC" network filter parameter should be specified for the filter to work properly.
Verified upstream with - 4.2.6.5-0.0.master.20180831090131.git1d64d4c.el7 vdsm-4.20.39-1.el7ev.x86_64 kernel 3.10.0-940.el7.x86_64 Red Hat Enterprise Linux Server release 7.6 Beta (Maipo) libvirt-daemon-4.5.0-7.el7.x86_64 libvirt-client-4.5.0-7.el7.x86_64 rhel 7.5 guests(VMs) Test flow - 1. Create 3 VMs with 1 vNIC each 2. Create logical network 'net1' 3. Edit net1's vNIC profile and choose 'clean-traffic-gateway' network filter 4. VM1 - assign the net1's vNIC profile and In 'Network Filter Parameters' set name=GATEWAY_MAC , value=MAC address of VM2 name=GATEWAY_MAC , value=ff:ff:ff:ff:ff:ff - for dhcp to work correctly 5. VM2 - assign the net's vNIC profile and In 'Network Filter Parameters' set name=GATEWAY_MAC , value=MAC address of VM1 name=GATEWAY_MAC , value=ff:ff:ff:ff:ff:ff - for dhcp to work correctly 6. VM3 - Create new vNIC profile for the 'net1' network without the clean-traffic-gateway network filter and assign the new net1's vNIC profile and don't set any 'Network Filter Parameters' 7. Ping between VM1 and VM2 - PASS 8. Try ping from VM3 VM1/VM2 - FAIL as expected 9. Try to ping from VM1/VM2 to VM3 - FAIL as expected 10. Try to ping from VM1/VM2 to default gateway - FAIL as expected 11. Try to ssh to VM1/VM2 from outside(MAC address that isn't specified in the network filter parameters) - FAIL as expected 12. xml passed correctly - <filterref filter='clean-traffic-gateway'> <parameter name='GATEWAY_MAC' value='ff:ff:ff:ff:ff:ff'/> <parameter name='GATEWAY_MAC' value='00:xx:xx:xx:xx:00'/> </filterref>
QE verification bot: the bug was verified upstream
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3480
The requirement is to enable traffic from VMs to default-gateway only As a result, we expected that any type of traffic between VMs will be blocked including broadcast, e.g.: ARP, DHCP requests, etc... The following 3 leaking issues break that requirement: https://bugzilla.redhat.com/show_bug.cgi?id=1647944 https://bugzilla.redhat.com/show_bug.cgi?id=1651499 https://bugzilla.redhat.com/show_bug.cgi?id=1651467