New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Xenserver 7.0 not working

Votes:

0

Your Vote:

Up

Down

I migrated a XenServer pool from 6.5 to 7.0 and now the XenServer sensors do not work. I tried re-adding them and they still do not function. It gives host not found at uuid (UUID). Any idea when Xenserver 7.0 will be supported?

citrix host-performance xenserver

Created on Jul 5, 2016 1:21:15 PM by  tom234679 (252) 1



17 Replies

Votes:

0

Your Vote:

Up

Down

We're currently implementing v7.0 support, please bear with us.

Created on Jul 5, 2016 2:06:43 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thank you, any estimated date?

Created on Jul 5, 2016 2:07:28 PM by  tom234679 (252) 1



Votes:

0

Your Vote:

Up

Down

Since we have yet to find out what exactly changed in the API, this may take some time. Usually, we don't give any estimates, but I hope we'll be done in about 1-2 months.

Created on Jul 5, 2016 5:49:39 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I also upgraded a XenServer pool from 6.5 to 7.0. The 'Citrix XenServer Virtual Machine' sensors are working, however the 'Citrix XenServer Host' sensors are not. I'm unclear if this behaviour is different from tom234679.

Two additional issues discovered are;

1. The VM sensors only ever use HTTP, even though 'VMware Protocol' is configured for HTTPS in settings. Blocking port 80 on XenServer through iptables, all VM sensors went Red.

2. Following initial upgrade Host sensors (using HTTPS) failed 'Could not find any data for the host with the uuid: xxx-xxx-etc' as reported.

After hardening XenServer SSL to TLS1.2 the error changed to 'The underlying connection was closed: An unexpected error occurred on a send.'

For hardening I followed Citrix 'xenserver-7-0-release-notes.pdf' page 9 : Advisories and Known Issues -> Security.

Resulting 'etc/xensource/xapi-ssl.conf',
...
[xapi] accept = :::443
connect = 80
cert = /etc/xensource/xapi-ssl.pem
ciphers = !SSLv2:RSA+AES128-SHA256
TIMEOUTclose = 0
options = NO_SSLv2
options = NO_SSLv3
sslVersion = TLSv1.2

Logging '/var/log/secure',
Aug 15 15:50:29 xen1 stunnel: LOG3[25192:139624009754368]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number

Created on Aug 15, 2016 5:22:07 PM by  Android256 (0)



Votes:

0

Your Vote:

Up

Down

For me neither work. I'm on the latest patch level of 7.0

Created on Aug 15, 2016 7:46:50 PM by  tom234679 (252) 1



Votes:

1

Your Vote:

Up

Down

7.0 is working again in the Canary build of PRTG - it will take some time until it reaches the stable build, probably early September. Thanks for your patience on this!

Created on Aug 16, 2016 5:30:19 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I switched from Preview to Canary v16.3.26.5718. Host sensors are working again to fully patched XenServer (including XS70E010 Toolstack). Many Thanks for resolving this problem.

HTTP/HTTPS problems 1 and 2 above are still apparent, is it planned to resolve these ? do I need to log a separate KB number ?

Created on Aug 16, 2016 12:24:01 PM by  Android256 (0)



Votes:

0

Your Vote:

Up

Down

Please let me know when this goes in either your Preview or Canary build. Would be willing to test.

Created on Aug 16, 2016 7:23:53 PM by  tom234679 (252) 1



Votes:

0

Your Vote:

Up

Down

I just tried in 16.3.26.5718 and I am still unable to add the hosts.

Created on Aug 16, 2016 8:40:59 PM by  tom234679 (252) 1



Votes:

0

Your Vote:

Up

Down

What specific error do you get and what patchlevel are you on? As it seems to work for Android256, apart from the HTTPS problem...

Created on Aug 17, 2016 4:20:11 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

The message i receive is:"The request was aborted: Could not create SSL/TLS secure channel." My Current 7.0 Patches are XS70E002 through XS70E010 Xenserver build date:2016-07-26 XenServer build number:125380c DBV:2016.0520

Created on Aug 17, 2016 12:50:14 PM by  tom234679 (252) 1



Votes:

0

Your Vote:

Up

Down

Could you run sslscan (https://github.com/rbsec/sslscan/releases) against this URL: https://<xenserver>:<xenport>/rrd_updates

We need the complete output of it to determine the supported SSL protocols. Thanks!

Created on Aug 18, 2016 11:39:39 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I wasn't sure who the request was meant for so I went ahead and made some tests.

Using TestSSLServer4 diagnostics tool (http://www.bolet.org/TestSSLServer/) to XenServer I get the following list of ciphers supported when in TLSv1.2 enforcing mode,

3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA256 \\
3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA256 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256 \\
3-- (key:  RSA)  RSA_WITH_AES_128_GCM_SHA256 \\
3-- (key:  RSA)  RSA_WITH_AES_256_GCM_SHA384 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384 \\

Using Wireshark to discover the ciphers proposed by PRTG I decoded the request as,

Secure Sockets Layer \\
TLSv1 Record Layer: Handshake Protocol: Client Hello \\
Content Type: Handshake (22) \\
Version: TLS 1.0 (0x0301) \\
Handshake Protocol: Client Hello \\
Handshake Type: Client Hello (1) \\
Version: TLS 1.0 (0x0301) \\
Cipher Suites (12 suites) \\
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) \\
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) \\
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) \\
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) \\
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) \\
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) \\
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) \\
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) \\
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) \\
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) \\
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) \\
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) \\

The response from XenServer is,                    
                    
Secure Sockets Layer \\
TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) \\
Content Type: Alert (21) \\
Version: TLS 1.0 (0x0301) \\
Alert Message \\
Level: Fatal (2) \\
Description: Protocol Version (70) \\

The obvious problem is that PRTG is making the request using TLS v1.0 and XenServer rejects that when in TLS v1.2 enforcing mode.

Please consider including a TLS version selection (1.0, 1.1, 1.2 etc) for "VMware Protocol = HTTPS". I guess that other hardware manufactures will start to enforce TLSv1.2 breaking monitoring...

Also, is there any news if the VM sensors will use HTTPS instead of incorrect HTTP, item 1 ?

Currently on 16.3.28.6626 after switching from Canary to Preview a while ago.

Thanks Andrew

Created on Nov 8, 2016 5:09:58 PM by  Android256 (0)

Last change on Nov 9, 2016 6:44:40 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I'll forward it to the developer, so he can take a look at it and do the necessary code changes, if needed :)


I just saw that we already have a bug ticket for that, thanks for the additional info. Certainly helpful! :)

Created on Nov 9, 2016 6:48:56 AM by  Stephan Linke [Paessler Support]

Last change on Nov 9, 2016 6:51:21 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

That is good news.

Please ask developer to optomize XenServerRRDSensor.exe if possible as it consumes a lot of CPU cycles...

Btw, I notice that PRTG 16.3.28.6626 is using XenServer.dll v6.0.0.1 which is several years out of date, SDK 7.0.0 is available from Xenserver.org which supports TLS1.2 as below code extract suggests,

public static Stream ConnectStream(Uri uri, IWebProxy proxy, bool nodelay, int timeout_ms)
......
sslStream.AuthenticateAsClient("", null, SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12, true); ......

Created on Nov 9, 2016 1:51:42 PM by  Android256 (0)



Votes:

0

Your Vote:

Up

Down

Forwarded as well, thank you very much for making PRTG more awesome and the life of our devs easier :)

Created on Nov 10, 2016 6:39:26 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Sorry, fell off the map due to being slammed with other stuff at work. I use xenserver for my home lab. Thank you for supplying the info Android256.

Created on Nov 14, 2016 3:30:38 PM by  tom234679 (252) 1



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.