We broke it with dirtyrate limit patches.

Signed-off-by: Juan Quintela <quint...@redhat.com>
---
 qapi/migration.json | 67 ++++++++++++++++++++++-----------------------
 1 file changed, 33 insertions(+), 34 deletions(-)

diff --git a/qapi/migration.json b/qapi/migration.json
index 6ff39157ba..ad8cc57071 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -258,17 +258,17 @@
 #     blocked.  Present and non-empty when migration is blocked.
 #     (since 6.0)
 #
-# @dirty-limit-throttle-time-per-round: Maximum throttle time (in 
microseconds) of virtual
-#                                       CPUs each dirty ring full round, which 
shows how
-#                                       MigrationCapability dirty-limit 
affects the guest
-#                                       during live migration. (since 8.1)
+# @dirty-limit-throttle-time-per-round: Maximum throttle time (in
+#     microseconds) of virtual CPUs each dirty ring full round, which
+#     shows how MigrationCapability dirty-limit affects the guest
+#     during live migration. (since 8.1)
 #
-# @dirty-limit-ring-full-time: Estimated average dirty ring full time (in 
microseconds)
-#                              each dirty ring full round, note that the value 
equals
-#                              dirty ring memory size divided by average dirty 
page rate
-#                              of virtual CPU, which can be used to observe 
the average
-#                              memory load of virtual CPU indirectly. Note 
that zero
-#                              means guest doesn't dirty memory (since 8.1)
+# @dirty-limit-ring-full-time: Estimated average dirty ring full time
+#     (in microseconds) each dirty ring full round, note that the
+#     value equals dirty ring memory size divided by average dirty
+#     page rate of virtual CPU, which can be used to observe the
+#     average memory load of virtual CPU indirectly. Note that zero
+#     means guest doesn't dirty memory (since 8.1)
 #
 # Since: 0.14
 ##
@@ -510,14 +510,13 @@
 #     (since 7.1)
 #
 # @dirty-limit: If enabled, migration will use the dirty-limit algo to
-#               throttle down guest instead of auto-converge algo.
-#               Throttle algo only works when vCPU's dirtyrate greater
-#               than 'vcpu-dirty-limit', read processes in guest os
-#               aren't penalized any more, so this algo can improve
-#               performance of vCPU during live migration. This is an
-#               optional performance feature and should not affect the
-#               correctness of the existing auto-converge algo.
-#               (since 8.1)
+#     throttle down guest instead of auto-converge algo.  Throttle
+#     algo only works when vCPU's dirtyrate greater than
+#     'vcpu-dirty-limit', read processes in guest os aren't penalized
+#     any more, so this algo can improve performance of vCPU during
+#     live migration. This is an optional performance feature and
+#     should not affect the correctness of the existing auto-converge
+#     algo.  (since 8.1)
 #
 # Features:
 #
@@ -811,17 +810,17 @@
 #     Nodes are mapped to their block device name if there is one, and
 #     to their node name otherwise.  (Since 5.2)
 #
-# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty limit 
during
-#                             live migration. Should be in the range 1 to 
1000ms,
-#                             defaults to 1000ms. (Since 8.1)
+# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
+#     limit during live migration. Should be in the range 1 to 1000ms,
+#     defaults to 1000ms. (Since 8.1)
 #
 # @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
-#                    Defaults to 1. (Since 8.1)
+#     Defaults to 1. (Since 8.1)
 #
 # Features:
 #
 # @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
-#            are experimental.
+#     are experimental.
 #
 # Since: 2.4
 ##
@@ -977,17 +976,17 @@
 #     Nodes are mapped to their block device name if there is one, and
 #     to their node name otherwise.  (Since 5.2)
 #
-# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty limit 
during
-#                             live migration. Should be in the range 1 to 
1000ms,
-#                             defaults to 1000ms. (Since 8.1)
+# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
+#     limit during live migration. Should be in the range 1 to 1000ms,
+#     defaults to 1000ms. (Since 8.1)
 #
 # @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
-#                    Defaults to 1. (Since 8.1)
+#     Defaults to 1. (Since 8.1)
 #
 # Features:
 #
 # @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
-#            are experimental.
+#     are experimental.
 #
 # TODO: either fuse back into MigrationParameters, or make
 #     MigrationParameters members mandatory
@@ -1180,17 +1179,17 @@
 #     Nodes are mapped to their block device name if there is one, and
 #     to their node name otherwise.  (Since 5.2)
 #
-# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty limit 
during
-#                             live migration. Should be in the range 1 to 
1000ms,
-#                             defaults to 1000ms. (Since 8.1)
+# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
+#     limit during live migration. Should be in the range 1 to 1000ms,
+#     defaults to 1000ms. (Since 8.1)
 #
 # @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
-#                    Defaults to 1. (Since 8.1)
+#     Defaults to 1. (Since 8.1)
 #
 # Features:
 #
-# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
-#            are experimental.
+# @unstable: Members @x-checkpoint-delay and
+#     @x-vcpu-dirty-limit-period are experimental.
 #
 # Since: 2.4
 ##
-- 
2.40.1


Reply via email to