When doing a live migration of a Xen guest with libxl, the images for
block devices are locked by the original QEMU process, and this prevent
the QEMU at the destination to take the lock and the migration fail.
From QEMU point of view, once the RAM of a domain is migrated, there is
two QMP commands, "stop" then "xen-save-devices-state", at which point a
new QEMU is spawned at the destination.
Release locks in "xen-save-devices-state" so the destination can takes
them.
Signed-off-by: Anthony PERARD <anthony.per...@citrix.com>
---
CCing libxl maintainers:
CC: Ian Jackson <ian.jack...@eu.citrix.com>
CC: Wei Liu <wei.l...@citrix.com>
---
migration/savevm.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index 4a88228614..69d904c179 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2263,6 +2263,20 @@ void qmp_xen_save_devices_state(const char *filename,
Error **errp)
qemu_fclose(f);
if (ret < 0) {
error_setg(errp, QERR_IO_ERROR);
+ } else {
+ /* libxl calls the QMP command "stop" before calling
+ * "xen-save-devices-state" and in case of migration failure, libxl
+ * would call "cont".
+ * So call bdrv_inactivate_all (release locks) here to let the other
+ * side of the migration take controle of the images.
+ */
+ if (!saved_vm_running) {
+ ret = bdrv_inactivate_all();
+ if (ret) {
+ error_setg(errp, "%s: bdrv_inactivate_all() failed (%d)",
+ __func__, ret);
+ }
+ }
}
the_end:
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
