From: Paul Durrant
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
NOTE: doc/misc/xenstore.txt is also amended to replace the term
for the INTRODUCE operation with the , since this is what
it actually is.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Wei Liu
v8:
- Addressed further comments form Julien
v7:
- Addressed further comments from Julien
- Switched migration records to defined structures instead of tuples
v6:
- Addressed comments from Julien
v5:
- Add QUIESCE
- Make semantics of in GET_DOMAIN_WATCHES more clear
v4:
- Drop the restrictions on special paths
v3:
- New in v3
---
docs/designs/xenstore-migration.md | 256 +
docs/misc/xenstore.txt | 6 +-
2 files changed, 259 insertions(+), 3 deletions(-)
create mode 100644 docs/designs/xenstore-migration.md
diff --git a/docs/designs/xenstore-migration.md
b/docs/designs/xenstore-migration.md
new file mode 100644
index 00..97695f3ec9
--- /dev/null
+++ b/docs/designs/xenstore-migration.md
@@ -0,0 +1,256 @@
+# Xenstore Migration
+
+## Background
+
+The design for *Non-Cooperative Migration of Guests*[1] explains that extra
+save records are required in the migrations stream to allow a guest running
+PV drivers to be migrated without its co-operation. Moreover the save
+records must include details of registered xenstore watches as well as
+content; information that cannot currently be recovered from `xenstored`,
+and hence some extension to the xenstore protocol[2] will also be required.
+
+The *libxenlight Domain Image Format* specification[3] already defines a
+record type `EMULATOR_XENSTORE_DATA` but this is not suitable for
+transferring xenstore data pertaining to the domain directly as it is
+specified such that keys are relative to the path
+`/local/domain/$dm_domid/device-model/$domid`. Thus it is necessary to
+define at least one new save record type.
+
+## Proposal
+
+### New Save Record
+
+A new mandatory record type should be defined within the libxenlight Domain
+Image Format:
+
+`0x0007: DOMAIN_XENSTORE_DATA`
+
+An arbitrary number of these records may be present in the migration
+stream and may appear in any order. The format of each record should be as
+follows:
+
+
+```
+0 1 2 3 4 5 6 7octet
++---+---+---+---+---+---+---+---+
+| type | record specific data |
++---+ |
+...
++---+
+```
+
+where type is one of the following values
+
+
+| Field | Description |
+||--|
+| `type` | 0x: invalid |
+|| 0x0001: NODE_DATA|
+|| 0x0002: WATCH_DATA |
+|| 0x0003: TRANSACTION_DATA |
+|| 0x0004 - 0x: reserved for future use |
+
+
+and data is one of the record data formats described in the following
+sections.
+
+
+NOTE: The record data does not contain an overall length because the
+libxenlight record header specifies the length.
+
+
+**NODE_DATA**
+
+
+Each NODE_DATA record specifies a single node in xenstore and is formatted
+as follows:
+
+
+```
+0 1 2 3 octet
++---+---+---+---+
+| NODE_DATA |
++---+
+| path length |
++---+
+| path data |
+...
+| pad (0 to 3 octets) |
++---+
+| perm count (N)|
++---+
+| perm0 |
++---+
+...
++---+
+| permN |
++---+
+| value length |
++---+
+| value data|
+...
+| pad (0 to 3 octets) |
++---+
+```
+
+where perm0..N are formatted as follows:
+
+
+```
+0 1 2 3 octet
++---+---+---+---+
+| perm | pad | domid |
++---+
+```
+
+
+path length and value length are specified in octets (excluding the NUL
+terminator of the path). perm should be one of the ASCII values `w`, `r`,
+`b` or `n` as described in [2]. All pad values should be 0.
+All paths should be absolute (i.e. start with `/`) and as described in
+[2].
+
+
+**WATCH_DATA**
+
+
+Each WATCH_DATA record specifies a registered watch and is
