[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] docs/devel/migration: start a debugging section
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH] docs/devel/migration: start a debugging section |
Date: |
Mon, 30 Mar 2020 18:59:24 +0100 |
User-agent: |
Mutt/1.13.3 (2020-01-12) |
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 <address@hidden>
> ---
> 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é <address@hidden>
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 :|