Quoting "Dan Kenigsberg" <dan...@redhat.com>:
This was devised as a security constraint - otherwise, a VM attached to
the non-VLAN network could sniff traffic from another (VLAN) network.
However, it seems that this is exactly what you need - a special VM that
is designed to do just that.
Well, I would prefer it not be a VM but part of the oVirt networking
stack itself. VMware has this built in with just a few clicks (you
assign a VLAN ID of "4095" to a port group/network and it is basically
tagging that port group with all VLAN IDs). VMware of course is not
using the Linux networking, though; they use their own "vSwitch", so
that is probably how they are able to do it.
So it seems to me the problem of no being able to do exactly what I am
looking to do within oVirt itself is not really a shortfall of oVirt,
per se, but the underlying platform on which it relies :-(
And it's not only you: there's another recent request for lifting this
limitation:
Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the
same NIC
I actually do not have a problem with not being able to mix untagged
and tagged Logical Networks on the same NIC; it is very convenient to
be able to do so, but would not be considered a show-stopper IMO; if
two physical NICs would need to be used, so be it.
I do not understand what you are trying to do with dummy devices (after
all, they are not going to send any packet anywhere).
Since my test server only has one physical NIC, I am using the dummy
devices instead of physical ones. I know they cannot pass traffic
outside of the server (unless attached to a VM was is also attached to
the physical NIC), but I am not concerned with that at the moment. I
am trying to test with a virtual lab, and as long as the
traffic/access behaves as expected within it, there should be no
reason it should not behave as expected with physical NICs, when I get
to that stage.
But if you are willing to mess with network configuration under the feet
of oVirt, you could do the following:
As long as it does not involve too much complexity, I have no problem
with having to mess with some configuration outside of oVirt. It has
to be kept pretty minimal.
We are looking for a good alternative to VMware so we don't have to
keep putting up with their onerous licensing. oVirt is our
evaluation; if it ticks all our boxes, we would likely go with RHEV
for those clients who are more comfortable with the commercial
support, and oVirt for the others. Unfortunately, this "trunk"
capability is a pretty big one :-(
- create a network tagged with an id that is not really used in your
datacenter, say 999, and attach it to the host.
- build and install vdsm-hook-extnet rpm
- define a vnic profile using this network, and adding a custom propery
called "extnet" with the value of (say) "untagged".
- set up a bridge named "untagged" directly on top of your eth0 (say
"breth0")
- define a libvirt bridged network named "untagged", that uses "breth0".
- attach the vnic of your firewall VM to your vnic profile.
I will give the above a try and let you know. It might be a few days
before I can get to it though. I am really looking to do a "trunk"
port though, which actually carries multiple tagged VLANs. Going back
to VMware, just for clarification, when VLAN ID "4095" is assigned to
the "trunk" port group/network we create, that's the same thing as
tagging that port group with all VLAN IDs, from "1" through to "4094".
It is very different from having it "untagged".
OpenvSwitch supports this, but it appears it will be a while until
full/natural integration is done with OpenvSwitch. Unfortunately, we
are not developers, so we are unable help with it's integration :-(
Anyway, we are not ready to give up yet. We'll see what we can do
with the above and let you know. The other work-around, of course, is
an earlier suggestion of just adding as many vNICs to the firewall VM
as we need for each VLAN'd Logical Network, but that would raise
another "problem", albeit a rare one: if we were to put oVirt/RHEV in
our own datacenter, replacing VMware, we have a couple of BGP routers
that are setup with a few dozen VLANs. It would be a PITA to add a
vNIC for each one :-( Most of our deployments with our clients,
though, have less than ten VLANs, so it *could* be workable enough in
those cases.
-Alan
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
