From patchwork Thu Jun 3 21:41:48 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Yoshiaki Tamura X-Patchwork-Id: 54526 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 76414B7D30 for ; Fri, 4 Jun 2010 07:43:42 +1000 (EST) Received: from localhost ([127.0.0.1]:37540 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKICR-0002mo-CM for incoming@patchwork.ozlabs.org; Thu, 03 Jun 2010 17:43:39 -0400 Received: from [140.186.70.92] (port=46805 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKIAh-0001oF-Hf for qemu-devel@nongnu.org; Thu, 03 Jun 2010 17:41:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKIAg-00069o-7z for qemu-devel@nongnu.org; Thu, 03 Jun 2010 17:41:51 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:51324) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKIAg-00069h-4r for qemu-devel@nongnu.org; Thu, 03 Jun 2010 17:41:50 -0400 Received: by gyd5 with SMTP id 5so495874gyd.4 for ; Thu, 03 Jun 2010 14:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Dme/9LfEZCwTpLYSJd7+1/ZQnwLI6S7CIyU5ynmCGGE=; b=UGYlpf5idh3RJos3RJFNXhfXHzGv+y0MrQVJ09rz9Tzl0/CCEJ0NoA7V+t3zaaLNxC YWtiQbP2s01XS5/h+tSLCCvTkt0wu/JLrBehCBucb0OKNyXWjoyhrtM2ygfwA2GYuJgb 9yiYzRiQwxIG7IARnZCj93F7tU1HuKzALefbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mQFLPdH1ZapJibXclBQgmzo4g5ylHOV9aGWbCzXm4/cAknpANzzmOucTHn6GdVSlk/ mlI7TvjWSuCvINsPucg5X2mmQHKTs8t+WkKBTLBWsWWuBtwVtZImFtKFAtGLZ6gsKp6P 4M9qObBPtSqSCwWTby98ZDa1txgKEbH5LN5Bo= MIME-Version: 1.0 Received: by 10.101.169.36 with SMTP id w36mr11516943ano.66.1275601308223; Thu, 03 Jun 2010 14:41:48 -0700 (PDT) Received: by 10.100.105.14 with HTTP; Thu, 3 Jun 2010 14:41:48 -0700 (PDT) In-Reply-To: <20100603181944.2106.17684.malonedeb@soybean.canonical.com> References: <20100603181944.2106.17684.malonedeb@soybean.canonical.com> <20100603181944.2106.17684.malonedeb@soybean.canonical.com> Date: Fri, 4 Jun 2010 06:41:48 +0900 X-Google-Sender-Auth: LLKdm1P1Z55euLJyOh-fQWn-oyw Message-ID: Subject: Re: [Qemu-devel] [Bug 589315] [NEW] qemu: Improve error reporting when migration can't connect From: Yoshiaki Tamura To: Bug 589315 <589315@bugs.launchpad.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: qemu-devel@nongnu.org, crobinso@redhat.com X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 2010/6/4 Cole Robinson : > Public bug reported: > > Tested with upstream qemu as of Jun 3 2010 > > If the source qemu instance can't connect to the migration destination (say > there is no listening QEMU instance, or port is blocked by a firewall), all we > get is info migrate -> Migration status: failed. This is all we have to report > back to libvirt users if their firewall is misconfigured, which is crappy. > > Ideally, if we can't connect, migration would fail immediately with a relevant > message and strerror(). More info from 'info migrate' would be nice too, no > idea how this will play with QMP though. > > As a slightly related issue, try entering > > migrate tcp:127.0.0.0:6000 > > We get a 'migration failed' error, and then the monitor hangs! > > ** Affects: qemu >     Importance: Undecided >         Status: New > > -- > qemu: Improve error reporting when migration can't connect > https://bugs.launchpad.net/bugs/589315 > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > > Status in QEMU: New > > Bug description: > Tested with upstream qemu as of Jun 3 2010 > > If the source qemu instance can't connect to the migration destination (say > there is no listening QEMU instance, or port is blocked by a firewall), all we > get is info migrate -> Migration status: failed. This is all we have to report > back to libvirt users if their firewall is misconfigured, which is crappy. > > Ideally, if we can't connect, migration would fail immediately with a relevant > message and strerror(). More info from 'info migrate' would be nice too, no > idea how this will play with QMP though. > > As a slightly related issue, try entering > > migrate tcp:127.0.0.0:6000 > > We get a 'migration failed' error, and then the monitor hangs! > Hi, Does the following patch fix the problem? Thanks, Yoshi [PATCH] migration-tcp: call migrate_fd_error() instead of close() and free(). This patch fixes the following error report. When changing migration-tcp.c to call migrate_fd_error() instead of close() and free() by itself, monitor is resumed, and returns allocated mig_state is set to current_migration in migration.c allows us to print "info migrate". Reported-by: Cole Robinson Signed-off-by: Yoshiaki Tamura --- qemu: Improve error reporting when migration can't connect https://bugs.launchpad.net/bugs/589315 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Tested with upstream qemu as of Jun 3 2010 If the source qemu instance can't connect to the migration destination (say there is no listening QEMU instance, or port is blocked by a firewall), all we get is info migrate -> Migration status: failed. This is all we have to report back to libvirt users if their firewall is misconfigured, which is crappy. Ideally, if we can't connect, migration would fail immediately with a relevant message and strerror(). More info from 'info migrate' would be nice too, no idea how this will play with QMP though. As a slightly related issue, try entering migrate tcp:127.0.0.0:6000 We get a 'migration failed' error, and then the monitor hangs! -- --- migration-tcp.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/migration-tcp.c b/migration-tcp.c index 95ce722..43af2e0 100644 --- a/migration-tcp.c +++ b/migration-tcp.c @@ -128,9 +128,7 @@ MigrationState *tcp_start_outgoing_migration(Monitor *mon, if (ret < 0 && ret != -EINPROGRESS && ret != -EWOULDBLOCK) { DPRINTF("connect failed\n"); - close(s->fd); - qemu_free(s); - return NULL; + migrate_fd_error(s); } else if (ret >= 0) migrate_fd_connect(s);