summary refs log tree commit diff stats
path: root/python/qemu/utils/qemu_ga_client.py
diff options
context:
space:
mode:
authorPeter Xu <peterx@redhat.com>2022-03-01 16:39:10 +0800
committerDr. David Alan Gilbert <dgilbert@redhat.com>2022-03-02 18:20:45 +0000
commitd5c8f2afe866b84ce9372d5c52c130d1e457fc95 (patch)
tree52582a3f6f0126b964f004d0676b87c6fa812a94 /python/qemu/utils/qemu_ga_client.py
parent755e8d7cb6ce2ba62d282ffbb367de391fe0cc3d (diff)
downloadfocaccia-qemu-d5c8f2afe866b84ce9372d5c52c130d1e457fc95.tar.gz
focaccia-qemu-d5c8f2afe866b84ce9372d5c52c130d1e457fc95.zip
migration: Enlarge postcopy recovery to capture !-EIO too
We used to have quite a few places making sure -EIO happened and that's the
only way to trigger postcopy recovery.  That's based on the assumption that
we'll only return -EIO for channel issues.

It'll work in 99.99% cases but logically that won't cover some corner cases.
One example is e.g. ram_block_from_stream() could fail with an interrupted
network, then -EINVAL will be returned instead of -EIO.

I remembered Dave Gilbert pointed that out before, but somehow this is
overlooked.  Neither did I encounter anything outside the -EIO error.

However we'd better touch that up before it triggers a rare VM data loss during
live migrating.

To cover as much those cases as possible, remove the -EIO restriction on
triggering the postcopy recovery, because even if it's not a channel failure,
we can't do anything better than halting QEMU anyway - the corpse of the
process may even be used by a good hand to dig out useful memory regions, or
the admin could simply kill the process later on.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20220301083925.33483-11-peterx@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Diffstat (limited to 'python/qemu/utils/qemu_ga_client.py')
0 files changed, 0 insertions, 0 deletions