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/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
