Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 522663 - libvirtd should return when it is fully initialized
Summary: libvirtd should return when it is fully initialized
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2009-09-11 00:57 UTC by Laurent Léonard
Modified: 2010-03-16 17:23 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-26 15:15:43 UTC

Attachments (Terms of Use)

Description Laurent Léonard 2009-09-11 00:57:54 UTC
Description of problem:
libvirtd returns but libvirt is not fully initialized.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. # libvirtd -d && /etc/init.d/libvirt-suspendonreboot start
2. libvirt should be started and the virsh-based script should work
Actual results:
The virsh-based script can't connect to libvirt:
resuming debian_sid ...
error: unable to connect to '/var/run/libvirt/libvirt-sock': Connexion refusée
error: failed to connect to the hypervisor

Expected results:
The virsh-based script should be able to connect to libvirt.

Additional info:
If the virsh-based script is launched 1/2 second later it works great:
# libvirtd -d && sleep 0.5 && /etc/init.d/libvirt-suspendonreboot start
resuming debian_sid ...
Domain restored from /var/lib/libvirt/autosuspend/debian_sid.dump

This problem is specially annoying when a virsh-based script should be executed at boot time, just after libvirt init script.

Comment 1 Daniel Berrangé 2009-10-23 16:53:15 UTC
This patch should address the problem


the libvirt initscript won't exit until at least the network sockets are setup, even though QEMU isn't initialized yet.

So any virsh process run immediately after starting will successfully make the TCP connection & be blocked until initialization is fully completed. This should avoids the 'failed to connect' race

Comment 2 Laurent Léonard 2009-10-25 00:12:24 UTC
I confirm your patch fixes the issue.

Comment 3 Daniel Berrangé 2009-11-26 15:15:43 UTC
Fixed in 0.7.4 release

Note You need to log in before you can comment on or make changes to this bug.