qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] efi var store migration assert (bdrv_co_do_pwritev: Ass


From: Laszlo Ersek
Subject: Re: [Qemu-devel] efi var store migration assert (bdrv_co_do_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.)
Date: Tue, 5 Apr 2016 13:34:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0

On 04/05/16 13:25, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (address@hidden) wrote:
>> On 04/05/16 12:48, Dr. David Alan Gilbert wrote:
>>> * Paolo Bonzini (address@hidden) wrote:
>>>>
>>>>
>>>> On 01/04/2016 19:58, Dr. David Alan Gilbert wrote:
>>>>> In the continuing journeys of trying to migrate a q35 guest with ovmf,
>>>>> I've just hit this assert:
>>>>>
>>>>> qemu-system-x86_64: /root/git/qemu/block/io.c:1297: bdrv_co_do_pwritev: 
>>>>> Assertion `!(bs->open_flags & 0x0800)' failed.
>>>>>
>>>>> This is just ahead of rc0 - 1458317c8ada834cf39287f6d11a8cb8a37360d6 from 
>>>>> yesterday.
>>>>
>>>> Try this...
>>>
>>> Well, migration survives; how do I test if pflash is sane after migration?
>>
>> You can run sha1sum before / after. The varstore is expected to change
>> only when the UEFI variable servies are exercised. So, if you boot e.g.
>> a Linux guest to a login prompt on the source host, checksum the
>> varstore, then migrate the guest, then verify the checksum on the target
>> host (or, well, shared storage, if you have set it up), it should match.
> 
> OK, yes that works; and I also tried using efibootmgr to tweak the timeout,
> seeing that the sha changed and then check the sha was correct again after
> migration.

Thank you both for fixing up the buggy-on-arrival code I had added.
Laszlo




reply via email to

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