All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.