From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr1fc-0007RI-RT for qemu-devel@nongnu.org; Wed, 19 Nov 2014 04:35:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr1fW-00062v-KD for qemu-devel@nongnu.org; Wed, 19 Nov 2014 04:35:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr1fW-00062o-Dv for qemu-devel@nongnu.org; Wed, 19 Nov 2014 04:35:22 -0500 Date: Wed, 19 Nov 2014 09:35:16 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141119093516.GA2355@work-vm> References: <546B781B.3070309@gmail.com> <546B791B.6040908@gmail.com> <20141118202805.GC29868@work-vm> <546BBC54.5050900@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546BBC54.5050900@redhat.com> Subject: Re: [Qemu-devel] Tunneled Migration with Non-Shared Storage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Gary R Hook , qemu-devel@nongnu.org * Paolo Bonzini (pbonzini@redhat.com) wrote: > > > On 18/11/2014 21:28, Dr. David Alan Gilbert wrote: > > This seems odd, since as far as I know the tunneling code is quite separate > > to the migration code; I thought the only thing that the migration > > code sees different is the file descriptors it gets past. > > (Having said that, again I don't know storage stuff, so if this > > is a storage special there may be something there...) > > Tunnelled migration uses the old block-migration.c code. Non-tunnelled > migration uses the NBD server and block/mirror.c. OK, that explains that. Is that because the tunneling code can't deal with tunneling the NBD server connection? > The main problem with > the old code is that uses a possibly unbounded amount of memory in > mig_save_device_dirty and can have huge jitter if any serious workload > is running in the guest. So that's sending dirty blocks iteratively? Not that I can see when the allocations get freed; but is the amount allocated there related to total disk size (as Gary suggested) or to the amount of dirty blocks? Dave > > Paolo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK