vCloud Director 5.1.2 – Bug – Retain IP/MAC resources does not apply when you use the “Move to” task to move to new Storage profile.

In previous blog post I mentioned the usefulness of this setting, but during our storage migration to new profile for vCloud director we ran into a bug where this is not applied.
I have opened a case with VMware and they verified this as a bug and now has a SR.  Hopefully get this fixed within the next build.
My current vcloud director version where this applies:
vCloud director 5.1.2.1068441
Debugging the problem:

When you have to move vAPPs to new storage profile the easiest way is  to shut down the vAPP and select “move to”.

However when you perform this task the vAPP will actually release the Org VDC NAT’d address for the VM.
If you have any NAT’s configured on the Edge gateway, this will now be out of sync.

Workaround:
I will discuss this in next blog post.

VMware Labs Flings: Lctree – Visualization of linked clone VM trees


Flings: Lctree

I was just pointed to Flings by the VMware support team.
These apps and tools build by VMware engineers are great and already found my favorite for vCloud director.



This tool is designed for the visualization of linked clone VM trees created by VMware vCloud Director when using fast provisioning.  
I managed Lab Manager before and always found the build in context view feature useful to show the relationship and dependencies between virtual machines.
This helped me a lot in finding the information about shadow copies in our environment as well as the visualizing the chain length and make decisions on when to consolidate.


Applications are not supported so no fixes and use at own risk.


vCloud director setting – Retain IP/MAC resources

This is a great setting and very useful, which I hope all users are aware of.
Scenario:
We make use of internal vAPP network on each vAPP which is then connected to the Org DC network. This means that each VM has a NAT’d address to its owned assigned ORG VDC IP.
On the OrgVDC IP we then again use NAT’s to our external networks.  
The destination IP for these NATs in the Edge gateway is the Org VDC IP address assigned to the VM.
This means that we need to keep the Org DC ip address always the same for the associated VM within the vAPP.
Why use it:
Whenever you shut down a vAPP and you don’t have this setting enabled, the vAPP will release the Org DC ip address and will get a new address. NOT good!
Now the NAT on the edge gateway is out of the sync with the Org DC IP address for the NAT’d VM, and you will run into problem.
Check it!

vCloud Director 5.1 bug with vCDNI network pools

This is something i picked up during my initial configuration of vCloud director and stumped me for a many days until i was finally able to figure out what was going on.

I created various isolated-backed networks, however during the course of the configuration changes were required and I delete ALL of the network pools to start over. When I then recreated the network pools with the same VLAN.  When I deployed the vApps with local vApp network the VM’s did not want to communicate with each other at all.

Debugging the problem:

I tried recreating all of the network pools again, and deployed the vApps multiple times with different configuration.  Tried to manually setup IP address and multiple network cards.  However when i change the VM network to a portgroup that was not part of vcloud director I was able to communicate with the VM which lead me to believe the issue was not with the VM itself but with the vCloud network component. Tested the vShield Manager which seems to be working correctly.
VMware support case opened:

VMware was unable to figure out the problem at the time…
vCloud director 5.1.1.868405
vShield manager 5.1.1-848085

Resolution:

Did some research to see if any other users were experiencing this problem and ran into the a community post which describe the problem to the teeth exactly like mine. Link below.

Solution we both came up with was to re-prepare the physical ESXi host within vCloud director, without needing to do anything else.
Another workaround to this was to always leave one network pool, and this problem only appears when you delete all the isolated-backed network pools.

Links:

http://communities.vmware.com/message/2138225#2138225

VMware Vcloud Director – Deploying of VM within vApp renames the vmxnet3 ethernet adapter to #2 and lost connection. (FIXED)

I just ran into a very interesting problem today within vCloud Director when a vApp is deployed from catalog a VM will loose its network connection.  Even when Guest OS customization is disabled.

We have a vApp with multiple VMs, all Windows 2008 R2 SP1.
The vApp was saved into catalog with “make identical copy”
After creating the vApp from catalog template all the VM’s come up correctly accept the one installed with Exchange.

Debugging the problem:

It seems the network was lost and then gets recreated but is set to DHCP so no network connections possible.

  • Tried to fix by disabling the “guest OS customization” before powering on the vApp.
  • Recreated the network card on the particular VM but with no luck.

Quick fix:
Shutdown the VM
Delete the Virtual network adapter.
Power on the VM
Use device manager to remove all network interfaces with name “VMXNET”.
    ( For more information, see the Microsoft Knowledge Base articles 241257 and 2550978.)
Shutdown the VM
Edit VM properties through Vcloud director interface and under the hardware tab add a new virtual network adapter.
Power on VM with force customization.

Resolution:

The solution to our problem was to install the hotfix from Microsoft:

http://support.microsoft.com/kb/2550978

Direct download of the file is available here:
After install the hotfix and then saving the vApp to catalog we were able to deploy the vApp without any further problems.

Links:

Found the following KB article on VMware: