WilliamLam.com

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

New Parameter in vim-cmd snapshot.remove for ESX(i) 4.1 Update 2

11.22.2011 by William Lam // 2 Comments

While going through my ghettoVCB backlog this past weekend, I came across an issue reported by a user with snapshot removal using vim-cmd in ghettoVCB. It looks like with the recent release of ESX(i) 4.1 Update 2, the "snapshot.remove" required parameters have changed. Prior to 4.1 Update 2, the command would just require a virtual machine's vmid and if it only had a single snapshot, it would automatically consolidate the snapshot.

If a VM had more than one snapshot, users would then need to specify some additional parameters that identified the particular level of the snapshot tree and the snapshot index to be removed. This was pretty difficult to use, even for myself. It now looks like VMware has simplified this command and introduced a new required parameter called snapshotId in ESX(i) 4.1 Update 2.

Here's an example VM with several snapshots and let's say we would like to consolidate snapshot3

First we'll need to query the VM snapshots using vim-cmd vmsvc/snapshot.get [vmid]

As you can see from the screenshot, there is a new property called "Snapshot Id" which can now be passed into the snapshot.remove operation.

After the snapshot3 is consolidated, the snapshot tree is re-displayed again to verify the operation. We can also confirm by looking at the vSphere Client UI

This now makes snapshot manipulation using vim-cmd extremely easy to use.

There is a fix in ghettoVCB.next that will support the new snapshot.remove operation which hopefully I'll be able to release very soon.

Categories // Uncategorized Tags // ESXi 4.1, snapshot, vim-cmd, vimsh

Unattended Deployment of vCloud Connector Server/Node Virtual Appliance

11.18.2011 by William Lam // 2 Comments

VMware just released vCloud Connector 1.5 Server and Node which is distributed as a virtual appliance. Just like in previous post Unattended Deployment of vCenter Orchestrator Virtual Appliance here is how you can automate the deployment of vCloud Connector Server and vCloud Connector Node.

Here are the four ovf properties that are used to configure the network for vCloud Connector 1.5

  • vami.gateway.VMware_vCloud_Connector_Server
  • vami.DNS.VMware_vCloud_Connector_Server
  • vami.ip0.VMware_vCloud_Connector_Server
  • vami.netmask0.VMware_vCloud_Connector_Server

Here are the four ovf properties that are used to configure the network for vCloud Connector 1.5

  • vami.gateway.VMware_vCloud_Connector_Node
  • vami.DNS.VMware_vCloud_Connector_Node
  • vami.ip0.VMware_vCloud_Connector_Node
  • vami.netmask0.VMware_vCloud_Connector_Node

To see these properties before deploying, you can query using the ovftool which can help you identify the name of the ovf variables using the following command:

ovftool --hideEula vCCServer-1.5.0.0-515166_OVF10.ovf

Here is an example of the ovftool command to deploy vCC Server:

ovftool --acceptAllEulas --skipManifestCheck '--net:Network 1=VM_Network' --datastore=vesxi50-1-local-storage-1 --diskMode=thin --name=vcc-server --prop:vami.DNS.VMware_vCloud_Connector_Server=172.30.0.100 --prop:vami.gateway.VMware_vCloud_Connector_Server=172.30.0.1 --prop:vami.ip0.VMware_vCloud_Connector_Server=172.30.0.143 --prop:vami.netmask0.VMware_vCloud_Connector_Server=255.255.255.0 vCCServer-1.5.0.0-515166_OVF10.ovf 'vi://root:*protected email*/?dns=vesxi50-1.primp-industries.com'

Here is an example of the ovftool command to deploy vCC Node:

ovftool --acceptAllEulas --skipManifestCheck '--net:Network 1=VM_Network' --datastore=vesxi50-1-local-storage-1 --diskMode=thin --name=vcc-node --prop:vami.DNS.VMware_vCloud_Connector_Node=172.30.0.100 --prop:vami.gateway.VMware_vCloud_Connector_Node=172.30.0.1 --prop:vami.ip0.VMware_vCloud_Connector_Node=172.30.0.144 --prop:vami.netmask0.VMware_vCloud_Connector_Node=255.255.255.0 vCCNode-1.5.0.0-515165_OVF10.ovf 'vi://root:*protected email*/?dns=vesxi50-1.primp-industries.com'

Of course, I wrote a simple shell script deployvCC.sh to help with the deployment. The script assumes you have ovftool installed and the OVF files located in the same directory as the script. You will need to edit the following variables if you wish to deploy vCC Server and/or Node:

Note: There are many ways of using the ovftool to deploy an OVF. In this simple example, it requires you to specify an ESX(i) host, but you can modify the locator to deploy to a VM folder or datacenter path. For more examples and options, please take a look at the ovftool documentation.

Here is an example of the script in action:

Once the vCC virtual appliance has been deployed, you can also have it automatically power on by specifying the following parameter --powerOn.

If everything was successful, you should now be able to point your browser to the hostname of your vCC Server/Node and you should taken to the vCC splash screen.

Happy vConnecting 🙂

Categories // Automation, OVFTool Tags // ovftool, vcc, vcloud connector

Unattended Deployment of vCloud Director Virtual Appliance

11.18.2011 by William Lam // 1 Comment

VMware just released vCloud Director 1.5 as a virtual appliance for the first time. This virtual appliance is not meant to be used in a production environment, but to help users easily deploy and evaluate vCloud Director. There is also an updated vCloud Director Evaluators Guide that goes along with the new vCD appliance that was released today which you should also check out.

Just like in previous post on unattended deployments of vCenter Orchestrator and vCloud Connector. Here is how you can automate the deployment of vCloud Director.

Here are the four ovf properties that are used to configure the network for vCloud Director 1.5

  • vami.gateway.VMware_vCloud_Director
  • vami.DNS.VMware_vCloud_Director
  • vami.ip0.VMware_vCloud_Director
  • vami.netmask0.VMware_vCloud_Director
  • vami.ip1.VMware_vCloud_Director
  • vami.netmask1.VMware_vCloud_Director

Note: There are two network interfaces for vCloud Director, one for HTTP and one for CONSOLE access.

To see these properties before deploying, you can query using the ovftool which can help you identify the name of the ovf variables using the following command:

ovftool --hideEula vCloud_Director_VA_CentoOS5-1.5.0.0-525550_OVF10.ova

Here is an example of the ovftool command to deploy vCD Server:

ovftool --acceptAllEulas --skipManifestCheck '--net:Network 1=VM_Network' '--net:Network 2=VM_Network' --datastore=vesxi50-2-local-storage-1 --diskMode=thin --name=vcd --prop:vami.DNS.VMware_vCloud_Director=172.30.0.100 --prop:vami.gateway.VMware_vCloud_Director=172.30.0.1 --prop:vami.ip0.VMware_vCloud_Director=172.30.0.148 --prop:vami.netmask0.VMware_vCloud_Director=255.255.255.0 --prop:vami.ip1.VMware_vCloud_Director=172.30.0.149 --prop:vami.netmask1.VMware_vCloud_Director=255.255.255.0 vCloud_Director_VA_CentoOS5-1.5.0.0-525550_OVF10.ova 'vi://root:*protected email*/?dns=vesxi50-2.primp-industries.com'

Of course, I wrote a simple shell script deployvCD.sh to help with the deployment. The script assumes you have ovftool installed and the OVF files located in the same directory as the script. You will need to edit the following variables if you wish to deploy vCD Server:

Note: There are many ways of using the ovftool to deploy an OVF. In this simple example, it requires you to specify an ESX(i) host, but you can modify the locator to deploy to a VM folder or datacenter path. For more examples and options, please take a look at the ovftool documentation.

Here is an example of the script in action:

Once the vCD virtual appliance has been deployed, you can also have it automatically power on by specifying the following parameter --powerOn.

If everything was successful, you should now be able to point your browser to the hostname of your vCD Server and you should taken to the vCD splash screen.

Happy vClouding 🙂

Categories // Automation, OVFTool Tags // ovftool, vcd, vcloud director

  • « Previous Page
  • 1
  • …
  • 503
  • 504
  • 505
  • 506
  • 507
  • …
  • 560
  • 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

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

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