Hi, Juan Thanks for your reply.
Yesterday, my disk has no space. So, the core-dump file not saved completely. The info of core-dump file is: #0 0x00007f7a0dbff341 in migration_thread (opaque=0x7f7a0e16cbc0) at migration.c:545 545 double bandwidth = transferred_bytes / time_spent; (gdb) bt #0 0x00007f7a0dbff341 in migration_thread (opaque=0x7f7a0e16cbc0) at migration.c:545 #1 0x00007f7a0becad14 in start_thread (arg=0x7f7957fff700) at pthread_create.c:309 #2 0x00007f7a07cf267d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) l 540 } 541 current_time = qemu_get_clock_ms(rt_clock); 542 if (current_time >= initial_time + BUFFER_DELAY) { 543 uint64_t transferred_bytes = qemu_ftell(s->file) - initial_bytes; 544 uint64_t time_spent = current_time - initial_time - sleep_time; 545 double bandwidth = transferred_bytes / time_spent; 546 max_size = bandwidth * migrate_max_downtime() / 1000000; 547 548 DPRINTF("transferred %" PRIu64 " time_spent %" PRIu64 549 " bandwidth %g max_size %" PRId64 "\n", (gdb) p time_spent $1 = 0 (gdb) p current_time $2 = 23945934 (gdb) p initial_time $3 = 23945833 (gdb) p sleep_time $4 = 101 (gdb) p s->file->last_error $5 = 0 I tested three times. And the value of sleep_time are: 101,100,101 I think that the transfer may be so fast(use a very little time, the bytes_xfer > xfer_limit), and the "g_usleep" function may not be very accurate. So the value of sleep_time may be 100(BUFFER_DELAY) or just a bit more than 100(BUFFER_DELAY). I don't know whether my understanding is correct? Below is my simple patch for evade this problem. Is that correct? But I don't know why using your patch may trigger the problem. diff --git a/migration.c b/migration.c index 3b4b467..58d69fb 100644 --- a/migration.c +++ b/migration.c @@ -503,6 +503,7 @@ static void *migration_thread(void *opaque) int64_t max_size = 0; int64_t start_time = initial_time; bool old_vm_running = false; + double bandwidth = 0; DPRINTF("beginning savevm\n"); qemu_savevm_state_begin(s->file, &s->params); @@ -542,7 +543,13 @@ static void *migration_thread(void *opaque) if (current_time >= initial_time + BUFFER_DELAY) { uint64_t transferred_bytes = qemu_ftell(s->file) - initial_bytes; uint64_t time_spent = current_time - initial_time - sleep_time; - double bandwidth = transferred_bytes / time_spent; + if (time_spent > 0) { + bandwidth = transferred_bytes / time_spent; + } + else { + //when time_spent <= 0, don't change the value of bandwidth. + DPRINTF("time_spent=%" PRIu64 " is too small.\n",time_spent); + } max_size = bandwidth * migrate_max_downtime() / 1000000; DPRINTF("transferred %" PRIu64 " time_spent %" PRIu64 @@ -550,7 +557,7 @@ static void *migration_thread(void *opaque) transferred_bytes, time_spent, bandwidth, max_size); /* if we haven't sent anything, we don't want to recalculate 10000 is a small enough number for our purposes */ - if (s->dirty_bytes_rate && transferred_bytes > 10000) { + if (s->dirty_bytes_rate && transferred_bytes > 10000 && bandwidth > 0) { s->expected_downtime = s->dirty_bytes_rate / bandwidth; } > Re: [PATCH 0/4] QEMUFile improvements and simplifications > > "Liuji (Jeremy)" <jeremy....@huawei.com> wrote: > > Hi, Paolo > > > > I tested your 4 patches in the latest version of qemu.git/master(commit: > > 93b48c201eb6c0404d15550a0eaa3c0f7937e35e,2013-04-09). > > These patches resolve the "savevm hanging" problem, which is detailedly > described > > in my preceding mail:"After executing "savevm", the QEMU process is > hanging". > > > > But, I found two other problem: > > 1、My VM's OS is winxp. After the execution of "savevm" is completed, > > I exec "loadvm". > > But the winxp change to "blue screen", and then restart. I tested 3 > > times, but the results are same. > > > > 2、The block migration is not OK. The qemu-system-x86_64 process of > > source host is core-dump. > > In the latest version of > > > qemu.git/master(commit:93b48c201eb6c0404d15550a0eaa3c0f7937e35e,201 > 3-04-09), > > the block migration is OK. > > > > > > The info of core-dump file: > > #0 0x00007f8a44cec341 in migration_thread (opaque=0x7f8a45259bc0) at > > migration.c:545 > > 545 double bandwidth = transferred_bytes / time_spent; > > (gdb) bt > > #0 0x00007f8a44cec341 in migration_thread (opaque=0x7f8a45259bc0) at > > migration.c:545 > > #1 0x00007f8a42fb7d14 in ?? () > > #2 0x0000000000000000 in ?? () > > > > Could you recompile with -g to see what is going on? > This really makes no sense :p It looks like the source file and the > compiled version don't agree. > > Paolo, any clue? > > /me re-reads: block-migration, ok, testing goes. > > Later, Juan.