[Spice-devel] [vdsm] [RFC] ipv6 support of vdsm

[David Jaša]

Hi,

huntxu píše v Čt 08. 11. 2012 v 18:58 +0800:
> Hi, folks.
> 
> Recently I am considering to implement ipv6 support for vdsm. First of all  
> I
> would like to know whether there is already someone working on this  
> feature.
> If so, I might do something to help, however, if not, I would try to  
> implement
> it with suggestions from this discussion.
> 
> With ipv6 support vdsm is supposed to work properly in:
>      * mixed environment, in which ipv4 and ipv6 addresses coexist
>      * ipv6-pure environment
> 
> My idea is:
> 
> 1) Provide a mechanism to setup ipv6 address configuration of a host via
> XMLRPC/RestAPI. This would be done in the current ConfigNetwork module by
> modifying the network-scripts/ifcfg-* of the devices. Thus the host is
> able to access ipv6 network (with correct configuration).
> 
> 2) For incoming spice connections, qemu is able to listen to ipv6 address,
> so we use a boolean option "spice_use_ipv6" which indicates whether qemu
> should listen to incoming ipv6 or ipv4 connections.

beware that this is a can of worms:

1) spice server can not really listen on v6 only, you can only choose
between v4 (default) or v6+v4 (if you set -spice ipv6,... or -spice
addr=::,... and its libvirt domain xml equivalents) because "-spice
ipv6" is just an equivalent of "-spice addr=::", not of IPV6_V6ONLY

2) spice server does not know or use SO_BINDTODEVICE

3) spice server can bind to a single IP address only:
https://bugzilla.redhat.com/show_bug.cgi?id=787259

points 2 + 3 combined have several unfortunate consequences:

1. you can't have separate display network and mixed ipv4 + ipv6
spice-server at once -- IIRC that's most of current RHEV deployments

2. you can't have spice-server listening on multiple ipv6 addresses at
once - that's requirement for essentially any serious ipv6 use

3. even if 1. and 2. would be resolved, the existing VM displays would
break if there is any network configuration change (that is much more
probable event than in ipv4 because of different network configuration
mechanisms as far as I know -- but Pavel could correct me here).
Using SO_BINDTODEVICE and bind to "::" (ipv6 wildcard) sounds like the
best option here but there is a catch: this option is supported by linux
kernel for root-processes only but qemu actually runs under regular
"qemu" user...

All of these make current spice ipv6 support limited to quite small
subset of real-world use cases, a kind of proof-of-concept one. Pavel
(CCd) could surely trow in several more examples of what can go wrong.

Given all of these, I'd leave spice part as-is for now till these
details are at least decided how they should look like...

David

> 
> 3) Make the connection with ovirt-engine(management connection) also ipv6-
> compatible. This requires modifying both XMLRPC and RestAPI servers to make
> them able to bind to the ipv6 address of the host. Also we need another
> boolean option "use_ipv6" to indicate what is the ip version of the  
> management
> connection.
> 
> 4) Regarding the register process, all is the same with the current  
> workflow,
> except for if we use ipv6 to register, we should firstly set "use_ipv6" to
> True, then XMLRPC and RestAPI servers would be listening on the ipv6  
> address
> after vdsm restarts.
> 
> 5) The management connection is supposed to be able to switch between ipv4
> and ipv6 on the fly (when host is under maintenance and with proper network
> configuration of the host). This requires another vdsm API.
> 
> Suggestions are always welcome. Thanks.
> 

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24