On Tue, Mar 19, 2013 at 03:21:31PM +0100, Jiri Denemark wrote: > On Mon, Mar 11, 2013 at 19:40:52 +0100, Ján Tomko wrote: > > Hello. > > > > We can only tell QEMU on the destination to listen either on IPv6 or on > > IPv4. > > > > If we're supplied with a numeric v6 address, that's the only thing we > > need to know to set the listen address to [::]. > > > > For hostnames, we can either assume this based on how it resolves by > > default on the destination (we keep trying all the resolved addresses on > > the source, but this might break a few cases), which John found > > disgusting, so that leaves user input: > > > > How about a VIR_DOMAIN_MIGRATE_IPV6 flag, depending on which we set the > > listen address on the destination and creating a new function > > virNetSocketNewConnectTCPHints, where we would add IPv4/IPv6 hint > > based on the presence/absence of this flag? > > Yeah, I think using an explicit flag would be the best approach. As we > learnt several times, implementing automagic behavior is too fragile and > leads to ugly code and confusion. IIUC, we would tell QEMU to listen on > :: iff either migrateuri uses IPv6 address explicitly or > VIR_DOMAIN_MIGRATE_IPV6 flag is set. In all other cases, 0.0.0.0 address > will be passed to QEMU. In other words, unless a user takes an explicit > action, migration will use IPv4 regardless on libvirt version. That would mean that migration is broken by default in an IPv6 only environment, so I don't think that is an satisfactory approach. We should be checking whether. Listening on '[::]' means that QEMU will accept connections on *both* IPv4 and IPv6, if configured with dual-stack. So if IPv6 is present on the target host, it is entirely reasonable to default to '[::]' if given a hostname. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list