On 06/21/2011 05:06 AM, Neil Wilson wrote:

...

The current modes are:

<forward layer='network' mode='route|nat'/>

(in addition to not listing any mode, which equates to "isolated")

Here are suggested new modes: Has anybody considered the migration requirements of networks in this new layout?

If you move a machine attached to a 'route|nat' network to another Host you need to extend the network to the new Host and eventually you need to move the supporting processes that hand out the IP addresses/DNS addresses etc (if you're decommissioning a Host server for example).

If you try to start a copy of the network on the new host, then it generally clashes with the pre-existing routing

It would be useful to be able to extend a network onto another Host somehow and be able to migrate the supporting processes (DNSMasq, IP addressing, etc) between Hosts. (And obviously remove extensions as required as well).

This work has been targeted mainly at making migration work properly for guests using a host bridge or macvtap device to connect to the network; any new migration functionality for guests connected via libvirt virtual networks is, at this point, coincidental (and, as you point out, if the network on the new host is identical to the one on the old host (in particular if the new network uses the same address range for dhcp), there could be address clashes between guests; alternately, if they're *too* different (a different subnet, for example, or the IP address of the bridge is different), the guest would have no connectivity. In the future we may want to come up with a method of centralizing the address/DNS management of virtual networks on multiple machines, and linking those networks into a single subnet (perhaps via a L2 VPN tunnel, or a vlan host interface if the two hosts are on the same subnet), but that's beyond the scope of what we can do now. For right now, we just need to make sure we don't break current functionality.

Perhaps this suggests that the address and route management systems need separating from the definition of the bridge network. (There's no real reason why the address management systems couldn't be attached to macvtap and vepa networks as well as basic bridges).

True, just that they're not normally needed, because they've already been supplied by the physical network so that the hosts themselves can operate properly :-)