(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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list