[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 5d6c59: migration, xen: Fix block image lock

From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 5d6c59: migration, xen: Fix block image lock issue on live...
Date: Thu, 23 Nov 2017 07:07:08 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 5d6c599fe1d69a1bf8c5c4d3c58be2b31cd625ad
  Author: Anthony PERARD <address@hidden>
  Date:   2017-11-21 (Tue, 21 Nov 2017)

  Changed paths:
    M migration/savevm.c
    M qapi/migration.json

  Log Message:
  migration, xen: Fix block image lock issue on live migration

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, if it's a live migration.

This patch add the "live" parameter to "xen-save-devices-state" which
default to true so older version of libxenlight can work with newer
version of QEMU.

Signed-off-by: Anthony PERARD <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Signed-off-by: Juan Quintela <address@hidden>

  Commit: acab30b85db0885ab161aff4c83c550628f6d8ca
  Author: Daniel Henrique Barboza <address@hidden>
  Date:   2017-11-22 (Wed, 22 Nov 2017)

  Changed paths:
    M migration/ram.c

  Log Message:
  migration/ram.c: do not set 'postcopy_running' in POSTCOPY_INCOMING_END

When migrating a VM with 'migrate_set_capability postcopy-ram on'
a postcopy_state is set during the process, ending up with the
state POSTCOPY_INCOMING_END when the migration is over. This
postcopy_state is taken into account inside ram_load to check
how it will load the memory pages. This same ram_load is called when
in a loadvm command.

Inside ram_load, the logic to see if we're at postcopy_running state

postcopy_running = postcopy_state_get() >= POSTCOPY_INCOMING_LISTENING

postcopy_state_get() returns this enum type:

typedef enum {
} PostcopyState;

In the case where ram_load is executed and postcopy_state is
POSTCOPY_INCOMING_END, postcopy_running will be set to 'true' and
ram_load will behave like a postcopy is in progress. This scenario isn't
achievable in a migration but it is reproducible when executing
savevm/loadvm after migrating with 'postcopy-ram on', causing loadvm
to fail with Error -22:


(qemu) migrate_set_capability postcopy-ram on
(qemu) migrate tcp:


(qemu) migrate_set_capability postcopy-ram on
ubuntu1704-intel login:
Ubuntu 17.04 ubuntu1704-intel ttyS0

ubuntu1704-intel login: (qemu)
(qemu) savevm test1
(qemu) loadvm test1
Unknown combination of migration flags: 0x4 (postcopy mode)
error while loading state for instance 0x0 of device 'ram'
Error -22 while loading VM state

This patch fixes this problem by changing the existing logic for
postcopy_advised and postcopy_running in ram_load, making them
'false' if we're at POSTCOPY_INCOMING_END state.

Signed-off-by: Daniel Henrique Barboza <address@hidden>
CC: Juan Quintela <address@hidden>
CC: Dr. David Alan Gilbert <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Reported-by: Balamuruhan S <address@hidden>
Signed-off-by: Juan Quintela <address@hidden>

  Commit: 54c85bebb59f73aa87b5db59a00a16a500a3d642
  Author: Peter Maydell <address@hidden>
  Date:   2017-11-23 (Thu, 23 Nov 2017)

  Changed paths:
    M migration/ram.c
    M migration/savevm.c
    M qapi/migration.json

  Log Message:
  Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20171122' 
into staging

migration/next for 20171122

# gpg: Signature made Wed 22 Nov 2017 08:43:13 GMT
# gpg:                using RSA key 0xF487EF185872D723
# gpg: Good signature from "Juan Quintela <address@hidden>"
# gpg:                 aka "Juan Quintela <address@hidden>"
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03  4B82 F487 EF18 5872 D723

* remotes/juanquintela/tags/migration/20171122:
  migration/ram.c: do not set 'postcopy_running' in POSTCOPY_INCOMING_END
  migration, xen: Fix block image lock issue on live migration

Signed-off-by: Peter Maydell <address@hidden>

Compare: https://github.com/qemu/qemu/compare/1b89975d420c...54c85bebb59f

reply via email to

[Prev in Thread] Current Thread [Next in Thread]