WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Cheatsheet for the entire VMware AppCatalyst API using cURL

01.22.2016 by William Lam // 1 Comment

There were a few questions recently about the required syntax for specific VMware AppCatalyst operations when consuming the REST API using cURL. I figured I put together a quick "cheatsheet" that contains cuRL examples for the entire VMware AppCatalyst API which not only would it help me in future but could also benefit others. Like many, I also learn by example and having explicit samples to start with is a great way to get familiar with a new technology or product. If you are new to VMware AppCatalyst and would like a quick run down on how to quickly get started, be sure to check out my getting started article here for more details.

While going through the AppCatalyst API, I did find a couple of API operations which had some inconsistencies and did not strictly adhere to the JSON format. Thanks to Roman Tarnvski for providing the solution. I am hopeful that these issues will be resolved in a future update of AppCatalyst as I do like the ease of use of their API. For the majority of the API, the self documentation via the AppCatalyst API Explorer is accurate, which you can see from the screenshot below.

appcatalyst-api-explorer
Before you can interact with the AppCatalyst REST API, you will need to start the AppCatalyst Daemon by running the following command:

/opt/vmware/appcatalyst/bin/appcatalyst-daemon

Once the AppCatalyst Daemon is running, you can open a new terminal and start working with the REST API via cURL or any other tool of choice.

1. Create a new VM from the default Photon OS VM template:

You technically only need to specify the unique "id" property, but you can also give a display name for the VM by using the "name" property.

curl -d '{"id":"VM1", "name":"MyAppCat-VM1"}' -X POST localhost:8080/api/vms

1. CreateVM
2. Clone a VM from an existing VM:

Similar to creating a new VM, you also have option of using the "tag" property to associate additional metadata with the VM.

curl -d '{"id":"VM2", "parentid":"VM1", "name":"MyAppCat-VM2", "tag":"Development"}' -X POST localhost:8080/api/vms

2. Clone VM
3. List all VMs

curl -X GET localhost:8080/api/vms

3. List VMs
4. Get a specific VM:

To retrieve a specific VM, you will need to power on the VM before this operation is allowed. I did find it strange that this was the case, but perhaps this could be enhanced in the future to not have this requirement, especially if you want to pull out details such as the "tag" property.

curl -X GET localhost:8080/api/vms/VM1

4. Get specific VM
5. Power On a VM:

curl -d 'on' -X PATCH localhost:8080/api/vms/power/VM1

Note: Other VM Power Operations: off, shutdown, suspend, pause & unpause

5. Power VM
6. Get the power state of a VM:

curl -X GET localhost:8080/api/vms/power/VM1

6. Get Power State
7. Get the IP Address of a VM:

curl -X GET localhost:8080/api/vms/VM1/ipaddress

7. Get IP Address
8. Enable folder sharing for a VM:

curl -d "true" -X PATCH localhost:8080/api/vms/VM1/folders

8. Enable Shared Folders
9. Create a shared folder mapping for a VM:

The "guestPath" property is not an absolute path within the guestOS, but rather a logical name. For more details about shared folders in AppCatalyst, please have a look at this article here. Currently there is only one "flags" property with the value of 4 which enables read/write, please refer to the article in the link above for more details about folder sharing in AppCatalyst.

curl -d '{"guestPath":"shared-folder","hostPath":"/Users/wlam/git","flags":4}' -X POST localhost:8080/api/vms/VM1/folders

9. Create Shared Folder
10. List all shared folders to a VM:

curl -X GET localhost:8080/api/vms/VM1/folders

10. List all Shared Folders
11. List a specific shared folder for a VM:

curl -X GET localhost:8080/api/vms/VM1/folders/shared-folder

11. List specific shared folder
12. Delete a shared folder for a VM:

curl -X DELETE localhost:8080/api/vms/VM1/folders/shared-folder

12. Delete shared folder
13. Delete VM:

curl -X DELETE localhost:8080/api/vms/VM1

13. Delete VM

Categories // Automation, Cloud Native Tags // appcatalyst, curl, REST API

How to change the default ports on the vCenter Server Appliance in vSphere 6.0?

01.20.2016 by William Lam // 13 Comments

When deploying the vCenter Server Appliance (VCSA), there are a set default network ports that are already pre-defined by VMware. It is generally recommended to stick with these defaults unless you have a really good reason to modify them. I am a big fan of strong defaults which can help reduce the number of steps it takes to deploy the VCSA, however I do understand that there are some organizations who may have specific security requirements which requires them to change some of the default ports. It is also important to note that changing the default network ports post-installation is not supported.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

If you deploy the VCSA using the new Guided UI installer, you will not be able to modify the default network ports. However, if you deploy using the new Scripted CLI installer, you do have the option of overriding some of the default ports. Below is a table of the ports that can be modified which includes the variable name, default port number and their port usage which is described in the vSphere 6.0 documentation here. The variable port names are required in the JSON configuration file if you decide to modify from the default.

Variable Name Port Port Usage
rhttpproxy.ext.port1 80 HTTP Reverse Proxy Port
rhttpproxy.ext.port2 443 HTTPs Reverse Proxy Port
syslog.ext.port 514 Syslog Service Port
vpxd.ext.port1 902 ESXi Heartbeat port
syslog.ext.tls.port 1514 Syslog Service TLS port
netdumper.ext.serviceport 6500 ESXi Dump Collector port
autodeploy.ext.serviceport 6501 Auto Deploy Service port
autodeploy.ext.managementport 6502 Auto Deploy Management port
sts.ext.port1 7444 Secure Token Service port
vsphere-client.ext.port1 9443  vSphere Web Client port

Under the "Networking" section of the JSON configuration file, there is a "Ports" field which accepts a JSON encoded string of the ports you wish to modify. It actually took me a bit of time to figure out the exact syntax as this was not clearly documented anywhere. Lets say we wish to change the default HTTPS Reverse Proxy from 443 to 13443 and PSC's STS port from 7444 to 7441, you will need to specify it as shown in the example below. The key is properly escape the inner-double quotations since ports accepts a single string input.

"network": {
    "hostname": "192.168.1.140",
    "dns.servers": [
        "192.168.1.1"
    ],
    "gateway": "192.168.1.1",
    "ip": "192.168.1.140",
    "ip.family": "ipv4",
    "mode": "static",
    "prefix": "24",
    "ports": "{\"rhttpproxy.ext.port2\":\"13443\",\"sts.ext.port1\":\"7441\"}"
},

If everything was successful, when you connect to the VCSA, you should see that we no longer use the default port of 443 to connect to the vCenter Server as you can see from the screenshot below.

changing-default-vcenter-server-appliance-ports
If you ever wonder what ports were selected for either a vCenter Server or Platform Services Controller, you can easily find that by following the instructions in this article.

For customers using the Windows version of vCenter Server, you do have the option of modifying the default ports using the Guided UI since there is no guarantee these ports are not in use as VMware does not control the underlying OS. You can also use the Windows Scripted CLI to modify the default ports which you can find more information here.

vcenter-server-appliance-default-ports-1

Categories // Automation, VCSA, vSphere 6.0, vSphere Web Client Tags // platform service controller, psc, rhttpproxy, vcenter server appliance, VCSA, vcva, vSphere 6.0

How to update AppCatalyst's default PhotonOS VM template w/Docker 1.9?

12.19.2015 by William Lam // 9 Comments

For those of you using VMware's free AppCatalyst Hypervisor, you may have noticed that there is currently not a way to update to the latest Docker 1.9 Engine/Client using Photon's package manager, Tiny Dandified YUM (tndf). Although you can manually install Docker 1.9 on any deployed PhotonOS VMs from AppCatalyst, the only issue with that is that all VMs based off of the default PhotonOS template will still be running version 1.8, which means you would need to apply to do this on ever new VM creation.

Not ideal at the moment, but there is a simple fix which is to update the default PhotonOS template with Docker 1.9. We can easily this simply by leveraging AppCatalyst itself to update itself 😉 or rather its default PhotonOS VMDK. Below are the manual steps if you wish to walk through this yourself, but if you rather just run a simple script that will compeltely automate the entire process, just jump straight to the bottom of this article 🙂

Step 1 - Create a new temp PhotonOS VM (in my example, I'm calling it PHOTON-DOCKER-1.9) which we will use to install Docker 1.9. You can do so by running the following command:

/opt/vmware/appcatalyst/bin/appcatalyst vm create PHOTON-DOCKER-1.9

update-docker-client-to-19-in-appcatalyst-photonos-template-1
Step 2 - Power on the temp PhotonOS VM that you just created by running the following command:

/opt/vmware/appcatalyst/bin/appcatalyst vmpower on PHOTON-DOCKER-1.9

update-docker-client-to-19-in-appcatalyst-photonos-template-2
Step 3 - Retrieve the IP Address of the temp PhotonOS by running the following command (this could take up to a minute or so to display):

/opt/vmware/appcatalyst/bin/appcatalyst guest getip PHOTON-DOCKER-1.9

update-docker-client-to-19-in-appcatalyst-photonos-template-3
Step 4 - We can now SSH to the temp PhotonOS by using the IP Address from the previous step. You will need to specify the private key to login to the PhotonOS by running the following command:

ssh -i /opt/vmware/appcatalyst/etc/appcatalyst_insecure_key photon@[IP-ADDRESS]

update-docker-client-to-19-in-appcatalyst-photonos-template-4
Step 5 - Now we will download and install Docker 1.9 but before doing so we also need to grab the "tar" utility as it does not seem to be part of the default PhotonOS. Here is a one-liner that will automatically install the tar utility and then perform the download and install of Docker (Thanks to Massimo Re'Ferre for his original install steps, just polishing up his awesomeness). Copy and paste the snippet below which you will run that inside of the PhotonOS:

sudo tdnf -y install tar;curl -O https://get.docker.com/builds/Linux/x86_64/docker-1.9.1.tgz;tar -zxvf docker-1.9.1.tgz;sudo systemctl stop docker;sudo cp usr/local/bin/docker /usr/bin/docker;sudo systemctl start docker;rm -rf usr/;rm -f docker-1.9.1.tgz;exit

update-docker-client-to-19-in-appcatalyst-photonos-template-5
Step 6 - Now that we have our PhotonOS updated with Docker 1.9, we just need to shut it down and replace the VMDK with AppCatalyst's default PhotonOS VMDK. Run the following command to find the name of your temp PhotonOS VMDK.

find "${HOME}/Documents/AppCatalyst/PHOTON-DOCKER-1.9" -name '*.vmdk'

Once you have the VMDK name, you should backup the original AppCatalyst's PhotonOS VMDK by running the following command:

sudo mv /opt/vmware/appcatalyst/photonvm/photon-disk1-cl1.vmdk /opt/vmware/appcatalyst/photonvm/photon-disk1-cl1.vmdk.bak

Next, we will copy our temp PhotonOS VMDK to AppCatalyst's default PhotonOS directory and replace its original VMDK by running the following command:

sudo cp ${HOME}/Documents/AppCatalyst/PHOTON-DOCKER-1.9/photon-disk1-cl2.vmdk /opt/vmware/appcatalyst/photonvm/photon-disk1-cl1.vmdk

Finally, we need to make sure the new VMDK has the correct permissions by running the following command:

sudo chmod 644 /opt/vmware/appcatalyst/photonvm/photon-disk1-cl1.vmdk

Step 7 - At this point, you can verify that your changes were successful by creating a new PhotonOS VM and once logged into the VM, you can run "docker version" to verify that you are now running Docker 1.9 as shown in the screenshot below.

update-docker-client-to-19-in-appcatalyst-photonos-template-6
For those those of you who do not wish to go through the manual steps, here is a quick script called update_docker_client_in_appcatalyst.sh which automates this entire process describe in the instructions above. Here is a quick screenshot of a sample execution of the script. I am hoping the Photon team will be updating the tdnf online repo so that you can simple run yum -y update docker in the future.

update-docker-client-to-19-in-appcatalyst-photonos-template-7

Categories // Apple, Automation, Cloud Native, Docker Tags // appcatalyst, Docker, Photon, tdnf

  • « Previous Page
  • 1
  • …
  • 172
  • 173
  • 174
  • 175
  • 176
  • …
  • 224
  • Next Page »

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...