My friend let me use one of his older, unused servers in his data center so I have a place to run some virtual machines for my automation projects. As you may expect there is no SLA for this server, no redundancy, limited storage. For me, it is still better to have lab running 24/7 there than using my desktop PC or pay for resources in the public cloud. The server is running ESXi 6.0 hypervisor and have a free license installed. 

The latest release of new VMware modules for Ansible was a trigger to develop a playbook that will let me back up the virtual machine from the datastore on a remote server to my home storage. Quite simple and straightforward idea lead to some unexpected problems and questions – Where should be the limit of features available in free licenses? Should automation be blocked, or at least some tasks, in free features?

The playbook

The idea of the playbook is really simple and consists of few steps:

• Get basic facts about the host, the VM and datastore
• Determine the location of the virtual machine files on the datastore
• Stop or suspend the VM
• Copy the files
• Start or resume the VM

The first two tasks are straightforward. Copying the files is a little harder because there is no module that will let you copy from datastore on ESXi host. As a workaround, I decided to enable the SSH service on the host and use the scp to copy the files. However, you cannot do this if the virtual machine is powered on because the host put read-write locks on the files. So you need to stop or suspend the virtual machine first. 

The licensing problem on ESXi hypervisor

Let’s say I faced two major problems:

• Some operations are not supported in Ansible modules (yet)
• Operations blocked because feature is no available in free license

I will just focus on the second problem. I do not deny that VMware has to earn money somehow and if you are using the free ESXi hypervisor license you can’t expect advanced features like Distributed Switch or vMotion. If you need advanced features you have to pay for them. 

The playbook task to change the virtual machine state:

- name: Start the VM
  vmware_guest_powerstate:
    hostname: "{{ esxi_hostname }}"
    username: "{{ esxi_username }}"
    password: "{{ esxi_password }}"
    validate_certs: "{{ esxi_validate_certs }}"
    name: "{{ vm_name }}"
    state: suspended
  delegate_to: localhost

It was quite unpleasant surprise to hit following error message

Current license or ESXi version prohibits execution of the requested operation.

I tested on other hypervisor running the trial full license and as expected I was able to change the virtual machine state successfully. 

Blocked in automation, allowed via CLI

Changing the virtual machine state using the API method is not possible due to license restrictions. You can do this via the web interface. If you are using an older version of the ESXi hypervisor you can also use the vSphere Client. You can also enable the SSH service on the host and use the vim-cmd command to change the VM state. 

So can you code it in your Ansible playbook? Yes, you can! Using the shell module you can execute any shell command on a remote host, the only disadvantage is you need to parse the output manually. In the presented scenario first, you need to execute the vim-cmd vmsvc/getallvms command to list all virtual machines and parse the output to read the Vmid of the virtual machine. This is the attribute you won’t get via API or Ansible module. Next, you execute the vim-cmd vmsvc/power.suspend command providing the Vmid as the last parameter.

The licensing (il)logic

VMware invested quite a lot of resources in many technologies supporting the automation. The PhotonOS, the VMware Harbor, the public cloud integration etc. are just some examples. Blocking some operations via API while allowing them via CLI does not fit into any reasonable model. It is like enforcing people to use the worst practice (remember, using the shell module should always be your last resort choice) or spending the money on licenses. 

I used a real case example here on VMware products. However, this is probably not just one vendor case. It leads to a wider question what licensing approach should we expect from vendors? Is it justified to expect additional payment for features required for automation, including the access to the API? Does it sound right the operation is blocked via API and allowed via CLI?

In my opinion, nowadays the programmable approach is no different than using the CLI or GUI. And the API available for everyone was never a different product for customers comparing to what vendors used in their GUI interfaces or dedicated software. Extended documentation of available methods is widely available and kept updated because more and more people are using them every day. If user can perform the operation via CLI requesting additional money to allow him performing it via API sounds unfair for me. There is nothing wrong in charging for advanced features of the product but it sounds wrong asking for additional licenses if you just want to use the API interface.

Shortly – in my opinion, there should be full parity between the CLI and API with no additional cost.