From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
qemu-devel@nongnu.org, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH] migration: fix analyze-migration.py script
Date: Thu, 26 Nov 2015 15:31:08 +0000 [thread overview]
Message-ID: <20151126153108.GC18216@work-vm> (raw)
In-Reply-To: <565723D8.1070401@suse.de>
* Alexander Graf (agraf@suse.de) wrote:
>
>
> On 30.10.15 17:50, Mark Cave-Ayland wrote:
> > On 26/10/15 09:48, Mark Cave-Ayland wrote:
> >
> >> On 06/09/15 12:54, Mark Cave-Ayland wrote:
> >>
> >>> On 06/09/15 09:36, Alexander Graf wrote:
> >>>
> >>>> On 05.09.15 21:51, Mark Cave-Ayland wrote:
> >>>>> Commit 61964 "Add configuration section" broke the analyze-migration.py script
> >>>>> which terminates due to the unrecognised section. Fix the script by parsing
> >>>>> the contents of the configuration section directly into a new
> >>>>> ConfigurationSection object (although nothing is done with it yet).
> >>>>>
> >>>>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> >>>>> ---
> >>>>> scripts/analyze-migration.py | 13 +++++++++++++
> >>>>> 1 file changed, 13 insertions(+)
> >>>>>
> >>>>> diff --git a/scripts/analyze-migration.py b/scripts/analyze-migration.py
> >>>>> index f6894be..1455387 100755
> >>>>> --- a/scripts/analyze-migration.py
> >>>>> +++ b/scripts/analyze-migration.py
> >>>>> @@ -252,6 +252,15 @@ class HTABSection(object):
> >>>>> def getDict(self):
> >>>>> return ""
> >>>>>
> >>>>> +
> >>>>> +class ConfigurationSection(object):
> >>>>> + def __init__(self, file):
> >>>>> + self.file = file
> >>>>> +
> >>>>> + def read(self):
> >>>>> + name_len = self.file.read32()
> >>>>> + name = self.file.readstr(len = name_len)
> >>>>> +
> >>>>> class VMSDFieldGeneric(object):
> >>>>> def __init__(self, desc, file):
> >>>>> self.file = file
> >>>>> @@ -474,6 +483,7 @@ class MigrationDump(object):
> >>>>> QEMU_VM_SECTION_FULL = 0x04
> >>>>> QEMU_VM_SUBSECTION = 0x05
> >>>>> QEMU_VM_VMDESCRIPTION = 0x06
> >>>>> + QEMU_VM_CONFIGURATION = 0x07
> >>>>> QEMU_VM_SECTION_FOOTER= 0x7e
> >>>>>
> >>>>> def __init__(self, filename):
> >>>>> @@ -514,6 +524,9 @@ class MigrationDump(object):
> >>>>> section_type = file.read8()
> >>>>> if section_type == self.QEMU_VM_EOF:
> >>>>> break
> >>>>> + elif section_type == self.QEMU_VM_CONFIGURATION:
> >>>>> + section = ConfigurationSection(file)
> >>>>> + section.read()
> >>>>
> >>>> So since we don't have a normal section header, there is no version
> >>>> field either. That in turn means that the format is determined by the
> >>>> machine version only - bleks.
> >>>
> >>> Yes :( I double-checked the output of a migration file with hexdump and
> >>> confirmed that just the raw fields are included without any additional
> >>> metadata, even though the state is held in a VMStateDescription.
> >>>
> >>>> So if there ever has to be more in the configuration section than the
> >>>> machine name, please move to a more detectable scheme. Ideally something
> >>>> that contains
> >>>>
> >>>> * version
> >>>> * length of dynamically sized fields
> >>>> * lenght of full blob
> >>>>
> >>>> would be ideal, so that we have a chance to at least put code into the
> >>>> analyze script to examine it.
> >>>>
> >>>> For now, I think the hard coded solution in the analyze script is
> >>>> reasonable.
> >>>>
> >>>> However, I think we should print out the name if we find it. It should
> >>>> be as simple as adding a special case for the configuration section in
> >>>> MigrationDump.getDict().
> >>>
> >>> I did play with adding a separate JSON object for configuration but was
> >>> torn between whether configuration should have its own JSON object
> >>> (better if we include extra fields and metadata as above) or to just
> >>> embed it as a simple "machine" property similar to "page_size". I'll
> >>> wait until we hear back from David/Juan and submit a v2 accordingly.
> >>
> >> Ping again from Juan/David? The analyze-migration.py script is currently
> >> broken without this patch (or another equivalent) applied.
> >
> > Ping^2? FWIW I've added this to the wiki at
> > http://wiki.qemu.org/Planning/2.5 since without this patch or something
> > similar applied, this feature is completely broken.
>
> Juan, David?
Isn't this already in ( 96e5c9bc77acef8b7b56cbe23a8a2611feff9e34 ) - or is
this a different breakage?
Dave
>
>
> Alex
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2015-11-26 15:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-05 19:51 [Qemu-devel] [PATCH] migration: fix analyze-migration.py script Mark Cave-Ayland
2015-09-05 19:51 ` Mark Cave-Ayland
2015-09-06 8:36 ` Alexander Graf
2015-09-06 11:54 ` Mark Cave-Ayland
2015-10-26 9:48 ` Mark Cave-Ayland
2015-10-30 16:50 ` Mark Cave-Ayland
2015-11-26 15:23 ` Alexander Graf
2015-11-26 15:31 ` Dr. David Alan Gilbert [this message]
2015-11-26 15:32 ` Alexander Graf
2015-11-26 21:40 ` Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151126153108.GC18216@work-vm \
--to=dgilbert@redhat.com \
--cc=agraf@suse.de \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).