UPDATE: With huge thanks to reader Nick R, the following will get this same solution up-and-running in XenServer 7.0.
“In Xenserver 7, it is using systemd, so to start apcupsd, it’s: systemctl start apcupsd.service and to have it start at boot, it’s: systemctl enable apcupsd.service
Also, in Xenserver 7, you need the rpm package for Centos7 available here:
Thanks to a very bad Google translation of a German blog post at flurweg.net, I managed to get apcupsd running on Citrix XenServer 6.2 at work without any problems at all, and all was wonderful with the world… right up until I installed the Citrix XenServer 6.5 upgrade over the weekend. That zapped the existing apcupsd installation entirely, and the instructions for 6.2 no longer work for 6.5 (I am guessing because 6.5 has an X64 native dom0 and subtly different dependencies). Information on using apcupsd with XenServer at all is thin on the ground, and 6.5 even less so, so having now “repaired” this, I thought I’d document the changes I had to make from the original flurweg.net post to get apcupsd running on Citrix XenServer 6.5, while at the same time making something written in native English for those that don’t grok Google German.
apcupsd running on Citrix XenServer 6.5
The problem: Citrix XenServer includes no native UPS services or settings.
The Windows solution
From a host with XenCenter installed the following command can be issued to shut down a VM:
xe.exe -s [XenServer IP] -u root -pw [Password] vm-shutdown vm=[VM name]
However, why should we be dependent on a separate Windows system to shut down a VM host system during a power outage??
My conclusion: DON’T if a UPS can operate natively on the VM host (via USB, network or serial connection).
The Linux solution
In Linux, the solution is a cross-platform application called apcupsd that is included in most distributions or can be installed from repository (or source). Too bad it’s not included in XenServer. However, it’s possible to use the official CentOS repository RPM package (Citrix XenServer is based on CentOS 5) and manually install it on XenServer, adjusting the configuration. In this article, I’ll take you through getting the basics (sending out an email notification and shutting everything down in an orderly fashion); very much more is possible.
apcupsd on XenServer, an overview
- apcupsd, daemon from CentOS
- apcupsd.conf, custom configuration file that calls vm_shutdown.sh and logs an entry in XenCenter
- vm_shutdown.sh, shell script that shuts down all VM guests on the XenServer (local VMs if the XenServer is in a pool!!)
- sendemail, shell application to make sending UP status SMTP emails easy
- mailconfigs, changeme, commfailure, commok, offbattery, onbattery, sendemail.conf
A TAR file of these items can be downloaded from the original blog post (see point 1 in the installation instructions below).
Apcupsd XenServer Installation Guide (Using TAR File)
- Download the TAR file on the XenServer host
- Unzip files
tar xvf xenserver6_apcupsdl.tar
- Install apcupsd
yum localinstall --nogpgcheck apcupsd-3.14.10-1.el5.rf.x86_64.rpm
If you get an error Cannot find a valid baseurl for repo: citrix, edit “/etc/yum.repos.d/Citrix.repo” and temporarily disable the repository:
name=XenServer 6.5.0 updates
I also had to temporarily enable the default CentOS yum repositories to clear dependencies; edit “/etc/yum.repos.d/CentOS-Base.repo and change all occurrences of
Remember to reverse any yum repository changes you made after apcupsd installs.
- Backup the distribution configuration files
mkdir -p /etc/apcupsd/org
cp /etc/apcupsd/* /etc/apcupsd/org
- Copy the new configuration files (answering YES [y] to overwrite)
cp -f etc/apcupsd/* /etc/apcupsd/
- Customize mail settings for your environment
- Install sendemail
cp usr/bin/sendemail /usr/bin
chmod +x /usr/bin/sendemail
- Test email notifications
- Customise apcupsd settings for your environment (the included configuration is for a Smart-UPS communicating via USB)
- Start apcupsd
General information about apcupsd
Check UPS communication:
Test/configure the UPS:
And this is where my take on the original flurweg.net post stops. There is further information in the post, but we’re not using it; YMMV.