Bug 522663

Summary:	libvirtd should return when it is fully initialized
Product:	[Community] Virtualization Tools	Reporter:	Laurent Léonard <laurent>
Component:	libvirt	Assignee:	Daniel Veillard <veillard>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	unspecified	CC:	agx, berrange, crobinso, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-11-26 15:15:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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):
0.7.0

How reproducible:
Always

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

http://www.redhat.com/archives/libvir-list/2009-October/msg00654.html

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