qemu-devel
[Top][All Lists]
Advanced

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

Re: -only-migrate and the two different uses of migration blockers


From: Juan Quintela
Subject: Re: -only-migrate and the two different uses of migration blockers
Date: Tue, 02 Nov 2021 15:32:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

David Gibson <david@gibson.dropbear.id.au> wrote:
> On Tue, Jul 20, 2021 at 07:30:16AM +0200, Markus Armbruster wrote:
>
> Right, it may well have been the first usage this way, this fwnmi
> stuff isn't super old.
>
>> >> While this isn't exactly terrible, it may be a weakness in our thinking
>> >> and our infrastructure.  I'm bringing it up so the people in charge are
>> >> aware :)
>> >
>> > Thanks.
>> >
>> > It almost feels like they need a way to temporarily hold off
>> > 'completion' of migratio - i.e. the phase where we stop the CPU and
>> > write the device data;  mind you you'd also probably want it to stop
>> > cold-migrates/snapshots?
>> 
>> Yes, a proper way to delay 'completion' for a bit would be clearer, and
>> wouldn't let -only-migrate interfere.
>
> Right.  If that becomes a thing, we should use it here.  Note that
> this one use case probably isn't a very strong argument for it,
> though.  The only problem here is slightly less that optimal error
> reporting in a rare edge case (hardware fault occurs by chance at the
> same time as a migration).
>
>
> .... and, also, I half-suspect that the whole fwnmi feature exists
> more to tick IBM RAS check boxes than because anyone will actually use
> it.

Right now the problem is when we broke migration stream.  Sometime there
is a field that is only needed on rare ocassions (othrewise we would
have found it right away).  But only thing that we can do now is abort
the migration.  If we were able to say, try it a little later, we could
fix that kind of trouble.

That is more or less what you have here.

Later, Juan.




reply via email to

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