diff options
Diffstat (limited to 'docs/interop')
| -rw-r--r-- | docs/interop/bitmaps.rst | 54 |
1 files changed, 27 insertions, 27 deletions
diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst index c29ac4a854..c20bd37a79 100644 --- a/docs/interop/bitmaps.rst +++ b/docs/interop/bitmaps.rst @@ -199,7 +199,7 @@ persistence, and recording state can be adjusted at creation time. to create a new, actively recording persistent bitmap: - .. code:: json + .. code-block:: QMP -> { "execute": "block-dirty-bitmap-add", "arguments": { @@ -220,7 +220,7 @@ persistence, and recording state can be adjusted at creation time. To create a new, disabled (``-recording``), transient bitmap that tracks changes in 32KiB segments: - .. code:: json + .. code-block:: QMP -> { "execute": "block-dirty-bitmap-add", "arguments": { @@ -254,7 +254,7 @@ Deletes a bitmap. Bitmaps that are ``+busy`` cannot be removed. Remove a bitmap named ``bitmap0`` from node ``drive0``: - .. code:: json + .. code-block:: QMP -> { "execute": "block-dirty-bitmap-remove", "arguments": { @@ -280,7 +280,7 @@ Clears all dirty bits from a bitmap. ``+busy`` bitmaps cannot be cleared. Clear all dirty bits from bitmap ``bitmap0`` on node ``drive0``: - .. code:: json + .. code-block:: QMP -> { "execute": "block-dirty-bitmap-clear", "arguments": { @@ -309,7 +309,7 @@ begin being recorded. ``+busy`` bitmaps cannot be enabled. To set ``+recording`` on bitmap ``bitmap0`` on node ``drive0``: - .. code:: json + .. code-block:: QMP -> { "execute": "block-dirty-bitmap-enable", "arguments": { @@ -347,7 +347,7 @@ writes to begin being ignored. ``+busy`` bitmaps cannot be disabled. To set ``-recording`` on bitmap ``bitmap0`` on node ``drive0``: - .. code:: json + .. code-block:: QMP -> { "execute": "block-dirty-bitmap-disable", "arguments": { @@ -393,7 +393,7 @@ in any one source bitmap, the target bitmap will mark that segment dirty. ``drive0``. If ``new_bitmap`` was empty prior to this command, this achieves a copy. - .. code:: json + .. code-block:: QMP -> { "execute": "block-dirty-bitmap-merge", "arguments": { @@ -424,7 +424,7 @@ attached to nodes serving as the root for guest devices. API. This result highlights a bitmap ``bitmap0`` attached to the root node of device ``drive0``. - .. code:: json + .. code-block:: QMP -> { "execute": "query-block", @@ -562,7 +562,7 @@ new, empty bitmap that records writes from this point in time forward. destination. These writes will be recorded in the bitmap accordingly. -.. code:: json +.. code-block:: QMP -> { "execute": "transaction", @@ -650,7 +650,7 @@ Example: Resetting an Incremental Backup Anchor Point If we want to start a new backup chain with an existing bitmap, we can also use a transaction to reset the bitmap while making a new full backup: -.. code:: json +.. code-block:: QMP -> { "execute": "transaction", @@ -730,7 +730,7 @@ Example: First Incremental Backup #. Issue an incremental backup command: - .. code:: json + .. code-block:: QMP -> { "execute": "drive-backup", @@ -788,7 +788,7 @@ Example: Second Incremental Backup #. Issue a new incremental backup command. The only difference here is that we have changed the target image below. - .. code:: json + .. code-block:: QMP -> { "execute": "drive-backup", @@ -869,7 +869,7 @@ image: #. Issue a new incremental backup command. Apart from the new destination image, there is no difference from the last two examples. - .. code:: json + .. code-block:: QMP -> { "execute": "drive-backup", @@ -932,7 +932,7 @@ point in time. #. Create a full (anchor) backup for each drive, with accompanying bitmaps: - .. code:: json + .. code-block:: QMP -> { "execute": "transaction", @@ -1018,7 +1018,7 @@ point in time. #. Issue a multi-drive incremental push backup transaction: - .. code:: json + .. code-block:: QMP -> { "execute": "transaction", @@ -1121,7 +1121,7 @@ described above. This example demonstrates the single-job failure case: #. Attempt to create an incremental backup via QMP: - .. code:: json + .. code-block:: QMP -> { "execute": "drive-backup", @@ -1139,7 +1139,7 @@ described above. This example demonstrates the single-job failure case: #. Receive a pair of events indicating failure: - .. code:: json + .. code-block:: QMP <- { "timestamp": {...}, @@ -1175,7 +1175,7 @@ described above. This example demonstrates the single-job failure case: #. Retry the command after fixing the underlying problem, such as freeing up space on the backup volume: - .. code:: json + .. code-block:: QMP -> { "execute": "drive-backup", @@ -1193,7 +1193,7 @@ described above. This example demonstrates the single-job failure case: #. Receive confirmation that the job completed successfully: - .. code:: json + .. code-block:: QMP <- { "timestamp": {...}, @@ -1233,7 +1233,7 @@ and one succeeds: #. Issue the transaction to start a backup of both drives. - .. code:: json + .. code-block:: QMP -> { "execute": "transaction", @@ -1267,13 +1267,13 @@ and one succeeds: #. Receive notice that the Transaction was accepted, and jobs were launched: - .. code:: json + .. code-block:: QMP <- { "return": {} } #. Receive notice that the first job has completed: - .. code:: json + .. code-block:: QMP <- { "timestamp": {...}, @@ -1289,7 +1289,7 @@ and one succeeds: #. Receive notice that the second job has failed: - .. code:: json + .. code-block:: QMP <- { "timestamp": {...}, @@ -1365,7 +1365,7 @@ applied: #. Issue the multi-drive incremental backup transaction: - .. code:: json + .. code-block:: QMP -> { "execute": "transaction", @@ -1401,13 +1401,13 @@ applied: #. Receive notice that the Transaction was accepted, and jobs were launched: - .. code:: json + .. code-block:: QMP <- { "return": {} } #. Receive notification that the backup job for ``drive1`` has failed: - .. code:: json + .. code-block:: QMP <- { "timestamp": {...}, @@ -1434,7 +1434,7 @@ applied: #. Receive notification that the job for ``drive0`` has been cancelled: - .. code:: json + .. code-block:: QMP <- { "timestamp": {...}, |