From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eK5Sm-00029Z-29 for qemu-devel@nongnu.org; Wed, 29 Nov 2017 11:43:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eK5Si-0005T0-VG for qemu-devel@nongnu.org; Wed, 29 Nov 2017 11:43:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40796) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eK5Si-0005Sc-Mm for qemu-devel@nongnu.org; Wed, 29 Nov 2017 11:43:52 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C6B125C25 for ; Wed, 29 Nov 2017 16:43:51 +0000 (UTC) From: Juan Quintela In-Reply-To: <20171122125840.GF29565@redhat.com> (Daniel P. Berrange's message of "Wed, 22 Nov 2017 12:58:40 +0000") References: <20171030112112.6952-1-quintela@redhat.com> <20171030112112.6952-6-quintela@redhat.com> <20171103100746.GC20155@redhat.com> <873756pkca.fsf@secure.mitica> <20171122125458.GE29565@redhat.com> <20171122125840.GF29565@redhat.com> Reply-To: quintela@redhat.com Date: Wed, 29 Nov 2017 17:43:35 +0100 Message-ID: <87609t9gso.fsf@secure.laptop> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 5/6] migration: Now set the migration uri List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: lvivier@redhat.com, qemu-devel@nongnu.org, peterx@redhat.com, dgilbert@redhat.com "Daniel P. Berrange" 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" 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.