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.
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.
Posts
0 comments:
Post a Comment