Thursday, December 12, 2013

VMware CPU Resource Pool Guide

When looking at the 'New Resource Pool' window in vCenter, you are presented with a few misleading options, Shares and Reservations. VMware has taken it upon themselves to work in three pre-configured settings you can choose from, Low, Normal and High. Once you begin to understand the ideology behind an RP and the inner workings of resource contention, then you will understand how pointless and dangerous those pre-configured 'RP Shares' settings can be.
Below is an example diagram that I have created to demonstrate a misconfigured RP environment.
misconfigured-resource-pools
I have found in my workings with resource pools that taking the approach of a balanced sharing system is key. Today I want to share with you the basic concept I use when implementing resource pools. Using simple math equations, you are able to create a balanced system that allocates shares evenly throughout all of your child pools. This equation is simple to understand.

The first thing to implement is a priority scale (High, Medium, Low, etc.) and assign a value to each priority (this will be used in the equation). I like to keep things on the 1:2:4 scale and use multiples of a thousand to keep my math simple. For this example, I will be using the following priorities:

High – 4000
Normal – 2000
Low – 1000

Now that our priorities are set, we need to begin building the resource pool structure. This structure will consist of three parent resource pools with child resource pools broken down by the number of vCPU's that each VM contains within that RP. Here is the breakdown for the Resource Pool infrastructure:

RP-High
RP-High-vCPU1
RP-High-vCPU2

RP-Normal
RP-Normal-vCPU1
RP-Normal-vCPU2

RP-Low
RP-Low-vCPU1
RP-Low-vCPU2

Understanding that virtual machines with multiple virtual CPU's are going to require more resources from the hypervisor, it is important to calculate the shares accordingly. Basically, within the parent resource pool, you will want to separate your VM's with 1 vCPU and place them in their appropriate child pool, and do the same with each VM that have 2 vCPU's (in a large environment, there will be many child pools, considering the amount of vCPU's you are allowed to give a VM is much higher that 2). This method allows you to give a higher number of shares to VM's in a resource pool that contains VM's with multiple vCPU's while maintaining the balance to the peer 'Parent Pools' (High, Normal and Low).

Now that the resource pools have been created and each virtual machine has been placed inside its appropriate child pool, it's time do the calculations.

To calculate the Shares, you must start from the bottom and work your way up. The equation is based off the number of virtual machines within the pool, the value assigned to your priority, and the number of virtual CPU’s that each machine maintains within the pool. Once all of the child resource pools have been calculated and assigned a share value, each child's share count is added together to give you the total number of shares to assign the parent pool. Here is the equation:

[#VM in pool × Priority Value] × vCPU count = Share Count

So, using this basic equation, let's calculate the 'High' resource pool and all of its child pools. The VM breakdown is as follows:

RP-High = 68 total virtual machines
RP-High-vCPU1 = 47 virtual machines
RP-High-vCPU2 = 21 virtual machines

Using our equation and understanding that (RP-High-vCPU1 Shares + RP-High-vCPU2 Shares = RP-High Total Shares), the math is:

RP-High-vCPU1 = [47 × 4000] × 1 = 188000 Total Shares
RP-High-vCPU2 = [21 × 4000] × 2 = 168000 Total Shares

Notice that even though vCPU1 RP has more shares, if you divide the number of shares by the number of VM's in the resource pool, you will notice that the share value per VM is lower than the share value per VM in the vCPU2 RP (8000 shares per VM in vCPU2 and 4000 shares per VM in vCPU1). Now we add these two values together to give us our parent resource pool count:

RP-High = 356000 total shares
RP-High-vCPU1 = 188000 total shares
RP-High-vCPU2 = 168000 total shares

This same equation would be applied to every resource pool/child resource pool in your environment to give you a balanced share value throughout your entire infrastructure. Once implemented, it will be your responsibility to update the equations as new VM's are introduced in to your environment to ensure you keep the values balanced.

Thursday, December 5, 2013

Installing VMware View Agent or View Composer fails with the error: The system must be rebooted before installation can continue (1029288)


    Symptoms:
  • You cannot install VMware View Composer/Agent.
  • Installing VMware View Composer/Agent fails.
  • You see this error:

    The system must be rebooted before installation can continue
     
  • Restarting the machine does not resolve this issue.
Possible cause?
This issue may occur if there are pending operations from previous installations.




 

Here's what I did to resolve my particular issue when trying to upgrade the View Composer from version 3.0 to 5.3 on the vCenter Server.
  1. Reboot the guest operating system to clear the pending operations.
  2. If the issue persists, try removing VMware Tools and re-installing it, then proceed to the next step if this does not resolve the issue.
  3. Click Start > Run, type regedit, and click OK.
  4. Look for these registry keys:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\FileRenameOperations


  5. If there is a string in either of these keys, delete the string.
  6. Re-install VMware View Agent again.
Note: If this does not resolve the issue, you may need to delete any strings in these keys as well:
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\
  • OnceEx\
    After deleting the strings, reboot the virtual machine and attempt to install the View Agent.