O'Reilly logo

VMware Cookbook, 2nd Edition by Ryan Troy, Matthew Helmke

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. Resource and vCenter Management

Resource management is key in any virtualized environment. In the context of VMware ESXi and vSphere, resource management includes clustering, HA, and the DRS. This chapter takes a look at the available technologies and how they work together to help you manage your environment effectively. We’ll explore:

vSphere clusters

Clusters within the ESXi environment allow you to pool multiple physical ESXi hosts to create a virtual pool of resources from the combined resources of all of the ESXi hosts. The three main elements of VMware clustering are the DRS, fault tolerance, and HA.

vSphere HA

This provides you with a cost-effective and intelligent engine that can provide high availability within your ESXi cluster. For example, if you have a four-node cluster and one node in the cluster goes down, you can configure HA to automatically start up the virtual machines from the failed node on any remaining node that has available resources.

vSphere DRS

The DRS actively monitors all virtual machines in a cluster and manages their resources. DRS can be configured to provide you, the administrator, with guidelines on which virtual machines can benefit from being moved to another host. You can also configure DRS to automatically take care of the migration through vMotion.

In this chapter we will discuss various aspects of these technologies and how to configure, set up, and maintain resources in vCenter.

Monitoring Virtual Machines Inside the vSphere Cluster

Problem

You wish to monitor a virtual machine inside the vSphere 5.0 cluster.

Solution

Enable virtual machine monitoring inside the vSphere cluster.

Discussion

vSphere 5 has the ability to monitor and watch virtual machines inside the cluster for a heartbeat. This allows virtual machines that time out or crash with the famous blue screen of death (in Windows) to be rebooted automatically. There are a few settings that can be configured and we’ll take a look at those now.

VM monitoring

This setting allows you to disable all monitoring, to monitor virtual machines only, or enable VM and application monitoring. Application monitoring is available via third-party scripts that interact with VMware Tools inside the guest to check and validate specific applications.

Monitoring sensitivity

By default, there are three options that can be selected:

Low

Checks are made at 2-minute intervals. A virtual machine will be rebooted after each failure for the first three failures every 7 days.

Medium

Checks are made at 1-minute intervals. A virtual machine will be rebooted after each failure for the first three failures every 24 hours.

High

Check are made at 30-second intervals. A virtual machine will be rebooted after each failure for the first three failures every hour.

Additionally, there is an option to create a custom monitoring policy. Do so as follows:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on the cluster on which you wish to enable VM monitoring and click Edit Settings.

  3. Under vSphere HA on the left menu, click the VM Monitoring option (Figure 4-1).

    VM Monitoring
    Figure 4-1. VM Monitoring
  4. In the right-hand pane, select the configuration that is suitable for your environment. Once completed, click the OK button to save these changes to the cluster.

4.1. Understanding Virtual Machine Memory Use Through Reservations, Shares, and Limits

Problem

You want to apportion memory among your virtual machines to meet specific application needs.

Solution

Specify the minimum and maximum amounts of RAM that should be available to your virtual machines.

Discussion

Much like CPU resource management, which we’ll discuss later in this chapter, memory management involves configuring reservations, shares, and limits. In this recipe, we will look at each resource setting and discuss their differences:

Available memory

Allocates a particular amount of RAM on the ESXI server to the virtual machine when it is created. This amount reflects the initial amount of memory available for the virtual machine, but the value can grow or shrink as the virtual machine takes on work and contends with other virtual machines for memory.

Memory reservations

Set a minimum amount of memory, measured in megabytes, that will always be available for a virtual machine.

Memory shares

These work the same as CPU shares (described in Recipe 4.3) and are specified in increments of Low (500 shares), Normal (1,000 shares), High (2,000 shares), or Custom, which allows you to enter a custom value. Shares allow you to establish a priority when memory contention is taking place and memory is becoming overcommitted.

Memory limits

Allow you to set a limit on the maximum amount of RAM that the virtual machine can consume. Memory limits are measured in megabytes. The memory limit on the virtual machine should be enough to satisfy the requirements of the OS inside the virtual machine. The initial available memory limit is specified when creating the virtual machine, but it can rise in accordance with the options discussed in this chapter.

You’ll start to see the benefits of using limits when you build your first virtualization cluster with a small number of virtual machines. This will allow you to manage user expectations and monitor your servers for actual usage so you can make adjustments later. However, you may notice performance degrade as you add more virtual machines to the cluster.

VMware also controls memory through the vmmemctl driver, which runs on a virtual machine and works with the server to reclaim unused memory and reassign it back to the resource pool for other virtual machines to use. This is called ballooning and kicks in when memory resources may be low or running out on the cluster.

Reservations not only help virtual machines to meet response time and workload requirements, but they can also lead to wasted idle resources. For example, if you give your virtual machine 1GB of memory but it’s only using 256MB, the remaining memory will not be available to the other virtual machines to use.

A server can allocate more memory than the amount specified in a reservation, but it will never allocate more than the limit. When you use reservations and limits together, you should set the reservation for each machine to 50% of its limit and make sure it’s set high enough for the operating system and applications to avoid surrender requests from the memory ballooning driver.

We recommend that you use limits only to satisfy specific needs. For other purposes, use shares instead. As with CPU shares, you can also leave the memory shares set to Normal as a base to start. However, if you have a mission-critical application that might have higher resource requirements, you can give it a High or Custom share value to ensure that the virtual machine will win the resources it needs when contention occurs.

You can set any of these memory measurements for a virtual machine as follows:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on the virtual machine and select Edit Settings from the menu. This will bring up another window where you can configure the virtual machine’s memory resources (see Figure 4-2).

  3. Click on the Resources tab. Here you can set specific memory, CPU, advanced CPU, and disk variables. We will specifically look at the memory options, so click Memory in the left-hand menu.

  4. In the right-hand pane, you can specify Shares, Reservation, and Limit values for memory resources, as seen in Figure 4-2. When you’ve completed your configurations, click the OK button to save the changes and have them applied to the virtual machine.

Memory resource configuration
Figure 4-2. Memory resource configuration

4.2. Configuring Virtual Machine CPU Limits

Problem

You need to understand CPU limits and how to use them effectively.

Solution

Apply CPU limits using the vCenter.

Discussion

CPU limiting within the ESXi environment is a way to restrict the CPU consumption, measured in megahertz, for specific virtual machines. Setting a limit on a virtual machine’s CPU consumption allows for better management of contention issues within your environment. It also allows you to know what the CPU on that virtual machine is capable of achieving when operating at full strength.

Setting the CPU limit too high or too low can cause performance issues on the virtual machine. The limit should be balanced such that there is enough CPU power at the machine’s disposal to handle load spikes and high application usage, but not so high that CPU cycles are being wasted.

It’s important to observe your virtual machines and adjust their CPU limits accordingly. For example, if you set a virtual machine’s CPU limit at 1,000MHz but notice that its usage never exceeds 700MHz, you might consider adjusting the CPU limit on that virtual machine to 800MHz. By doing this, you are effectively freeing up 200MHz for other virtual machines and not wasting the cycles. That said, virtual machines’ CPU usage is generally low, and the DRS will do a good job of managing those resources; if you set your virtual machine’s limit to 1,000MHz, the unused cycles will be put back into the pool of resources.

Adding a CPU limit to a virtual machine is simple using the vCenter client:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on the virtual machine on which you wish to adjust the CPU limit and select Edit Settings from the menu. This will bring up another window in which you can configure the virtual machine’s CPU limit.

  3. Click on the Resources tab. From here you can set specific values for memory, CPU, advanced CPU, and disk variables. We will specifically look at the CPU limit variable in this recipe. Click the CPU option in the left window pane to configure this setting (Figure 4-3).

Setting a CPU limit
Figure 4-3. Setting a CPU limit
  1. A slider bar next to the Limit label allows you to configure a CPU limit by dragging the bar; alternatively, you can enter an amount in the box or click the up and down arrows. As you can see in this example, we have given the virtual machine a CPU limit of 4,102MHz, a small amount of the CPU resources available in the DRS cluster. We could achieve the same effect by checking the Unlimited box.

    Once you are satisfied, click the OK button to make the change.

See Also

Recipes 4.3 and 4.4

4.3. Configuring Virtual Machine CPU Shares

Problem

You want to apportion CPU, memory, or disk resources among machines unequally, while remaining flexible in case resources change.

Solution

Configure CPU shares using the vCenter client.

Discussion

CPU shares allow you to regulate how many competitions a virtual machine will “win” when trying to access resources within the pool. For example, when contention occurs within the ESXi Host or cluster, a virtual machine with 2,000 shares will receive more CPU resources than a virtual machine with, say, 1,000 shares. Shares are configured relative to the other shares; thus, only the proportion of shares matters, not the values of the shares. Three virtual machines with share values of 1,000, 2,000, and 3,000 will act exactly the same as three virtual machines with share values of 1, 2, and 3. You may choose to use any number scheme you prefer, although we suggest leaving ample space between the numbers to make future additions to your resource pool easier to configure within your existing scheme (this way, you won’t have to renumber the share values of all or many of your existing virtual machines).

When there is no contention for resources, shares mean very little to the operations of the virtual machines.

One benefit of using shares rather than limits or reservations is that when you upgrade the ESXi Host’s memory or CPU, you will not have to adjust the resources used by each virtual machine; because each virtual machine keeps the same number of shares, new resources will automatically be apportioned in the same ratios as the old ones.

Using shares really comes in handy when planning your environment to ensure your resource pool is balanced. Of course, you can change a virtual machine’s settings at any time if you specifically have to allocate X amount of resources, and at that point, shares may not be useful.

Typically, VMware recommends that you use shares instead of setting reservations, although we will discuss setting fixed reservations in the next recipe just in case you find yourself in a situation that requires it.

Let’s take a look at configuring shares on a virtual machine using the vCenter client:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on the virtual machine to which you wish to assign the shares and select Edit Settings from the menu. This will bring up another window in which you can configure the virtual machine’s CPU share values.

  3. Click on the Resources tab. From here, you can set specific values for memory, CPU, advanced CPU, and disk variables. We will look at the CPU shares variable in this recipe. To configure it, click the CPU option in the left window pane (Figure 4-4).

Setting CPU shares
Figure 4-4. Setting CPU shares
  1. In the drop-down box next to the Shares label you can choose between Low (500 shares), Normal (1,000 shares), High (2,000 shares), and Custom. Giving a virtual machine more shares increases its chances of “winning” when virtual machines compete for more CPU cycles.

    Generally, you can start with the Normal share selection until you reach a point of contention, at which point you can go back and adjust your virtual machines based on their usage and requirements.

    Once you have selected the appropriate level for your virtual machine, click the OK button to save this change.

See Also

Recipes 4.2 and 4.4

4.4. Configuring Virtual Machine CPU Reservations

Problem

You want to reserve some percentage of the CPU on the ESXI server for specific virtual machines.

Solution

Configure CPU reservations on the virtual machines using the vCenter client.

Discussion

In addition to shares and limits, you can also set reservations on your virtual machines. A reservation is a set number in megahertz that you allocate to a particular virtual machine. Typically, this is between 5% and 10% of the processor’s capacity, but it will vary based on your environment.

Setting a reservation guarantees that a certain minimum amount of resources will be available to the virtual machine, so that it can power on (if these resources do not exist or are not available, the virtual machine will not power on). Once the virtual machine is started, the reservation amount is taken away from the pool of resources over which other virtual machines compete. In other words, each of the virtual machines will take its individual reservation first, and then compete with the other virtual machines for the remainder of the (unreserved) resources.

You can add a reservation to a virtual machine through the vCenter client:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click the virtual machine you wish to modify and select Edit Settings from the menu. This will bring up another window, which you will use to configure the virtual machine’s CPU reservation.

  3. Click on the Resources tab. From here you can set specific values for memory, CPU, advanced CPU, and disk variables. We will look at the CPU Reservation variable in this recipe; to configure it, click the CPU option in the left window pane (Figure 4-5).

  4. CPU reservations are the second available option. Notice there is a slider bar as well as a box in which you can specify how much CPU to allocate to the virtual machine: you can drag the bar to the desired amount, type a value in the box, or click the up and down arrows (also shown in Figure 4-5).

    Once you have selected the appropriate level for your virtual machine, click the OK button to save this change.

Setting CPU reservations
Figure 4-5. Setting CPU reservations

See Also

Recipes 4.2 and 4.3

4.5. Setting Up Resource Pools

Problem

You want to group virtual machines and manage the allocation of resources to various groups.

Solution

Create resource pools and assign resources to them.

Discussion

Resource pools are a great way to manage and divide resources among groups or departments within your organization.

Before resource pools can be enabled on a cluster, you will need to ensure DRS is enabled (see Recipe 4.10).

To enable a resource pool on a cluster, log in to your vCenter server and follow these steps:

  1. Right-click on the cluster in which you wish to create the resource pool and choose New Resource Pool (Figure 4-6).

Creating a new resource pool
Figure 4-6. Creating a new resource pool
  1. You will now be presented with a new window from which you can configure the resource pool (Figure 4-7).

    The CPU and memory resource allocations for the resource pool work similarly to the way they work for virtual machines. For example, we have given this resource pool a reservation of 12,066MB of memory and 12,066MHz of CPU. Because we left the Expandable option checked, the pool can burst above the 12,066MHz reservation if required and if the resources are available in the cluster. Refer to Recipes 4.6 and 4.7 for more detailed information.

    You can adjust these values to suit your needs and divide your resource pools between production, development, etc.

Setting values on the new resource pool
Figure 4-7. Setting values on the new resource pool
  1. When you’re finished, click the OK button and the resource pool will be added.

Adding new virtual machines to the resource pool can be done in two ways:

  • By dragging the virtual machine into the resource pool in the vCenter client

  • By placing a new virtual machine into an existing resource pool when you create the virtual machine

See Also

Recipe 4.6

4.6. Understanding Resource Pools

Problem

You want to understand how resource pools work and what capabilities they offer.

Solution

Investigate the various resource pool options and how to use them.

Discussion

Resource pools can be used to create partitions of available CPU and memory. Resource pools help you better manage and use resources across different departments or within a group of servers.

For example, perhaps you want to give your production team 20GHz of CPU and 20GB of memory, and your development team 10GHz of CPU and 10GB of memory. You can accomplish this by creating resource pools and assigning the virtual machines for the given departments to their respective pools (Figure 4-8).

Example resource pool layout
Figure 4-8. Example resource pool layout

Notice that in Figure 4-8 we have a master resource pool called General and two subresource pools called Development and Production. In this configuration, the subresource pools are assigned resources from the master (General) resource pool. In this example, the Development and Production subresource pools have been assigned the amounts shown in Figure 4-9.

Example resource pool reservations
Figure 4-9. Example resource pool reservations

Let’s take a closer look at the reservations we’ve given each resource pool:

General resource pool

The General resource pool has 4,094MHz and 8,041MB of unreserved resources available for the development and production subpools to use. It is not handed out all at once at the start, but rather is made available as needed (see the next recipe for details).

Development subresource pool

We have given the Development resource pool a total of 12,496MHz of reserved CPU.

Production subresource pool

The Production resource pool has only 5,171MHz of reserved CPU.

In this example, if the resources required by the Production pool exceed 5,171MHz of CPU, it will borrow resources from the master resource pool, which has 4,094MHz available.

See Also

Recipes 4.5, 4.7, and 4.10

4.7. Expandable Reservations in Resource Pools

Problem

You want to understand expandable reservations.

Solution

Investigate expandable reservations and when and how they should be used.

Discussion

Expandable reservations give extra flexibility when you allocate resources to a specific resource pool. You can assign a minimum set of resources to each subresource pool and allow it, by defining the reservation as Expandable, to get more resources from the ESXI server as needed. Thus, on a day when the development team is racing to do a lot of bug fixing to meet a deadline, its subresource pool may expand beyond the normal limits. On another day, the production subresource pool may get more resources.

However, be aware that once a reservation has been exceeded/expanded, those additional resources will not be freed up again until the virtual machine is shut down and you explicitly reduce its reservation. You should also be careful when using expandable resource pools to ensure that your virtual machines do not become dependent on extra resources being available. If a subresource pool routinely expands far beyond its original allocation, you should increase the original allocation and add more hardware resources if necessary.

Notice that in Figure 4-10 we have two resource pools, Development and Production, which are each set to Expandable. Examining this figure further, you’ll see that we have 4,094MHz of CPU and 8041MB of memory unreserved at the top level of our resource pool. Because both of our subresource pools are set to Expandable, when they use the reservations we have set for them, they can borrow from the unreserved values available in the top-level resource pool.

Expandable resource pools
Figure 4-10. Expandable resource pools

Expandable reservations also come in handy when a resource pool has used all of its resources and a virtual machine needs to be powered on; if the resource pool has no available resources left, it can borrow resources from the top-level pool to ensure that the virtual machine can be powered on.

Let’s look at how to configure expandable reservations on a resource pool:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on the resource pool you wish to edit and select Edit Settings (Figure 4-11).

Editing a resource pool
Figure 4-11. Editing a resource pool
  1. The Edit Settings screen (Figure 4-12) lets you adjust the memory and CPU resources reserved for the selected resource pool. Notice that you can set expandable reservations on both CPU and memory resources, independently. To enable expandable resources, put a check in the Expandable box.

Editing expandable reservations
Figure 4-12. Editing expandable reservations

Once you’re finished, click OK to have the changes applied.

See Also

Recipe 4.5

4.8. Creating a Cluster

Problem

You want to create a cluster to manage the resources offered by multiple ESXI servers together.

Solution

Use the vCenter client to create a VMware Cluster.

Discussion

Creating a cluster inside the vCenter allows you to combine multiple ESXi hosts in a centralized group by placing all of their CPU and memory resources into a general pool for use by virtual machines. When you add an ESXi Host to a cluster, the resources will automatically become available for use by the virtual machines.

For example, Figure 4-13 shows two ESXi hosts, each of which has 16GB of memory and two quad-core CPUs (i.e., 8 CPUs per ESXi host, for a total of 16). Because clustering pools the resources, you effectively have an enormous unified pool of CPUs and memory for the virtual machines to run. Combining a cluster with HA and DRS will further enhance your environment.

VMware cluster overview
Figure 4-13. VMware cluster overview

There are a few requirements that should be completed prior to creating a cluster.

Storage

All ESXi hosts should have access to the same shared storage. This can be a SAN via iSCSI, Fibre Channel, FCoE, or NFS.

VMFS volumes

Virtual machines need to access all the VMFS datastores that are presented to the ESXI servers in the cluster. This is important to facilitate HA in case of a physical hardware failure.

Processor support

The physical ESXI servers that make up the cluster should have the same family of processor, such as Intel or AMD. You cannot mix Intel and AMD processors inside the same cluster. The second most important thing is to ensure the processor models inside the family are compatible with each other. VMware includes an EVC mode that allows the combination of different processor generations to work by taking the highest (newest) grade processor and downgrading it to the slow older model. If you are mixing processor generations, you should enable this feature.

Networking

The ESXi hosts must be configured to use a common vMotion network. This network must be accessible between all ESXI servers inside the cluster.

Note

You do not need a license to create ESXi clusters. However, to take advantage of HA and DRS, you will need to obtain a license key from VMware.

VMware has done a really nice job of making it simple to add a new cluster in the vCenter:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on the datacenter name and select New Cluster (Figure 4-14).

    Adding a new cluster to a datacenter
    Figure 4-14. Adding a new cluster to a datacenter

    The New Cluster Wizard will launch to guide you through the process of creating the new cluster. The first screen in the wizard will ask you to enter a name for the cluster and indicate whether or not to enable two features:

    Turn on vSphere HA

    This feature is available only to users who have a license for the HA product extension. When you enable VMware HA, it will detect and provide rapid recovery of virtual machines if an ESXi Host fails. This is an optional feature and doesn’t need to be enabled to create a basic cluster.

    Turn on VSphere DRS

    This feature also requires a license. DRS allows the vCenter server to manage hosts as an aggregate pool of resources. Clusters can be broken down into smaller groups by using resource pools. VMware DRS also allows the vCenter to manage resources on virtual machines, even placing them on different hosts if used in conjunction with VMotion. This is an optional feature that is not required to create a cluster.

    When you’ve made your selections, press the Next button to continue. Additional cluster features (including DRS and HA) can be enabled or disabled at a later time using processes described elsewhere in this chapter.

  3. VMware EVC will allow you to enable enhanced vMotion between different CPU types. You can select different ESXi hosts, and this feature is limited to both AMD and Intel. You cannot mix Intel and AMD servers in the same cluster at this time. This feature is useful if you have hosts with older CPUs and are adding in new hosts and wish to enable compatibility. Once finished, select Next.

  1. Next, you will be asked where to store the swapfiles for the virtual machines. VMware gives you two options here:

    • Store the swapfile in the same directory as the virtual machine. (Recommended.)

    • Store the swapfile in the datastore specified by the host. (This option is not recommended because you could experience degraded performance.)

    Make your selection, then press the Next button to continue.

  2. Finally, review the summary and click Finish to initiate building the cluster.

You can now add ESXi hosts to the cluster (see Recipe 4.9).

See Also

Recipes 4.9 and 4.10

4.9. Adding Hosts to a Cluster

Problem

You wish to add more hosts to your ESXi cluster.

Solution

Use the vCenter client to add new hosts to an existing ESXi cluster.

Discussion

Adding additional ESXI servers to an already established cluster is easy in vCenter:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on the datacenter name and select Add Host. This launches the Add Host Wizard in a new window (Figure 4-15).

    Adding your IP address and login information in the Add Host Wizard
    Figure 4-15. Adding your IP address and login information in the Add Host Wizard

    The first screen in the Add Host Wizard will ask you for some basic information:

    Hostname

    Enter the hostname of the server, such as ESXi01.yourdomain.com. Although ESXi allows you to use an IP address, you should always use a fully qualified domain name as the hostname to ensure maximum compatibility, because ESXi relies heavily on DNS.

    Username

    Enter the username of the user who has administrative privileges. Typically, this is the root user, although this can be changed if required.

    Password

    Enter the password for the username just entered.

    When you are satisfied with your entries, click the Next button.

  3. Next, you will be presented with an informational summary showing you the name, model, version, and vendor of the host that is being added and a list of any virtual machines on that host. Click Next to continue.

  4. Next, select the licenses that will be applied to this ESXi Host. If you are using evaluation licenses, you can select that option as well. Click Next.

  5. Next, Lockdown mode, when enabled, prevents remote users from logging into the ESXi Host using administrative accounts such as root or admin (Figure 4-16). If this mode is enabled and no other accounts exist, the ESXi Host can be managed only from the vCenter. However, the administrative accounts will be able to log in to the console on the ESXi Host. This feature can be changed at a later time; if you are unsure you can leave it unchecked and enable lockdown mode later if security becomes a concern. Click Next to continue the installation.

    Enable lockdown mode
    Figure 4-16. Enable lockdown mode
  1. The next screen in the wizard is the resource pool configuration screen. You will be presented with two options, as shown in Figure 4-17. These options are pretty self-explanatory, but we’ll take a quick look at them anyway:

    Put all of this host’s virtual machines into the cluster’s root resource pool. Resource pools currently present on the host will be deleted.

    Assuming you have a resource pool set up in your cluster, this option will take all the virtual machines from the single ESXi resource pool and move them into the cluster’s pool. Once that operation is completed, it will remove the resource pools from the single ESXI server. Be careful here—remember that the virtual machines currently in the pool are getting their resources based on their pool’s settings, and adding virtual machines to the pool could take resources away from the existing virtual machines.

    Create a new resource pool for this host’s virtual machines and resource pools. This preserves the host’s current resource pool hierarchy.

    This option allows you to keep the resource pools you have already set up on your single ESXi Host. It will create new resource pools within the cluster that match those currently available on the ESXi Host.

    Resource pool settings
    Figure 4-17. Resource pool settings

    Once you have selected which resource pool option you want to use, click the Next button to continue.

  2. You will now be presented with a summary. Use the Back button if you need to make any changes, and when you’re satisfied click the Finish button to add the ESXi Host to the cluster.

    If HA is enabled on the cluster in which the host is being added, the host will automatically be configured for HA. If you are not adding the host to an HA cluster, the host will run standalone.

See Also

Recipe 4.8

Enabling Hyperthreading on a Virtual Machine

Problem

You wish to enable hyperthreading on a virtual machine, after it is enabled on your physical server.

Solution

Follow the steps to enable hyperthreading on a specific virtual machine.

Discussion

Some CPU’s come with hyperthreading support, which is not to be confused with multi-core processors. Hyperthreading allows multiple threads to be spawned off the primary CPU to help balance processing. However, in a virtualized environment, this might not always be the best solution. Hyperthreading doesn’t double the CPU speed, it just allows the server to split the logical CPU into multiple logical CPUs, creating a virtualized CPU. Hyperthreading can, in some situations, provide a benefit with virtual machines. However, it can also decrease performance, because it contains the potential to place additional workloads on the primary logical CPU.

To enable hyperthreading on a virtual machine, follow these steps (Figure 4-18). We assume that hyperthreading has already been enabled in the physical ESXI server’s BIOS.

  1. Load the vCenter client and log in to your vCenter server.

  2. Select the virtual machine from the inventory list, then right-click on the virtual machine and select Edit Settings.

  3. Click the Resources Tab and select Advanced CPU.

  4. Here you will see three options that control hyperthreading. None of the options affect the way the virtual machine is allocated CPU time.

    Enable hyperthread core sharing
    Figure 4-18. Enable hyperthread core sharing
    Any

    This is the default setting when turning on hyperthreading for a virtual machine. This will allow the virtual machine to share virtual CPU time across multiple virtual machines.

    None

    This setting will prevent the virtual machine from sharing its CPU and from borrowing CPU time from other virtual machines. The processor acts as a dedicated core.

    Internal

    This setting may be useful if you have an SMP-enabled virtual machine. The setting allows the virtual machine to borrow CPU time from multiple processors, but does not allow sharing with other virtual machines.

  5. Once you have selected the settings that best reflect your environment, click OK.

4.10. Enabling DRS in a Cluster

Problem

You wish to enable DRS in your current cluster.

Solution

Use the vCenter Client tool to enable DRS.

Discussion

Enabling DRS inside an already created cluster is easy using the vCenter client. If you have VMware vSphere Enterprise, DRS is integrated already. With the standard version of vSphere, DRS is an optional add-on. Regardless of which version you have, we’ll walk you through the steps of enabling DRS and explain the different settings along the way:

  1. Load the vCenter client and log in to your vCenter server.

  2. Right-click on your cluster and select Edit Settings from the menu. This will bring up another window with configuration options for the cluster. We are going to be looking at the General area as well as the VMware DRS area and its subsections.

  3. Click the General label in the left-hand window. You will now be able to rename your cluster and enable or disable vSphere HA and vSphere DRS on the cluster (Figure 4-19). Put a check next to Enable vSphere DRS.

  1. Click on the vSphere DRS item in the menu tree on the left and you will be presented with a choice between three different automation levels (Figure 4-20).

    Enabling DRS on a cluster
    Figure 4-19. Enabling DRS on a cluster

    The choices are:

    Manual

    When you power on a virtual machine, DRS will display a list of suggested hosts for placement. Also, if it determines that there is a better host for a virtual machine, DRS will suggest a manual migration.

    Partially automated

    When you power on a virtual machine, DRS will automatically put it on the host it feels is the best. As with the manual level of automation, when a cluster node becomes unbalanced, DRS will give you a list of suggested hosts for placement of the virtual machine(s).

    Fully automated

    When you power on a virtual machine, DRS will automatically place it on the most suitable host. When a cluster becomes unbalanced, DRS will automatically start the VMotion process and automatically move the virtual machine(s) without involving the system administrator.

    The migration threshold, shown below the automation options, is based on a star system of 1 through 5, where 1 is the most conservative and 5 is the most aggressive:

    Level 1

    This is the most conservative level of automation and applies only to 5-star recommendations.

    Level 2

    This level of automation applies to recommendations with 4 or more stars and aims to improve the cluster’s load balance.

    Level 3

    This is the default level of automation and applies to recommendations with 3 or more stars.

    Level 4

    This level of automation applies to 2 or more stars.

    Level 5

    This is the most aggressive method of automation and applies to recommendations with any number of stars.

    DRS automation levels
    Figure 4-20. DRS automation levels

    Essentially, the higher the automation level you use, the more minor and frequent migrations you will see if DRS deems improvements can be made. A less aggressive selection will result in changes only when DRS deems that they will make a large improvement to the cluster’s load balance.

    Within the DRS environment you can also set a per-virtual-machine automation level, which will override the automation level set on the entire cluster. By setting the automation levels on this more granular basis, you can fine-tune your cluster for your specific needs (Figure 4-21).

    Virtual machine automation levels
    Figure 4-21. Virtual machine automation levels

    Another important feature of DRS is the ability to set rules and guidelines for virtual machines within the cluster. Along with the star system, these affect the choices made by DRS. You can specify two kinds of rules for your virtual machines:

    • Affinity rules allow you to specify certain virtual machines that should be run on the same host and in multi–virtual-machine environments when better performance can be achieved by such a configuration. For example, machines that communicate frequently may perform better when run on the same host.

    • Antiaffinity rules allow you to force virtual machines to run on separate hosts. This can be important when you have two servers that are in a failover or load-balancing environment and you want them to always run on separate ESXi nodes in the cluster.

    In Figure 4-22, we have set an antiaffinity rule telling DRS that we want the virtual machines TESTDEV and TEST1223 to run on separate physical ESXi nodes. DRS will always ensure that those virtual machines are separate from one another.

    Virtual machine DRS rules
    Figure 4-22. Virtual machine DRS rules

    Some tips about using DRS:

    • When removing a host from a cluster, always put that host in maintenance mode.

    • When you have your automation level set to Manual and DRS makes strong recommendations (typically, level 4 or 5), follow them. Otherwise, balance and fairness within the cluster will deteriorate.

    • Let DRS automatically handle most virtual machines, and set the override on virtual machines that you do not want DRS to automatically handle.

4.11. Understanding Cluster States and Warnings

Problem

You need to know the different states and warnings that are possible within a cluster.

Solution

Familiarize yourself with the various states in the vCenter and what they mean.

Discussion

VMware has three separate warnings that give the administrator basic information about the state of the cluster, virtual machine, or ESXi Host.

For example, if there is no network redundancy on the service console port, you will see a yellow triangle on your cluster. The detailed configuration issues will then be listed on the Summary tab of the cluster, telling you what configuration warnings exist.

Let’s take a look at the three different statuses that VMware provides for clusters:

Green (valid)

Clusters are considered valid as long as they have no configuration issues, resource overcommitments, or failed ESXi Hosts. A valid cluster will have a working configuration and all resources will be available for use by the virtual machines. In addition to all the resources being available, a valid cluster will also have one host available for standby in case an ESXi Host fails.

Yellow (overcommitted)

This warning shows a potential risk of resources. For example, removing a host from the cluster might cause the reserve of available resources to fall below the level needed by the virtual machines. Minor configuration issues, such as no network redundancy on the service port network group, may also trigger this status.

Red (invalid)

A cluster can become invalid when there are not enough resources available to handle all the virtual machines in the cluster. Clusters can also become invalid because of configuration issues such as HA becoming disabled on an ESXi Host or one of the ESXi Hosts in the cluster going down without being properly taken offline in the vCenter (and thereby taking away necessary resources).

A cluster can become invalid or overcommitted if one or more hosts fail. A cluster can also become invalid if the vCenter is unable to power on a virtual machine, if an HA cluster’s capacity is lower than the configured failover, or if the primary hosts in the cluster do not respond in a timely fashion to HA heartbeat checks.

Depending on the type of failure that causes the cluster to become invalid, you may attempt to resolve the issue by adding more resources, reconfiguring HA on the ESXi Host, or powering off unneeded virtual machines so that the resource requirements of the other virtual machines can be satisfied.

It’s very important to remedy an invalid cluster as soon as possible to avoid the cluster becoming imbalanced.

4.12. Using ESXi CPU/RAM Hot Add/Hotplug Support

Problem

You want to add more CPUs or memory to a virtual machine.

Solution

Using technology within VMware ESXi 5.x, you can add CPUs, memory, and devices to a virtual machine while it is running.

Discussion

vSphere 5.x Enterprise, Enterprise Plus, and Advanced customers have the ability to hotplug or hot add CPUs, memory, and devices to their virtual machines without powering them off. These new technologies illustrate the improvements VMware is making in its products in an effort to reduce downtime on mission-critical applications and servers.

Hot add support in ESXi 5.x is limited to a specific set of guest operating systems. Please refer to the HCL located at: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software

To enable hot add support on a virtual machine:

  1. Log in to your vCenter server, right-click on the virtual machine on which you wish to enable support, and select Edit Settings.

  2. Click Advanced and select Memory/CPU Hotplug.

  3. Select “Enable memory hot add” for the virtual machine, and then select “Hot add CPU support” for the virtual machine.

  4. Click OK when you’re finished to finalize the changes.

Warning

VMware Tools must be installed on the guest OS for this procedure to work correctly.

4.13. Surviving a vCenter Server Failure or Outage

Problem

Your vCenter server has gone down or refuses to start, and you want to continue operations until the problem can be fixed.

Solution

This recipe discusses what pieces of ESXi will continue to run when your vCenter server is down or offline.

Discussion

When your vCenter server needs an upgrade or maintenance, or when it suffers a crash, it’s important to know what pieces of the environment can and will function without the benefit of a vCenter server orchestrating and managing the various resources within the environment.

When the vCenter server is offline, your virtual machines will continue to function, along with HA. However, other key pieces will be unavailable or will work in a degraded mode. Tables 4-1 through 4-8 list the impacts that a vCenter server outage can have on an environment.

Table 4-1. vCenter Server outage effects on VMware HA

VMware Infrastructure Function

Available

Comment

Restart virtual machine

Yes

No impact

Admission control

No

vCenter Server is required as the source of the load information

Add new host to cluster

No

vCenter Server is required to resolve IP addresses of cluster members

Allow hosts to rejoin the cluster

Yes

Resolved host information is stored on the ESXi Host itself in /etc/FT_HOST

Table 4-2. vCenter Server outage effects on VMware DRS

VI Function

Available

Comment

Manual

No

Requires vCenter Server to manage

Automatic

No

Requires vCenter Server to manage

Affinity rules

No

Requires vCenter Server to manage

Table 4-3. vCenter Server outage effects on resource pools

VI Function

Available

Comment

Create

No

Requires vCenter Server to manage

Add virtual machine

No

Requires vCenter Server to manage

Remove VM

No

Requires vCenter Server to manage

Table 4-4. vCenter Server outage effects on vMotion

VI Function

Available

Comment

vMotion

No

Requires vCenter Server to manage

Table 4-5. vCenter Server outage effects on ESXi Host

VI Function

Available

Comment

Shutdown

Degraded

Through a direct connection to the ESXi Host Server only

Start-up

Yes

Expires within 14 days

Maintenance mode

Degraded

Requires vCenter Server to manage

Deregister

No

Requires vCenter Server to manage

Register

No

Requires vCenter Server to manage

Table 4-6. vCenter Server outage effects on virtual machines

VI Function

Available

Comment

Power on

Degraded

Expires in 14 days; direct connection to ESXi Host Server only

Power off

Degraded

Direct connection to ESXi Host Server only

Register

No

Requires vCenter Server to manage

Deregister

No

Requires vCenter Server to manage

Hot migration

No

Requires vCenter Server (vMotion)

Cold migration

Degraded

Within the same ESXi Host only

Table 4-7. vCenter Server outage effects on templates

VI Function

Available

Comment

Convert from virtual machine

Degraded

Direct connection to host only; requires vCenter Server to manage

Convert to virtual machine

Degraded

Direct connection to host only; requires vCenter Server to manage

Deploy virtual machine

No

Requires vCenter Server to manage

Table 4-8. vCenter Server outage effects on virtual machines (guests)

VI Function

Available

Comment

Guest OS (virtual machine)

Yes

No impact, will run without vCenter server

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required