From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbQI4-0004LZ-B4 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 05:11:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbQHy-0002Jd-J8 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 05:10:56 -0400 Received: from [59.151.112.132] (port=2918 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbQHy-0002JE-7t for qemu-devel@nongnu.org; Fri, 27 Mar 2015 05:10:50 -0400 Message-ID: <55151F59.8020000@cn.fujitsu.com> Date: Fri, 27 Mar 2015 17:14:01 +0800 From: Wen Congyang MIME-Version: 1.0 References: <55128084.2040304@huawei.com> <87a8z12yot.fsf@neno.neno> <5513793B.6020909@cn.fujitsu.com> <874mp8xd9k.fsf@neno.neno> <20150327085634.GB3304@stefanha-thinkpad.redhat.com> In-Reply-To: <20150327085634.GB3304@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi , Juan Quintela Cc: Kevin Wolf , hangaohuai@huawei.com, zhanghailiang , Li Zhijian , Michael Tsirkin , qemu-devel@nongnu.org, "Dr. David Alan Gilbert (git)" , "Gonglei (Arei)" , Amit Shah , peter.huangpeng@huawei.com, david@gibson.dropbear.id.au On 03/27/2015 04:56 PM, Stefan Hajnoczi wrote: > 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 continue to Run. >>>>> >>>>> We use a patch like bellow to find this issue, you can find it from affix, >>>>> and Steps to reprduce: >>>>> >>>>> (1) Compile QEMU: >>>>> ./configure --target-list=x86_64-softmmu --extra-ldflags="-lssl" && make >>>>> >>>>> (2) Command and output: >>>>> SRC: # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cpu >>>>> qemu64,-kvmclock -netdev tap,id=hn0-device >>>>> virtio-net-pci,id=net-pci0,netdev=hn0 -boot c -drive >>>>> file=/mnt/sdb/pure_IMG/sles/sles11_sp3.img,if=none,id=drive-virtio-disk0,cache=unsafe >>>>> -device >>>>> virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 >>>>> -vnc :7 -m 2048 -smp 2 -device piix3-usb-uhci -device usb-tablet >>>>> -monitor stdio >>>> >>>> Could you try to reproduce: >>>> - without vhost >>>> - without virtio-net >>>> - cache=unsafe 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=on, it still doesn't happen. I guess >>> it is because I migrate the guest when it is booting. The virtio net >>> device is not used in this case. >> >> Kevin, Stefan, Michael, any great idea? > > You must use -drive cache=none if you want to use live migration. It > should not directly affect memory during migration though. Otherwise, what will happen? If the user doesn't use cache=none, and tries to use live migration, qemu doesn't output any message or trigger an event to notify the user. Thanks Wen Congyang > >>>>> 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. >>>> >>>> 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 >