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.
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:
Load the vCenter client and log in to your vCenter server.
Right-click on the cluster on which you wish to enable VM monitoring and click Edit Settings.
Under vSphere HA on the left menu, click the VM Monitoring option (Figure 4-1).
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.
Specify the minimum and maximum amounts of RAM that should be available to your virtual machines.
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:
Load the vCenter client and log in to your vCenter server.
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).
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.
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.
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:
Load the vCenter client and log in to your vCenter server.
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.
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).
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.
You want to apportion CPU, memory, or disk resources among machines unequally, while remaining flexible in case resources change.
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:
Load the vCenter client and log in to your vCenter server.
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.
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).
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.
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:
Load the vCenter client and log in to your vCenter server.
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.
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).
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.
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:
Right-click on the cluster in which you wish to create the resource pool and choose New Resource Pool (Figure 4-6).
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.
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
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).
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.
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.
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 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:
Load the vCenter client and log in to your vCenter server.
Right-click on the resource pool you wish to edit and select Edit Settings (Figure 4-11).
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.
Once youâre finished, click OK to have the changes applied.
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.
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:
Load the vCenter client and log in to your vCenter server.
Right-click on the datacenter name and select New Cluster (Figure 4-14).
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.
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.
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.
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).
Adding additional ESXI servers to an already established cluster is easy in vCenter:
Load the vCenter client and log in to your vCenter server.
Right-click on the datacenter name and select Add Host. This launches the Add Host Wizard in a new window (Figure 4-15).
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.
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.
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.
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.
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.
Once you have selected which resource pool option you want to use, click the Next button to continue.
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.
You wish to enable hyperthreading on a virtual machine, after it is enabled on your physical server.
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.
Load the vCenter client and log in to your vCenter server.
Select the virtual machine from the inventory list, then right-click on the virtual machine and select Edit Settings.
Click the Resources Tab and select Advanced CPU.
Here you will see three options that control hyperthreading. None of the options affect the way the virtual machine is allocated CPU time.
- 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.
Once you have selected the settings that best reflect your environment, click OK.
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:
Load the vCenter client and log in to your vCenter server.
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.
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.
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).
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.
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).
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.
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.
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.
Using technology within VMware ESXi 5.x, you can add CPUs, memory, and devices to a virtual machine while it is running.
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:
Log in to your vCenter server, right-click on the virtual machine on which you wish to enable support, and select Edit Settings.
Click Advanced and select Memory/CPU Hotplug.
Select âEnable memory hot addâ for the virtual machine, and then select âHot add CPU supportâ for the virtual machine.
Click OK when youâre finished to finalize the changes.
Your vCenter server has gone down or refuses to start, and you want to continue operations until the problem can be fixed.
This recipe discusses what pieces of ESXi will continue to run when your vCenter server is down or offline.
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
Table 4-6. vCenter Server outage effects on virtual machines
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 |
Get VMware Cookbook, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
