Re: [Qemu-devel] [pve-devel] QEMU LIve Migration - swap_free: Bad swap file entry

[Orit Wasserman <owasserm@redhat.com>]

On 02/11/2014 03:33 PM, Stefan Priebe - Profihost AG wrote:
>
> Am 11.02.2014 14:32, schrieb Orit Wasserman:
>> On 02/08/2014 09:23 PM, Stefan Priebe wrote:
>>> i could fix it by explicitly disable xbzrle - it seems its
>>> automatically on if i do not set the migration caps to false.
>>>
>>> So it seems to be a xbzrle bug.
>>>
>>
>> XBZRLE is disabled by default (actually all capabilities are off by
>> default)
>> What version of QEMU are you using that you need to disable it explicitly?
>> Maybe you run migration with XBZRLE and canceled it, so it stays on?
>
> No real idea why this happens - but yes this seems to be a problem for me.
>

I checked upstream QEMU and it is still off by default (always been)

> But the bug in XBZRLE is still there ;-)
>

We need to understand the exact scenario in order to understand the problem.

What exact version of Qemu are you using?
Can you try with the latest upstream version, there were some fixes to the
XBZRLE code?

> Stefan
>
>> Orit
>>
>>> Stefan
>>>
>>> Am 07.02.2014 21:10, schrieb Stefan Priebe:
>>>> Am 07.02.2014 21:02, schrieb Dr. David Alan Gilbert:
>>>>> * Stefan Priebe (s.priebe@profihost.ag) wrote:
>>>>>> anything i could try or debug? to help to find the problem?
>>>>>
>>>>> I think the most useful would be to see if the problem is
>>>>> a new problem in the 1.7 you're using or has existed
>>>>> for a while; depending on the machine type you used, it might
>>>>> be possible to load that image on an earlier (or newer) qemu
>>>>> and try the same test, however if the problem doesn't
>>>>> repeat reliably it can be hard.
>>>>
>>>> I've seen this first with Qemu 1.5 but was not able to reproduce it for
>>>> month. 1.4 was working fine.
>>>>
>>>>> If you have any way of simplifying the configuration of the
>>>>> VM it would be good; e.g. if you could get a failure on
>>>>> something without graphics (-nographic) and USB.
>>>>
>>>> Sadly not ;-(
>>>>
>>>>> Dave
>>>>>
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> Am 07.02.2014 14:45, schrieb Stefan Priebe - Profihost AG:
>>>>>>> it's always the same "pattern" there are too many 0 instead of X.
>>>>>>>
>>>>>>> only seen:
>>>>>>>
>>>>>>> read:0x0000000000000000 ... expected:0xffffffffffffffff
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> read:0xffffffff00000000 ... expected:0xffffffffffffffff
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> read:0x0000bf000000bf00 ... expected:0xffffbfffffffbfff
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> read:0x0000000000000000 ... expected:0xb5b5b5b5b5b5b5b5
>>>>>>>
>>>>>>> no idea if this helps.
>>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>> Am 07.02.2014 14:39, schrieb Stefan Priebe - Profihost AG:
>>>>>>>> Hi,
>>>>>>>> Am 07.02.2014 14:19, schrieb Paolo Bonzini:
>>>>>>>>> Il 07/02/2014 14:04, Stefan Priebe - Profihost AG ha scritto:
>>>>>>>>>> first of all i've now a memory image of a VM where i can
>>>>>>>>>> reproduce it.
>>>>>>>>>
>>>>>>>>> You mean you start that VM with -incoming 'exec:cat
>>>>>>>>> /path/to/vm.img'?
>>>>>>>>> But google stress test doesn't report any error until you start
>>>>>>>>> migration _and_ it finishes?
>>>>>>>>
>>>>>>>> Sorry no i meant i have a VM where i saved the memory to disk - so i
>>>>>>>> don't need to wait hours until i can reproduce as it does not happen
>>>>>>>> with a fresh started VM. So it's a state file i think.
>>>>>>>>
>>>>>>>>> Another test:
>>>>>>>>>
>>>>>>>>> - start the VM with -S, migrate, do errors appear on the
>>>>>>>>> destination?
>>>>>>>>
>>>>>>>> I started with -S and the errors appear AFTER resuming/unpause
>>>>>>>> the VM.
>>>>>>>> So it is fine until i resume it on the "new" host.
>>>>>>>>
>>>>>>>> Stefan
>>>>>>>>
>>>>>>
>>>>> --
>>>>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>>>>>
>>>
>>