Re: [libvirt] Trouble with virsh on Windows
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/ :|