qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org,
	agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH 0/4] Add section footers to detect corrupted migration streams
Date: Tue, 19 May 2015 08:13:52 -0600	[thread overview]
Message-ID: <555B4520.7000109@redhat.com> (raw)
In-Reply-To: <20150519140649.GB2127@work-vm>

[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]

On 05/19/2015 08:06 AM, Dr. David Alan Gilbert wrote:

>> Does it let us detect a corrupted
>> stream earlier in the process?  Or is the main benefit that it gives
>> better error messages at the point corruption is first detected?
> 
> Both; there are two cases that often happen; both triggered by a section
> reading too little or too much, and it gets back to the main loop and
> we read the next byte:
>    1) the next byte on the stream is a 0x00 - that's read as an end-of-migration
>       marker, we start the VM  and you get a hung VM with no errors.
> 
>    2) the next byte is between 0x01..0x04 - and it looks like a section header,
>       then we try and read the next few bytes to figure out which section;
>       this could a) result in an error saying it's an unknown section or
>       b) Happen to match a section ID and then get an error about a problem
>       in that section.  In either case you don't get an error pointing to
>       the previous section which was the actual problem.

Probably worth incorporating into the commit body then :)

> 
>>>
>>> The footers are tied to new machine types (on both pc types).
>>
>> Good that you tied it to machine type, but is it enough?  When we added
>> the optional section for giving the json representation of the stream,
>> we ended up having to add a knob to turn off that section, so that
>> backwards migration from a new qemu to an older one did not send it.
>> I'm wondering if we'll need to expose a knob to turn off footers, again
>> for the sake of backwards migration in downstream distros.
> 
> That knob is already the knob that I've created and tied to the machine
> type; the downstream distros will just turn the same knob in their old
> machine types.

I'm not asking about the machine type defaults, but a command line
override: -machine suppress-vmdesc=on, commit 9850c604

[uggh - why'd we give that option an inverted name? Just so we could
have a default of off?  It might have been nicer as -machine
send-vmdesc=off with a default of on for new machine types]


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2015-05-19 14:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 11:29 [Qemu-devel] [PATCH 0/4] Add section footers to detect corrupted migration streams Dr. David Alan Gilbert (git)
2015-05-19 11:29 ` [Qemu-devel] [PATCH 1/4] Merge section header writing Dr. David Alan Gilbert (git)
2015-05-20  8:50   ` Juan Quintela
2015-05-19 11:29 ` [Qemu-devel] [PATCH 2/4] Disable section footers on older machine types Dr. David Alan Gilbert (git)
2015-05-20  8:52   ` Juan Quintela
2015-05-20 17:02     ` Dr. David Alan Gilbert
2015-05-19 11:29 ` [Qemu-devel] [PATCH 3/4] Add a protective section footer Dr. David Alan Gilbert (git)
2015-05-20  8:53   ` Juan Quintela
2015-05-19 11:29 ` [Qemu-devel] [PATCH 4/4] Teach analyze-migration.py about section footers Dr. David Alan Gilbert (git)
2015-05-19 13:51 ` [Qemu-devel] [PATCH 0/4] Add section footers to detect corrupted migration streams Eric Blake
2015-05-19 14:06   ` Dr. David Alan Gilbert
2015-05-19 14:13     ` Eric Blake [this message]
2015-05-19 14:28       ` Dr. David Alan Gilbert
2015-05-19 14:40         ` Eric Blake
2015-05-20  8:58         ` Juan Quintela
2015-05-20  7:13       ` Amit Shah
2015-05-20  7:18 ` Amit Shah

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=555B4520.7000109@redhat.com \
    --to=eblake@redhat.com \
    --cc=agraf@suse.de \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --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).