On Mon, Dec 13, 2010 at 1:20 PM, Apollon Oikonomopoulos
<[email protected]> wrote:
> KVM networking configuration refactoring
>
> Current state and shortcomings
>
> Currently, Ganeti uses KVM's builtin per-NIC “script=” option to configure tap
> devices. This approach generally works, however there are a number of
> shortcomings:
>
>  a) The tap interface name is not known beforehand; furthermore, the script
>    does not know which NIC it is called for, which rules out passing the whole
>    instance configuration as environment variables to KVM and from there to
>    the script. Thus, Ganeti has to write out an ifup script per instance
>    NIC to disk, having among others the side-effect that /tmp cannot be
>    mounted noexec.
>
>  b) There is no easy way (other than getting it from the script) for the
>    admin to know which tap device(s) are attached to a running KVM instance.
>
>  c) Currently no action may be run during an instance's networking shutdown;
>    using KVMs downscript support with either “pool” or “user” security models
>    is probably pointless as the downscript will be run as an unprivileged 
> user.
>
>  d) The most significant issue perhaps is that live migration of routed
>    instances is broken; KVM configures the network interface right away as
>    it is spawned, even in “incoming” mode. This is harmless for bridged
>    instances, however in routed instances this means that the instance's IP
>    addresses are announced (either directly through e.g. an IGP, or indirectly
>    through Proxy-ARP/proxy-NDP) by two nodes during the whole migration
>    process, causing possible network disruption for the migrated instance.
>

I couldn't agree more with the problems you've pointed out. I've taken
a look at the other patches and they look good to me, although  as you
said, some features are missing. When you send a more complete version
I will be happy to test it out.

Regards,

Miguel

Reply via email to