[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