* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote: > On Thu, Nov 05, 2015 at 06:10:27PM +0000, Dr. David Alan Gilbert (git) wrote: > > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > > > This is the 9th cut of my version of postcopy. > > > > The userfaultfd linux kernel code is now in the upstream kernel > > tree, and so 4.3 can be used without modification. > > > > This qemu series can be found at: > > https://github.com/orbitfp7/qemu.git > > on the wp3-postcopy-v9 tag > > > > Testing status: > > * Tested heavily on x86 > > * Smoke tested on aarch64 (so it does work on different page sizes) > > Tested minimally on ppc64 with back and forth postcopy migration of > unloaded pseries guest within the localhost - works as expected. > > However I am seeing a failure in one case. I am not sure if this is > a user error or a real issue in postcopy migration. If I switch to postcopy > migration immediately after starting the migration, I see the migration > failing with error: > > qemu-system-ppc64: qemu_savevm_send_packaged: Unreasonably large packaged > state: 25905005
I put an arbitrary limit of 16MB (see MAX_VM_CMD_PACKAGED_SIZE in include/sysemu/sysemu.h) on the size of the data accepted into the packaged blob. How big is the htab data likely to be? Dave > 1. (qemu) migrate_set_capability x-postcopy-ram on > > 2. (qemu) migrate -d tcp:localhost:4444 > > 3. (qemu) info migrate > capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: > off compress: off events: off x-postcopy-ram: on > Migration status: active > total time: 4177 milliseconds > expected downtime: 300 milliseconds > setup: 75 milliseconds > transferred ram: 115523 kbytes > throughput: 155.69 mbps > remaining ram: 30117196 kbytes > total ram: 33554688 kbytes > duplicate: 835311 pages > skipped: 0 pages > normal: 24061 pages > normal bytes: 96244 kbytes > dirty sync count: 1 > > 4. (qemu) migrate_start_postcopy > > 5. (qemu) info migrate > capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: > off compress: off events: off x-postcopy-ram: on > Migration status: failed > total time: 0 milliseconds > > If I run 'info migrate' in step 3 a few more times before step 4, then > the migration succeeds. So is there a way to figure out when to switch > over to postcopy migration ? > > QEMU cmdline: ./ppc64-softmmu/qemu-system-ppc64 --enable-kvm --nographic -vga > none -machine pseries -m 32G,slots=32,maxmem=64G -smp 16 -device > virtio-blk-pci,drive=rootdisk -drive > file=/home/bharata/F20-snap1,if=none,cache=none,id=rootdisk,format=qcow2 > -monitor telnet:127.0.0.1:1234,server,nowait > > Host: 4.3.0-rc7+ > > Regards, > Bharata. > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK