Hints for creating a XenCenter Clone
Getting started building a XenCenter clone (including options for linux and other non-windows platforms)
Recently, I posted a blog post about the flexibility and extensibility of XenCenter. In the blog I mentioned the availability of our developer APIs in C, C#, Python, PowerShell and Java and the fact that the functionality available to XenCenter is in fact open to any individual, product or competitor that wishes to build a management or monitoring product on top of XenServer.
One of the first questions I received was whether Citrix plans to release a mobile or linux/MacOS version of XenCenter. We don't have any current plans to do so ourselves, many of our customers are requesting these solutions to be cross-hypervisor and actively choosing products from independent vendors. If customer-demand changes, it is of course a decision we'll revisit. At the moment though, we are focusing on opening up our APIs and enhancing their functionality to enable as many products and vendors. A range of vendors offering a diversity of functionality, pricing and competition is currently offering our end-users better value.
Community and third party development of XenCenter alternatives
There are already some third party products offering non-windows monitoring for XenServer. There is a large open source project in xvpsource.org. xvp offer a ready-to-use free web console that can be used as an alternative to XenCenter on linux. However they also give developers access to the components to make their own solution. Being open source developers are also free to enhance the code with functionality they feel should be added, at the moment the community is developing snapshot orchestration capabilities.
If you are looking for a mobile solution you might like to take a look at the free solutions available from hypOps. The solution for iPad or iPhone, available at iTunes, will allow monitoring of XenServer hosts alongside Amazon EC2 Cloud and the CloudStack platform. I thought the user interface was particularly pretty on this product.
Getting started building your own XenCenter
For many developers thinking about writing a monitoring or management solution or script, one of the first things they want to do is work out which VMs are running on which host. Although it may sound like a fairly simple question there can be complexities and we've been asked the question enough times that it seemed appropriate to write this developer's how-to-guide. Our SDK developers' forum is a very good place to get answers to such questions and encourage us to write these articles.
A VM which is running must of course be running on a host. You can find out which VMs are running on a Host using the field Host.resident_vms (see the XenServer API documentation).
If you want to go the other way and find out which host a VM is running on then you could:
- find all the VMs in your session
- check if each VM: that it is not a template and is also running, via the VM.is_a_template and VM.power_state
- for each running VM check the VM.resident_on field
There is additional help for each language binding via the code examples; in particular these examples may be especially relevant:
- the C# example in the SDK download \XenServer-6.1-SDK.zip\XenServer-SDK\XenServer.NET\samples\VmPowerStates
- the python example powercycle.py in the SDK download \XenServer-6.1-SDK.zip\XenServer-SDK\XenServerPython\samples
- the Java example VMlifecycle.java in the SDK download \XenServer-6.1-SDK.zip\XenServer-SDK\XenServerJava\samples
If a VM is not running it is not necessarily associated with any host. It is only when a VM is running that it has a defined host. A VM that is not running may be associated with no host.
This is where we get the most questions, as many monitoring products display halted VMs as if they are "on" a host including our own XenCenter management product, if you look at the screenshot below screenshot you will see that some non-running VMs e.g. Demo Linux VM (3) have been associated with the host isis. This is as a feature of some clever logic in XenCenter that displays the VM as being associated with the host on which it is most likely to start. When the VM starts in XenCenter, occasionally it will start on a different host. The display when not running is a best guess (although we usually get it right and so it is not something most users notice).
If you want to incorporate similar behaviour into your own product or tools and associate a non-running VM with a host then you could guess the host based on the following logic (best way first)
- Look at the local storage associated with the VM as this frequently indicates only one possible host; if the SR is associated with only one host and is not shared. i.e. determine if the VM is tied to a SINGLE host by the storage
- Look at the affinity field of the VM, this is the preferred starting host (although you cannot guarantee this) - you would probably want to check the host specified is live too
- If you can infer nothing from the local storage or the affinity, sometimes all storage is shared and no affinity expressed, it is not possible to guess with any reasonable accuracy and it would be best to do something like XenCenter does and associate the VM with the pool at pool level, sometimes you will see powered off VMs in the tree below the pool in XenCenter and not under a host.