Hi Alan,
May I just inquire about the two alternative solutions that had been
proposed here, and why you opted against? As a reminder, I'm referring to:
1. Using a firewall VM with one vNIC per VLAN network.
2. Using VDMS hooks to simulate TRUNK.
Both of these should allow migration, etc. without any additional
procurement, and require only the one firewall VM. Are the Lanner and
dual-firewall solutions simpler?
Yours, Lior.
On 21/01/14 05:07, Alan Murrell wrote:
I just thought I would reply back to my own thread with what my team and
I have come up with. While I have marked this as Solved, don't get
too excited; it is not exactly the resolution we were looking for, but
is acceptable nonetheless.
After some further digging around, we found that it is possible to pass
hardware (including a NIC) through to a guest. Unfortunately, this
renders the guest unable to be migrated to another host automatically.
In a single-server setup (which many of our clients' setups are via
VMware, currently0, this would not make a difference, since there is no
other host to migrate to anyway. Son in those cases, not much changes.
For multi-server setups, we have two choices:
1.) Forgo the virtual firewall and purchase a Lanner or similar
hardware to install the firewall onto. Since a multi-server setup (at
least two server + SAN) typically runs a minimum of $10K-$15K in
hardware alone, an addition $300 or so for the Lanner (or similar
hardware) would not increase the overall cost of the project in a
significant way. (This option could of course be used in a
single-server setup as well, but hardware cost is usually more of a
factor with these setups for our clients)
2.) Setup a firewall guest on two of the hosts, and configure them in
an active-passive fashion. As long as both of the hosts with the
firewall VMs do not go down at the same time, then there should not be
an issue. If a host with a firewall VM goes down, the other firewall VM
will take over.
So, those are the work-arounds that we have come up with (nothing new
to anyone here, I am sure) until such time as OpenVSwitch gets adopted
into oVirt/RHEV as either an easy-to-enable option, or as the
standard/default switch.
Anyway, this post was really more of a closure post so anyone coming
across this thread in the future does not wonder what the ultimate
outcome was. :-)
-Alan
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
