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. But the bug in XBZRLE is still there ;-) 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.pri...@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 / dgilb...@redhat.com / Manchester, UK >>>> >> >
