From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbQ4Z-0004xX-6I for qemu-devel@nongnu.org; Fri, 27 Mar 2015 04:57:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbQ4U-0005ix-S1 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 04:56:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbQ4U-0005iR-K3 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 04:56:54 -0400 Date: Fri, 27 Mar 2015 08:56:34 +0000 From: Stefan Hajnoczi Message-ID: <20150327085634.GB3304@stefanha-thinkpad.redhat.com> References: <55128084.2040304@huawei.com> <87a8z12yot.fsf@neno.neno> <5513793B.6020909@cn.fujitsu.com> <874mp8xd9k.fsf@neno.neno> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline In-Reply-To: <874mp8xd9k.fsf@neno.neno> Subject: Re: [Qemu-devel] [Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Kevin Wolf , hangaohuai@huawei.com, zhanghailiang , Michael Tsirkin , Li Zhijian , qemu-devel@nongnu.org, "Dr. David Alan Gilbert (git)" , "Gonglei (Arei)" , Amit Shah , peter.huangpeng@huawei.com, david@gibson.dropbear.id.au --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2015 at 11:29:43AM +0100, Juan Quintela wrote: > Wen Congyang wrote: > > On 03/25/2015 05:50 PM, Juan Quintela wrote: > >> zhanghailiang wrote: > >>> Hi all, > >>> > >>> We found that, sometimes, the content of VM's memory is > >>> inconsistent between Source side and Destination side > >>> when we check it just after finishing migration but before VM continu= e to Run. > >>> > >>> We use a patch like bellow to find this issue, you can find it from a= ffix, > >>> and Steps to reprduce: > >>> > >>> (1) Compile QEMU: > >>> ./configure --target-list=3Dx86_64-softmmu --extra-ldflags=3D"-lssl= " && make > >>> > >>> (2) Command and output: > >>> SRC: # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cpu > >>> qemu64,-kvmclock -netdev tap,id=3Dhn0-device > >>> virtio-net-pci,id=3Dnet-pci0,netdev=3Dhn0 -boot c -drive > >>> file=3D/mnt/sdb/pure_IMG/sles/sles11_sp3.img,if=3Dnone,id=3Ddrive-vir= tio-disk0,cache=3Dunsafe > >>> -device > >>> virtio-blk-pci,bus=3Dpci.0,addr=3D0x4,drive=3Ddrive-virtio-disk0,id= =3Dvirtio-disk0 > >>> -vnc :7 -m 2048 -smp 2 -device piix3-usb-uhci -device usb-tablet > >>> -monitor stdio > >>=20 > >> Could you try to reproduce: > >> - without vhost > >> - without virtio-net > >> - cache=3Dunsafe is going to give you trouble, but trouble should only > >> happen after migration of pages have finished. > > > > If I use ide disk, it doesn't happen. > > Even if I use virtio-net with vhost=3Don, it still doesn't happen. I gu= ess > > it is because I migrate the guest when it is booting. The virtio net > > device is not used in this case. >=20 > Kevin, Stefan, Michael, any great idea? You must use -drive cache=3Dnone if you want to use live migration. It should not directly affect memory during migration though. > >>> We have done further test and found that some pages has been > >>> dirtied but its corresponding migration_bitmap is not set. > >>> We can't figure out which modules of QEMU has missed setting bitmap > >>> when dirty page of VM, > >>> it is very difficult for us to trace all the actions of dirtying VM's= pages. > >>=20 > >> This seems to point to a bug in one of the devices. I think you'll need to track down which pages are different. If you are lucky, their contents will reveal what the page is used for. Stefan --nVMJ2NtxeReIH9PS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVFRtCAAoJEJykq7OBq3PIVRkH/1oLgVlQKezDVeVgqOIYsSzM i5wDrTAq24d49bdxmhkWsDYGslYXGN8l97kk2iuZZ5rWsCfELhJQFQguEGXJT/1q PrOTx84WmAHTYhBly3GsmWgiR8Vn61jv+MJSnAz4DIn7BbHf9IDjsTvPeoaJA0Dk +hq20nyEhA3J2WIBDwl4Qz5RH00HSLiYtta45MCC2wipOX4SvniT/RyjGBBQnm7F lTxMGJ4//DaAj0ubHtSBFY7zeGGRTSYbOM+cP8ANOF5xVqnWRSz3MH1eRFUBeO6F aTyC4U18oRMMvIQjjY5x3T0Qpac3XaHuN4baf52s0VGX4En/cFlX9sh8OpfUyis= =Qlwv -----END PGP SIGNATURE----- --nVMJ2NtxeReIH9PS--