vSphere ESXi 5.0/vCenter Server 5.0资源管理指南

vsphere

需积分: 1 124 浏览量更新于2024-06-26 收藏 1.31MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

Ensure that the Marketing virtual machine has a certain amount of guaranteed CPU resources. You can

do so using a reservation setting.

Procedure

1 Start the vSphere Client and connect to a vCenter Server system.

2 Right-click VM-QA, the virtual machine for which you want to change shares, and select Edit Settings.

3 Select the Resources tab, and in the CPU panel, select High from the Shares drop-down menu.

4 In the Memory panel, select High from the Shares drop-down menu.

5 Click OK.

6 Right-click the marketing virtual machine (VM-Marketing) and select Edit Settings.

7 In the CPU panel, change the Reservation value to the desired number.

8 Click OK.

If you select the cluster’s Resource Allocation tab and click CPU, you should see that shares for VM-QA are

twice that of the other virtual machine. Also, because the virtual machines have not been powered on, the

Reservation Used fields have not changed.

Admission Control

When you power on a virtual machine, the system checks the amount of CPU and memory resources that have

not yet been reserved. Based on the available unreserved resources, the system determines whether it can

guarantee the reservation for which the virtual machine is configured (if any). This process is called admission

control.

If enough unreserved CPU and memory are available, or if there is no reservation, the virtual machine is

powered on. Otherwise, an Insufficient Resources warning appears.

NOTE In addition to the user-specified memory reservation, for each virtual machine there is also an amount

of overhead memory. This extra memory commitment is included in the admission control calculation.

When the vSphere DPM feature is enabled, hosts might be placed in standby mode (that is, powered off) to

reduce power consumption. The unreserved resources provided by these hosts are considered available for

admission control. If a virtual machine cannot be powered on without these resources, a recommendation to

power on sufficient standby hosts is made.

vSphere Resource Management

16 VMware, Inc.

CPU Virtualization Basics 3

CPU virtualization emphasizes performance and runs directly on the processor whenever possible. The

underlying physical resources are used whenever possible and the virtualization layer runs instructions only

as needed to make virtual machines operate as if they were running directly on a physical machine.

CPU virtualization is not the same thing as emulation. ESXi does not use emulation to run virtual CPUs. With

emulation, all operations are run in software by an emulator. A software emulator allows programs to run on

a computer system other than the one for which they were originally written. The emulator does this by

emulating, or reproducing, the original computer’s behavior by accepting the same data or inputs and

achieving the same results. Emulation provides portability and runs software designed for one platform across

several platforms.

When CPU resources are overcommitted, the ESXi host time-slices the physical processors across all virtual

machines so each virtual machine runs as if it has its specified number of virtual processors. When an ESXi

host runs multiple virtual machines, it allocates to each virtual machine a share of the physical resources. With

the default resource allocation settings, all virtual machines associated with the same host receive an equal

share of CPU per virtual CPU. This means that a single-processor virtual machines is assigned only half of the

resources of a dual-processor virtual machine.

This chapter includes the following topics:

“Software-Based CPU Virtualization,” on page 17

“Hardware-Assisted CPU Virtualization,” on page 18

“Virtualization and Processor-Specific Behavior,” on page 18

“Performance Implications of CPU Virtualization,” on page 18

Software-Based CPU Virtualization

With software-based CPU virtualization, the guest application code runs directly on the processor, while the

guest privileged code is translated and the translated code executes on the processor.

The translated code is slightly larger and usually executes more slowly than the native version. As a result,

guest programs, which have a small privileged code component, run with speeds very close to native. Programs

with a significant privileged code component, such as system calls, traps, or page table updates can run slower

in the virtualized environment.

VMware, Inc.

Hardware-Assisted CPU Virtualization

Certain processors provide hardware assistance for CPU virtualization.

When using this assistance, the guest can use a separate mode of execution called guest mode. The guest code,

whether application code or privileged code, runs in the guest mode. On certain events, the processor exits

out of guest mode and enters root mode. The hypervisor executes in the root mode, determines the reason for

the exit, takes any required actions, and restarts the guest in guest mode.

When you use hardware assistance for virtualization, there is no need to translate the code. As a result, system

calls or trap-intensive workloads run very close to native speed. Some workloads, such as those involving

updates to page tables, lead to a large number of exits from guest mode to root mode. Depending on the number

of such exits and total time spent in exits, hardware-assisted CPU virtualization can speed up execution

significantly.

Virtualization and Processor-Specific Behavior

Although VMware software virtualizes the CPU, the virtual machine detects the specific model of the processor

on which it is running.

Processor models might differ in the CPU features they offer, and applications running in the virtual machine

can make use of these features. Therefore, it is not possible to use vMotion

to migrate virtual machines

between systems running on processors with different feature sets. You can avoid this restriction, in some

cases, by using Enhanced vMotion Compatibility (EVC) with processors that support this feature. See the

vCenter Server and Host Management documentation for more information.

Performance Implications of CPU Virtualization

CPU virtualization adds varying amounts of overhead depending on the workload and the type of

virtualization used.

An application is CPU-bound if it spends most of its time executing instructions rather than waiting for external

events such as user interaction, device input, or data retrieval. For such applications, the CPU virtualization

overhead includes the additional instructions that must be executed. This overhead takes CPU processing time

that the application itself can use. CPU virtualization overhead usually translates into a reduction in overall

performance.

For applications that are not CPU-bound, CPU virtualization likely translates into an increase in CPU use. If

spare CPU capacity is available to absorb the overhead, it can still deliver comparable performance in terms

of overall throughput.

ESXi supports up to 32 virtual processors (CPUs) for each virtual machine.

NOTE Deploy single-threaded applications on uniprocessor virtual machines, instead of on SMP virtual

machines, for the best performance and resource use.

Single-threaded applications can take advantage only of a single CPU. Deploying such applications in dual-

processor virtual machines does not speed up the application. Instead, it causes the second virtual CPU to use

physical resources that other virtual machines could otherwise use.

vSphere Resource Management

18 VMware, Inc.

Specifying CPU Configuration

You can specify CPU configuration to improve resource management. However, if you do not customize CPU

configuration, the ESXi host uses defaults that work well in most situations.

You can specify CPU configuration in the following ways:

Use the attributes and special features available through the vSphere Client. The vSphere Client graphical

user interface (GUI) allows you to connect to the ESXi host or a vCenter Server system.

Use advanced settings under certain circumstances.

Use the vSphere SDK for scripted CPU allocation.

Use hyperthreading.

Multicore Processors

Multicore processors provide many advantages for a host performing multitasking of virtual machines.

Intel and AMD have each developed processors which combine two or more processor cores into a single

integrated circuit (often called a package or socket). VMware uses the term socket to describe a single package

which can have one or more processor cores with one or more logical processors in each core.

A dual-core processor, for example, can provide almost double the performance of a single-core processor, by

allowing two virtual CPUs to execute at the same time. Cores within the same processor are typically

configured with a shared last-level cache used by all cores, potentially reducing the need to access slower main

memory. A shared memory bus that connects a physical processor to main memory can limit performance of

its logical processors if the virtual machines running on them are running memory-intensive workloads which

compete for the same memory bus resources.

Each logical processor of each processor core can be used independently by the ESXi CPU scheduler to execute

virtual machines, providing capabilities similar to SMP systems. For example, a two-way virtual machine can

have its virtual processors running on logical processors that belong to the same core, or on logical processors

on different physical cores.

The ESXi CPU scheduler can detect the processor topology and the relationships between processor cores and

the logical processors on them. It uses this information to schedule virtual machines and optimize performance.

The ESXi CPU scheduler can interpret processor topology, including the relationship between sockets, cores,

and logical processors. The scheduler uses topology information to optimize the placement of virtual CPUs

onto different sockets to maximize overall cache utilization, and to improve cache affinity by minimizing

virtual CPU migrations.

In undercommitted systems, the ESXi CPU scheduler spreads load across all sockets by default. This improves

performance by maximizing the aggregate amount of cache available to the running virtual CPUs. As a result,

the virtual CPUs of a single SMP virtual machine are spread across multiple sockets (unless each socket is also

a NUMA node, in which case the NUMA scheduler restricts all the virtual CPUs of the virtual machine to

reside on the same socket.)

In some cases, such as when an SMP virtual machine exhibits significant data sharing between its virtual CPUs,

this default behavior might be sub-optimal. For such workloads, it can be beneficial to schedule all of the virtual

CPUs on the same socket, with a shared last-level cache, even when the ESXi host is undercommitted. In such

scenarios, you can override the default behavior of spreading virtual CPUs across packages by including the

following configuration option in the virtual machine's .vmx configuration file:

sched.cpu.vsmpConsolidate="TRUE".

vSphere Resource Management

20 VMware, Inc.

剩余111页未读，继续阅读

rocazj

粉丝: 9
资源: 725

vSphere ESXi 5.0/vCenter Server 5.0资源管理指南

vsphere-esxi-vcenter-server-51-resource-management-guide

vsphere-esxi-vcenter-server-501-storage-guide

vsphere-esxi-vcenter-server-501-host-management-guide

vsphere-esxi-vcenter-server-70-setup-wsfc.pdf

vmw-esxi-7.0.3-metadata

nvidia-grid-vsphere-6.7-510.47.03-511.65.zip

vmware-esxi-7.0u1-16850804-depot.zip

ESXI使用记录---esxi主机磁盘空间回收

nvidia-grid-vsphere-7.0-510.73.06-510.73.08-512.78

vmware 服务器虚拟化部署流程

TrustedPlatformModuleversion2.0是ESXI哪个版本开始有的功能,告诉我你的依据是什么，以及原文链接

在Zabbix服务器上安装VMware vSphere Perl SDK

没有你说的prometheus-vsphere-exporter这个，github上有这个prometheus-vmware-exporter

esxi vsphere 安装部署

vmware-vcsa-all-7

vcenter server 6.7安装

vcenter 体系结构

vmware vsphere esxi

成功添加一个新的ESXi6.x主机到vCenter服务器后,几分钟后管理员看到其不响应vSphereWeb客户端界面。如果问题是由网络防火墙阻塞交通引起的,哪个端口必须打开来改正这个特殊问题

vsphere esxi密码规则

最新资源