diff options
author | Kevin Wolf <kwolf@redhat.com> | 2017-04-04 17:29:03 +0200 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2017-04-07 14:44:05 +0200 |
commit | d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a (patch) | |
tree | 69d406988e6ff392367c8703c331003257d5c76a /migration | |
parent | 5fe2339e6b09da7d6f48b9bef0f1a7360392b489 (diff) |
block: Ignore guest dev permissions during incoming migration
Usually guest devices don't like other writers to the same image, so
they use blk_set_perm() to prevent this from happening. In the migration
phase before the VM is actually running, though, they don't have a
problem with writes to the image. On the other hand, storage migration
needs to be able to write to the image in this phase, so the restrictive
blk_set_perm() call of qdev devices breaks it.
This patch flags all BlockBackends with a qdev device as
blk->disable_perm during incoming migration, which means that the
requested permissions are stored in the BlockBackend, but not actually
applied to its root node yet.
Once migration has finished and the VM should be resumed, the
permissions are applied. If they cannot be applied (e.g. because the NBD
server used for block migration hasn't been shut down), resuming the VM
fails.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Diffstat (limited to 'migration')
-rw-r--r-- | migration/migration.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/migration/migration.c b/migration/migration.c index 54060f749a..ad4036fdb1 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -349,6 +349,14 @@ static void process_incoming_migration_bh(void *opaque) exit(EXIT_FAILURE); } + /* If we get an error here, just don't restart the VM yet. */ + blk_resume_after_migration(&local_err); + if (local_err) { + error_free(local_err); + local_err = NULL; + autostart = false; + } + /* * This must happen after all error conditions are dealt with and * we're sure the VM is going to be running on this host. |