Slow Deploy from Template

I have run into this same issue at a couple of different customers, it doesn't get much press considering how broad the impact of this issue. Normally this manifests itself as slow deploy from template operations at customers with larger vsphere environments, and the root cause is a vcenter bug relating to how deploy from template operations are performed. 

VMware KB: Cloning or deploying from a template takes longer time after upgrading to VMware vSphere 5.1 Update 2 and…

If we look at this KB article we can see that the way that vCenter does the clone operation changed with 5.1u2 and 5.5. In versions previous to this vCenter told the DESTINATION ESX host to perform the clone operation, starting in 5.1u2 and 5.5 vCenter began telling the SOURCE esx host to perform the clone operation. 

This doesn't cause issues in small environments where all ESX hosts have access to all datastores, but what happens in larger environments? In larger environments the performance will depend on where the template VM is registered. Many times the template VMs are registered in management clusters that can't see the production storage. If vCenter tells the source ESX host to execute the copy (where the template is registered) and it can't see the destination datastore it will copy the VMDK to the destination host over the MGMT VMkernel interface. This leads to slow clone times, and timeouts during multiple clone operations since the ESX host where the template is registered is doing every clone operation. 

In order to resolve the issue it is recommended to upgrade to 5.5u2d or 6.0 release of vCenter. This returns the behavior to the destination ESX host performing the copy operation. As long as all hosts have access to the mgmt datastore where the templates are registered then the destination ESX hosts can copy them directly over the storage network, many times with VAAI acceleration. During multiple deployments DRS assigns the new VMs to multiple ESX hosts, so the process doesn't overwhelm the single host where the templates are registered. 

So to resolve : 

1. Create a MGMT datastore available to all ESX hosts at the site.

2. Place all templates on MGMT datastore

3. Make sure vCenter is at 5.5u2d or greater. 

Read More

Static Routes on vCenter Server Appliance

Sometimes in the lab I have to make some interesting choices in how I make things work, that might not specifically be the best practice. I ran into one of these decisions today, as I needed to create static routes in the vCenter Server Appliance to create connectivity to a vRA install in the lab. This VRA install was behind an NSX edge router, while vCenter was on the same VLAN as the uplink of the NSX edge.

In this case I'm using the 5.5 vCenter Server Appliance, but this would probably work on other versions of the appliance.

I logged into the host with SSH, and checked the routing table (route -n). In this case my vCenter appliance had the IP address of 192.168.1.120, and the only route I had was to the default gateway of 192.168.1.1. I need to create a specific route for the 192.168.110.0/24 network, and point it to the upstream interface of the NSX edge at 192.168.1.124.

I could add the route using the route command, but it would need to be reentered after a reboot. Since I need this to be sticky I'll create the route with the ifroute-eth0 config file, located at /etc/sysconfig/network/ifroute-eth0 . I'll pipe the config I need to the file to route all traffic headed for 192.168.110.0/24 to 192.168.1.124, then restart networking.

echo 192.168.110.0 192.168.1.124 255.255.255.0 eth0 > /etc/sysconfig/network/ifroute-eth0

Restart networking:

service network restart

And make sure the route took by checking the routing table with route -n.

Simple and helped my get some things running in the lab that would have otherwise slowed down a project.

Read More