Re: [Qemu-devel] [PATCH 0/3] Live migration without shared storage

[Pierre Riteau]

On 8 sept. 2009, at 15:26, Lennart Sorensen wrote:

> On Mon, Sep 07, 2009 at 06:40:51PM +0200, Pierre Riteau wrote:
> > I'm trying blk migration (not incremental) between two machines
> > connected over Gigabit ethernet.
> > The transfer is quite slow (about 2 MB/s over the wire).
> > While the load on the sending end is low (vmstat says ~2000 blocks  
> > in/
> > sec, and top says ~1% in io wait), on the receiving end I see  
> > almost 40%
> > CPU in io wait, kjournald takes 20% of the CPU and vmstat reports  
> > ~14000
> > blocks out/sec.
> >
> > Hosts are running Debian Lenny (2.6.26 32 bits), kvm-87 + your  
> > patches.
> > The guest is also running Debian Lenny and is idle io wise. I tried  
> > with
> > both idle and full cpu utilization, it doesn't change anything.
>
> If you happen to be using ext3, then that might explain it.  ext3 has
> long had issues with performance while slowly writing a large file
> (this affects mythtv a lot for example).  2.6.30 should improve  
> things a
> lot, although ext3 will never be great.  ext4 is better, and hopefully
> btrfs will be great (when done).  xfs is also supposed to handle such
> tasks very well.
>
> --
> Len Sorensen


Yes, I'm using ext3. When I tested last week, I created the disk image  
on the destination machine using qemu-img create -f raw, which creates  
a sparse file.
I experimented again today, but this time I allocated all the blocks  
in the disk image prior to the migration.
This resulted in increased throughput (between 6 and 8 MB/s on the  
wire), reduced CPU usage on the destination node (now qemu is the top  
CPU user, not kjournald), and the IO interrupt numbers are similar on  
the origin and destination node (about 7000/s).
Still, it could be better, but I see Liran is working on it :)

--
Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/