[libvirt-users] Quadratic function-like call delay

[Doug Goldstein]

On Mon, Sep 24, 2012 at 2:12 PM, Andrey Korolyov <andrey at xdel.ru> wrote:
> On Mon, Sep 24, 2012 at 4:35 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> On Mon, Sep 24, 2012 at 11:48:44AM +0400, Andrey Korolyov wrote:
>>> Hi,
>>>
>>> There is a quite annoying thing, don`t sure if I can call it a bug.
>>>
>>> How to reproduce:
>>>
>>> - start a bunch of VMs,
>>> - stop libvirt,
>>> - start libvirt and immediately issue any call, say, 'virsh version',
>>> - delay until call completion may be fitted nearly as quadratic
>>> function from number of running VMs, qemu-kvm in my case (see link
>>> below). After this delay passed, any calls executed without slowdown,
>>> so problem is only a 'dead gap' after restarting service.
>>
>> When you restart the libvirtd service, while KVM guests are running,
>> the first thing libvirtd needs todo is to connect to the QEMU monitor
>> for each guest and figure out its status. This can take some time
>> depending on how loaded the host is in general. It will definitely
>> slow libvirt API calls which need to query individual VMs, but I'm
>> rather surprised that you saw any slowdown of the 'virsh version'
>> command, since that should not touch VMs at all. So I think I *would*
>> class this as a bug. It could be something silly like the main I/O
>> event loop having some badly written bit of non-scalable code. Please
>> do file a bug about this, providing as much raw data as you have
>> managed to collect.
>>
>
> Here is a report, please take a look.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=860053
>

I've commented on the bug. But for what its worth, I see this as well
but the delay comes from the fact that I have a number of storage
pools marked as autostart. The solution^H^H^H^Hhack was to unmark them
from autostart and make an init script which started up all of my
storage pools. Now I can restart libvirt as often as I like with a
fairly linear with relation to VMs delay.

-- 
Doug Goldstein