| Message ID | 1451443075-27428-3-git-send-email-wency@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote: > It is the negotiation record for COLO. > Primary->Secondary: > control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint > Secondary->Primary: > 0x00000001: Secondary VM is suspended > 0x00000002: Secondary VM is ready > 0x00000003: Secondary VM is resumed > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> > Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> > --- > docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- > tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ > tools/python/xen/migration/libxl.py | 9 +++++++++ > 3 files changed, 43 insertions(+), 2 deletions(-) > > diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc > index 2c97d86..5166d66 100644 > --- a/docs/specs/libxl-migration-stream.pandoc > +++ b/docs/specs/libxl-migration-stream.pandoc > @@ -1,6 +1,6 @@ > % LibXenLight Domain Image Format > % Andrew Cooper <<andrew.cooper3@citrix.com>> > -% Revision 1 > +% Revision 2 > > Introduction > ============ > @@ -119,7 +119,9 @@ type 0x00000000: END > > 0x00000004: CHECKPOINT_END > > - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ > + 0x00000005: CHECKPOINT_STATE > + > + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ This is in the 'mandatory' records. Should it be part of optional records? Would this checkpoint state always present on non-COLO guest migration?
On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote: >> It is the negotiation record for COLO. >> Primary->Secondary: >> control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint >> Secondary->Primary: >> 0x00000001: Secondary VM is suspended >> 0x00000002: Secondary VM is ready >> 0x00000003: Secondary VM is resumed >> >> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> >> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> >> --- >> docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- >> tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ >> tools/python/xen/migration/libxl.py | 9 +++++++++ >> 3 files changed, 43 insertions(+), 2 deletions(-) >> >> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc >> index 2c97d86..5166d66 100644 >> --- a/docs/specs/libxl-migration-stream.pandoc >> +++ b/docs/specs/libxl-migration-stream.pandoc >> @@ -1,6 +1,6 @@ >> % LibXenLight Domain Image Format >> % Andrew Cooper <<andrew.cooper3@citrix.com>> >> -% Revision 1 >> +% Revision 2 >> >> Introduction >> ============ >> @@ -119,7 +119,9 @@ type 0x00000000: END >> >> 0x00000004: CHECKPOINT_END >> >> - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ >> + 0x00000005: CHECKPOINT_STATE >> + >> + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ > > This is in the 'mandatory' records. Should it be part of optional records? > > Would this checkpoint state always present on non-COLO guest migration? No. Will be fixed in the next version Thanks Wen Congyang > > > > . >
On 27/01/16 06:47, Wen Congyang wrote: > On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote: >> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote: >>> It is the negotiation record for COLO. >>> Primary->Secondary: >>> control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint >>> Secondary->Primary: >>> 0x00000001: Secondary VM is suspended >>> 0x00000002: Secondary VM is ready >>> 0x00000003: Secondary VM is resumed >>> >>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> >>> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> >>> --- >>> docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- >>> tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ >>> tools/python/xen/migration/libxl.py | 9 +++++++++ >>> 3 files changed, 43 insertions(+), 2 deletions(-) >>> >>> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc >>> index 2c97d86..5166d66 100644 >>> --- a/docs/specs/libxl-migration-stream.pandoc >>> +++ b/docs/specs/libxl-migration-stream.pandoc >>> @@ -1,6 +1,6 @@ >>> % LibXenLight Domain Image Format >>> % Andrew Cooper <<andrew.cooper3@citrix.com>> >>> -% Revision 1 >>> +% Revision 2 >>> >>> Introduction >>> ============ >>> @@ -119,7 +119,9 @@ type 0x00000000: END >>> >>> 0x00000004: CHECKPOINT_END >>> >>> - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ >>> + 0x00000005: CHECKPOINT_STATE >>> + >>> + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ >> This is in the 'mandatory' records. Should it be part of optional records? >> >> Would this checkpoint state always present on non-COLO guest migration? > No. Will be fixed in the next version It is correct that CHECKPOINT_STATE is a mandatory record. Optional records which are free for the receiving end to ignore if they are not understood. ~Andrew
On Wed, Jan 27, 2016 at 11:00:24AM +0000, Andrew Cooper wrote: > On 27/01/16 06:47, Wen Congyang wrote: > > On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote: > >> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote: > >>> It is the negotiation record for COLO. > >>> Primary->Secondary: > >>> control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint > >>> Secondary->Primary: > >>> 0x00000001: Secondary VM is suspended > >>> 0x00000002: Secondary VM is ready > >>> 0x00000003: Secondary VM is resumed > >>> > >>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> > >>> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> > >>> --- > >>> docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- > >>> tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ > >>> tools/python/xen/migration/libxl.py | 9 +++++++++ > >>> 3 files changed, 43 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc > >>> index 2c97d86..5166d66 100644 > >>> --- a/docs/specs/libxl-migration-stream.pandoc > >>> +++ b/docs/specs/libxl-migration-stream.pandoc > >>> @@ -1,6 +1,6 @@ > >>> % LibXenLight Domain Image Format > >>> % Andrew Cooper <<andrew.cooper3@citrix.com>> > >>> -% Revision 1 > >>> +% Revision 2 > >>> > >>> Introduction > >>> ============ > >>> @@ -119,7 +119,9 @@ type 0x00000000: END > >>> > >>> 0x00000004: CHECKPOINT_END > >>> > >>> - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ > >>> + 0x00000005: CHECKPOINT_STATE > >>> + > >>> + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ > >> This is in the 'mandatory' records. Should it be part of optional records? > >> > >> Would this checkpoint state always present on non-COLO guest migration? > > No. Will be fixed in the next version > > It is correct that CHECKPOINT_STATE is a mandatory record. > > Optional records which are free for the receiving end to ignore if they > are not understood. What you are saying is that the receving end has to expect this (CHECKPOINT_STATE) even there is nothing in them - as the size of them is zero (becuase there are no dirty PFNs to send). > > ~Andrew
On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 27, 2016 at 11:00:24AM +0000, Andrew Cooper wrote: >> On 27/01/16 06:47, Wen Congyang wrote: >>> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote: >>>> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote: >>>>> It is the negotiation record for COLO. >>>>> Primary->Secondary: >>>>> control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint >>>>> Secondary->Primary: >>>>> 0x00000001: Secondary VM is suspended >>>>> 0x00000002: Secondary VM is ready >>>>> 0x00000003: Secondary VM is resumed >>>>> >>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> >>>>> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> >>>>> --- >>>>> docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- >>>>> tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ >>>>> tools/python/xen/migration/libxl.py | 9 +++++++++ >>>>> 3 files changed, 43 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc >>>>> index 2c97d86..5166d66 100644 >>>>> --- a/docs/specs/libxl-migration-stream.pandoc >>>>> +++ b/docs/specs/libxl-migration-stream.pandoc >>>>> @@ -1,6 +1,6 @@ >>>>> % LibXenLight Domain Image Format >>>>> % Andrew Cooper <<andrew.cooper3@citrix.com>> >>>>> -% Revision 1 >>>>> +% Revision 2 >>>>> >>>>> Introduction >>>>> ============ >>>>> @@ -119,7 +119,9 @@ type 0x00000000: END >>>>> >>>>> 0x00000004: CHECKPOINT_END >>>>> >>>>> - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ >>>>> + 0x00000005: CHECKPOINT_STATE >>>>> + >>>>> + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ >>>> This is in the 'mandatory' records. Should it be part of optional records? >>>> >>>> Would this checkpoint state always present on non-COLO guest migration? >>> No. Will be fixed in the next version >> It is correct that CHECKPOINT_STATE is a mandatory record. >> >> Optional records which are free for the receiving end to ignore if they >> are not understood. > What you are saying is that the receving end has to expect this (CHECKPOINT_STATE) > even there is nothing in them - as the size of them is zero (becuase there are > no dirty PFNs to send). The sole difference between a mandatory record an an option record is the receivers behaviour. Mandatory records may not be ignored, and constitutes a hard error. Optional records may be ignored, without error, if they are not understood. ~Andrew
On Wed, Jan 27, 2016 at 03:15:47PM +0000, Andrew Cooper wrote: > On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 27, 2016 at 11:00:24AM +0000, Andrew Cooper wrote: > >> On 27/01/16 06:47, Wen Congyang wrote: > >>> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote: > >>>> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote: > >>>>> It is the negotiation record for COLO. > >>>>> Primary->Secondary: > >>>>> control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint > >>>>> Secondary->Primary: > >>>>> 0x00000001: Secondary VM is suspended > >>>>> 0x00000002: Secondary VM is ready > >>>>> 0x00000003: Secondary VM is resumed > >>>>> > >>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> > >>>>> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> > >>>>> --- > >>>>> docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- > >>>>> tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ > >>>>> tools/python/xen/migration/libxl.py | 9 +++++++++ > >>>>> 3 files changed, 43 insertions(+), 2 deletions(-) > >>>>> > >>>>> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc > >>>>> index 2c97d86..5166d66 100644 > >>>>> --- a/docs/specs/libxl-migration-stream.pandoc > >>>>> +++ b/docs/specs/libxl-migration-stream.pandoc > >>>>> @@ -1,6 +1,6 @@ > >>>>> % LibXenLight Domain Image Format > >>>>> % Andrew Cooper <<andrew.cooper3@citrix.com>> > >>>>> -% Revision 1 > >>>>> +% Revision 2 > >>>>> > >>>>> Introduction > >>>>> ============ > >>>>> @@ -119,7 +119,9 @@ type 0x00000000: END > >>>>> > >>>>> 0x00000004: CHECKPOINT_END > >>>>> > >>>>> - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ > >>>>> + 0x00000005: CHECKPOINT_STATE > >>>>> + > >>>>> + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ > >>>> This is in the 'mandatory' records. Should it be part of optional records? > >>>> > >>>> Would this checkpoint state always present on non-COLO guest migration? > >>> No. Will be fixed in the next version > >> It is correct that CHECKPOINT_STATE is a mandatory record. > >> > >> Optional records which are free for the receiving end to ignore if they > >> are not understood. > > What you are saying is that the receving end has to expect this (CHECKPOINT_STATE) > > even there is nothing in them - as the size of them is zero (becuase there are > > no dirty PFNs to send). > > The sole difference between a mandatory record an an option record is > the receivers behaviour. > > Mandatory records may not be ignored, and constitutes a hard error. > Optional records may be ignored, without error, if they are not understood. You are still not answering my question. Is it a hard error if the mandatory record is zero length? > > ~Andrew
On 27/01/16 15:28, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 27, 2016 at 03:15:47PM +0000, Andrew Cooper wrote: >> On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote: >>> On Wed, Jan 27, 2016 at 11:00:24AM +0000, Andrew Cooper wrote: >>>> On 27/01/16 06:47, Wen Congyang wrote: >>>>> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote: >>>>>> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote: >>>>>>> It is the negotiation record for COLO. >>>>>>> Primary->Secondary: >>>>>>> control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint >>>>>>> Secondary->Primary: >>>>>>> 0x00000001: Secondary VM is suspended >>>>>>> 0x00000002: Secondary VM is ready >>>>>>> 0x00000003: Secondary VM is resumed >>>>>>> >>>>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> >>>>>>> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> >>>>>>> --- >>>>>>> docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- >>>>>>> tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ >>>>>>> tools/python/xen/migration/libxl.py | 9 +++++++++ >>>>>>> 3 files changed, 43 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc >>>>>>> index 2c97d86..5166d66 100644 >>>>>>> --- a/docs/specs/libxl-migration-stream.pandoc >>>>>>> +++ b/docs/specs/libxl-migration-stream.pandoc >>>>>>> @@ -1,6 +1,6 @@ >>>>>>> % LibXenLight Domain Image Format >>>>>>> % Andrew Cooper <<andrew.cooper3@citrix.com>> >>>>>>> -% Revision 1 >>>>>>> +% Revision 2 >>>>>>> >>>>>>> Introduction >>>>>>> ============ >>>>>>> @@ -119,7 +119,9 @@ type 0x00000000: END >>>>>>> >>>>>>> 0x00000004: CHECKPOINT_END >>>>>>> >>>>>>> - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ >>>>>>> + 0x00000005: CHECKPOINT_STATE >>>>>>> + >>>>>>> + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ >>>>>> This is in the 'mandatory' records. Should it be part of optional records? >>>>>> >>>>>> Would this checkpoint state always present on non-COLO guest migration? >>>>> No. Will be fixed in the next version >>>> It is correct that CHECKPOINT_STATE is a mandatory record. >>>> >>>> Optional records which are free for the receiving end to ignore if they >>>> are not understood. >>> What you are saying is that the receving end has to expect this (CHECKPOINT_STATE) >>> even there is nothing in them - as the size of them is zero (becuase there are >>> no dirty PFNs to send). >> The sole difference between a mandatory record an an option record is >> the receivers behaviour. >> >> Mandatory records may not be ignored, and constitutes a hard error. >> Optional records may be ignored, without error, if they are not understood. > You are still not answering my question. > > Is it a hard error if the mandatory record is zero length? Not if the type specifies that a zero length record is permitted. ~Andrew
Andrew Cooper writes ("Re: [Xen-devel] [PATCH v9 02/25] docs/libxl: Introduce COLO_CONTEXT to support migration v2 colo streams"):
> On 27/01/16 15:28, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 27, 2016 at 03:15:47PM +0000, Andrew Cooper wrote:
> >> Mandatory records may not be ignored, and constitutes a hard
> >> error. Optional records may be ignored, without error, if they
> >> are not understood.
`Mandatory' is a somewhat misleading term. (In a past life we called
these different kinds of protocol extension `harmful' and `harmless'.
A `harmless' extension is one that is safe to ignore if the receiver
does not know about the extension. A `harmful' extension will always
cause a naive receiver to get a parse error.)
> > You are still not answering my question.
> >
> > Is it a hard error if the mandatory record is zero length?
>
> Not if the type specifies that a zero length record is permitted.
This is misleading. Obviously the behaviour of a naive receiver
cannot depend on the specification document for the type, because that
specification document was written after the type was invented.
Let me provide an exhaustive case analysis:
Optional or Value sent Receiver knows Receiver
Mandatory about the type? behaviour
Optional or No record of Yes Depends on type
Mandatory this type spec and semantics;
reciever may fail
if information is
required.
Optional or Empty Yes Depends on type
Mandatory record(s) spec and semantics;
empty record might be
invalid or semantically
inappropriate (eg
inconsistent with
other info)
Optional or Nonempty Yes Depends on type
Mandatory record(s) spec and semantics
Optional or No record of No Whatever it does
Mandatory this type normally, obviously
And these are the only cases where `Optional' or `Mandatory' makes a
difference:
Optional Empty No Record(s) silently
record(s) discarded by receiver
Optional Nonempty No Record(s) silently
record(s) discarded by receiver
Mandatory Empty No Receiver ABORTS
record(s) entire operation
Mandatory Nonempty No Receiver ABORTS
record(s) entire operation
There is nothing special about empty records. Indeed an empty record
can be used as a flag.
Ian.
diff --git a/docs/specs/libxl-migration-stream.pandoc b/docs/specs/libxl-migration-stream.pandoc index 2c97d86..5166d66 100644 --- a/docs/specs/libxl-migration-stream.pandoc +++ b/docs/specs/libxl-migration-stream.pandoc @@ -1,6 +1,6 @@ % LibXenLight Domain Image Format % Andrew Cooper <<andrew.cooper3@citrix.com>> -% Revision 1 +% Revision 2 Introduction ============ @@ -119,7 +119,9 @@ type 0x00000000: END 0x00000004: CHECKPOINT_END - 0x00000005 - 0x7FFFFFFF: Reserved for future _mandatory_ + 0x00000005: CHECKPOINT_STATE + + 0x00000006 - 0x7FFFFFFF: Reserved for future _mandatory_ records. 0x80000000 - 0xFFFFFFFF: Reserved for future _optional_ @@ -249,6 +251,25 @@ A checkpoint end record marks the end of a checkpoint in the image. The end record contains no fields; its body_length is 0. +CHECKPOINT\_STATE +-------------- + +A checkpoint state record contains the control information for checkpoint. + + 0 1 2 3 4 5 6 7 octet + +------------------------+------------------------+ + | control_id | padding | + +------------------------+------------------------+ + +-------------------------------------------------------------------- +Field Description +------------ --------------------------------------------------- +control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint + 0x00000001: Secondary VM is suspended + 0x00000002: Secondary VM is ready + 0x00000003: Secondary VM is resumed +-------------------------------------------------------------------- + Future Extensions ================= diff --git a/tools/libxl/libxl_sr_stream_format.h b/tools/libxl/libxl_sr_stream_format.h index 54da360..75f5190 100644 --- a/tools/libxl/libxl_sr_stream_format.h +++ b/tools/libxl/libxl_sr_stream_format.h @@ -36,6 +36,7 @@ typedef struct libxl__sr_rec_hdr #define REC_TYPE_EMULATOR_XENSTORE_DATA 0x00000002U #define REC_TYPE_EMULATOR_CONTEXT 0x00000003U #define REC_TYPE_CHECKPOINT_END 0x00000004U +#define REC_TYPE_CHECKPOINT_STATE 0x00000005U typedef struct libxl__sr_emulator_hdr { @@ -47,6 +48,16 @@ typedef struct libxl__sr_emulator_hdr #define EMULATOR_QEMU_TRADITIONAL 0x00000001U #define EMULATOR_QEMU_UPSTREAM 0x00000002U +typedef struct libxl_sr_checkpoint_state +{ + uint32_t id; +} libxl_sr_checkpoint_state; + +#define CHECKPOINT_NEW 0x00000000U +#define CHECKPOINT_SVM_SUSPENDED 0x00000001U +#define CHECKPOINT_SVM_READY 0x00000002U +#define CHECKPOINT_SVM_RESUMED 0x00000003U + #endif /* LIBXL__SR_STREAM_FORMAT_H */ /* diff --git a/tools/python/xen/migration/libxl.py b/tools/python/xen/migration/libxl.py index fc0acf6..d5f54dc 100644 --- a/tools/python/xen/migration/libxl.py +++ b/tools/python/xen/migration/libxl.py @@ -37,6 +37,7 @@ REC_TYPE_libxc_context = 0x00000001 REC_TYPE_emulator_xenstore_data = 0x00000002 REC_TYPE_emulator_context = 0x00000003 REC_TYPE_checkpoint_end = 0x00000004 +REC_TYPE_checkpoint_state = 0x00000005 rec_type_to_str = { REC_TYPE_end : "End", @@ -44,6 +45,7 @@ rec_type_to_str = { REC_TYPE_emulator_xenstore_data : "Emulator xenstore data", REC_TYPE_emulator_context : "Emulator context", REC_TYPE_checkpoint_end : "Checkpoint end", + REC_TYPE_checkpoint_state : "Checkpoint state" } # emulator_* header @@ -212,6 +214,11 @@ class VerifyLibxl(VerifyBase): if len(content) != 0: raise RecordError("Checkpoint end record with non-zero length") + def verify_record_checkpoint_state(self, content): + """ Checkpoint state """ + if len(content) == 0: + raise RecordError("Checkpoint state record with zero length") + record_verifiers = { REC_TYPE_end: @@ -224,4 +231,6 @@ record_verifiers = { VerifyLibxl.verify_record_emulator_context, REC_TYPE_checkpoint_end: VerifyLibxl.verify_record_checkpoint_end, + REC_TYPE_checkpoint_state: + VerifyLibxl.verify_record_checkpoint_state, }
It is the negotiation record for COLO. Primary->Secondary: control_id 0x00000000: Secondary VM is out of sync, start a new checkpoint Secondary->Primary: 0x00000001: Secondary VM is suspended 0x00000002: Secondary VM is ready 0x00000003: Secondary VM is resumed Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn> --- docs/specs/libxl-migration-stream.pandoc | 25 +++++++++++++++++++++++-- tools/libxl/libxl_sr_stream_format.h | 11 +++++++++++ tools/python/xen/migration/libxl.py | 9 +++++++++ 3 files changed, 43 insertions(+), 2 deletions(-)