[libvirt] [PATCH] qemu: enable direct migration over IPv6

[Ján Tomko]

(Replying to myself to correct some mistakes)

On 02/26/13 11:56, Ján Tomko wrote:
> On 02/19/13 17:36, John Ferlan wrote:
>> On 02/15/2013 05:13 AM, Peter Krempa wrote:
>>> On 02/15/13 11:00, Ján Tomko wrote:
>>>>           }
>>>>       }
>>>>
>>>> +    if (getaddrinfo(hostname, NULL, NULL, &info)) {
>>>> +        virReportError(VIR_ERR_INTERNAL_ERROR,
>>>> +                       _("unable to get address info for %s"),
>>>> hostname);
>>>> +        goto cleanup;
>>>
>>> Isn't there a possibility to fall back on IPv4 if this fails to minimize
>>> the chance of regressing?
>>>
>>
>> Yeah - this is tricky for some of the reasons I listed above. It seems
>> we need a way to tell or force the target qemu to use one family style
>> over the other because that's what the source resolved to using.
> 
> Qemu does support ipv4 or ipv6 flags for hostnames. From a quick glance
> at the git history it seems it always has. Maybe we could always add the
> address family option to the migration URI to force this?

Wrong. It does support these options in inet_listen/inet_connect
functions, but it only uses these for migration since 1.1. For
inet_listen we either pass :: or 0.0.0.0 so there is no need for these
flags and the connection on the source is made by libvirt

> 
>>
>> Assuming I'm reading things correctly we are about to tell the target
>> qemu how to start and to listen over the "first" style of address we
>> found in the source hosts' list.  The source connect will use that
>> uri_out to perform the migration. The issue I can see becomes what if
>> the target (for some reason) doesn't support/have/use the family that
>> the host found first?  When it goes to start up a localhost port, it
>> will fail right?  Then what?
>>
> 
> No, the perform phase happens on the destination, but the result is

s/perform/prepare/

> still the same. If the families do not match (or they do match but they
> can't connect to each other via that family), migration will fail. Then
> the user either has to change the network configuration or specify the
> IP address directly.
> 

...

>>>> +    } else {
>>>> +        snprintf(migrateFrom, sizeof(migrateFrom),
>>>> +                 "tcp:0.0.0.0:%d", this_port);
>>>
>>> I thing this would be doable. Just do IPv4 by default if the resolution
>>> fails.
>>>
>>
>> Hmm... which resolution fails do you mean?  Perhaps the "feature" needs
>> to be set/check some field that says the target qemu wants/desires IPv6;
>> otherwise, always fall back to use IPv4.
>>
> 
> If the hostname specified by the user can only be resolved on the
> source, migration still works, but erroring out on getaddrinfo failure
> would break it.
> 
> 
> We can definitely tell qemu to listen on v4/v6 if we received an IP
> address. As for hostnames, we can either guess it from how it resolves
> on the source, destination or get the input from the user. Maybe we
> could add a migration flag for this and add ipv4 or ipv6 option to the
> migration URI for qemu based on the presence/absence of this flag. Or
> only do IPv6 migration if a URI with a v6 address or tcp6: scheme was
> present?

Since we don't pass the URI to qemu, adding the ipv{4,6} options makes
no sense.