[libvirt] Re: libvirk KVM save (migrate) terribly slow

Pierre Riteau Pierre.Riteau at irisa.fr
Thu Dec 10 12:30:00 UTC 2009


On 10 déc. 2009, at 12:44, Daniel P. Berrange wrote:

> On Thu, Dec 10, 2009 at 08:05:12AM +0100, Nikola Ciprich wrote:
>> Hi,
>> I noticed that using libvirt to save running domain is terribly slow,
>> I mean it can take even 10 minutes to save VM with 2GB RAM, although
>> the host is almost idle (8CPU, 16GB RAM). If I understand correctly, 
>> libvirt first pauses the vm and then migrates it to file (optionally through gzip).
>> Restoring it back to running state is almost instant.
>> I guess this is not what should be expected, is there something particular 
>> I should check?
> 
> This matches behaviour that I see when saving VMs. QEMU takes a really
> very long time to save itself using migrate exec:.  It is not CPU limited
> even in gzip mode - there is near zero CPU usage while this is going on.
> QEMU just seems to be very slow at sending the data. I've not had time to
> investigate whether this is a flaw in QEMU's exec: migration handling,
> or whether it is being hurt by too small pipe buffers, or something else
> entirely.  I must say I'm not entirely convinced that it is a good idea
> for QEMU to be mixing use of FILE * / popen, with non-blocking I/O, but
> that could be a red-herring.
> 
> Daniel

I've reported this issue back when the regression was introduced in qemu.
Anthony had the same idea (not mixing popen with non-blocking I/O), but no solution was found at the time.
I haven't tried recently (I'm using TCP migration only) but the problem must still be here.

The thread on qemu-devel:
http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg01557.html
http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00020.html

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





More information about the libvir-list mailing list