* Paolo Bonzini (pbonz...@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 / dgilb...@redhat.com / Manchester, UK
