[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Network device abstraction aka virtual switch - V3



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 :-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]