All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Andrew Farmer <andrewf@hq.newdream.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC: exit on incoming exec migrate failure
Date: Fri, 11 Dec 2009 21:19:35 +0000	[thread overview]
Message-ID: <20091211211935.GO21297@redhat.com> (raw)
In-Reply-To: <8994198D-0AA5-45C0-8A46-375BCA34E201@hq.newdream.net>

On Wed, Dec 09, 2009 at 01:10:18PM -0800, Andrew Farmer wrote:
> Right now, if an incoming migrate through exec fails, the qemu process 
> will end up chewing CPU indefinitely - it looks like it closes the 
> migration FD but doesn't remove its IO handler properly. An easy way 
> to reproduce this is to try launching with -incoming exec:/bin/false.
> This is obviously useless, but illustrates the issue handily.

I've hit this in real life too, with restore from a file containing
the saved state which had got corrupted/truncated. I only discovered
the failure when I wondered by QEMU was chewing 100% cpu

> One solution might be to retry the command on migrate failure, but that
> won't really help in all circumstances (for instance, if the migration 
> command is broken!), so it seems equally appropriate to just die if an 
> incoming exec migration fails. The patch is trivial, and follows - does
> this look sensible? (I'm new to qemu development, but trying to pick it up.)

It looks like a reasonable approach to me. If we carried on running, it would
be hard for apps to determine whether migration succeeded & thus QEMU is
running, or whether it failed and is just idling. By exiting we give the
management app/user the optional to retry simply by relaunching

> diff --git a/migration-exec.c b/migration-exec.c
> index c830669..0292c19 100644
> --- a/migration-exec.c
> +++ b/migration-exec.c
> @@ -114,7 +114,7 @@ static void exec_accept_incoming_migration(void *opaque)
>      ret = qemu_loadvm_state(f);
>      if (ret < 0) {
>          fprintf(stderr, "load of migration failed\n");
> -        goto err;
> +        exit(0);
>      }
>      qemu_announce_self();
>      dprintf("successfully loaded vm state\n");
> @@ -123,7 +123,6 @@ static void exec_accept_incoming_migration(void *opaque)
>      if (autostart)
>          vm_start();
>  
> -err:
>      qemu_fclose(f);
>  }


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

  reply	other threads:[~2009-12-11 21:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09 21:10 [Qemu-devel] RFC: exit on incoming exec migrate failure Andrew Farmer
2009-12-11 21:19 ` Daniel P. Berrange [this message]
2009-12-14 19:05   ` Andrew Farmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091211211935.GO21297@redhat.com \
    --to=berrange@redhat.com \
    --cc=andrewf@hq.newdream.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.