Best practices for retrying QEMU P2P migrations

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



We’ve recently hit a number of failures on QEMU P2P live migrations
which appear to be caused by transient networking disconnects at
different points in the migration process. We would like to implement
smarter retry logic in our control plane to ensure such issues don’t
stall critical workflows. On the other hand, we cannot blindly retry
every failed migration because doing so greatly lengthens the time to
fail high level autmation when there is a real problem.

Are there currently any generally understood best practices for retrying
migrations from a control plane perspective?  Ideally we would decide
whether or not to retry based on error codes, but especially in the QEMU
P2P migration path many generic codes are returned. For example, see [1]
where we attempted to improve an error code for a likely retry-able set
of failure cases.



[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux