On Tue, Apr 18, 2017 at 08:02:35AM -0400, Charles Bancroft wrote:
On 4/18/2017 4:48 AM, Daniel P. Berrange wrote:
On Mon, Apr 17, 2017 at 09:49:01AM -0400, Charles Bancroft wrote:
Hi List,
I have a question about some troubles I am having with virsh on Windows x64. I am currently running a KVM server on a linux box and need to allow Windows clients to access it. I have set up the server for access with:
``` listen_tls = 0 listen_tcp = 1 auth_tcp = "none"
Here is the log of my execution run. Looks like there was an error on the socket, but nothing useful came back. I have also attached a tcpdump log of the network traffic to show it is the client end(192.168.1.10) issuing the reset after receiving some data from the server (192.168.1.113) ``` Execution log $ LIBVIRT_DEBUG=1 ./virsh -c qemu+tcp://192.168.1.113/system -d0 2017-04-18 11:46:23.778+0000: 1: info : libvirt version: 3.1.0 2017-04-18 11:46:23.778+0000: 1: info : hostname: <HOSTNAME>
Is '<HOSTNAME>' /really/ your local hostname, or did you just edit the logs to hide your hostname ?
2017-04-18 11:46:23.790+0000: 1: debug : doRemoteOpen:907 : proceeding with name = qemu:///system 2017-04-18 11:46:23.790+0000: 1: debug : doRemoteOpen:916 : Connecting with transport 5
Ok, we're trying to connect to the host over TCP which is good
2017-04-18 11:46:23.875+0000: 1: debug : virNetSocketNew:235 : localAddr=000000000069f540 remoteAddr=000000000069f5d0 fd=5 errfd=-1 pid=0 2017-04-18 11:46:23.875+0000: 1: info : virObjectNew:202 : OBJECT_NEW: obj=0000000000faebe0 classname=virNetSocket 2017-04-18 11:46:23.875+0000: 1: info : virNetSocketNew:291 : RPC_SOCKET_NEW: sock=0000000000faebe0 fd=5 errfd=-1 pid=0 localAddr=192.168.1.10;61441, remoteAddr=192.168.1.113;16509
Ok, the TCP connection is successfull, which is also good.
2017-04-18 11:46:23.875+0000: 1: debug : doRemoteOpen:1170 : Trying authentication
We're now trying to authenticate with the server
2017-04-18 11:46:23.875+0000: 1: debug : virNetMessageNew:46 : msg=0000000000fba700 tracked=0 2017-04-18 11:46:23.875+0000: 1: debug : virNetMessageEncodePayload:386 : Encode length as 28 2017-04-18 11:46:23.875+0000: 1: info : virNetClientSendInternal:2104 : RPC_CLIENT_MSG_TX_QUEUE: client=0000000000faa9a0 len=28 prog=536903814 vers=1 proc=66 type=0 status=0 serial=0 2017-04-18 11:46:23.875+0000: 1: debug : virNetClientCallNew:2057 : New call 0000000000fd7ad0: msg=0000000000fba700, expectReply=1, nonBlock=0 2017-04-18 11:46:23.875+0000: 1: debug : virNetClientIO:1866 : Outgoing message prog=536903814 version=1 serial=0 proc=66 type=0 length=28 dispatch=0000000000000000
We've put the authentication message on the queue to send.
2017-04-18 11:46:23.879+0000: 1: debug : virNetClientMarkClose:776 : client=0000000000faa9a0, reason=1
We're marking the conneciton as closed, due to EOF. This is the first sign of something wrong. I'm not 100% sure if this is due to the server closing the connection, or a client side bug in the poll loop. I'd be interested to see the libvirtd server side logs - if you configure libvirtd.conf with log_outputs="1:file:/var/log/libvirt/libvirtd.log" log_filters="1:remote 1:rpc 1:event 1:daemon"
error: failed to connect to the hypervisor error: An error occurred, but the cause is unknown
This however is a clear bug - we should never get this particular error message. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|