WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Apple / How to enable remote REST API access for VMware Fusion 10

How to enable remote REST API access for VMware Fusion 10

09.29.2017 by William Lam // 4 Comments

In case you did not hear the good news, VMware Fusion 10 along with its older brother VMware Workstation 14 just GA'ed a few days ago and there are a TON of cool new features (like new Network Simulator) for both product lines. I am personally excited about the Automation capabilities that have been introduced in Fusion which includes a brand new REST API which I wrote about here during the Tech Preview release.

There was a lot of great feedback both from the community as well as myself on the REST API in particular. It looks like Fusion team took the feedback very seriously and have made a number of improvements to the GA release.

The first enhancement is that users will now be required to setup credentials before the REST API endpoint can start. During the Tech Preview, there was no way to setup passwords and anyone could login remotely to the API which was not a good thing from a security standpoint. Below is a screenshot if you try to run the vmrest binary without configuring your credentials.


Secondly, there are a number of configurable options that the vmrest utility now supports such as binding to a specific IP Address or changing the default port. These were not configurable during the Tech Preview and I am glad the Fusion team has added more flexibility to where the REST API endpoint could run.

Usage of ./vmrest:
  -c, --cert-path <cert-path>
    	REST API Server certificate path
  -C, --config
    	Configure credential
  -d, --debug
    	Enable debug logging
  -h, --help
    	Print usage
  -i, --ip <ip>
    	REST API Server IP binding (default 127.0.0.1)
  -k, --key-path <key-path>
    	REST API Server private key path
  -p, --port <port>
    	REST API Server port (default 8697)
  -v, --version
    	Print version information

Lastly, the REST API now also supports both HTTP and HTTPS where-as before, only HTTP was supported. In addition, if you wish to expose the REST API remotely (e.g. not-running on the loop back address), you will also be required to have the API endpoint running over HTTPS. Overall, these are fantastic changes and thank you to the Fusion team for being security conscious with their first release of the Fusion REST APIs.

After upgrading to Fusion 10 on my home machine, I wanted to enable remote access to the REST API but I could not find any instructions on how to set that up. I figure it should not be that difficult and the help menu mentioned the need for a private key and certificate, so I tried my luck with generating a self-signed openssl-based certificate and that worked!

Here are the instructions on enabling remote access to Fusion REST API:

Step 1 - Generate the private key and SSL Certificate by running the following command:

openssl req -x509 -newkey rsa:4096 -keyout fusionapi-key.pem -out fusionapi-cert.pem -days 365 -nodes

Step 2 - Setup your Fusion REST API credentials. To do so, first change into the /Applications/VMware Fusion.app/Contents/Public directory. Next, run the following command:

./vmrest -C


Step 3 - Start the Fusion REST API by running the following command and specifying the full path to both the fusionapi-key.pem and fusionapi-cert.pem files as well as the IP Address you wish to serve the REST API endpoint off of:

./vmrest -c /Users/wlam/fusionapi-cert.pem -k /Users/wlam/fusionapi-key.pem -i 192.168.204.1

If the operation was successful, you should see a message like the one below stating the REST API is now listening to the IP Address and port you had provided.


To verify that we can connect to the REST API remotely, lets go ahead and use our favorite REST Client, cURL! You can actually use any client from PowerShell to Postman, but since I am on a macOS system, that is the least amount of effort.

We will need to provide our credentials, using the -u option and then REST API endpoint and we will perform a GET on /vms to list all VMs within our Fusion instance by running the following:

curl -k -u 'vmware:VMw@re123!' https://192.168.204.1:8697/api/vms


As expected, the command was successful and it listed all my VMs, which I only have one.

Since the Fusion REST API is using basic authentication, you can also encode the username/password using Base64 and pass it in as a header like the following:

curl -k -H "Authorization: Basic dm13YXJlOlZNd0ByZTEyMyE=" https://192.168.204.1:8697/api/vms


Here is a quick way to generate the basic auth value using shell and one-liner python:

echo "import base64;print(base64.b64encode(b'vmware:VMw@re123!'))" | python

Thanks to read Andrew Sharpe, here is an even easier way to generate the basic auth encoding simply using echo and base64 utility:

echo -n 'vmware:VMw@re123!' | base64

More from my site

  • Automated enablement of vSphere with Tanzu using vSphere Zones in vSphere 8
  • What's New in VMware Vsish for ESXi 5
  • Can the VCSA 6.5 forward to multiple syslog targets?
  • Automating VM keystrokes using the vSphere API & PowerCLI
  • vYetti - Fun animated vSphere Login UI customization

Categories // Apple, Automation, Fusion

Comments

  1. *protectedAndrew Sharpe says

    09/29/2017 at 5:11 pm

    No need for python to generate base64:

    $ echo -n vmware:VMw@re123! | base64
    dm13YXJlOlZNd0ByZTEyMyE=

    Reply
    • William Lam says

      10/01/2017 at 7:31 am

      Thanks for the tip Andrew! I've just updated the article with your simpler method

      Reply
  2. *protectedjeffwu says

    09/29/2017 at 5:14 pm

    great blog, thanks William

    Reply
  3. *protectedJosh says

    10/10/2017 at 2:08 pm

    Thanks for the info about how to fire up the new rest API service!

    The "-u" curl option encodes and presents the supplied credentials using the most secure authentication method supported by the remote server. Which, in this case, is HTTP Basic auth -- it's not clear to me why you'd want to do that by hand. (except just for fun? 🙂

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...