From: Juan Quintela <quintela@redhat.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH 0/6] Refactor autostart of machines
Date: Wed, 19 Aug 2009 04:07:43 +0200 [thread overview]
Message-ID: <cover.1250646771.git.quintela@redhat.com> (raw)
Hi
This series add several things:
- delay sighandler_setup(). Current code hangs until you are using
telnet:....,server for instance. With this change, ^C while waiting
for telnet program to conect will kill the vm.
- refactor autostart behaviour:
* incoming migration: depend of -S parameter
* loadvm from command line: depend of -S parameter
* loadvm from monitor: same state that the vm it replaces
* no loadvm no incoming: depend of -S parameter
I tested, and all combinations works this way.
- refactor do_loadvm(). do_loadvm() don't return errors, if there were
any error while loading a vm, it would obey autostart value independently of
the errors. Now it will never start a vm that had erros while loading.
- if you type "cont" in the monitor of one machine just migrated, qemu will
proceed with the start, with the consequent corruption. Last patch forbides
to continue a vm that has just been migrated with an error message. If you
load a new vm, flag is reset. This "bug/feature" was reported as a bug
by users.
One comment:
- Is there really a good idea to allow loadvm in the monitor even if the current
vm is running? I think that allowing loadvm command to only works when vm is
stopped is a better idea. what does everybody else thinks?
Comments?
Later, Juan.
Juan Quintela (6):
Delay sighandler_setup()
We want to autostart on incoming conections Once there, indent
surrounded code in qemu style
split do_loadvm() into do_loadvm() and load_vmstate()
move do_loadvm() to monitor.c
make load_vmstate() return errors
Continue a migrated vm is a bad idea
migration.c | 1 +
monitor.c | 16 ++++++++++++++++
savevm.c | 19 +++++++------------
sysemu.h | 3 ++-
vl.c | 24 +++++++++++++-----------
5 files changed, 39 insertions(+), 24 deletions(-)
next reply other threads:[~2009-08-19 2:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 2:07 Juan Quintela [this message]
2009-08-19 2:07 ` [Qemu-devel] [PATCH 1/6] Delay sighandler_setup() Juan Quintela
2009-08-19 2:07 ` [Qemu-devel] [PATCH 2/6] We want to autostart on incoming conections Once there, indent surrounded code in qemu style Juan Quintela
2009-08-19 6:56 ` [Qemu-devel] " Paolo Bonzini
2009-08-19 9:18 ` Juan Quintela
2009-08-19 10:54 ` Paolo Bonzini
2009-08-19 2:07 ` [Qemu-devel] [PATCH 3/6] split do_loadvm() into do_loadvm() and load_vmstate() Juan Quintela
2009-08-19 2:07 ` [Qemu-devel] [PATCH 4/6] move do_loadvm() to monitor.c Juan Quintela
2009-08-19 2:07 ` [Qemu-devel] [PATCH 5/6] make load_vmstate() return errors Juan Quintela
2009-08-19 2:07 ` [Qemu-devel] [PATCH 6/6] Continue a migrated vm is a bad idea Juan Quintela
2009-08-20 8:40 ` Avi Kivity
2009-08-20 9:10 ` [Qemu-devel] " Juan Quintela
2009-08-20 9:28 ` Avi Kivity
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=cover.1250646771.git.quintela@redhat.com \
--to=quintela@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).