Re: [PATCH] docs/devel/migration: start a debugging section

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Mar 30, 2020 at 07:48:52PM +0200, Marc-André Lureau wrote:
> Explain how to use analyze-migration.py, this may help.
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  docs/devel/migration.rst | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst
> index e88918f7639..2eb08624fc3 100644
> --- a/docs/devel/migration.rst
> +++ b/docs/devel/migration.rst
> @@ -50,6 +50,26 @@ All these migration protocols use the same infrastructure to
>  save/restore state devices.  This infrastructure is shared with the
>  savevm/loadvm functionality.
>  
> +Debugging
> +=========
> +
> +The migration stream can be analyzed thanks to `scripts/analyze_migration.py`.
> +
> +Example usage:
> +
> +.. code-block:: shell
> +
> +  $ qemu-system-x86_64
> +   (qemu) migrate "exec:cat > mig"
> +  $ ./scripts/analyze_migration.py -f mig
> +  {
> +    "ram (3)": {
> +        "section sizes": {
> +            "pc.ram": "0x0000000008000000",
> +  ...
> +
> +See also ``analyze_migration.py -h`` help for more options.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Side note: who else loves the fact that we have both spellings
of analyse - 'z' and 's' in the scripts directory. We ought to
pick one :-)

Another side note - could analyze_migration be used as the basis
for doing compatibility testing of migration support between QEMU
versions ?

eg, we can have a pair of files  "foo.argv" and "foo.migration"
containing the QEMU argv to run, and the corresponding output
expected from "analyze_migration.py" (perhaps we certain bits like
precise register values scrubbed).  On each release commit a new
pairs to git for new machine types, with various interesting argv,
and then we can validate that all future versions of QEMU produce
the same output & thus remain migration compatible ?  This feels
like this kind of approach could have caught the regression today
with the duplicated  serial device migration output sections. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|