Recently I had the honor to participate as an architect for our new XenServer training (CXS-300: XenServer 6.5 SP1 Administration). Instead of simply updating the existing course for the latest features, we’ve decided to completely redesign it to better reflect the feedback we’ve received over the years.
The updated course now explains under the hood details, but there is also a heavy focus on the field experience.
I really like to final result and hope you will too! But while working on the new XenServer course, I’ve realized that there is a skeleton in my closet – my XenServer plugins haven’t been updated in a while and I’ve decided to start working on it right away.
As I’ve described in my first release of XenCenter plugins back in 2012, I’m one of the “lazy” consultants. There is a special kind of “lazy” IT professionals that don’t mind spending hours and hours to automate and simplify a potentially easy task that can be achieved in seconds. I’ve written XenCenter plugins to make it easier to RDP into VMs (I was too lazy to type in the name of VM) and later added more and more functionality. It turns out that plugins were really popular; almost 4 years after the latest release it’s still being actively used and I’m getting emails about it every day.
That’s why I’ve decided to listen to the community and add two most commonly requested features – ability to connect using IPs instead of VM names and simplified installation.
While it sounds like small changes, if you have a look at the code, this is actually a lot more complicated than it sounds, due to the range of IP addresses that needs to be parsed before the right one can be selected.
Why plugins?
There are different groups of people that are using XenServer. Some people use it exclusively with Windows workloads (typically our XenApp\XenDesktop customers), others are having mostly Linux workloads. Some people like to use PowerShell for automation, while others will prefer more *nix-oriented automation tools.
This diversity is amazing and definitely proves that XenServer is a very flexible platform, but it also makes it much harder to build a user interface that will provide all options for these different groups and keep it uncluttered and easy to use. Luckily, XenCenter implements a plugin architecture that’s actually very easy to use.
If you want to customize the UI to your needs, plugins are the right way to go. Or if you are offering a product that integrates with XenServer (monitoring, backup or storage integration), it would also make sense to provide UI extension.
What’s available?
Plugins are simply adding new menu options to the XenCenter user interface – and we encourage you to add your own and integrate XenCenter with your existing IT tools. Below you can see an example context menu with additional options added:
Some of these options are relevant only for Windows machines, while the others are more universal.
Windows-only extensions
- Establish an RDP connection to VM
- Open remote Services of VM
- Open remote Event Log of VM
- Open remote disk drives (C, D and E) of VM
Universal extensions
- Connect to VM using Putty (most useful for Linux VMs)
- Connect to VM using WinSCP
- Connect to VM using HTTP
- Ability to Ping VM
XenServer host
- Connect to XS host using Putty
- Connect to XS host using WinSCP
- Connect to XS host using PowerShell
Available for multiple objects
- You can copy an UUID from various objects – XS host, VM, pool or local and remote storage repositories.
If you are familiar with the previous releases, you have maybe noticed that no new context menu options have been added. The biggest changes in this release are related to the IP handling (big change), addition of installer and cleanup of all the scripts.
How to install?
Installation is very simple – just extract the archive and run Install.cmd. This script needs to run elevated – and you can use it to upgrade an existing installation of plugins, just make sure that XenCenter is not running.
There is only one configuration option that you need to select during installation – you need to select how you want to pass the details about VM (or host) to scripts.
There are two options available:
1.) By IP – list of all IPs is passed to the script and first IP in IPv4 format is passed to the script. For example “Ping.cmd 192.168.1.10”
2.) By Name – name of VM is passed to a script as an argument. For example “Ping.cmd XDC-001”
If your VM names are the same as an actual hostname (e.g. VM name is XDC-001 and OS name is XDC-001), it’s recommended to use Name for resolution. IP resolution is more limited – as IP addresses are reported by XenTools, this only works for running VMs with XenTools installed. Also, only the first IP is being used.
That being said, if you would like to modify the script responsible for IP parsing, you can find it under Shared\Resolve.cmd. You can modify the RegEx definition right after FindStr to search only for specific IP ranges.
For WinSCP and Putty, you also need to download\install those programs as they’re not included in the installation.
After installation, plugins should be automatically loaded and available. If you want to disable them (or just see available plugins), you can find details in XenCenter under Tools\Options\Plugins:
What’s next?
Maybe you are missing some options here – or you have your own solution that you would like to integrate with XenCenter. XenCenter supports two different types of plugins – the first type allows you to add new menu options (that’s what I’m using here), but you can also add new tab-pages to the interface (for example to display the NetScaler interface in a tab).
So why not start your own plugins? The process is well documented and you can find some examples of implementation here. Or you can just copy your new script to the Plugins\Citrix\ExtraTools\Scripts folder and modify file ExtraTools.xcplugin.xml accordingly (just be aware that the changes will be overwritten if you update the plugins) if you are planning to keep it for yourself.
You can also find Compile.cmd script and resource file under \Source folder – this can automatically generate the required binary for you (that’s not very important) and you can focus on the scripting part and XML file.
Download
As always, standard disclaimer applies here (download link follows):
“This software application is provided to you “as is” with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.”
Download
UPDATE: Version 5.2 has been released with some fixes for the installation script. Special thanks to Tobias Kreidl for helping with the troubleshooting.