[libvirt] Trouble with virsh on Windows

Daniel P. Berrange berrange at redhat.com
Tue Apr 18 12:41:27 UTC 2017


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/ :|




More information about the libvir-list mailing list