qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 15/28] migration: create new section to store glo


From: Juan Quintela
Subject: Re: [Qemu-devel] [PULL 15/28] migration: create new section to store global state
Date: Wed, 08 Jul 2015 14:25:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Christian Borntraeger <address@hidden> wrote:
> Am 08.07.2015 um 14:08 schrieb Juan Quintela:
>> Christian Borntraeger <address@hidden> wrote:
>>> Am 07.07.2015 um 15:08 schrieb Juan Quintela:
>>>> This includes a new section that for now just stores the current qemu 
>>>> state.
>>>>
>>>> Right now, there are only one way to control what is the state of the
>>>> target after migration.
>>>>
>>>> - If you run the target qemu with -S, it would start stopped.
>>>> - If you run the target qemu without -S, it would run just after
>>>> migration finishes.
>>>>
>>>> The problem here is what happens if we start the target without -S and
>>>> there happens one error during migration that puts current state as
>>>> -EIO.  Migration would ends (notice that the error happend doing block
>>>> IO, network IO, i.e. nothing related with migration), and when
>>>> migration finish, we would just "continue" running on destination,
>>>> probably hanging the guest/corruption data, whatever.
>>>>
>>>> Signed-off-by: Juan Quintela <address@hidden>
>>>> Reviewed-by: Dr. David Alan Gilbert <address@hidden>
>>>
>>> This is bisected to cause a regression on s390.
>>>
>>> A guest restarts (booting) after managedsave/start instead of continuing.
>>>
>>> Do you have any idea what might be wrong?
>> 
>> Can you check the new patch series that I sent.  There is a fix that
>> *could* help there.  *could* because I don't fully understand why it can
>> give you problems (and even only sometimes).  Current guess is that some
>> of the devices are testing the guest state on LOAD, so that patch.
>> 
>> Please, test.
>
> That patch does indeed fix my problem.
> I can see that virtio_init uses the runstate to set vm_running of the vdev. 
> This
> is used in virtio-net for several aspects.
> But I really dont understand why this causes the symptoms.
> So I am tempted to add
> a
> Tested-by: Christian Borntraeger <address@hidden>
>
> but I have a bad feeling on the "why" :-/

The other reason of that patch is that it removes the need that the
global_state is the last migration section.  Could it be that you are
adding sections after you launch qemu?  Or that virtio devices are
generated later on s390 for any reason?

Later, Juan.



reply via email to

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