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. _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
