Hide Forgot
Created attachment 528617 [details] Screenshot of network config settings Description of problem: There seems to be no way to create the equivalent of following configuration: eth0 \ eth1 -+-- bond0 +------------- rhevm (bridge) +\- vlan50 --- bvlan50 (bridge) |\- vlan51 --- bvlan51 (bridge) \- vlan52 --- bvlan52 (bridge) Near as I can tell, it's only possible to have a single Network on a single physical interface (or bond). Is this a design restriction, a documentation limitation or a misunderstanding on my part? Version-Release number of selected component (if applicable): RHEV Manager for Servers and Desktops: 3.0.0_0001-41.el6 Red Hat Enterprise Virtualization Hypervisor Hosts: OS Version - RHEL - 6Server - 6.1.0.2.el6 VDSM Version - 3.0.96.1 Additional info: I tried creating the networks by hand on the RHEL hosts as described above, but RHEV-M doesn't understand that they're there.
Created attachment 528651 [details] Example of desired network setup
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
you can set up rhev-m and other logical networks on the same bridge only if all are vlans (i.e., rhev-m would also have to be a vlan'd network). GSS has a KB on how to set this up. known issue on supporting this for future versions
I'm not looking to put more than one logical network on the same bridge, I'm trying to have a single bonded interface with multiple VLAN subinterfaces. Each one (the untagged and each subinterface) would have its own bridge.
Unfortunately, that is not supported, either. It was intentionally blocked since we did not want packets from a vlan'ed broadcust domain to spill over into an unrelated network (rhevm in your case). It is understood that your wiring may make sense if untrusted VMs are not going to going to be attached to the "rhevm" network, and if the latter network can spare the bandwidth. We may consider this topology in the next version if it has an important use-case.