[Top][All Lists]

[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: Christian Borntraeger
Subject: Re: [Qemu-devel] [PULL 15/28] migration: create new section to store global state
Date: Wed, 08 Jul 2015 14:34:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

Am 08.07.2015 um 14:25 schrieb Juan Quintela:
> 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.

Hmm, we have some register_savevm here and there, but these seem
to be called in device realize/init or machine init.

> Could it be that you are
> adding sections after you launch qemu?  Or that virtio devices are
> generated later on s390 for any reason?

Not that I am aware of. There can be hotplug of course, but I dont see
why libvirt should do that during migration.

Still looking.....

reply via email to

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