[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 5/6] migration: Now set the migration uri
From: |
Juan Quintela |
Subject: |
Re: [Qemu-devel] [PATCH 5/6] migration: Now set the migration uri |
Date: |
Wed, 29 Nov 2017 17:43:35 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
"Daniel P. Berrange" <address@hidden> 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" <address@hidden> 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.