From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: zhanghailiang <zhang.zhanghailiang@huawei.com>
Cc: hangaohuai@huawei.com, Li Zhijian <lizhijian@cn.fujitsu.com>,
Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org, peter.huangpeng@huawei.com,
"Gonglei (Arei)" <arei.gonglei@huawei.com>,
Amit Shah <amit.shah@redhat.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: Wed, 25 Mar 2015 09:46:40 +0000 [thread overview]
Message-ID: <20150325094639.GB2313@work-vm> (raw)
In-Reply-To: <55128084.2040304@huawei.com>
* 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 reproduce:
>
> (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
> (qemu) migrate tcp:192.168.3.8:3004
> before saving ram complete
> ff703f6889ab8701e4e040872d079a28
> md_host : after saving ram complete
> ff703f6889ab8701e4e040872d079a28
>
> DST: # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cpu qemu64,-kvmclock -netdev tap,id=hn0,vhost=on -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 -incoming tcp:0:3004
> (qemu) QEMU_VM_SECTION_END, after loading ram
> 230e1e68ece9cd4e769630e1bcb5ddfb
> md_host : after loading all vmstate
> 230e1e68ece9cd4e769630e1bcb5ddfb
> md_host : after cpu_synchronize_all_post_init
> 230e1e68ece9cd4e769630e1bcb5ddfb
>
> This happens occasionally, and it is more easy to reproduce when issue migration command during VM's startup time.
>
> 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.
>
> Actually, the first time we found this problem was in the COLO FT development, and it triggered some strange issues in
> VM which all pointed to the issue of inconsistent of VM's memory. (We have try to save all memory of VM to slave side every time
> when do checkpoint in COLO FT, and everything will be OK.)
>
> Is it OK for some pages that not transferred to destination when do migration ? Or is it a bug?
That does sound like a bug.
The only other explanation I have is that memory is being changed by a device emulation
that happens after the end of a saving the vm, or after loading the memory. That's
certainly possible - especially if a device (say networking) hasn't been properly
stopped.
> This issue has blocked our COLO development... :(
>
> Any help will be greatly appreciated!
I suggest:
1) Does it happen with devices other than virtio?
2) Strip the devices down - e.g. just run with serial and no video/usb
3) Try doing the md5 comparison at the end of ram_save_complete
4) mprotect RAM after the ram_save_complete and see if anything faults.
5) Can you trigger this with normal migration or just COLO?
I'm wondering if something is doing something on a running/paused/etc state
change and isn't expecting the new COLO states.
Dave
>
> Thanks,
> zhanghailiang
>
> --- a/savevm.c
> +++ b/savevm.c
> @@ -51,6 +51,26 @@
> #define ARP_PTYPE_IP 0x0800
> #define ARP_OP_REQUEST_REV 0x3
>
> +#include "qemu/rcu_queue.h"
> +#include <openssl/md5.h>
> +
> +static void check_host_md5(void)
> +{
> + int i;
> + unsigned char md[MD5_DIGEST_LENGTH];
> + MD5_CTX ctx;
> + RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check 'pc.ram' block */
> +
> + MD5_Init(&ctx);
> + MD5_Update(&ctx, (void *)block->host, block->used_length);
> + MD5_Final(md, &ctx);
> + printf("md_host : ");
> + for(i = 0; i < MD5_DIGEST_LENGTH; i++) {
> + fprintf(stderr, "%02x", md[i]);
> + }
> + fprintf(stderr, "\n");
> +}
> +
> static int announce_self_create(uint8_t *buf,
> uint8_t *mac_addr)
> {
> @@ -741,7 +761,13 @@ void qemu_savevm_state_complete(QEMUFile *f)
> qemu_put_byte(f, QEMU_VM_SECTION_END);
> qemu_put_be32(f, se->section_id);
>
> + printf("before saving %s complete\n", se->idstr);
> + check_host_md5();
> +
> ret = se->ops->save_live_complete(f, se->opaque);
> + printf("after saving %s complete\n", se->idstr);
> + check_host_md5();
> +
> trace_savevm_section_end(se->idstr, se->section_id, ret);
> if (ret < 0) {
> qemu_file_set_error(f, ret);
> @@ -1030,6 +1063,11 @@ int qemu_loadvm_state(QEMUFile *f)
> }
>
> ret = vmstate_load(f, le->se, le->version_id);
> + if (section_type == QEMU_VM_SECTION_END) {
> + printf("QEMU_VM_SECTION_END, after loading %s\n", le->se->idstr);
> + check_host_md5();
> + }
> +
> if (ret < 0) {
> error_report("error while loading state section id %d(%s)",
> section_id, le->se->idstr);
> @@ -1061,7 +1099,11 @@ int qemu_loadvm_state(QEMUFile *f)
> g_free(buf);
> }
>
> + printf("after loading all vmstate\n");
> + check_host_md5();
> cpu_synchronize_all_post_init();
> + printf("after cpu_synchronize_all_post_init\n");
> + check_host_md5();
>
> ret = 0;
>
> --
> From ecb789cf7f383b112da3cce33eb9822a94b9497a Mon Sep 17 00:00:00 2001
> From: Li Zhijian <lizhijian@cn.fujitsu.com>
> Date: Tue, 24 Mar 2015 21:53:26 -0400
> Subject: [PATCH] check pc.ram block md5sum between migration Source and
> Destination
>
> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
> ---
> savevm.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
> mode change 100644 => 100755 savevm.c
>
> diff --git a/savevm.c b/savevm.c
> old mode 100644
> new mode 100755
> index 3b0e222..3d431dc
> --- a/savevm.c
> +++ b/savevm.c
> @@ -51,6 +51,26 @@
> #define ARP_PTYPE_IP 0x0800
> #define ARP_OP_REQUEST_REV 0x3
>
> +#include "qemu/rcu_queue.h"
> +#include <openssl/md5.h>
> +
> +static void check_host_md5(void)
> +{
> + int i;
> + unsigned char md[MD5_DIGEST_LENGTH];
> + MD5_CTX ctx;
> + RAMBlock *block = QLIST_FIRST_RCU(&ram_list.blocks);/* Only check 'pc.ram' block */
> +
> + MD5_Init(&ctx);
> + MD5_Update(&ctx, (void *)block->host, block->used_length);
> + MD5_Final(md, &ctx);
> + printf("md_host : ");
> + for(i = 0; i < MD5_DIGEST_LENGTH; i++) {
> + fprintf(stderr, "%02x", md[i]);
> + }
> + fprintf(stderr, "\n");
> +}
> +
> static int announce_self_create(uint8_t *buf,
> uint8_t *mac_addr)
> {
> @@ -741,7 +761,13 @@ void qemu_savevm_state_complete(QEMUFile *f)
> qemu_put_byte(f, QEMU_VM_SECTION_END);
> qemu_put_be32(f, se->section_id);
>
> + printf("before saving %s complete\n", se->idstr);
> + check_host_md5();
> +
> ret = se->ops->save_live_complete(f, se->opaque);
> + printf("after saving %s complete\n", se->idstr);
> + check_host_md5();
> +
> trace_savevm_section_end(se->idstr, se->section_id, ret);
> if (ret < 0) {
> qemu_file_set_error(f, ret);
> @@ -1007,6 +1033,13 @@ int qemu_loadvm_state(QEMUFile *f)
> QLIST_INSERT_HEAD(&loadvm_handlers, le, entry);
>
> ret = vmstate_load(f, le->se, le->version_id);
> +#if 0
> + if (section_type == QEMU_VM_SECTION_FULL) {
> + printf("QEMU_VM_SECTION_FULL, after loading %s\n", le->se->idstr);
> + check_host_md5();
> + }
> +#endif
> +
> if (ret < 0) {
> error_report("error while loading state for instance 0x%x of"
> " device '%s'", instance_id, idstr);
> @@ -1030,6 +1063,11 @@ int qemu_loadvm_state(QEMUFile *f)
> }
>
> ret = vmstate_load(f, le->se, le->version_id);
> + if (section_type == QEMU_VM_SECTION_END) {
> + printf("QEMU_VM_SECTION_END, after loading %s\n", le->se->idstr);
> + check_host_md5();
> + }
> +
> if (ret < 0) {
> error_report("error while loading state section id %d(%s)",
> section_id, le->se->idstr);
> @@ -1061,7 +1099,11 @@ int qemu_loadvm_state(QEMUFile *f)
> g_free(buf);
> }
>
> + printf("after loading all vmstate\n");
> + check_host_md5();
> cpu_synchronize_all_post_init();
> + printf("after cpu_synchronize_all_post_init\n");
> + check_host_md5();
>
> ret = 0;
>
> --
> 1.7.12.4
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2015-03-25 9:46 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 [this message]
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
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=20150325094639.GB2313@work-vm \
--to=dgilbert@redhat.com \
--cc=amit.shah@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=david@gibson.dropbear.id.au \
--cc=hangaohuai@huawei.com \
--cc=lizhijian@cn.fujitsu.com \
--cc=peter.huangpeng@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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).