---
qapi-schema.json | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
+# Only for performance testing. (Since 2.x)
+#
+# @mc-rdma-copy: MC requires creating a local-memory checkpoint before
+# transmission to the destination. This requires heavy use of
+# memcpy() which dominates the processor pipeline. This option
+# makes use of *local* RDMA to perform the copy instead of the CPU.
+# Enabled by default only if the migration transport is RDMA.
+# Disabled by default otherwise. (Since 2.x)
How does that work? If I query migration capabilities before requesting
a migration, what state am I going to read? Is there coupling where I
would observe the state of this flag change merely because I did some
other action? And if so, then how do I know that explicitly setting
this flag won't be undone by similar coupling?
It sounds like you are describing a tri-state option (unspecified so
default to migration transport, explicitly disabled, explicitly
enabled); but that doesn't work for something that only lists boolean
capabilities. The only way around that is to have 2 separate
capabilities (one on whether to base decision on transport or to honor
override, and the other to provide the override value which is ignored
when defaulting by transport).
+#
+# @rdma-keepalive: RDMA connections do not timeout by themselves if a peer
+# has disconnected prematurely or failed. User-level keepalives
+# allow the migration to abort cleanly if there is a problem with the
+# destination host. For debugging, this can be problematic as
+# the keepalive may cause the peer to abort prematurely if we are
+# at a GDB breakpoint, for example.
+# Enabled by default. (Since 2.x)
Enabled-by-default is an interesting choice, but I suppose it is okay.