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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel