On Thu, Mar 21, 2013 at 01:16:35PM +0100, Ján Tomko wrote: > On 03/21/2013 11:52 AM, Daniel P. Berrange wrote: > > 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: > ... > >> > >> 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. > > Checking whether...? IPv6 is present. > > > > > 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. > > I thought this might break IPv4 migration on FreeBSD, but QEMU turns > IPV6_V6ONLY off since the support of IPv6 migration in 1.1. > > So this would only break migration with QEMU older than 1.1 and could be > worked around by specifying the IPv4 address in the migration URI? We know the QEMU version from the capabilities, so it should not need to break QEMU < 1.1 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