WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Exploring the vCloud API Using Ruby

02.21.2013 by William Lam // 2 Comments

While working on something that was completely random, I started to play around a bit with the Ruby programming language. I had a few questions and I reached out to a buddy of mine who is Ruby developer and in doing so I was introduced to a very cool Ruby gem called HTTParty. For those of you who are not familiar with Ruby gems, it is a packaged library or application for Ruby, similar to an rpm or pkg file. The neat thing about HTTParty is that it makes working with REST APIs extremely easy and processing XML request/responses into Ruby objects without too much effort.

With the bit of knowledge I gained from my buddy, I wanted to see how easy it would be to apply this to the vCloud API using Ruby and HTTParty. To my surprise, it was actually pretty easy!

Disclaimer: I am not a developer nor even a Ruby novice. This is probably the second or third time I have used Ruby.

Before getting started, you will need to have the following installed on your system:

  • ruby (I used the latest release which is 1.9.3)
  • ruby gem
  • httparty
  • xml-fu 
  • yaml

The following vCloud APIs are implemented in the sample below:

  • Query Service API for looking up vCloud vApps
  • PowerOn vApp
  • PowerOff vApp
  • Shutdown vApp
  • Suspend vApp
  • Reset vApp
  • Create Snapshot for vApp
  • Remove Snapshot for vApp

To demonstrate the use of Ruby & HTTParty, I created a very simple Ruby script called vcd.rb which primarily deals with vApp operations.

To use the script, you will need to create a file called config-vcd.yml which contains the credentials to your vCloud Director instance. Here is what the file should look like:

:username: administrator@system
:password: supersecretpassword
:site: https://vcd.primp-industries.com

Note: This example assumes you are running vCloud Director 5.1 (but sample can be modified to support 1.5)

Here is an example of listing all vApps for the given Organization you are logging into:

Here is an example of listing a specific vApp:

Here is an example of performing several operations on the vApp:

At the end of this little exercise, I was pretty impressed at how easy it was to work with REST APIs using Ruby and HTTParty. I think the toughest part for me personally was getting used to Ruby's syntax which I was not familiar with. I also extended this exercise to the vCloud Networking and Security REST APIs which I will share in another blog post.

Useful Resources:

  • http://www.railstips.org/blog/archives/2008/07/29/it-s-an-httparty-and-everyone-is-invited/
  • http://blogs.vmware.com/vsphere/2012/03/exploring-the-vcloud-rest-api-part-1.html
  • http://blogs.vmware.com/vsphere/2012/03/exploring-the-vcloud-rest-api-part-2.html

 

Categories // Uncategorized Tags // httparty, REST API, ruby, vcloud api, vcloud director, vcloud director 5.1

Why Are There Two VMX Files?

02.19.2013 by William Lam // 4 Comments

Have you noticed that for a powered on virtual machine in vSphere 5.1, there is now an additional VMX file that ends with an ~ (tilde) found within the virtual machine's configuration directory?

This was an observation that was made by a few folks and some thought it might be related to a virtual machine's lock file which is created when a virtual machine is powered on. After a bit of research, it turns out this extra VMX file is not a lock file but actually an "edit file". This edit file is a copy of the original VMX file and when changes are required, they are applied to the edit file first. Once the changes are complete, the edit file is then atomically swapped with the original VMX file which helps prevent potential VMX file corruption. In the worst case event where the original VMX file is somehow corrupted, the virtual machine can be restored using the edit file.

This is another reason why you should not be manually editing a virtual machine's VMX file, especially when it is still powered on. For any VMX configuration changes, you should be automating using the vSphere API through the use of either PowerCLI or the vSphere SDK for Perl. For more information on automating advanced settings across your virtual machines, please take a look at this article.

Categories // Uncategorized Tags // vmx

Automating VCSA Network Configurations For Greenfield Deployments

02.17.2013 by William Lam // 6 Comments

If you deploy the VCSA (vCenter Server Appliance) or other virtual appliances directly onto an ESXi host,
you will notice the network configuration wizard for the virtual appliance is not available as you would expect when deploying to a vCenter Server.

The reason for this is that ESXi does not support some of the advanced OVF/OVA properties such as the Networking section and you will need to deploy the OVF/OVA to a vCenter Server to be able to configure these advanced options. This poses a problem if you need to deploy the VCSA in a greenfield environment where you will not have an existing vCenter Server running and you will be deploying directly to the ESXi host. Unless you have a DHCP enabled network, you will most likely need to manually go into the vSphere C# Client to change the network configuration as it was unable to obtain an IP Address.

Though this is a one time configuration, it is still not ideal and would require the use of a Windows system to access the vSphere C# Client. You can actually get around this by leveraging the GuestOperations API (previously known as VIX API) which allows you to perform operations within the guestOS that is running VMware Tools. The other nice thing about the GuestOperations API is that it does not require any network connectivity from the virtual machine.

Note: The GuestOperations API can be accessed in variety of ways and in this article I am demonstrating just two methods and does not require a Windows system. You can also access the GuestOperations API using PowerCLI if you are more comfortable with Windows and do not wish to use the vSphere C# Client to manually configure the network settings for the VCSA. I would also like to stress that though this article is about the VCSA, you can easily apply this to any VMware based virtual appliance or virtual appliance running VMware Tools.

The most important thing to identity before using the GuestOperations API is the specific command or program you wish to invoke and the argument it accepts. To configure the network configuration for the VCSA or any other VMware based virtual appliance, you would use /opt/vmware/share/vami/vami_set_network If you just run this command by itself, there are variety of options from IPv4 to IPv6, static or dhcp configuration. In our example, we will be configuring a Static IPv4 address for our VCSA and the command we would run is the following:

/opt/vmware/share/vami/vami_set_network "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"

Method 1 - Using RVC (Ruby vSphere Console)

 

RVC is a nice open-source tool for interactively managing and configuring your vSphere infrastructure. RVC can be installed on any platform, in this example, I am running RVC on my Apple OS X laptop.

Step 1 - We first need to deploy the VCSA OVA and we can do so by using the ovftool via the command-line which can also be installed on Mac OS X system.

Step 2 - We then login to our ESXi host using RVC.

Step 3 - Next we will need to "change directory" to the location of our VM, in this example my VCSA is called VCSA-5.1. We can then run the "info ." command to view the summary of our VM. We can see that our VM is powered on from our initial deployment and we are ready to apply our network configurations in the next step.

Step 4 - To be able to run the above command, we will need to first authenticate into the guestOS. To do so, we will run the "vm_guest.authenticate ." and we will be prompted for the VCSA password. By default, the command assumes the username is root but that can also be specified on the command-line. If you are successful, you should not see any errors and then we can run the "vm_guest.start_program" command. Run the following to set a IPv4 static IP Address:

vm_guest.start_program . --program-path /opt/vmware/share/vami/vami_set_network --arguments "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1"

Note: All commands in RVC can be tabbed out with auto-completion.

If the command was successful, you can quit RVC and you should be able to ping the IP Address that you have just configured.

Method 2 - Using vSphere SDK for Perl Script

 

Awhile back I wrote a script called guestOperations.pl which is a vSphere SDK for Perl script that implements the new GuestOperations API. This is a generic script which can be used to remotely connect to either a vCenter Server or ESXi host and perform operations within a guestOS as long as VMware Tools is installed and running. In this example, I also have the vSphere SDK for Perl installed on my Mac OS X laptop, but you can also install this SDK on any platform as well.

Step 1 - We will first use the "validate" operation to ensure our credentials to the guestOS is correct, but more importantly ensure that VMware Tools is up and running.

If the operation was successful, we should see our guest credentials validated. If not, you may need to wait a minute or two while VMware Tools is still loading up.

Step 2 - To invoke the command to configure the network configuration, we will use the "startprog" operation and run the following:

./guestOpsManagement.pl --server mini --username root --guestusername root --vm VCSA-5.1 --operation startprog --program_path /opt/vmware/share/vami/vami_set_network --program_args "eth0 STATICV4 192.168.1.150 255.255.255.0 192.168.1.1" --working_dir /

If the command was successful, then you should now be able to ping the IP Address that you have just configured.

As you can see, with the use of the GuestOperations API, you can do more than just setup the network configuration for a VM, you can run pretty much any command within the guestOS as you normally would if you were to RDP or SSH in. This is a very powerful interface that you can leverage to help you automate your virtual machine deployment and configurations!

Categories // Automation, OVFTool, VCSA, vSphere Tags // appliance, ip address, ruby vsphere console, rvc, vami, VCSA, vcva, vix, vix api, vsphere sdk for perl

  • « Previous Page
  • 1
  • …
  • 462
  • 463
  • 464
  • 465
  • 466
  • …
  • 561
  • 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

  • Automating the vSAN Data Migration Pre-check using vSAN API 06/04/2025
  • VCF 9.0 Hardware Considerations 05/30/2025
  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/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