[Users] why ovirt does not support NAT network

Dan Kenigsberg danken at redhat.com
Wed Mar 13 09:10:54 UTC 2013


On Wed, Mar 13, 2013 at 01:09:16AM +0200, Itamar Heim wrote:
> On 03/11/2013 05:16 AM, Mark Wu wrote:
> >On 03/08/2013 05:16 AM, Dan Kenigsberg wrote:
> >>On Thu, Mar 07, 2013 at 03:57:49PM +0100, Adrian Gibanel wrote:
> >>>Just in case it might help you please check:
> >>>
> >>>http://lists.ovirt.org/pipermail/users/2012-April/001751.html
> >>This is almost 1 year old, but I did not notice it yet. I love the
> >>detailed solution!
> >+1 on NAT network.  Except that it can save ip address, it also could
> >reduce the external physical switch's pressure on mac table. Because the
> >VM's
> >mac address is invisible to external switch.
> >
> >But there're two limitations of NAT network compared with physically
> >bridged network:
> >1. The VMs attached to the same NAT network, but on different hosts
> >can't hear each other.  It could be resolved by constructing a tunnel or
> >tunnels
> >     among the hosts in the same cluster and centralizing the mac
> >address management of dnsmasq on ovirt engine.
> >
> >2. The VMs in NAT network are hidden behind the host. The external host
> >can't initiate a connection to the VM.  I think it's fine for a desktop VM.\
> >For a server VM, it can't be resolved by add a DNAT rule on demand. It's
> >similar to the 'floating ip address' in quantum.
> 
> also need to remember live migration will probably not work with NAT.

That's why I consider this as an option to host-local networks.

> how would floating IP work? wouldn't you need to map it 1:1 with the
> NAT'd IP?
> 
> >
> >////
> >>
> >>Yes, the rant there, about ovirt network being tightly-coupled with a
> >>physical interface, is 100% justified. I'm trying to address some of
> >>that inhttp://www.ovirt.org/Features/Nicless_Network  but it's a long
> >>way to go.



More information about the Users mailing list