With the release of the XenServer 6.2 SDK, there is a better alignment between the PowerShell snap-in and the PowerShell standards of Cmdlet design and usage. Here are some great reference documents:
In the Citrix Solutions Lab, we’ve been using this SDK for all of our XenServer environment deployment needs and we’d like to share with you.
Downloading and installing the XenServer PowerShell Snap-in
All of these scripts involve connecting to the XenServer pool master and executing a series of Cmdlets to perform the different tasks below. This, of course, requires that you have installed the latest PowerShell XenServer Snap-in which is available for download at http://www.xenserver.org/partners/developing-products-for-xenserver.html under Download SDK Components and clicking the Software Development Kit link.
After downloading the XenServer-6.2.0-SDK.zip file, extract and run the XenServerPSSnapIn-6.2.0-1.msi located under XenServer-SDK\XenServerPSSnapIn.
Also, keep in mind that the XenServerPSSnapIn_old folder contains the old version of the PowerShell snap-in which is not used in this discussion. If this one was installed by mistake, you can uninstall it and install the correct one from the XenServerPSSnapIn folder.
The sample tasks
To perform a task, as with any other complex operation, the script must go through a set of steps in order to achieve the desired result. Below I go over the steps that are used to achieve the sample tasks. Each of these steps can be referenced in the example scripts as comments prefixed with “Blog Step:” to help you follow along.
Creating VMs from other VMs or Templates
- Load the XenServer Snap-in
- Connect to the XenServer pool master
- Get the source VM or Template
- Decide if we’re doing a clone or copy (i.e. thin vs. thick provision)
- Schedule the creation of the VMs
- Wait for the creation to finish
- If we started with templates, then we need to provision VMs from the copies/clones and wait for the provisioning to finish
- If we want to start the VMs, then get each VM and schedule a power on
- Disconnect from XenServer pool master
- Remove the XenServer Snap-in
Modify the VM resources such as CPU, memory, and networks
- Load the XenServer Snap-in
- Connect to the XenServer pool master
- Get each VM and schedule a graceful shut down
- Get each VM and ensure that the VM is powered down
- If we are modifying networking:
- If we are not keeping existing networks on the VM, then remove all existing networks on the VM
- Add networks to VMs while making sure to skip duplicates and keep a device count
- If we are modifying CPU (we must always satisfy a CPU rule of 0 < VCPUs_at_startup ≤ VCPUs_max):
- If CPUs on VM are greater than our desired count, then we reduce start-up CPUs followed by max CPUs
- If CPUs on VM are less than our desired count, then we increase max CPUs followed by start-up CPUs
- Otherwise, we skip this action
- If we are modifying memory (we must always satisfy a memory rule of memory_static_min ≤ memory_dynamic_min ≤ memory_dynamic_max ≤ memory_static_max):
- If desired memory amount is less than the static minimum, then change our desired amount to the memory static minimum
- If static maximum memory on VM is greater than our desired amount, then we set dynamic minimum, followed by dynamic maximum, and finally static maximum
- If static maximum memory on VM is less than our desired amount, then we set the static maximum, followed by the dynamic maximum, and finally dynamic minimum
- Otherwise, we skip this action
- Get each VM and schedule the power on
- If networks were added, then we wait until the VM is rebootable to schedule a graceful reboot to apply changes
- Disconnect from XenServer pool master
- Remove the XenServer Snap-in
Creating and reverting VM snapshots
- Load the XenServer Snap-in
- Connect to the XenServer pool master
- If we are creating a snapshot:
- Get each VM and schedule a graceful shut down of VMs
- Get each VM, ensure that the VM is powered down, and schedule the creation of snapshot
- If we are reverting a snapshot:
- Get each VM, get the snapshot, schedule the reversion of snapshot
- Get each VM and schedule the power on
- Disconnect from XenServer pool master
- Remove the XenServer Snap-in
Get the example scripts
We’d like to share with you some example scripts that go over the steps in each tasks detailed above. These scripts are extremely useful when performing the sample tasks as bulk operations across multiple VMs.
Creating VMs from other VMs or Templates
Modify the VM resources such as CPU, memory, and networks
Creating and reverting VM snapshots
Happy Scripting!
Santiago Cardenas
Disclaimer:
This software / sample code is provided to you “AS IS” with no representations, warranties or conditions of any kind. You may use, modify 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 / sample code 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 / sample code 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 / sample code. In no event should the software / 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 / SAMPLE CODE, 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.
