qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v9 00/56] Postcopy implementation


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v9 00/56] Postcopy implementation
Date: Fri, 6 Nov 2015 09:09:53 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

* Bharata B Rao (address@hidden) wrote:
> On Thu, Nov 05, 2015 at 06:10:27PM +0000, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> >   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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]