From: Wen Congyang <wency@cn.fujitsu.com>
To: Stefan Hajnoczi <stefanha@redhat.com>,
Juan Quintela <quintela@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
hangaohuai@huawei.com,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
Li Zhijian <lizhijian@cn.fujitsu.com>,
Michael Tsirkin <mst@redhat.com>,
qemu-devel@nongnu.org,
"Dr. David Alan Gilbert (git)" <dgilbert@redhat.com>,
"Gonglei (Arei)" <arei.gonglei@huawei.com>,
Amit Shah <amit.shah@redhat.com>,
peter.huangpeng@huawei.com, david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration
Date: Fri, 27 Mar 2015 17:14:01 +0800 [thread overview]
Message-ID: <55151F59.8020000@cn.fujitsu.com> (raw)
In-Reply-To: <20150327085634.GB3304@stefanha-thinkpad.redhat.com>
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 <wency@cn.fujitsu.com> wrote:
>>> On 03/25/2015 05:50 PM, Juan Quintela wrote:
>>>> zhanghailiang <zhang.zhanghailiang@huawei.com> 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
>
next prev parent reply other threads:[~2015-03-27 9:11 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 9:31 [Qemu-devel] [Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration zhanghailiang
2015-03-25 9:46 ` Dr. David Alan Gilbert
2015-03-25 11:28 ` zhanghailiang
2015-03-25 11:36 ` Dr. David Alan Gilbert
2015-03-25 11:48 ` zhanghailiang
2015-03-25 9:50 ` Juan Quintela
2015-03-25 10:21 ` Wen Congyang
2015-03-25 13:12 ` Paolo Bonzini
2015-03-26 1:43 ` Wen Congyang
2015-03-25 11:32 ` zhanghailiang
2015-03-26 3:12 ` Wen Congyang
2015-03-26 3:52 ` Li Zhijian
2015-03-27 10:13 ` zhanghailiang
2015-03-27 10:18 ` Dr. David Alan Gilbert
2015-03-28 9:54 ` zhanghailiang
2015-03-30 7:59 ` Dr. David Alan Gilbert
2015-03-31 11:48 ` zhanghailiang
2015-03-31 19:06 ` Dr. David Alan Gilbert
2015-04-02 11:52 ` zhanghailiang
2015-04-02 13:00 ` Paolo Bonzini
2015-04-03 8:51 ` Jason Wang
2015-04-03 9:08 ` Wen Congyang
2015-04-03 9:20 ` zhanghailiang
2015-04-08 8:08 ` Jason Wang
2015-03-27 10:51 ` Juan Quintela
2015-03-28 1:08 ` zhanghailiang
2015-03-26 10:29 ` Juan Quintela
2015-03-26 11:57 ` Michael S. Tsirkin
2015-03-27 8:56 ` Stefan Hajnoczi
2015-03-27 9:14 ` Wen Congyang [this message]
2015-03-27 9:57 ` Stefan Hajnoczi
2015-03-27 10:05 ` Wen Congyang
2015-03-27 10:11 ` Stefan Hajnoczi
2015-03-27 10:36 ` Juan Quintela
2015-03-27 10:34 ` Juan Quintela
2015-03-31 7:54 ` Wen Congyang
2015-03-31 14:16 ` Stefan Hajnoczi
2015-04-02 9:14 ` Wen Congyang
2015-04-02 13:17 ` Paolo Bonzini
2015-04-03 1:29 ` Wen Congyang
2015-04-03 10:56 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55151F59.8020000@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=amit.shah@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=hangaohuai@huawei.com \
--cc=kwolf@redhat.com \
--cc=lizhijian@cn.fujitsu.com \
--cc=mst@redhat.com \
--cc=peter.huangpeng@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).