qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] Add section footers to detect corrupted mig


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 0/4] Add section footers to detect corrupted migration streams
Date: Tue, 19 May 2015 08:13:52 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]