6:06 a.m.
Hi Shantan,
I believe the problem may be that libvirt 1.x requires TLS by default on
connections. I saw that same problem the 1st time I replaces a running
libvirt 0.9.x with 1.0.0. I believe there may be a way to turn off this
requirement in libvirtd.conf, e.g.
#
# Network connectivity controls
#
# Flag listening for secure TLS connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# It is necessary to setup a CA and issue server certificates before
# using this capability.
#
# This is enabled by default, uncomment this to disable it
#listen_tls = 0
# Listen for unencrypted TCP connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# Using the TCP socket requires SASL authentication by default. Only
# SASL mechanisms which support data encryption are allowed. This is
# DIGEST_MD5 and GSSAPI (Kerberos5)
#
# This is disabled by default, uncomment this to enable it.
#listen_tcp = 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
On the two instances of libvirt 1.x I have deployed, I just configure
and use TLS. Instructions on doing this may be found here:
http://wiki.libvirt.org/page/TLSSetup
HTH,
Will
8:17 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
Hi Dennis,
Thanks for the response. I tried two options: Disabling TLS and recompiling libvirt with
TLS enabled. Both scenarios result in the same error.
All,
Another thing I did not mention in the previous post: I am only using the client (virsh)
from the compiled set of tools. Libvirtd used on the server is from the standard prebuilt
RPMS, would that make any difference, Any other ideas, suggestions?
Thanks,
Shantan
From: Will Dennis <wdennis@nec-labs.com<mailto:wdennis@nec-labs.com>>
Date: Tuesday, March 5, 2013 2:06 PM
To: Cisco Employee <shanredd@cisco.com<mailto:shanredd@cisco.com>>,
"libvirt-users@redhat.com<mailto:libvirt-users@redhat.com>"
<libvirt-users@redhat.com<mailto:libvirt-users@redhat.com>>
Subject: Re: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
Hi Shantan,
I believe the problem may be that libvirt 1.x requires TLS by default on connections. I
saw that same problem the 1st time I replaces a running libvirt 0.9.x with 1.0.0. I
believe there may be a way to turn off this requirement in libvirtd.conf, e.g.
#
# Network connectivity controls
#
# Flag listening for secure TLS connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# It is necessary to setup a CA and issue server certificates before
# using this capability.
#
# This is enabled by default, uncomment this to disable it
#listen_tls = 0
# Listen for unencrypted TCP connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# Using the TCP socket requires SASL authentication by default. Only
# SASL mechanisms which support data encryption are allowed. This is
# DIGEST_MD5 and GSSAPI (Kerberos5)
#
# This is disabled by default, uncomment this to enable it.
#listen_tcp = 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
On the two instances of libvirt 1.x I have deployed, I just configure and use TLS.
Instructions on doing this may be found here:
http://wiki.libvirt.org/page/TLSSetup
HTH,
Will
5:35 p.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
On 03/05/13 23:06, Will Dennis wrote:
Hi Shantan,
I believe the problem may be that libvirt 1.x requires TLS by default on
connections. I saw that same problem the 1^st time I replaces a running
libvirt 0.9.x with 1.0.0. I believe there may be a way to turn off this
requirement in libvirtd.conf, e.g.
This is true for normal connections using TCP. SSH tunneling works in a
different way.
#
# Network connectivity controls
#
# Flag listening for secure TLS connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# It is necessary to setup a CA and issue server certificates before
# using this capability.
#
# This is enabled by default, uncomment this to disable it
#listen_tls = 0
# Listen for unencrypted TCP connections on the public TCP/IP port.
# NB, must pass the --listen flag to the libvirtd process for this to
# have any effect.
#
# Using the TCP socket requires SASL authentication by default. Only
# SASL mechanisms which support data encryption are allowed. This is
# DIGEST_MD5 and GSSAPI (Kerberos5)
#
# This is disabled by default, uncomment this to enable it.
#listen_tcp = 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
This is not needed for SSH.
On the two instances of libvirt 1.x I have deployed, I just configure
and use TLS. Instructions on doing this may be found here:
http://wiki.libvirt.org/page/TLSSetup
Please verify that you've got "netcat" installed on the host the daemon
is running on (command "nc" in the shell). Also you need to verify that
the user account you are using on the machine the daemon is running on
has rights to access the libvirt socket.
Peter
1:48 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
Peter, Thanks for the reply. Just to let you know turning off TLS did not
solve the issue for me. I have netcat and the user I am trying to login to
virsh console does have privileges to create socket. Enabling debug while
I try to login using QEMU+SSH, I get prompted for my password and get the
following debugs. The error message "Failed to connect to the hypervisor"
looks a little suspicious. The same uri with a prebuilt virsh binary, does
not have any issues connecting. Any thoughts?
shanredd(a)xxxxx.cisco.com's password:
2013-03-06 17:30:25.993+0000: 28966: debug : virNetClientMarkClose:631 :
client=0x1c52b10, reason=0
2013-03-06 17:30:25.993+0000: 28966: debug : virEventPollRemoveHandle:180
: EVENT_POLL_REMOVE_HANDLE: watch=2
2013-03-06 17:30:25.993+0000: 28966: debug : virEventPollRemoveHandle:193
: mark delete 1 5
2013-03-06 17:30:25.993+0000: 28966: debug :
virEventPollInterruptLocked:716 : Interrupting
2013-03-06 17:30:25.993+0000: 28966: debug :
virNetClientIOEventLoopPassTheBuck:1423 : Giving up the buck 0x1c528e0
2013-03-06 17:30:25.993+0000: 28966: debug :
virNetClientIOEventLoopPassTheBuck:1437 : No thread to pass the buck to
2013-03-06 17:30:25.993+0000: 28966: debug : virNetClientCloseLocked:644 :
client=0x1c52b10, sock=0x1c52980, reason=0
2013-03-06 17:30:25.993+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52980
2013-03-06 17:30:25.993+0000: 28967: debug : virEventPollRunOnce:640 :
Poll got 1 event(s)
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchTimeouts:425 : Dispatch 0
2013-03-06 17:30:25.993+0000: 28966: debug : virObjectRef:295 :
OBJECT_REF: obj=0x1c52b10
2013-03-06 17:30:25.993+0000: 28966: debug : virKeepAliveStop:299 :
RPC_KEEPALIVE_STOP: ka=0x1c52c30 client=0x1c52b10
2013-03-06 17:30:25.993+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52c30
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchHandles:470 : Dispatch 1
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchHandles:484 : i=0 w=1
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchHandles:498 : EVENT_POLL_DISPATCH_HANDLE: watch=1
events=1
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupTimeouts:516 : Cleanup 0
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupTimeouts:552 : Found 0 out of 0 timeout slots used,
releasing 0
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupHandles:564 : Cleanup 2
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupHandles:577 : EVENT_POLL_PURGE_HANDLE: watch=2
2013-03-06 17:30:25.993+0000: 28967: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.993+0000: 28967: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52980
2013-03-06 17:30:25.993+0000: 28967: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52980
2013-03-06 17:30:25.993+0000: 28967: debug : virNetSocketDispose:998 :
sock=0x1c52980 fd=5
2013-03-06 17:30:25.993+0000: 28967: debug : virEventPollRemoveHandle:180
: EVENT_POLL_REMOVE_HANDLE: watch=2
2013-03-06 17:30:25.993+0000: 28967: debug : virFileClose:72 : Closed fd 5
2013-03-06 17:30:25.993+0000: 28967: debug : virFileClose:72 : Closed fd 7
2013-03-06 17:30:25.993+0000: 28967: debug : virProcessAbort:92 : aborting
child process 28968
2013-03-06 17:30:25.994+0000: 28967: debug : virProcessAbort:97 : process
has ended: exit status 1
2013-03-06 17:30:25.994+0000: 28967: debug : virEventRunDefaultImpl:244 :
running default event implementation
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCleanupTimeouts:516 : Cleanup 0
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCleanupTimeouts:552 : Found 0 out of 0 timeout slots used,
releasing 0
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCleanupHandles:564 : Cleanup 1
2013-03-06 17:30:25.994+0000: 28967: debug : virEventPollMakePollFDs:393 :
Prepare n=0 w=1, f=3 e=1 d=0
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCalculateTimeout:332 : Calculate expiry of 0 timers
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCalculateTimeout:361 : Timeout at 0 due in -1 ms
2013-03-06 17:30:25.994+0000: 28967: debug : virEventPollRunOnce:629 :
EVENT_POLL_RUN: nhandles=1 timeout=-1
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52c30
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virNetClientIO:1806 : All
done with our call head=(nil) call=0x1c528e0 rv=-1
2013-03-06 17:30:25.994+0000: 28966: debug : virNetMessageFree:73 :
msg=0x1c53010 nfds=0 cb=(nil)
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c526f0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52600
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52d70
2013-03-06 17:30:25.994+0000: 28966: debug : virNetClientCloseInternal:685
: client=0x1c52b10 wantclose=0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c526f0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c526f0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52600
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52600
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52d70
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52d70
2013-03-06 17:30:25.994+0000: 28966: debug : virFileClose:72 : Closed fd 8
2013-03-06 17:30:25.994+0000: 28966: debug : virFileClose:72 : Closed fd 6
2013-03-06 17:30:25.994+0000: 28966: debug : virNetMessageClear:56 :
msg=0x1c52b70 nfds=0
2013-03-06 17:30:25.994+0000: 28966: debug : do_open:1206 : driver 1
remote returned ERROR
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c51f20
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c51f20
error: failed to connect to the hypervisor
error: End of file while reading data: 2013-03-06 17:30:22.327+0000:
28968: debug : virFileClose:72 : Closed fd 6
2013-03-06 17:30:22.327+0000: 28968: debug : virFileClose:72 : Closed fd 8
2013-03-06 17:30:22.327+0000: 28968: debug : virCommandHook:2119 : Hook is
done 0: Input/output error
2013-03-06 17:30:25.994+0000: 28966: debug : virEventPollAddTimeout:225 :
Used 0 timeout slots, adding at least 10 more
2013-03-06 17:30:25.994+0000: 28966: debug :
virEventPollInterruptLocked:716 : Interrupting
2013-03-06 17:30:25.994+0000: 28966: debug : virEventPollAddTimeout:248 :
EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x4122ee opaque=(nil)
ff=(nil)
2013-03-06 17:30:25.994+0000: 28967: debug : virEventPollRunOnce:640 :
Poll got 1 event(s)
On 3/6/13 1:35 AM, "Peter Krempa" <pkrempa(a)redhat.com> wrote:
On 03/05/13 23:06, Will Dennis wrote:
> Hi Shantan,
>
> I believe the problem may be that libvirt 1.x requires TLS by default on
> connections. I saw that same problem the 1^st time I replaces a running
> libvirt 0.9.x with 1.0.0. I believe there may be a way to turn off this
> requirement in libvirtd.conf, e.g.
This is true for normal connections using TCP. SSH tunneling works in a
different way.
>
> #
>
> # Network connectivity controls
>
> #
>
> # Flag listening for secure TLS connections on the public TCP/IP port.
>
> # NB, must pass the --listen flag to the libvirtd process for this to
>
> # have any effect.
>
> #
>
> # It is necessary to setup a CA and issue server certificates before
>
> # using this capability.
>
> #
>
> # This is enabled by default, uncomment this to disable it
>
> #listen_tls = 0
>
> # Listen for unencrypted TCP connections on the public TCP/IP port.
>
> # NB, must pass the --listen flag to the libvirtd process for this to
>
> # have any effect.
>
> #
>
> # Using the TCP socket requires SASL authentication by default. Only
>
> # SASL mechanisms which support data encryption are allowed. This is
>
> # DIGEST_MD5 and GSSAPI (Kerberos5)
>
> #
>
> # This is disabled by default, uncomment this to enable it.
>
> #listen_tcp = 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
This is not needed for SSH.
>
> On the two instances of libvirt 1.x I have deployed, I just configure
> and use TLS. Instructions on doing this may be found here:
>
> http://wiki.libvirt.org/page/TLSSetup
Please verify that you've got "netcat" installed on the host the daemon
is running on (command "nc" in the shell). Also you need to verify that
the user account you are using on the machine the daemon is running on
has rights to access the libvirt socket.
Peter
2:08 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
Just to add a little context to what Shantan has been trying to do.
We have libvirt 1.0 from standard fedora RPMs on a few standard Fedora 17
servers used as virtualization hosts
[root@cnh-nehalem-1 ~]# libvirtd --version
libvirtd (libvirt) 1.0.0
We are able to use virsh from these standard installs to connect between
servers through
virsh -c qemu+ssh://sarvi@libvirthost/system
This has been working.
What we are now trying to do is to
1. compile a slightly newer libvirt-1.0.2 on of these servers
2. Install them into a non standard location like
./configure --prefix=/users/sarvi/nonstddir
3. This compiles and installs fine.
4. Just start plain virsh works fine.
5. Using this virsh to connect to one of the other existing servers
using the following fails with an error.
/users/sarvi/nonstddir/bin/virsh -c
qemu+ssh://sarvi@libivirthost/system
error: failed to connect to the hypervisor
error: End of file while reading data: Input/output error
We are looking for some pointers on what the problem might be how to go
about troubleshooting this problem.
Thanks,
Sarvi
On 3/6/13 9:48 AM, "Shantan Marepally (shanredd)" <shanredd(a)cisco.com>
wrote:
Peter, Thanks for the reply. Just to let you know turning off TLS did
not
solve the issue for me. I have netcat and the user I am trying to login to
virsh console does have privileges to create socket. Enabling debug while
I try to login using QEMU+SSH, I get prompted for my password and get the
following debugs. The error message "Failed to connect to the hypervisor"
looks a little suspicious. The same uri with a prebuilt virsh binary, does
not have any issues connecting. Any thoughts?
shanredd(a)xxxxx.cisco.com's password:
2013-03-06 17:30:25.993+0000: 28966: debug : virNetClientMarkClose:631 :
client=0x1c52b10, reason=0
2013-03-06 17:30:25.993+0000: 28966: debug : virEventPollRemoveHandle:180
: EVENT_POLL_REMOVE_HANDLE: watch=2
2013-03-06 17:30:25.993+0000: 28966: debug : virEventPollRemoveHandle:193
: mark delete 1 5
2013-03-06 17:30:25.993+0000: 28966: debug :
virEventPollInterruptLocked:716 : Interrupting
2013-03-06 17:30:25.993+0000: 28966: debug :
virNetClientIOEventLoopPassTheBuck:1423 : Giving up the buck 0x1c528e0
2013-03-06 17:30:25.993+0000: 28966: debug :
virNetClientIOEventLoopPassTheBuck:1437 : No thread to pass the buck to
2013-03-06 17:30:25.993+0000: 28966: debug : virNetClientCloseLocked:644 :
client=0x1c52b10, sock=0x1c52980, reason=0
2013-03-06 17:30:25.993+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52980
2013-03-06 17:30:25.993+0000: 28967: debug : virEventPollRunOnce:640 :
Poll got 1 event(s)
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchTimeouts:425 : Dispatch 0
2013-03-06 17:30:25.993+0000: 28966: debug : virObjectRef:295 :
OBJECT_REF: obj=0x1c52b10
2013-03-06 17:30:25.993+0000: 28966: debug : virKeepAliveStop:299 :
RPC_KEEPALIVE_STOP: ka=0x1c52c30 client=0x1c52b10
2013-03-06 17:30:25.993+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52c30
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchHandles:470 : Dispatch 1
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchHandles:484 : i=0 w=1
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollDispatchHandles:498 : EVENT_POLL_DISPATCH_HANDLE: watch=1
events=1
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupTimeouts:516 : Cleanup 0
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupTimeouts:552 : Found 0 out of 0 timeout slots used,
releasing 0
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupHandles:564 : Cleanup 2
2013-03-06 17:30:25.993+0000: 28967: debug :
virEventPollCleanupHandles:577 : EVENT_POLL_PURGE_HANDLE: watch=2
2013-03-06 17:30:25.993+0000: 28967: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.993+0000: 28967: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52980
2013-03-06 17:30:25.993+0000: 28967: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52980
2013-03-06 17:30:25.993+0000: 28967: debug : virNetSocketDispose:998 :
sock=0x1c52980 fd=5
2013-03-06 17:30:25.993+0000: 28967: debug : virEventPollRemoveHandle:180
: EVENT_POLL_REMOVE_HANDLE: watch=2
2013-03-06 17:30:25.993+0000: 28967: debug : virFileClose:72 : Closed fd 5
2013-03-06 17:30:25.993+0000: 28967: debug : virFileClose:72 : Closed fd 7
2013-03-06 17:30:25.993+0000: 28967: debug : virProcessAbort:92 : aborting
child process 28968
2013-03-06 17:30:25.994+0000: 28967: debug : virProcessAbort:97 : process
has ended: exit status 1
2013-03-06 17:30:25.994+0000: 28967: debug : virEventRunDefaultImpl:244 :
running default event implementation
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCleanupTimeouts:516 : Cleanup 0
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCleanupTimeouts:552 : Found 0 out of 0 timeout slots used,
releasing 0
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCleanupHandles:564 : Cleanup 1
2013-03-06 17:30:25.994+0000: 28967: debug : virEventPollMakePollFDs:393 :
Prepare n=0 w=1, f=3 e=1 d=0
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCalculateTimeout:332 : Calculate expiry of 0 timers
2013-03-06 17:30:25.994+0000: 28967: debug :
virEventPollCalculateTimeout:361 : Timeout at 0 due in -1 ms
2013-03-06 17:30:25.994+0000: 28967: debug : virEventPollRunOnce:629 :
EVENT_POLL_RUN: nhandles=1 timeout=-1
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52c30
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virNetClientIO:1806 : All
done with our call head=(nil) call=0x1c528e0 rv=-1
2013-03-06 17:30:25.994+0000: 28966: debug : virNetMessageFree:73 :
msg=0x1c53010 nfds=0 cb=(nil)
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c526f0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52600
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52d70
2013-03-06 17:30:25.994+0000: 28966: debug : virNetClientCloseInternal:685
: client=0x1c52b10 wantclose=0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52b10
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c526f0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c526f0
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52600
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52600
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c52d70
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c52d70
2013-03-06 17:30:25.994+0000: 28966: debug : virFileClose:72 : Closed fd 8
2013-03-06 17:30:25.994+0000: 28966: debug : virFileClose:72 : Closed fd 6
2013-03-06 17:30:25.994+0000: 28966: debug : virNetMessageClear:56 :
msg=0x1c52b70 nfds=0
2013-03-06 17:30:25.994+0000: 28966: debug : do_open:1206 : driver 1
remote returned ERROR
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:258 :
OBJECT_UNREF: obj=0x1c51f20
2013-03-06 17:30:25.994+0000: 28966: debug : virObjectUnref:260 :
OBJECT_DISPOSE: obj=0x1c51f20
error: failed to connect to the hypervisor
error: End of file while reading data: 2013-03-06 17:30:22.327+0000:
28968: debug : virFileClose:72 : Closed fd 6
2013-03-06 17:30:22.327+0000: 28968: debug : virFileClose:72 : Closed fd 8
2013-03-06 17:30:22.327+0000: 28968: debug : virCommandHook:2119 : Hook is
done 0: Input/output error
2013-03-06 17:30:25.994+0000: 28966: debug : virEventPollAddTimeout:225 :
Used 0 timeout slots, adding at least 10 more
2013-03-06 17:30:25.994+0000: 28966: debug :
virEventPollInterruptLocked:716 : Interrupting
2013-03-06 17:30:25.994+0000: 28966: debug : virEventPollAddTimeout:248 :
EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x4122ee opaque=(nil)
ff=(nil)
2013-03-06 17:30:25.994+0000: 28967: debug : virEventPollRunOnce:640 :
Poll got 1 event(s)
On 3/6/13 1:35 AM, "Peter Krempa" <pkrempa(a)redhat.com> wrote:
>On 03/05/13 23:06, Will Dennis wrote:
>> Hi Shantan,
>>
>> I believe the problem may be that libvirt 1.x requires TLS by default
>>on
>> connections. I saw that same problem the 1^st time I replaces a running
>> libvirt 0.9.x with 1.0.0. I believe there may be a way to turn off this
>> requirement in libvirtd.conf, e.g.
>
>This is true for normal connections using TCP. SSH tunneling works in a
>different way.
>
>>
>> #
>>
>> # Network connectivity controls
>>
>> #
>>
>> # Flag listening for secure TLS connections on the public TCP/IP port.
>>
>> # NB, must pass the --listen flag to the libvirtd process for this to
>>
>> # have any effect.
>>
>> #
>>
>> # It is necessary to setup a CA and issue server certificates before
>>
>> # using this capability.
>>
>> #
>>
>> # This is enabled by default, uncomment this to disable it
>>
>> #listen_tls = 0
>>
>> # Listen for unencrypted TCP connections on the public TCP/IP port.
>>
>> # NB, must pass the --listen flag to the libvirtd process for this to
>>
>> # have any effect.
>>
>> #
>>
>> # Using the TCP socket requires SASL authentication by default. Only
>>
>> # SASL mechanisms which support data encryption are allowed. This is
>>
>> # DIGEST_MD5 and GSSAPI (Kerberos5)
>>
>> #
>>
>> # This is disabled by default, uncomment this to enable it.
>>
>> #listen_tcp = 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>This is not needed for SSH.
>
>>
>> On the two instances of libvirt 1.x I have deployed, I just configure
>> and use TLS. Instructions on doing this may be found here:
>>
>> http://wiki.libvirt.org/page/TLSSetup
>
>
>Please verify that you've got "netcat" installed on the host the daemon
>is running on (command "nc" in the shell). Also you need to verify that
>the user account you are using on the machine the daemon is running on
>has rights to access the libvirt socket.
>
>Peter
>
2:31 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
On Wed, Mar 06, 2013 at 06:08:29PM +0000, Saravanan Shanmugham (sarvi) wrote:
Just to add a little context to what Shantan has been trying to do.
We have libvirt 1.0 from standard fedora RPMs on a few standard Fedora 17
servers used as virtualization hosts
[root@cnh-nehalem-1 ~]# libvirtd --version
libvirtd (libvirt) 1.0.0
We are able to use virsh from these standard installs to connect between
servers through
virsh -c qemu+ssh://sarvi@libvirthost/system
This has been working.
What we are now trying to do is to
1. compile a slightly newer libvirt-1.0.2 on of these servers
2. Install them into a non standard location like
./configure --prefix=/users/sarvi/nonstddir
This is your problem. By specifying a different prefix, your new
libvirt client is going to be looking for the libvirtd socket
in /users/sarvi/nonstddir/var/lib/libvirt/libvirt-sock instead
of in /var/lib/libvirt/libvirt-sock
The --prefix you use to compile your libvirt must match the settings
used for the target libvirt you are connecting to.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
2:42 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
Thanks Daniel.
Is there a way around this.
We want the virtualization hosts to have standard Fedora libvirt RPMs
installed and running.
We are eventually trying to compile a subset of libvirt client tools
only(the virsh client, python, libvirt and remote-drivers to run on
various other developer systems ranging from RHEL 4/5/6 to allow them to
be able to connect to the virtualization hosts. These compiled client
tools will need to go into a --prefix=/usr/nonstddir/ which will be NFS
mounted by all developer machines.
I guess one alternative is to custom compile what runs on the
virtualization servers too and have them all be built with
--prefix=/user/nonstddir.
But I am wondering if there is a way to avoid this.
Thanks for your help,
Sarvi
On 3/6/13 10:31 AM, "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Wed, Mar 06, 2013 at 06:08:29PM +0000, Saravanan Shanmugham
(sarvi)
wrote:
> Just to add a little context to what Shantan has been trying to do.
>
> We have libvirt 1.0 from standard fedora RPMs on a few standard Fedora
>17
> servers used as virtualization hosts
> [root@cnh-nehalem-1 ~]# libvirtd --version
> libvirtd (libvirt) 1.0.0
>
> We are able to use virsh from these standard installs to connect between
> servers through
> virsh -c qemu+ssh://sarvi@libvirthost/system
>
> This has been working.
>
> What we are now trying to do is to
> 1. compile a slightly newer libvirt-1.0.2 on of these servers
> 2. Install them into a non standard location like
> ./configure --prefix=/users/sarvi/nonstddir
This is your problem. By specifying a different prefix, your new
libvirt client is going to be looking for the libvirtd socket
in /users/sarvi/nonstddir/var/lib/libvirt/libvirt-sock instead
of in /var/lib/libvirt/libvirt-sock
The --prefix you use to compile your libvirt must match the settings
used for the target libvirt you are connecting to.
Daniel
--
|: http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o-
http://virt-manager.org :|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|
2:52 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
On Wed, Mar 06, 2013 at 06:42:05PM +0000, Saravanan Shanmugham (sarvi) wrote:
Thanks Daniel.
Is there a way around this.
We want the virtualization hosts to have standard Fedora libvirt RPMs
installed and running.
We are eventually trying to compile a subset of libvirt client tools
only(the virsh client, python, libvirt and remote-drivers to run on
various other developer systems ranging from RHEL 4/5/6 to allow them to
be able to connect to the virtualization hosts. These compiled client
tools will need to go into a --prefix=/usr/nonstddir/ which will be NFS
mounted by all developer machines.
You might get away with using
--prefix=/usr/nonstddir --localstatedir=/var --sysconfdir=/etc
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
3:37 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
With these options, it fails to install as below
/bin/mkdir -p '/ws/sarvi-sjc/skunkworks/bspace/usrcisco/libexec'
/bin/mkdir -p
'/ws/sarvi-sjc/skunkworks/bspace/usrcisco/share/augeas/lenses'
/bin/mkdir -p
'/ws/sarvi-sjc/skunkworks/bspace/usrcisco/share/augeas/lenses/tests'
/bin/mkdir -p '/etc/libvirt'
/bin/mkdir: cannot create directory `/etc/libvirt': Permission denied
make-3.79.1-p7[3]: *** [install-confDATA] Error 1
make-3.79.1-p7[3]: Leaving directory
`/ws/sarvi-sjc/skunkworks/bspace/libvirt-1.0.3/src'
make-3.79.1-p7[2]: *** [install-am] Error 2
make-3.79.1-p7[2]: Leaving directory
`/ws/sarvi-sjc/skunkworks/bspace/libvirt-1.0.3/src'
make-3.79.1-p7[1]: *** [install] Error 2
make-3.79.1-p7[1]: Leaving directory
`/ws/sarvi-sjc/skunkworks/bspace/libvirt-1.0.3/src'
make-3.79.1-p7: *** [install-recursive] Error 1
Just changing
# define LIBVIRTD_PRIV_UNIX_SOCKET LOCALSTATEDIR
"/run/libvirt/libvirt-sock"
# define LIBVIRTD_PRIV_UNIX_SOCKET_RO LOCALSTATEDIR
"/run/libvirt/libvirt-sock-ro"
To
# define LIBVIRTD_PRIV_UNIX_SOCKET "/var" "/run/libvirt/libvirt-sock"
# define LIBVIRTD_PRIV_UNIX_SOCKET_RO "/var"
"/run/libvirt/libvirt-sock-ro"
Fixed the problem and things worked fine.
It would be nice for a client only builds to be able to control through a
./configure argument or through some other .conf file where the server
expects to find its socket file.
That said, I am wondering why the client has to know where the server
maintains its libvirt-sock files? Can't client and the server both talk in
relative path terms instead of absolute?
Sarvi
On 3/6/13 10:52 AM, "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Wed, Mar 06, 2013 at 06:42:05PM +0000, Saravanan Shanmugham
(sarvi)
wrote:
> Thanks Daniel.
>
> Is there a way around this.
> We want the virtualization hosts to have standard Fedora libvirt RPMs
> installed and running.
>
> We are eventually trying to compile a subset of libvirt client tools
> only(the virsh client, python, libvirt and remote-drivers to run on
> various other developer systems ranging from RHEL 4/5/6 to allow them to
> be able to connect to the virtualization hosts. These compiled client
> tools will need to go into a --prefix=/usr/nonstddir/ which will be NFS
> mounted by all developer machines.
You might get away with using
--prefix=/usr/nonstddir --localstatedir=/var --sysconfdir=/etc
Regards,
Daniel
--
|: http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o-
http://virt-manager.org :|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|
5:01 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
On 03/07/2013 12:37 PM, Saravanan Shanmugham (sarvi) wrote:
Just changing
# define LIBVIRTD_PRIV_UNIX_SOCKET LOCALSTATEDIR
"/run/libvirt/libvirt-sock"
# define LIBVIRTD_PRIV_UNIX_SOCKET_RO LOCALSTATEDIR
"/run/libvirt/libvirt-sock-ro"
To
# define LIBVIRTD_PRIV_UNIX_SOCKET "/var"
"/run/libvirt/libvirt-sock"
# define LIBVIRTD_PRIV_UNIX_SOCKET_RO "/var"
"/run/libvirt/libvirt-sock-ro"
Fixed the problem and things worked fine.
It would be nice for a client only builds to be able to control through a
./configure argument or through some other .conf file where the server
expects to find its socket file.
But you DO have that capability:
./configure --localstatedir=/var
That said, I am wondering why the client has to know where the server
maintains its libvirt-sock files? Can't client and the server both talk in
relative path terms instead of absolute?
You're welcome to propose a patch along those lines.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
5:45 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
Comments inline
On 3/7/13 1:01 PM, "Eric Blake" <eblake(a)redhat.com> wrote:
On 03/07/2013 12:37 PM, Saravanan Shanmugham (sarvi) wrote:
>
> Just changing
> # define LIBVIRTD_PRIV_UNIX_SOCKET LOCALSTATEDIR
> "/run/libvirt/libvirt-sock"
> # define LIBVIRTD_PRIV_UNIX_SOCKET_RO LOCALSTATEDIR
> "/run/libvirt/libvirt-sock-ro"
> To
> # define LIBVIRTD_PRIV_UNIX_SOCKET "/var"
"/run/libvirt/libvirt-sock"
> # define LIBVIRTD_PRIV_UNIX_SOCKET_RO "/var"
>"/run/libvirt/libvirt-sock-ro"
>
> Fixed the problem and things worked fine.
>
> It would be nice for a client only builds to be able to control through
>a
> ./configure argument or through some other .conf file where the server
> expects to find its socket file.
But you DO have that capability:
./configure --localstatedir=/var
Yes. That¹s what Daniel suggested and it errors during install because I
don't have root access and I am trying to install it into
/users/sarvi/mytools for a personal install that doesn't affect all the
users on the machine.
./configure --prefix=/users/sarvi/mytools --localstatedir=/var
--sysconfdir=/etc
This is the libvirt remote client only and from what I see it can maintain
its own client side state under /users/sarvi/mytools as well and would
probably be preferred.
Having to change the client side install locations to match the different
server side install locations seems inconvenient in this use case.
Sarvi
>
> That said, I am wondering why the client has to know where the server
> maintains its libvirt-sock files? Can't client and the server both talk
>in
> relative path terms instead of absolute?
You're welcome to propose a patch along those lines.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3:44 p.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
On 03/07/13 20:37, Saravanan Shanmugham (sarvi) wrote:
With these options, it fails to install as below
/bin/mkdir -p '/ws/sarvi-sjc/skunkworks/bspace/usrcisco/libexec'
/bin/mkdir -p
'/ws/sarvi-sjc/skunkworks/bspace/usrcisco/share/augeas/lenses'
/bin/mkdir -p
'/ws/sarvi-sjc/skunkworks/bspace/usrcisco/share/augeas/lenses/tests'
/bin/mkdir -p '/etc/libvirt'
/bin/mkdir: cannot create directory `/etc/libvirt': Permission denied
make-3.79.1-p7[3]: *** [install-confDATA] Error 1
make-3.79.1-p7[3]: Leaving directory
`/ws/sarvi-sjc/skunkworks/bspace/libvirt-1.0.3/src'
make-3.79.1-p7[2]: *** [install-am] Error 2
make-3.79.1-p7[2]: Leaving directory
`/ws/sarvi-sjc/skunkworks/bspace/libvirt-1.0.3/src'
make-3.79.1-p7[1]: *** [install] Error 2
make-3.79.1-p7[1]: Leaving directory
`/ws/sarvi-sjc/skunkworks/bspace/libvirt-1.0.3/src'
make-3.79.1-p7: *** [install-recursive] Error 1
Just changing
# define LIBVIRTD_PRIV_UNIX_SOCKET LOCALSTATEDIR
"/run/libvirt/libvirt-sock"
# define LIBVIRTD_PRIV_UNIX_SOCKET_RO LOCALSTATEDIR
"/run/libvirt/libvirt-sock-ro"
To
# define LIBVIRTD_PRIV_UNIX_SOCKET "/var"
"/run/libvirt/libvirt-sock"
# define LIBVIRTD_PRIV_UNIX_SOCKET_RO "/var"
"/run/libvirt/libvirt-sock-ro"
Fixed the problem and things worked fine.
Okay, this fixes the stuff at first but it isn't a nice fix.
It would be nice for a client only builds to be able to control through a
./configure argument or through some other .conf file where the server
expects to find its socket file.
Hmm, you still can configure the LOCALSTATEDIR variable. The only
drawback is that it puts all daemon state into the configured path.
That said, I am wondering why the client has to know where the server
maintains its libvirt-sock files? Can't client and the server both talk in
relative path terms instead of absolute?
Remote clients don't know the path on the remote host so we can't really
do this. On the other hand, we provide means for configuring the path to
the socket while opening the remote connection. It makes the URI ugly,
but works:
virsh -c qemu+ssh://user@host:port/system?socket=/path/to/socket/on/remote
Peter
12:52 a.m.
New subject: [libvirt-users] Virsh+QEMU, SSH issue on compiled libvirt
On 03/08/2013 12:44 AM, Peter Krempa wrote:
> Just changing
> # define LIBVIRTD_PRIV_UNIX_SOCKET LOCALSTATEDIR
> "/run/libvirt/libvirt-sock"
> # define LIBVIRTD_PRIV_UNIX_SOCKET_RO LOCALSTATEDIR
> "/run/libvirt/libvirt-sock-ro"
> To
> # define LIBVIRTD_PRIV_UNIX_SOCKET "/var"
"/run/libvirt/libvirt-sock"
> # define LIBVIRTD_PRIV_UNIX_SOCKET_RO "/var"
> "/run/libvirt/libvirt-sock-ro"
>
> Fixed the problem and things worked fine.
Okay, this fixes the stuff at first but it isn't a nice fix.
That's fine for a local fix, but too hard-coded to go upstream.
>
> It would be nice for a client only builds to be able to control through a
> ./configure argument or through some other .conf file where the server
> expects to find its socket file.
Hmm, you still can configure the LOCALSTATEDIR variable. The only
drawback is that it puts all daemon state into the configured path.
I had indeed missed that fact - you want your local install to go into
one location, but to tell your connection to the remote server to look
in the remote server's configured location, different from your local
configuration.
>
> That said, I am wondering why the client has to know where the server
> maintains its libvirt-sock files? Can't client and the server both
> talk in
> relative path terms instead of absolute?
Remote clients don't know the path on the remote host so we can't really
do this. On the other hand, we provide means for configuring the path to
the socket while opening the remote connection. It makes the URI ugly,
but works:
virsh -c qemu+ssh://user@host:port/system?socket=/path/to/socket/on/remote
Indeed, that looks like the right approach. And if it bothers you to
type that much on every connection, you can set up configured connection
names: http://libvirt.org/uri.html#URI_config
That is, by modifying the libvirt.conf file as installed into your local
prefix (the web page mentioned /etc/libvirt/libvirt.conf, but that was
assuming the default installation prefix), you can make:
virsh -c remote
be shorthand for the longer
qemu+ssh://user@host:port/system?socket=/path/to/remote/socket.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4201
days inactive
4204
days old
12 comments
6 participants
participants (6)
-
Daniel P. Berrange -
Eric Blake -
Peter Krempa -
Saravanan Shanmugham (sarvi) -
Shantan Marepally (shanredd) -
Will Dennis