If migration failed in migrate_fd_put_buffer, the monitor may have been
resumed not only in the error path of that function but also once again
in migrate_fd_put_ready which is called unconditionally by
migrate_fd_connect.
Fix this by establishing a cleaner policy: the monitor shall be resumed
when the migration file is closed, either via callback
(migrate_fd_close) or in migrate_fd_cleanup if no file is open (i.e. no
callback invoked).
Reported-By: Michael Tokarev <mjt@tls.msk.ru>
Tested-By: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This allows to pass additional information to the notifier callback
which is useful if sender and receiver do not share any other distinct
data structure.
Will be used first for the clock reset notifier.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Define and use dedicated constants for vm_stop reasons, they actually
have nothing to do with the EXCP_* defines used so far. At this chance,
specify more detailed reasons so that VM state change handlers can
evaluate them.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
This patch adds functions to register and unregister notifiers for
migration state changes and a function to query the migration state.
The notifier is called on every state change. Once after establishing a
new migration object (which is in active state then) and once when the
state changes from active to completed, canceled or error.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The no_migrate save state flag is currently only checked in the
last phase of migration. This means that we potentially waste
a lot of time and bandwidth with the live state handlers before
we ever check the no_migrate flags. The error message printed
when we catch a non-migratable device doesn't get printed for
a detached migration. And, no_migrate does nothing to prevent
an incoming migration to a target that includes a non-migratable
device. This attempts to fix all of these.
One notable difference in behavior is that an outgoing migration
now checks for non-migratable devices before ever connecting to
the target system. This means the target will remain listening
rather than exit from failure.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There's no need to flush requests after vmstop
as vmstop does it for us automatically now.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Jason Wang <jasowang@redhat.com>
I'd like to disable bandwidth limit or make it very high,
Use int64_t all over to make values >= 4g work.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Jason Wang <jasowang@redhat.com>
Clarify default value of MB in migration speed argument in monitor, if
no suffix is specified. This differ from previous default of bytes,
but is consistent with the rest of the places where we accept a size
argument.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If ->write fails, declare migration status as MIG_STATE_ERROR.
Also, in buffered_file.c, ->close the object in case of an
error.
Fixes "migrate -d "exec:dd of=file", where dd fails to open file.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When a 'cont' is issued on a VM that's just waiting for an incoming
migration, the VM reboots and boots into the guest, possibly corrupting
its storage since it could be shared with another VM running elsewhere.
Ensure that a VM started with '-incoming' is only run when an incoming
migration successfully completes.
A new qerror, QERR_MIGRATION_EXPECTED, is added to signal that 'cont'
failed due to no incoming migration has been attempted yet.
Reported-by: Laine Stump <laine@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Historically, user monitor arguments beginning with '-' (eg. '-f')
were passed as integers down to handlers.
I've maintained this behavior in the new monitor because we didn't
have a boolean type at the very beginning of QMP. Today we have it
and this behavior is causing trouble to QMP's argument checker.
This commit fixes the problem by doing the following changes:
1. User Monitor
Before: the optional arg was represented as a QInt, we'd pass 1
down to handlers if the user specified the argument or
0 otherwise
This commit: the optional arg is represented as a QBool, we pass
true down to handlers if the user specified the
argument, otherwise _nothing_ is passed
2. QMP
Before: the client was required to pass the arg as QBool, but we'd
convert it to QInt internally. If the argument wasn't passed,
we'd pass 0 down
This commit: still require a QBool, but doesn't do any conversion and
doesn't pass any default value
3. Convert existing handlers (do_eject()/do_migrate()) to the new way
Before: Both handlers would expect a QInt value, either 0 or 1
This commit: Change the handlers to accept a QBool, they handle the
following cases:
A) true is passed: the option is enabled
B) false is passed: the option is disabled
C) nothing is passed: option not specified, use
default behavior
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Although there is no difference, other migration related code use
qemu_free(), and it should be better to be consistent.
Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch makes sure that if the exec: process exits with a non-zero return
status, we treat the migration as failed.
This fixes https://bugs.launchpad.net/qemu/+bug/391879
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Previous commit added QMP documentation to the qemu-monitor.hx
file, it's is a copy of this information.
While it's good to keep it near code, maintaining two copies of
the same information is too hard and has little benefit as we
don't expect client writers to consult the code to find how to
use a QMP command.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
While there I'm also dropping a unneeded else clause (the last
one in the function).
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The following handlers always succeed and hence can be converted
to cmd_new_ret() in the same commit.
- do_stop()
- do_quit()
- do_system_reset()
- do_system_powerdown()
- do_migrate_cancel()
- do_qmp_capabilities()
- do_migrate_set_speed()
- do_migrate_set_downtime()
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
It's not needed to check the return of qobject_from_jsonf()
anymore, as an assert() has been added there.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Before, it used type 's', which strips quotes and interprets escapes,
and is quite inappropriate for QMP.
Negative arguments are no flushed to zero. Before, they were cast to
uint32_t, which wrecked the sign.
Ridiculously large arguments including infinities are now rejected.
Before, they were interpreted as zero. Same for NaN.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Before, it used type 's', which strips quotes and interprets escapes,
and is quite inappropriate for QMP.
Negative arguments are no flushed to zero. Before, they were cast to
uint32_t, which wrecked the sign.
Ridiculously large arguments including infinities are now rejected.
Before, they were interpreted as zero. Same for NaN.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This reverts commit 3a4921047d.
From Luiz:
do_migrate_set_speed() accepts a suffix for the 'value' argument and this is
not good for QMP. We will have to add a new argument type to handle that and
this will have to wait for 0.13.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Return a QDict, which may contain up to more two QDicts, depending
on the type of migration we're performing.
IMPORTANT: as a QInt stores a int64_t integer, RAM values are going
to be stored as int64_t and not as uint64_t as they are today. If
this is a problem QInt will have to be changed.
This commit should not change user output.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In order to allow proper progress reporting to the monitor that
initiated the migration, forward the monitor reference through the
migration layer down to SaveLiveStateHandler.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Introduce qemu_savevm_state_cancel and inject a stage -1 to cancel a
live migration. This gives the involved subsystems a chance to clean up
dynamically allocated resources. Namely, the block migration layer can
now free its device descriptors and pending blocks.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu_fclose frees the passed file structure, but do_migrate_set_speed
may access it later on. Fix it by setting file NULL in
migrate_fd_cleanup and checking for this.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch introduces block migration called during live migration. Block
are being copied to the destination in an async way. First the code will
transfer the whole disk and then transfer all dirty blocks accumulted during
the migration.
Still need to improve transition from the iterative phase of migration to the
end phase. For now transition will take place when all blocks transfered once,
all the dirty blocks will be transfered during the end phase (guest is
suspended).
Changes from v4:
- Global variabels moved to a global state structure allocated dynamically.
- Minor coding style issues.
- Poll block.c for tracking of dirty blocks instead of manage it here.
Signed-off-by: Liran Schour <lirans@il.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Error is still directly printed, as we are only converting
regular output.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This commit ports command handlers that receive two arguments to use
the new monitor's dictionary.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This commit ports command handlers that receive one argument to use
the new monitor's dictionary.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This commit ports command handlers that receive no arguments to use
the new monitor's dictionary.
It might seem no sense to do this, as the handlers have no arguments,
but at the end of this porting work all handlers will have the same
structure.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Implement migration via unix sockets. While you can fake this using
exec and netcat, this involves forking another process and is
generally not very nice. By doing this directly in qemu, we can avoid
the copy through the external nc command. This is useful for
implementations (such as libvirt) that want to do "secure" migration;
we pipe the data on the sending side into the unix socket, libvirt
picks it up, encrypts it, and transports it, and then on the remote
side libvirt decrypts it, dumps it to another unix socket, and
feeds it into qemu.
The implementation is straightforward and looks very similar to
migration-exec.c and migration-tcp.c
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When we finish migration, there may be pending async io requests
in flight. If we don't flush it before stage3 starting, it might be
the case that the guest loses it.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
provide a monitor command to allow one to set the maximum
downtime he is willing to suffer during migration, in seconds.
"ms", "us", "ns" and "s" are accepted as modifiers.
This parameter will be used by ram_save_live() code to determine
a safe moment to enter stage 3
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Currently, we're entering migration's stage 3 when
a treshold of 10 pages remain to be transferred in the system.
This has hurt some users. However, any proposed threshold is
arbitrary by nature, and would only shift the annoyance.
The proposal of this patch is to define a max_downtime variable,
which represents the maximum downtime a migration user is willing
to suffer. Then, based on the bandwidth of last iteration, we
calculate how much data we can transfer in such a window of time.
Whenever we reach that value (or lower), we know is safe to enter
stage3.
This has largely improved the situation for me.
On localhost migrations, where one would expect things to go as
quickly as me running away from the duty of writting software for
windows, a kernel compile was enough to get the migration stuck.
It takes 20 ~ 30 iterations now.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
It may happen that the io-handler is still registered. That causes
select() to return with EBADF, not calling handlers for other fds.
The io-handler would be registered when (on the source) the whole state
was written but not yet flushed. For example when using QEMUFileBuffered,
(tcp-migration) there may be data left in a buffer waiting to be transferred.
In such a case buffered_close() calls buffered_flush() which calls
migrate_fd_put_buffer, which may, upon EAGAIN, register migrate_fd_put_notify
as a handler.
Signed-off-by: Uri Lublin <uril@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch allow us to call migrate_set_speed on running
migrations. This should allow mgmt tools to increase the allocated
bandwidth of a running migration if there is no progress, and they
really want the migration to succeed.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch augments info migrate output with status about:
* ram bytes remaining
* ram bytes transferred
* ram bytes total
This should be enough for management tools to realize
whether or not there is progress in migration. We can
add more information later on, if the need arrives
[v2: fixes bytes_transferred type]
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The migration code is non-blocking, designed for live migration.
Practically migrate_fd_put_buffer busy-loops trying to write, as
on many machines EWOULDBLOCK==EAGAIN (look in include/asm-generic/errno.h).
Signed-off-by: Uri Lublin <uril@redhat.com>
migrate_fd_put_ready() calls qemu_savevm_state_complete(),
but the later can fail.
If it happens, re-start the vm and propagate the error up
Based on a patch by Yaniv Kamay
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6997 c046a42c-6fe2-441c-8c8c-71466251a162
