I am constantly amazed at the number of new use cases that can now be enabled with some of the new and updated capabilities of our vSphere Platform. I recently discovered a new vSphere API that was introduced in vSphere 6.5 called PutUsbScanCodes() which may sound a little strange but it enables some really slick Automation capabilities. This feature allows customers to send keyboard character keystrokes directly to a VM regardless of the underlying OS. In fact, the OS does not even have to be booted up for this to work which means there is no reliance on VMware Tools as this is happening at the Virtual Hardware layer.

You might ask, why would this be interesting? Lets take a look at a scenario that I had ran into years ago when I was a customer and why this feature would have really helped. At the time, there were several Virtual Appliance solutions that I needed to deploy, although I could automate the deployment, I could not automate the initial setup process. The reason for this is that before the OS is fully booted up, it required the user to interactively provide password on boot which can only be done using the VM Console. This meant solutions like the Guest Operations API was out of the question since VMware Tools is not running during this time. I suspect many of you have probably came across a similiar situation, where you are prompted for a password or some other manual input was required and the only solution is to be in front of the VM Console. Some other interesting use cases that this feature could help with are OS installations where automated deployments may not be possible due to the type of OS, automated filesystem check (fsck) or verification where manual intervention was the only option. The possibilities for this API is truly endless and I am sure there are many many more use cases where this feature could be used.

OK, so now that are you sold on the feature, lets take a look at how it works! I have built a PowerCLI script called VMKeystrokes.ps1 which demonstrates the use of this vSphere API.

The API takes in an array of scan code events or what is referred to as USB Human Interface Device (HID) Codes which is part of the USB specification for human interactions with a computer system. There was not any details on what exactly this even looked like, so it took me awhile to figure out the input and what the API was expecting. I found this online reference here which provided a mapping of keyboard keys to their respective scan codes which I have implemented a subset of the scan codes within my script. However, upon further inspection, these scan codes could not be used as-is and required a conversion to the appropriate HID format which can be seen in my code. There also a modifier type within the API that can be associated with a given scan code. One use for this is to send an upper-case character rather than a lower case.

Lets now go through a demonstration to see how the Set-VMKeystrokes function works. In my environment, I have a PhotonOS VM running and I want to automate the login via the console which means I want to pass in the username (root), hit return, pass in the password (VMware1!) and hit return.

Here is are the two commands you would provide after retrieving the name of the VM:

Set-VMKeystrokes -VMName $VM -StringInput "root" -ReturnCarriage $true
Set-VMKeystrokes -VMName $VM -StringInput "VMware1!" -ReturnCarriage $true

If now head over to our VM and open up the VM Console, we should see that both the username and password was submitted and we have just automated the login via the console! How cool is that!?

The function also supports a -DebugOn boolean option in case you want to see or debug which characters are being sent to VM along with their respective HID Code (Hex) and their converted HID Code Value (int).

Below is an example of running the same workflow as above but debugging turned on:

Set-VMKeystrokes -VMName $VM -StringInput "root" -DebugOn $true
Set-VMKeystrokes -VMName $VM -StringInput "VMware1!" -ReturnCarriage $true -DebugOn $true

From a security standpoint, this might sound like a scary feature but users do need to have the proper privilege on a given VM to use this capability. Today, this is defined by the VirtualMachine.Interact.ConsoleInteract privilege. There is a more granular privilege for this feature called VirtualMachine.Interact.PutUsbScanCodes as the previous also controls whether you can interact within the VM Console. However, this more granular privilege currently has a bug which I have already reported where it is not doing what it states. Hopefully this should be resolve in a future update and you can truly lock down this feature if have such a requirement.

In addition, from an auditing standpoint, this API does generate the appropriate vCenter Event and this can be seen both in the UI (screenshot below) as well as API. In general, this operation is no different than someone having access to the VM Console and providing input to the VM, this is merely automating that aspect of it.

Hopefully you can see all the awesome and cool potential of this API! One other neat thing you could do is combine this API with the Screenshot feature that is also available as part of the vSphere API and using Optical Character Recognition or OCR as its known to do some interesting auto-remediation. Take for example, if a Windows VM crashes (BSOD) or Linux VM kernel panics, you could process the output and instead of just reporting on it, you could take some additional action 🙂

UPDATE (10/03/17) - The following snippet below demonstrates how to send CTRL+ALT+DEL combination which simply sending in the delete character (0x63) per HID Codes along with the two modifiers  (CTRL and ALT) as outline in the vSphere API.

5 thoughts on “Automating VM keystrokes using the vSphere API & PowerCLI

  1. The method is available in vCenter Server 6.0.2 Plugin for vRO, but it’s not working (“Unable to resolve WSDL method name PutUsbScanCodes”). So yeah, not available in vCenter Server 6.0. :/

    • As the vSphere API Reference (which is the bible for vSphere APIs), states this was only introduced in vSphere 6.5. Per the error, this makes sense as the underlying WSDL in 6.0 wouldn’t know about this API. The vRO Plugin looks to have a bug 🙂

Thanks for the comment!