Category: XenServer

XenServer: Unknown Error Occurred Connecting with XenCenter

When connecting to XenServer 5.5 from XenCenter on up to date Windows devices, you get an Unknown Error. To fix this, we need to generate a stronger SSL certificate. The logs below show the errors and locations to verify that this is the issue.

I couldn’t find all of this information easily consolidated into once place and hopefully this will save someone time if they come across the same issues.

XenCenter Logs
—
Location: %appdata%\Citrix\XenCenter\logs\XenCenter.log

2017-10-17 13:05:08,154 DEBUG XenAdmin.Network.XenConnection [Connection to xxx.xxx.xxx.xxx] - XenConnection: trying to connect to 192.168.10.24
2017-10-17 13:05:08,661 DEBUG XenAdmin.Network.XenConnection [Connection to xxx.xxx.xxx.xxx] - The request was aborted: Could not create SSL/TLS secure channel.
2017-10-17 13:05:08,661 WARN  XenAdmin.Network.XenConnection [Connection to xxx.xxx.xxx.xxx] - XenConnection: failed to connect to 192.168.10.24: The request was aborted: Could not create SSL/TLS secure channel.
2017-10-17 13:05:08,661 DEBUG XenAdmin.Actions.Action [Connection to xxx.xxx.xxx.xxx] - The request was aborted: Could not create SSL/TLS secure channel.

(Source: Citrix: XenCenter Event Log)

XenServer Logs
—
Location: /var/log/secure
—

Oct 17 13:06:29 xen-105519 stunnel: LOG5[15145:3085974416]: xapi connected from xxx.xxx.xxx.xxx:55170
Oct 17 13:06:29 xen-105519 stunnel: LOG3[15145:3085974416]: SSL_accept: Peer suddenly disconnected
Oct 17 13:06:29 xen-105519 stunnel: LOG5[15145:3085974416]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

(Source:Xencenter 6.5 and 7 “unknown error” while connecting to XenServer 5.6.0)

Fix :
—
Through SSH or Console Access do the following
Verify the key is 512

openssl x509 -in /etc/xensource/xapi-ssl.pem -text

Because the file that generates it is read only, create a copy in the temp directory.

cp /opt/xensource/libexec/generate_ssl_cert /tmp

Use vi to edit the new file.

vi /tmp/generate_ssl_cert

Update the following line to look like the one below it by pressing i to insert text.

openssl genrsa > privkey.rsa
openssl genrsa 1024 > privkey.rsa

Press escape followed by k, then type !wq to write changes to the file and quit without prompting.

Backup the existing cert.

cp /etc/xensource/xapi-ssl.pem /etc/xensource/xapi-ssl.pem.backup

Stop the xapissl service.

/etc/init.d/xapissl stop

Generate the new SSL cert.

/tmp/generate_ssl_cert /etc/xensource/xapi-ssl.pem ‘hostname -f’

Start the xapissl service.

/etc/init.d/xapissl start

(Source: WebbosWorld: XenCenter Could not create SSL/TLS Secure Channel)

https://italcultur.com/

XenServer: Alternate Auto-Start VM Option

Create the boot script

Method 1: Auto-start all servers

vi /etc/rc.d/init.d/RunVMonBoot.sh
#!/bin/bash
xe vm-list power-state=halted | grep uuid | cut -c 24- | xargs -I {Var} xe vm-start uuid={Var}

Method 2: Auto-start selected servers

vi /etc/rc.d/init.d/RunVMonBoot.sh
#!/bin/bash
xe vm-start uuid=SERVERUUIDHERE

Note: Repeat “xe vm-start uuid=” line as many times as needed.

Press Escape followed by K to stop editing.

Press : followed by wq! to save changes and quit editing.

Run the following command to add execute privileges to the script.

chmod +x /etc/init.d/RunVMonBoot.sh

Run to add execute privileges to the startup script.
chmod +x /etc/rc.d/rc.local

Run the following to edit the startup script.
vi /etc/rc.d/rc.local

Append these lines to the script. (Press I to allow inserting.)

Sleep 180

/etc/rc.d/init.d/RunVMonBoot.sh

Press Escape followed by K to stop editing.

Press : followed by wq! to save changes and quit editing.

XenServer Security: Clearing CIFS/SMB Passwords

XenServer stores the passwords to any CIFS/SMB share you are currently using or have used in the past even if the share was removed. (Tested this up to XenServer 7.)

Now, this can be a concern because these credentials might be to a domain account, domain administrator account, or have privileged access to a specific system. I wrote the following command to go through and clear all of the stored CIFS/SMB shares.

xe secret-list | grep uuid | cut -c 17- | xargs -I {Var} xe secret-destroy uuid={Var}

This query’s all existing passwords, removes the unnecessary text, and removes the saved passwords.

Breakdown

xe secret-list

Lists all passwords and UUIDs.

xe secret-list | grep uuid

Lists just the UUIDs of existing CIFS passwords

cut -c 17-

Removes the excess characters of the “xe secret-list | grep uuid” command.

xargs -I {Var}

Passes the results of the previous command to the next one with a set variable, in this case “{Var}”

xe secret-destroy uuid=

Removes the password from “xe secret-list”

XenServer: Rogue/Missing/Invisible Virtual Machine

Yesterday, I had the pleasure of finding out that there was an invisible/missing/rogue VM on one of the servers in our pool.

We had a “dead-beef” issue a few weeks prior and had attempted to migrate our VMs off to other members of the pool before rebooting the member. With that attempt, it caused all of the VMs to go into a paused state from which a forced shutdown was required. We rebooted the server at that point because it was the only way we could get the “dead-beef” issue recovered.

After the pool member reboot, the VMs would not start, so we cloned them and booted them up. Everything seemed fine in the next few weeks, until I decided to delete the originals as the replacements appeared to be functioning fine.

One of those servers had apparently been running in the background even though XenServer showed it as off.

We could ping it, see a MAC address for it that didn’t match the server it should have been, etc. Though, it didn’t show up in any VM list, be it from the XenCenter console, or through the “xe vm-list” command.

Later, we discovered that there was an extra domain (command: list_domains) on one of the servers. It’s possible that it could have been fixed by destroying that domain, but we ended up rebooting the entire pool. I started with that pool member after shutting down / migrating the existing VMs and placing it into Maintenance Mode.

The rogue server stopped responding pretty much immediately at this point and when it came back up it was no longer an issue.

TL;DR – Apparently, sometimes a server can be running in XenServer with nearly no record of it’s existence after being deleted in a “powered off” state.