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
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
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:
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
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@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@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:
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
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@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@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@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:
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
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 :|
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@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 :|
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 :|
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@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 :|
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
Comments inline On 3/7/13 1:01 PM, "Eric Blake" <eblake@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
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
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
participants (6)
-
Daniel P. Berrange -
Eric Blake -
Peter Krempa -
Saravanan Shanmugham (sarvi) -
Shantan Marepally (shanredd) -
Will Dennis