WilliamLam.com

vSphere MoRef (Managed Object Reference) ID Finder Script

by // 20 Comments

There was an interesting article this morning by my colleague Dave Hill about Looking up Managed Object Reference (MoRef) in vCenter Server, which references a VMware KB article showing you how to use vSphere MOB to find MoRef IDs.

A Managed Object Reference ID also known just as MoRef ID is a unique value that is generated by the vCenter Server and is guaranteed to be unique for a given entity in a single vCenter instance. Steve Jin has a great article going into detail about MoRef's, that you should check out here. MoRef ID's are not only used in vSphere, but they can also be referenced in other VMware products such as vCD (vCloud Director) or SRM to name a few or even by 3rd party/custom tools as a way to uniquely track objects within vCenter.

Using the vSphere MOB is one way of retrieving the MoRef ID, but of course this can be tedious if you are trying to locate MoRef's for multiple entities, in multiple vCenters. I decided to write a quick vSphere SDK for Perl script called moRefFinder.pl that allows a users to quickly query for a variety of Managed Objects (VM,Host,Cluster,Datacenter,Resource Pool,Network, Distributed vSwitch, Folder, vApp and Datastore) in a vCenter Server.

I also noted earlier, MoRef ID is only unique within a vCenter instance, so how do you track these objects across multiple vCenters? Well, VMware introduced a new property called instanceUUID (128 bit UUID) which is unique for a given vCenter Server and you can use this along with the MoRef ID to uniquely track objects across multiple vCenters and the script automatically outputs this value for any query.

Note: There have been some optimization in the latest vSphere SDK for Perl 5.0, it is recommended you use the latest version which is backwards compatible with vSphere 3.x and 4.x

The script requires two parameters:

  • type - The type of managed object
  • name - The name of the object as seen in vCenter Server

Here is an example querying for a Virtual Machine:

Here is an example querying for a Host:

Here is an example querying for a Cluster:

Here is an example querying for a Datacenter:

Here is an example querying for a Resource Pool:

Here is an example querying for a Network (Portgroup):

Here is an example querying for a Distributed vSwitch:

Here is an example querying for a Folder:

Here is an example querying for a vApp:

Here is an example querying for a Datastore:

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

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

Unattended Deployment of vCloud Connector Server/Node Virtual Appliance

by // 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 🙂