ghettoVCB + ghettoVCB-restore Updates

I finally got a chance to finish up the documentation on some of the new feature enhancements and bug fixes for both ghettoVCB and ghettoVCB-restore this weekend. One of the biggest change is both ghettoVCB and ghettoVCB-restore are now bundled together and ghettoVCB-restore is now being version controlled on github just like ghettoVCB. This has been on the backlog for awhile and I am sorry it took this long to get implemented.

Here are the release notes for the enhancement/fixes for both ghettoVCB + ghettoVCB-restore. Hope you enjoy these updates and if you have any issues, please report them on the ghettoVCB VMTN group.

ghettoVCB 

Enhancements:

• ghettoVCB & ghettoVCB-restore is now packaged together and both scripts are versioned on github
• ESXi 5 firewall check for email port (Check FAQ #33 for more details)
• New EMAIL_DELAY_INTERVAL netcat variable to control slow SMTP servers
• ADAPTER_TYPE (buslogic,lsilogic,ide) no longer need to manually specified, script will auto-detect based on VMDK descriptor file
• Using symlink -f parameter for quicker unlink/re-link for RSYNC use case
• Updated documentation, including NFS issues (Check FAQ #19 for more details including new VMware KB 1035332 article)

Fixes:

• vSphere 4.1 Update 2 introduced new vim-cmd snapshot.remove param, this has now been updated in script to detect this new param change

ghettoVCB-restore

Enhancements:

• Support for ESX(i) 5.0
• Combined ghettoVCB + ghettoVCB-restore scripts
• ghettoVCB-restore is now versioned on github

When Do vSphere MoRef's Change?

I received a few follow-up questions from my earlier article vSphere MoRef (Managed Object Reference) ID Finder Script regarding when the MoRef (Managed Object Reference) ID changes. As mentioned in my previous article, a MoRef ID is guaranteed to be unique within a vCenter instance to track all entities such as virtual machines, hosts, datacenters, resource pools, etc. and this is stored within the vCenter Database. One thing that I did not mention in the other article, is there is also a MoRef ID for objects that reside directly on an ESX(i) host. The scope of a MoRef ID on an ESX(i) host is only within the host itself, this is another reason why it is a best practice to use vCenter to not only manage your inventory but also keeping track of a single consistent global MoRef ID.

An entities MoRef ID will remain the same throughout it's lifespan unless it is destroyed or unregistered from vCenter Server (e.g. virtual machine or host). With a MoRef ID on an ESX(i) host, this will slightly change with vSphere operations such as vMotion and/or Storage vMotion of a virtual machine in which the VM will be unregistered and re-registered on a completely different host.

Here are a few examples demonstrating some vSphere operations and what happens to MoRef ID:

1. vMotion of a VM from HostA to HostB

As you can see, the vCenter MoRef ID stays the same during the vMotion, but the MoRef ID on the hosts will change as the VM changes hosts.

2. Storage vMotion of a VM's disk while residing on the same host (HostB)

With Storage vMotion, the vCenter MoRef ID stays the same as one would expect, but the MoRef ID on the hosts still changes because start with vSphere 4.x, a Storage vMotion starts off just like a vMotion and hence a new VM entity is registered on the same host.

3. Clone of VM1 to VM2

Since vCenter is creating a new VM entity, a new MoRef ID will be generated as expected.

4. FT of VM

Just like with a clone, an FT'ed VM will contain two unique entities on each local ESX(i) host and hence a different MoRef ID will be found, but still only a single MoRef ID in vCenter.

5. Deleting VM1 and creating a new VM with same name as VM1

Again, since the entity was destroyed and re-created with the same name, it is treated as a new object and hence a new MoRef ID will be assigned to the entity, even if it has the same name. This is true if you remove an ESX(i) host from vCenter and re-add it, all information including the MoRef will be re-generated. 

Lastly, you might ask if one could modify or set a MoRef ID for an entity in vCenter since it is stored in the vCenter Database? The answer is no. The MoRef ID is stored in the vCenter Database but there are many internal pointers that uses the MoRef ID, especially when it comes to VM MoRef IDs. Just updating the ID in one location will not suffice and can cause integrity issues with your vCenter Database, not to mention it is not supported by VMware.

However, there is one way you could influence the algorithm on how the MoRef ID's are generated. Within vCenter, there is a instance ID property that is generated during the installation of vCenter Server which ranges from 0 to 63. This value can manually be adjusted as it is also used to uniquely generate VM Mac Addresses and UUID's as described in this VMware KB.

Here are some additional scenarios in which MoRef ID's will change:

• Performing a full image restore of a VM when the original VM reference was removed from vCenter (the restored VM will have a new MOR after being registered with vCenter)

• Restoring a datastore from a snapshot. Although the snapshot is the same datastore, technically it's a new LUN with a unique signature.

• VMs restored at a DR site, especially when using 3rd party replication tools.

• Hosts that have been removed from inventory and re-registered with the same vCenter server.
• restoring a vCenter DB Backup with new VM's after backup taken

vSphere MoRef (Managed Object Reference) ID Finder Script

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

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 Director Virtual Appliance

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:vmware@vcenter50-3.primp-industries.com/?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 :)

Unattended Deployment of vCloud Connector Server/Node Virtual Appliance

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:vmware@vcenter50-3.primp-industries.com/?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:vmware@vcenter50-3.primp-industries.com/?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 :)

Unattended Deployment of vCenter Orchestrator Virtual Appliance

This weekend I spent sometime with the new vCenter Orchestrator virtual appliance in the ghetto lab. Instead of using the vSphere Client to deploy the OVF, I wanted to see if I could deploy it 100% from the command line using the ovftool. One of the cool things about OVF from an author perspective, is the ability to create custom variables which can then be specified during deployment to include guest customization, network or application configurations.

In the case of the new vCO virtual appliance, VMware provides the following four variables to customize the network configuration:

• vami.DNS.vCO_Appliance
• vami.gateway.vCO_Appliance
• vami.ip0.vCO_Appliance
• vami.netmask0.vCO_Appliance

Using the ovftool, you can specify the following variables to not only deploy the vCO OVF through the commandline but also configure the guestOS network without having to manually go through vSphere Client or remote console.

Here is an example of the ovftool command to deploy vCO:

/usr/bin/ovftool --acceptAllEulas --skipManifestCheck '--net:Network 1=VM_Network' --datastore=vesxi50-1-local-storage-1 --diskMode=thin --name=vco --prop:vami.DNS.vCO_Appliance=172.30.0.100 --prop:vami.gateway.vCO_Appliance=172.30.0.1 --prop:vami.ip0.vCO_Appliance=172.30.0.142 --prop:vami.netmask0.vCO_Appliance=255.255.255.0 vCO_VA-4.2.0.1-507352_OVF10.ovf 'vi://root:vmware@vcenter50-3.primp-industries.com/?dns=vesxi50-1.primp-industries.com'
Opening OVF source: vCO_VA-4.2.0.1-507352_OVF10.ovf

If the command looks a little daunting, it is really not and to make the deployment of vCO even simpler, I decided to write a small shell script called deployvCO.sh that users can use.

The script assumes you have ovftool installed and downloaded both the vCO OVF and system disk in the same working directory. You will need to edit a few variables within the script which specifies the vCenter and ESXi host to deploy to and resources for vCO appliance such as network portgroup, datastore, etc.

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 vCO 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 vCO server and you should taken to the vCO splash screen.

Now you can easily deploy vCO without the need of the vSphere Client! Happy workflowing :)

New sponsor: Embotics

Please welcome our latest blog sponsor, Embotics!

Here is a quick intro of what Embotics provides:

Embotics Corporation provides enterprises with easy-to-use, virtualization management and private cloud automation solutions that deliver the fastest time-to-value in the industry. Hundreds of organizations globally have used V-Commander™ to reduce complexity and more effectively monitor, optimize and automate their dynamic data centers. Embotics is headquartered in Ottawa, Canada with offices in the U.S. and EMEA, and has a growing network of global partners. For more information, please visit www.embotics.com.

If you are interested in advertising with us, please contact us at admin[at]virtuallyghetto[dot]com