From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axuRU-00053R-1j for qemu-devel@nongnu.org; Wed, 04 May 2016 06:54:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axuRI-0000fK-Ak for qemu-devel@nongnu.org; Wed, 04 May 2016 06:54:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axuRI-0000ah-5U for qemu-devel@nongnu.org; Wed, 04 May 2016 06:53:56 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D6C8B7F6B1 for ; Wed, 4 May 2016 10:53:44 +0000 (UTC) From: Juan Quintela In-Reply-To: <1461751518-12128-11-git-send-email-berrange@redhat.com> (Daniel P. Berrange's message of "Wed, 27 Apr 2016 11:05:00 +0100") References: <1461751518-12128-1-git-send-email-berrange@redhat.com> <1461751518-12128-11-git-send-email-berrange@redhat.com> Reply-To: quintela@redhat.com Date: Wed, 04 May 2016 12:53:42 +0200 Message-ID: <874maegkll.fsf@emacs.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v6 for-2.7 10/28] migration: add reporting of errors for outgoing migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Amit Shah "Daniel P. Berrange" wrote: > Currently if an application initiates an outgoing migration, > it may or may not, get an error reported back on failure. If > the error occurs synchronously to the 'migrate' command > execution, the client app will see the error message. This > is the case for DNS lookup failures. If the error occurs > asynchronously to the monitor command though, the error > will be thrown away and the client left guessing about > what went wrong. This is the case for failure to connect > to the TCP server (eg due to wrong port, or firewall > rules, or other similar errors). > > In the future we'll be adding more scope for errors to > happen asynchronously with the TLS protocol handshake. > TLS errors are hard to diagnose even when they are well > reported, so discarding errors entirely will make it > impossible to debug TLS connection problems. > > Management apps which do migration are already using > 'query-migrate' / 'info migrate' to check up on progress > of background migration operations and to see their end > status. This is a fine place to also include the error > message when things go wrong. > > This patch thus adds an 'error-desc' field to the > MigrationInfo struct, which will be populated when > the 'status' is set to 'failed': > > (qemu) migrate -d tcp:localhost:9001 > (qemu) info migrate > capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off > Migration status: failed (Error connecting to socket: Connection refused) > total time: 0 milliseconds > > In the HMP, when doing non-detached migration, it is > also possible to display this error message directly > to the app. > > (qemu) migrate tcp:localhost:9001 > Error connecting to socket: Connection refused > > Or with QMP > > { > "execute": "query-migrate", > "arguments": {} > } > { > "return": { > "status": "failed", > "error-desc": "address resolution failed for myhost:9000: No address associated with hostname" > } > } > > Reviewed-by: Dr. David Alan Gilbert > Signed-off-by: Daniel P. Berrange > --- Reviewed-by: Juan Quintela