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