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 :-)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list