Re: [Qemu-devel] [PATCH 5/6] migration: Now set the migration uri

[Juan Quintela <quintela@redhat.com>]

"Daniel P. Berrange" <berrange@redhat.com> wrote:
> On Wed, Nov 22, 2017 at 12:54:58PM +0000, Daniel P. Berrange wrote:
>> On Wed, Nov 22, 2017 at 01:29:57PM +0100, Juan Quintela wrote:
>> > "Daniel P. Berrange" <berrange@redhat.com> wrote:
>> > > On Mon, Oct 30, 2017 at 12:21:11PM +0100, Juan Quintela wrote:

> > > This is bad as it is throwing away data that the original URI
>> > > had. In particular
>> > > you loose the 'ipv4=on|off' and 'ipv6=on|off' flags. If you need to keep the
>> > > original URI for later, then why not just keep the 'host_port' parameter that
>> > > was passed into this function instead of trying to reverse
>> > > engineeer the URI ?
>> > 
>> > I don't need the original uri anymore, this is the incoming side of
>> > migration, and we can only set that once, if migration fails, we need to
>> > restart qemu anymore.
>> > 
>> > I changed it to this:
>> > 
>> >             new_uri = g_strdup_printf("tcp:%s:%s%s%s", address->u.inet.host,
>> >                                       address->u.inet.port,
>> >                                       iaddr->has_ipv4 ? ",ipv4" : "",
>> >                                       iaddr->has_ipv6 ? ",ipv6" : "");
>> > 
>> > 
>> > Clearly, we don't care about the to= parameter.
>> > 
>> > The whole point of this exercise is that in destination, we use
>> > 
>> > -incoming tcp:0:0
>> > 
>> > and with the output of info migrate_parameters (uri) we are able to
>> > migrate to that place.  For rest of migration posibilities, there is no
>> > changes at all.
>> 
>> That doesn't work typically. When the incoming QEMU listens for connections,
>> by default it will listen on 0.0.0.0, or ::, so that's what the address
>> you're creating will contain.  You can't use 0.0.0.0 or :: in a connect()
>> call on the other side as that's a wildcard address that refers to "any 
>> valid IP address on the current host".
>> 
>> When you connect to the listening QEMU you need the actual IP address
>> of one (of the possibly many) NICs on the target host.  IOW, the only
>> time the listen address is useful is if you have told QEMU to listen on
>> a specific NIC's IP address, instead of the wildcard address.
>> 
>> This is the core reason why libvirt calls 'gethostname()' on the target
>> host to identify the primary IP address of the host, and uses that on the
>> source host to establish the connection.
>
> I should have said the port number info will still be useful (if you're
> using the dynamic port allocation), it is just the IP address that's not
> usable in general.

I gave up O:-)

I introduced tcp_port parameter, that is really what I wanted to know.
The test use case (the one that I am interested right now) is that I
do:

qemu-system-x86_64 ..... --incomping tcp:127.0.0.1:0

And I want to know the port that the destination gets to connect to it.
For migration, it don't really matters if we _also_ set the
address/ip/whatever it gets translated to, because it is not possible
right now to restart the migration incoming side (you need to restart
qemu for long and boring historic reasons).

So, I ended just adding:

+#
+# @tcp-port: Only used for tcp, to know what is the real port
+#                     (Since 2.12)
 #

And all the boilerplate code to access/setup this one.

BTW, I am not sure how  well the current code will work with a range of
ports, because we don't have a way to tell the source which one the
kernel/qemu decided to use O:-)

Later, Juan.