Bug 199415

Summary:	virDomainLookupByID fails on repeated calls with UNIX sockets disabled
Product:	[Fedora] Fedora	Reporter:	Bryan D. Payne <bryan>
Component:	libvirt	Assignee:	Daniel Veillard <veillard>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://www.bryanpayne.org/testing/libvirt.html
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-11-06 16:53:00 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 Bryan D. Payne 2006-07-19 13:53:35 UTC

Description of problem:
When running as root, with UNIX sockets disabled, calls to virDomainLookupByID
succeed the first time and fail the second time.  Turning on UNIX sockets in the
xend-config.sxp file removes this error condition.  However, a complete solution
 should include the following:
* failure condition should be reported more descriptively
* if it is a failure of communications, that should be detected and reported
* two successive calls should not behave differently
* maybe XML dump should be added too when using the proxy

Version-Release number of selected component (if applicable):
Failure occurs with version 0.1.3, not with version 0.1.1.

How reproducible:
Every time.

Steps to Reproduce:
1. Run xend with config found at URL below.
2. Run test code found at URL below.
http://www.bryanpayne.org/testing/libvirt.html
  
Actual results:
First call to virDomainLookupByID succeeds, second call fails.
[root@guinness examples]# ./test
(0) (null)
ERROR: Failed to find Domain 1
Failed on second try
[root@guinness examples]#

Expected results:
Both calls succeed.

Additional info:
Xen on my test machine was compiled from stable source version 3.0.2-2.  See
output from 'xm info' below for details.
[root@guinness examples]# xm info
host                   : guinness.beer.home
release                : 2.6.16-xen
version                : #1 SMP Tue Jun 20 22:00:41 EDT 2006
machine                : i686
nr_cpus                : 1
nr_nodes               : 1
sockets_per_node       : 1
cores_per_socket       : 1
threads_per_core       : 1
cpu_mhz                : 2202
hw_caps                :
078bfbff:e3d3fbff:00000000:00000010:00000000:00000001:00000001
total_memory           : 2048
free_memory            : 1
xen_major              : 3
xen_minor              : 0
xen_extra              : .2-2
xen_caps               : xen-3.0-x86_32
platform_params        : virt_start=0xfc000000
xen_changeset          : Thu Apr 13 15:18:37 2006 +0100 9617:5802713c159b
cc_compiler            : gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
cc_compile_by          : root
cc_compile_domain      : beer.home
cc_compile_date        : Tue Jun 20 22:02:29 EDT 2006
[root@guinness examples]#

Comment 1 Daniel Veillard 2006-11-06 16:53:00 UTC

Hum, the test code is not available anymore. I have tried here with libvirt
CVS, I stopped xend reconfigured it with just http access (no unix socket) and
restarted it. See,s that consecutive calls to the list function is working
when asking virsh to list twice:

[root@paphio src]# ./virsh 
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # list
 Id Name                 State
----------------------------------
  0 Domain-0             running

virsh # list
 Id Name                 State
----------------------------------
  0 Domain-0             running

virsh # 

  as root libvirt will first give the list of ID via an hypercall
and then virDomainLookupByID will be called to do the id to name mapping,
and it will get this only from the HTTP access to Xend. So this seems
to work for me with the current version.
  If you still experience the problem, could you make the code example
available again (or show how to get this with virsh) ?

   thanks,

Daniel