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.
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 12, 2013
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.
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.
- Reboot the guest operating system to clear the pending operations.
- 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.
- Click Start > Run, type
regedit
, and click OK. - Look for these registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\FileRenameOperations
- If there is a string in either of these keys, delete the string.
- Re-install VMware View Agent again.
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.
Subscribe to:
Posts (Atom)