vsphere

multi-clone.py minimal user permissions

multi-clone.py minimal user permissions

Half a year ago, I posted about a Python script I created using PySphere, called multi-clone.py. I used this script to quickly deploy multiple vm’s from the same template and do some post-processing. This allowed me to easily setup a lab environment to test any sort of cluster tool, configuration management tool, …

This tool has been picked up by some other people. I’m happy to see my work is useful to others. This also meant that I got the occasional question about it.

Last week someone came to me with an issue, he got strange error messages. At first I thought it might have been a version mismatch as the original script was developed using PySphere 0.1.7, and he was using PySphere 0.1.8. After a quick update on my end and testing it with PySphere 0.1.8, everything worked fine. I had the same vSphere version, the same PySphere version and I did the same command as he did. Sadly, I couldn’t reproduce the error.

At this point, all I could think of was a permissions error. So we tested if the user could create a template with the exact same information, using the web-client. It seemed he couldn’t.

All this got me thinking about the minimal security permissions a user needed to run my script in a vSphere environment. So I tested a few permission setups and came up with a minimal permissions list. I added this to the Github repository readme file, but decided to post it here as well.

All permissions are only necessary on their appropriate item. For instance: datastore permissions are only necessary for the datastores on which the template and VMs will be located (or cluster if a Storage DRS cluster), so you can limit access to only a certain set of datastores.

Minimal permissions necessary to run multi-clone.py and all it’s features

  • Datastore
    • Allocate space
  • Network
    • Assign Network
  • Resource
    • Apply recommendation
    • Assign virtual machine to resource pool
  • Scheduled task
    • Create tasks
    • Run task
  • Virtual Machine
    • Configuration
      • Add new disk
    • Interaction
      • Power on
    • Inventory
      • Create from existing
    • Provisioning
      • Clone virtual machine (*)
      • Deploy from template

(*) This is in case you want to use the script to clone an actual VM instead of a VM template

vCenter 5.5 Server Appliance quirks

vCenter 5.5 Server Appliance quirks

Last week I upgraded my whole vSphere 5.1 environment to 5.5 and migrated to the vCenter 5.5 Server Appliance (VSA). Overall, I’m happy with this migration as the appliance gives me everything i need and the new web client works amazingly well, both with Mac OS X and Windows.

But there are a few quirks and small issues with it. Nothing to serious, and as i understand it, the VMware engineers are looking into it, but for those who are experiencing these issues, I wanted to provide a bit of explanation on how to fix them.

Quick stats on hostname is not up to date

20131003_vcenter_quick.stats.error

The first issue I noticed, was a message that kept appearing in the web client when I was looking at the summary of my hosts. At first I thought that there was a DNS or connection issue, but i was capable of managing my hosts, so that was all good.

Starting to investigate the issue on internet, I noticed a few people reporting this issue, and apparently VMware already posted a KB article (KB 2061008) on it.

Let’s go to the simple steps on how to fix this on the VSA:

  1. Make sure SSH is enabled in your VSA admin panel:
    20131003_vsa_ssh
  2. SSH to the VSA with user root and use the root password from the admin panel
  3. Copy the /etc/vmware-vpx/vpxd.cfg file to a save location, you will keep this as a backup
  4. Open the /etc/vmware-vpx/vpxd.cfg file with an editor
  5. Locate the </vpxd> tag
  6. Add the following text above that tag:
  7. It should more or less look like this:
    20131003_vpxd_config
  8. Save the file
  9. Restart your VSA, the easiest way is just to reboot it using the admin panel, or using the reboot command.

If you ever update the VSA, check the release notes, if this bug is fixed, you might want to remove these config values again.

Unable to connect to HTML5 VM Console

After a reboot of my VSA, I was unable to open the HTML5 VM Console from the web client. I got “Could not connect to x.x.x.x:7331”, the service seemed down. VMware is aware of this issue and a KB article (KB 2060604) is available.

The cause of this issue is a missing environment variable (VMWARE_JAVA_HOME). To make VSA aware of this variable, you can follow these steps:

  1. Make sure SSH is enabled in your VSA admin panel (see screenshot in step 1 of the issue above)
  2. SSH to the VSA with user root and the root password from the admin panel
  3. Open the /usr/lib/vmware-vsphere-client/server/wrapper/conf/wrapper.conf file with an editor
  4. Locate the Environment Variables part
  5. Add the following text to the list of environment variables:
  6. It should look more or less like this:
    20131003_vsa_wrapper
  7. Save the file
  8. Restart the vSphere Web client using:

That should fix the issue and the HTML5 VM Console should work fine!

PySphere script to clone a template into multiple VMs with post processing

PySphere script to clone a template into multiple VMs with post processing

*There is a better/newer version of this script, for more details, check this post: https://dellaert.org/2014/02/03/multi-clone-py-multi-threaded-cloning-of-a-template-to-multiple-vms/ – Or via github: https://github.com/pdellaert/vSphere-Python *

For an internal test setup i needed to be able to deploy multiple VMs from a template without to much hassle. So i started thinking that the best way to approach this, would be using a script. At first i thought i had to do this using PowerCLI as this is the preferred VMware way of scripting.

Luckily i came across the wonderful site of PySphere, which is a Python library that provides tools to access and administer a VMware vSphere setup. As Python wasn’t my strong suite, i was in a bit of a dilemma, i had almost no experience with either of those languages, so which to go for. Altho PowerCLI/Powershell has a lot more possibilities, as it is maintained and developed by VMware itself, Python had the great advantage i could do it all in a more familiar environment (Linux). It’s also closer to the languages i know than Powershell is. So i decided to just go for Python and see if it got me where i wanted to go.

This script deploys multiple VMs from a single template, you can specify how many and what basename the VMs should have. Each VM gets a name starting with the basename and a number which increments with each new VM. You are able to specify at what number it should start. You can also specify in which resource pool the VMs should be placed.

And as a final feature, you can specify a script which should be called after the VM has successfully booted and the guest OS has initiated it’s network interface. This script will be called with two arguments: the VM name and it’s IP. You can even specify it may only return a valid IPv6 address (i needed this to deploy VMs in an IPv6-only test environment).

The output if run with the help argument (-h):

To run the script, the command should look something like this:

And finally, the script itself, you can also download it on Github:

The script is probably a work in progress, as there are a lot of possibilities for improvement, if you have any requests feel free to contact me!

This is the first Python script i’ve ever written, so forgive me if i made some basic mistakes against best practices. Feel free to submit a patch.