[libvirt] IPv6 migration
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? Would it be better to auto-add this flag for numeric addresses, or just check for them both in the Prepare phase on the dest (and set listen_addr accordingly) and before connecting from the source, so we don't use the IPv4 hint (in case we wanted to use the partial fix for just numeric addresses for older libvirt). Jan Bug: https://bugzilla.redhat.com/show_bug.cgi?id=846013 v3: https://www.redhat.com/archives/libvir-list/2013-February/msg01379.html unfortunately I posted v3 before reading John's feedback to v1: https://www.redhat.com/archives/libvir-list/2013-February/msg01059.html
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.
Would it be better to auto-add this flag for numeric addresses, or just check for them both in the Prepare phase on the dest (and set listen_addr accordingly) and before connecting from the source, so we don't use the IPv4 hint (in case we wanted to use the partial fix for just numeric addresses for older libvirt).
I don't think auto-adding the flag is wise. Jirka
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 :|
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...?
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? Jan
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 :|
participants (3)
-
Daniel P. Berrange -
Jiri Denemark -
Ján Tomko