[libvirt] Network device abstraction aka virtual switch - V3

Laine Stump laine at laine.org
Tue Jun 21 12:29:21 UTC 2011

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

More information about the libvir-list mailing list