Vsphere Esxi Vcenter Server 703 Resource Management Guide

Gerenciamento de
recursos do vSphere
Atualizar 3
VMware vSphere 7.0
VMware ESXi 7.0
vCenter Server 7.0
Este documento foi traduzido automaticamente do inglês. Se você observar

algum erro de tradução, deixe seu feedback na parte inferior da página
específica da publicação no VMware Docs.
Gerenciamento de recursos do vSphere
Você pode encontrar a documentação técnica mais atualizada no site da VMware, em:
https://docs.vmware.com/br/
VMware, Inc. VMware Brasil

3401 Hillview Ave. Rua Surubim, 504 4º andar CEP 04571-050
Palo Alto, CA 94304 Cidade Monções
www.vmware.com São Paulo
SÃO PAULO: 04571-050
Brasil
Tel: +55 11 55097200
Fax: + 55. 11. 5509-7224
www.vmware.com/br
©
Copyright 2006-2021 VMware, Inc. Todos os direitos reservados. Informações sobre direitos autorais e
marca registrada.
VMware, Inc. Traduzido automaticamente 2

Conteúdo
Sobre o vSphere Resource Management 10
1 Introdução ao gerenciamento de recursos 11

Tipos de recursos 11
Provedores de recursos 12
Consumidores de recursos 12
Objetivos do gerenciamento de recursos 13
2 Definindo as configurações de alocação de recursos 14

Compartilhamentos de alocação de recursos 14
Reserva de alocação de recursos 16
Limite de alocação de recursos 16
Sugestões de configurações de alocação de recursos 16
Editar configurações 17
Alterando as configurações de alocação de recursos - exemplo 18
Controle de admissão 19
3 Noções básicas de virtualização de CPU 20

Virtualização de CPU baseada em software 20
Virtualização de CPU Assistida por Hardware 21
Virtualização e comportamento específico do processador 21
Implicações de desempenho da virtualização de CPU 21
4 Administrando recursos de CPU 23

Exibir informações do processador 23
Especificando a configuração da CPU 24
Processadores multicore 24
Hyperthreading 25
Hyperthreading e ESXi hosts 25
Habilitar Hyperthreading 26
Usando a afinidade de CPU 27
Atribuir uma máquina virtual a um processador específico 27
Problemas potenciais com afinidade de CPU 28
Políticas de gerenciamento de energia do host 29
Selecione uma política de gerenciamento de energia da CPU 29
Configurar parâmetros de política personalizados para o gerenciamento de energia do host
30

5 Conceitos básicos de virtualização de memória 32

Memória da máquina virtual 32
Comprometimento excessivo da memória 33
Compartilhamento de memória 34
Virtualização de memória 35
Virtualização de memória assistida por hardware 36
Suporte para tamanhos de página grandes 37
6 Administrando recursos de memória 38

Entendendo a sobrecarga de memória 38
Memória de sobrecarga em máquinas virtuais 39
Como os hosts ESXi alocam memória 40
Imposto de memória para máquinas virtuais ociosas 40
Arquivos de permuta VMX 41
Recuperação de memória 41
Driver de Balão de Memória 42
Usando arquivos de permuta 42
Localização do arquivo de permuta 43
Ativar permuta host-local para um cluster do DRS 43
Habilitar permuta host-local para um host autônomo 44
Excesso de compromissos de espaço de permuta e memória 44
Configurar as propriedades do arquivo de permuta da máquina virtual para o host 46
Configurar uma localização de arquivo de permuta da máquina virtual para um cluster 47
Apagar arquivos de permuta 48
Compartilhando memória entre máquinas virtuais 48
Compressão de memória 49
Ativar ou desativar o cache de compactação de memória 49
Definir o tamanho máximo do cache de compactação de memória 50
Medindo e diferenciando tipos de uso de memória 50
Confiabilidade da Memória 52
Corrigindo uma notificação de isolamento de erro 52
Sobre a permuta do sistema 53
Configurar a permuta do sistema 53
7 Memória persistente 55
Configurar vSphere HA para VMs de PMem 57
vSphere HA Controle de admissão PMem Reserva 58
Monitoramento e correção de memória do vSphere 59
8 Configurando gráficos virtuais 62

Exibir estatísticas de GPU 62

Adicionar uma vGPU do NVIDIA GRID a uma máquina virtual 63

Configurando gráficos do host 63
Configuração de dispositivos gráficos 64
9 Gerenciando recursos de E / S do armazenamento 65

Sobre as políticas de armazenamento de máquina virtual 66
Sobre os filtros de E / S 66
Requisitos do Storage I/O Control 67
Storage I/O Control Compartilhamentos de recursos e limites 67
Visualizar Storage I/O Control compartilhamentos e limites 68
Monitorar compartilhamentos Storage I/O Control 68
Definir Storage I/O Control compartilhamentos e limites de recursos 69
Habilitar o Storage I/O Control 70
Definir valor do limite Storage I/O Control 70
Integração do Storage DRS com perfis de armazenamento 72
10 Gerenciando pools de recursos 74

Por que usar pools de recursos? 75
Criar um pool de recursos 76
Editar um pool de recursos 78
Adicionar uma máquina virtual a um pool de recursos 79
Remover uma máquina virtual de um pool de recursos 80
Remover um pool de recursos 81
Controle de admissão do pool de recursos 81
Exemplo de reservas expansíveis 1 82
Exemplo de reservas expansíveis 2 82
11 Criando um cluster DRS 84

vSphere Cluster Services (vCLS) 85
Posicionamento do datastore do vCLS 87
Monitorando o vSphere Cluster Services 87
Mantendo a integridade do vSphere Cluster Services 88
Colocando um cluster no modo de retirada 90
Recuperando a senha para VMs do vCLS 91
Políticas antiafinidade de VM do vCLS 91
Controle de admissão e colocação inicial 93
Ligar uma única máquina virtual 93
Ligar o grupo 93
Migração de máquina virtual 94
Limite de migração do DRS 96
Recomendações de migração 96

Requisitos de cluster do DRS 97

Requisitos de armazenamento compartilhado 97
Requisitos de volume de VMFS compartilhado 97
Requisitos de compatibilidade do processador 98
Requisitos do vMotion para clusters do DRS 99
Configurando o DRS com o Virtual Flash 99
Criar um cluster 99
Editar configurações do cluster 101
Definir um nível de automação personalizado para uma máquina virtual 103
Desativar DRS 104
Restaurar uma árvore do pool de recursos 105
Reconhecimento de DRS do cluster estendido do vSAN 106
12 Funcionalidade do modo de manutenção do DRS com licença empresarial ROBO

108
Limitações do modo de manutenção do DRS com licença empresarial ROBO 108
Usando o modo de manutenção DRS com a licença empresarial ROBO 109
Solucionando problemas do modo de manutenção do DRS com a licença empresarial ROBO
110
13 Usando clusters do DRS para gerenciar recursos 111

Adicionando hosts a um cluster 111
Adicionar um host gerenciado a um cluster 112
Adicionar um host não gerenciado a um cluster 112
Adicionando máquinas virtuais a um cluster 113
Mover uma máquina virtual para um cluster 114
Removendo máquinas virtuais de um cluster 114
Mover uma máquina virtual de um cluster 114
Removendo um host de um cluster 115
Colocar um host no modo de manutenção 115
Remover um host de um cluster 116
Usando o modo de espera 117
Validade do cluster do DRS 117
Clusters de DRS válidos 118
Clusters de DRS supercomprometidos 120
Clusters de DRS inválidos 121
Gerenciamento de recursos de energia 122
Definir as configurações de IPMI ou iLO para o vSphere DPM 123
Testar a ativação na LAN para o vSphere DPM 124
Habilitando o vSphere DPM para um cluster do DRS 125
Monitorando o vSphere DPM 127
Usando regras de afinidade do DRS 128

Criar um grupo de DRS de host 129

Criar um grupo DRS de máquina virtual 130
Regras de Afinidade entre VMs e VMs 130
Regras de Afinidade de Host da VM 131
14 Criando um cluster de repositório de dados 135

Posicionamento inicial e balanceamento em andamento 136
Recomendações de migração de armazenamento 136
Criar um cluster de repositório de dados 137
Ativar e desativar DRS de armazenamento 137
Definir o nível de automação para clusters de datastore 138
Definindo o nível de agressividade para DRS de armazenamento 139
Definir regras de tempo de execução do DRS de armazenamento 140
Requisitos de cluster de repositório de dados 141
Adicionando e removendo repositórios de dados de um cluster de repositório de dados 142
15 Usando clusters de datastore para gerenciar recursos de armazenamento 143

Usando o modo de manutenção do DRS de armazenamento 143
Colocar um repositório de dados no modo de manutenção 144
Ignorar regras de afinidade de DRS de armazenamento para o modo de manutenção 144
Aplicando recomendações de DRS de armazenamento 145
Atualizar recomendações de DRS de armazenamento 146
Alterar o nível de automação do DRS de armazenamento para uma máquina virtual 146
Configurar o agendamento fora do horário de trabalho para DRS de armazenamento 147
Regras de antiafinidade do DRS de armazenamento 148
Criar regras de antiafinidade de VM 150
Criar regras de antiafinidade do VMDK 150
Substituir regras de afinidade do VMDK 151
Limpar estatísticas de DRS de armazenamento 152
Storage vMotion Compatibilidade com clusters de datastore 153
16 Usando sistemas NUMA com o ESXi 154

O que é o NUMA? 154
Desafios para sistemas operacionais 155
Como funciona o agendamento do ESXi NUMA 155
VMware Algoritmos de Otimização do NUMA e Configurações 156
Nós iniciais e posicionamento inicial 157
Balanceamento de carga dinâmico e migração de página 157
Compartilhamento transparente de páginas otimizado para NUMA 158
Gerenciamento de recursos em arquiteturas NUMA 159
Usando o Virtual NUMA 159

Controles virtuais do NUMA 160

Especificando controles NUMA 160
Associar máquinas virtuais a processadores específicos 161
Associar alocações de memória a nós NUMA específicos usando a afinidade de memória
162
Associar máquinas virtuais a nós NUMA especificados 163
17 Atributos avançados 165

Definir atributos de host avançados 165
Atributos avançados de memória 166
Atributos avançados de NUMA 167
Definir atributos de máquina virtual avançada 168
Atributos avançados de máquina virtual 169
Atributos avançados de NUMA virtual 170
Sensibilidade à latência 171
Ajustar a sensibilidade da latência 171
Sobre a memória confiável 172
Exibir memória confiável 172
Fazendo backup da vRAM guest com páginas de 1 GB 172
18 Definições de falha 174

A máquina virtual está fixada 175
A máquina virtual não é compatível com nenhum host 175
Regra de VM / VM DRS violada ao mover para outro host 175
Host incompatível com máquina virtual 175
O host tem uma máquina virtual que viola as regras de DRS de VM / VM 176
O host tem capacidade insuficiente para a máquina virtual 176
Host em estado incorreto 176
O host tem um número insuficiente de CPUs físicas para a máquina virtual 176
O host tem capacidade insuficiente para cada CPU de máquina virtual 176
A máquina virtual está no vMotion 176
Nenhum host ativo no cluster 176
Recursos insuficientes 177
Recursos insuficientes para satisfazer o nível de failover configurado para HA 177
Nenhum host de afinidade rígida compatível 177
Nenhum host de afinidade flexível compatível 177
Correção de violação da regra flexível não é permitida 177
Impacto da correção da violação da regra flexível 177
19 Informações de solução de problemas do DRS 178

Problemas de cluster 178
Carregar desequilíbrio no cluster 178

O cluster é amarelo 179

O cluster está vermelho devido a um pool de recursos inconsistente 179
O cluster está vermelho porque a capacidade de failover está violada 180
Nenhum host é desligado quando a carga total do cluster é baixa 180
Os hosts são desligados quando a carga total do cluster é alta 181
O DRS raramente ou nunca executa migrações do vMotion 181
Problemas do host 182
O DRS recomenda que o host seja ligado para aumentar a capacidade quando a carga total
do cluster for baixa 182
A carga total do cluster é alta 183
A carga total do cluster é baixa 183
O DRS não evacua um host solicitado para entrar no modo de manutenção ou de espera
184
O DRS não move nenhuma máquina virtual para um host 184
O DRS não move nenhuma máquina virtual de um host 185
Problemas da máquina virtual 185
Recursos insuficientes de CPU ou memória 186
Regra de VM / DRS de VM ou regra de DRS de VM / host violada 187
Falha na operação ao ligar a máquina virtual 188
O DRS não move a máquina virtual 188

Sobre o vSphere Resource Management
O Gerenciamento de Recursos do vSphere descreve o gerenciamento de recursos para os

® ®
ambientes VMware ESXi e vCenter Server.
Esta documentação se concentra nos tópicos a seguir.
n Conceitos de alocação e gerenciamento de recursos
n Atributos da máquina virtual e controle de admissão
n Pools de recursos e como gerenciá-los

®
n Clusters, vSphere Distributed Resource Scheduler (DRS), vSphere Distributed Power
Management (DPM) e como trabalhar com eles
n Clusters de armazenamento de dados, DRS de armazenamento, Storage I/O Control e como

trabalhar com eles
n Opções avançadas de gerenciamento de recursos
n Considerações de desempenho
Em VMware, valorizamos a inclusão. Para promover esse princípio dentro de nossa comunidade
de clientes, parceiros e interna, criamos conteúdo usando uma linguagem inclusiva.
Público-alvo
Essas informações são para administradores de sistema que desejam compreender como o
sistema gerencia recursos e como eles podem personalizar o comportamento padrão. Também
é essencial para quem deseja compreender e usar pools de recursos, clusters, DRS, clusters de
armazenamento de dados, DRS de armazenamento, Storage I/O Control ou vSphere DPM.
Esta documentação pressupõe que você tenha um conhecimento prático do VMware ESXi e do
vCenter Server.
Observação Neste documento, "Memória" pode se referir à memória RAM física ou memória
persistente.

Introdução ao gerenciamento de
recursos 1
Para entender o gerenciamento de recursos, você deve estar ciente de seus componentes, seus
objetivos e a melhor forma de implementá-lo em uma configuração de cluster.
As configurações de alocação de recursos para uma máquina virtual (compartilhamentos,

reserva e limite) são discutidas, incluindo como defini-las e exibi-las. Além disso, o controle
de admissão é explicado o processo pelo qual as configurações de alocação de recursos são
validadas em relação aos recursos existentes.
Gerenciamento de recursos é a alocação de recursos dos provedores de recursos para os

consumidores de recursos.
A necessidade de gerenciamento de recursos surge do comprometimento excessivo dos

recursos - ou seja, mais demanda do que capacidade e do fato de que a demanda e
a capacidade variam ao longo do tempo. O gerenciamento de recursos permite realocar
dinamicamente recursos, para que você possa usar a capacidade disponível de forma mais
eficiente.
Observação Neste capítulo, "Memória" refere-se à RAM física.
Este capítulo inclui os seguintes tópicos:
n Tipos de recursos
n Provedores de recursos
n Consumidores de recursos
n Objetivos do gerenciamento de recursos
Tipos de recursos
Os recursos incluem recursos de CPU, memória, energia, armazenamento e rede.
Observação O ESXi gerencia a largura de banda da rede e os recursos de disco em uma

base por host, usando a modelagem de tráfego de rede e um mecanismo de compartilhamento
proporcional, respectivamente.

Provedores de recursos
Hosts e clusters, incluindo clusters de datastore, são provedores de recursos físicos.
Para hosts, os recursos disponíveis são a especificação de hardware do host, menos os recursos
usados pelo software de virtualização.
Um cluster é um grupo de hosts. Você pode criar um cluster usando vSphere Client e adicionar
vários hosts ao cluster. vCenter Server gerencia os recursos desses hosts em conjunto: o
cluster possui toda a CPU e memória de todos os hosts. Você pode habilitar o cluster para
balanceamento de carga ou failover conjunto. Consulte Capítulo 11 Criando um cluster DRS para
obter informações.
Um cluster de repositório de dados é um grupo de repositórios de dados. Como os clusters do

DRS, você pode criar um cluster de repositório de dados usando o vSphere Client e adicionar
vários repositórios de dados ao cluster. vCenter Server gerencia os recursos do repositório
de dados em conjunto. Você pode ativar o Storage DRS para balancear a carga de E / S e a
utilização de espaço. Consulte Capítulo 14 Criando um cluster de repositório de dados.
Consumidores de recursos
As máquinas virtuais são consumidores de recursos.
As configurações de recursos padrão atribuídas durante a criação funcionam bem para a maioria
das máquinas. Posteriormente, você poderá editar as configurações da máquina virtual para
alocar uma porcentagem baseada em compartilhamento do total de CPU, memória e E / S de
armazenamento do provedor de recursos ou uma reserva garantida de CPU e memória. Quando
você liga essa máquina virtual, o servidor verifica se há recursos não reservados suficientes
disponíveis e permite a ativação somente se houver recursos suficientes. Esse processo é
chamado de controle de admissão.
Um pool de recursos é uma abstração lógica para o gerenciamento flexível de recursos. Os pools
de recursos podem ser agrupados em hierarquias e usados para particionar hierarquicamente os
recursos de CPU e memória disponíveis. Portanto, os pools de recursos podem ser considerados
provedores de recursos e consumidores. Eles fornecem recursos para pools de recursos filho e
máquinas virtuais, mas também são consumidores de recursos porque consomem os recursos de
seus pais. Consulte Capítulo 10 Gerenciando pools de recursos.
ESXi hosts alocam a cada máquina virtual uma parte dos recursos de hardware subjacentes com
base em vários fatores:
n Limites de recursos definidos pelo usuário.
n Total de recursos disponíveis para o host ESXi (ou o cluster).
n Número de máquinas virtuais ligadas e uso de recursos por essas máquinas virtuais.
n Sobrecarga necessária para gerenciar a virtualização.

Objetivos do gerenciamento de recursos

Ao gerenciar seus recursos, você deve estar ciente de quais são suas metas.
Além de resolver o comprometimento excessivo de recursos, o gerenciamento de recursos pode

ajudá-lo a realizar o seguinte:
n Isolamento do desempenho: evite que as máquinas virtuais monopolizem recursos e

garantam taxas de serviço previsíveis.
n Uso eficiente: Explore recursos subcomprometidos e supercommit com degradação normal.
n Administração fácil: controle a importância relativa das máquinas virtuais, forneça o

particionamento dinâmico flexível e atenda a acordos absolutos de nível de serviço.

Definindo as configurações de
alocação de recursos 2
Quando a capacidade de recursos disponíveis não atende às demandas dos consumidores de
recursos (e da sobrecarga de virtualização), os administradores podem precisar personalizar a
quantidade de recursos que são alocados para máquinas virtuais ou para os pools de recursos
nos quais eles residem.
Use as configurações de alocação de recursos (compartilhamentos, reserva e limite) para

determinar a quantidade de recursos de CPU, memória e armazenamento fornecidos para uma
máquina virtual. Em particular, os administradores têm várias opções para alocar recursos.
n Reserve os recursos físicos do host ou cluster.
n Defina um limite superior nos recursos que podem ser alocados para uma máquina virtual.
n Garanta que uma determinada máquina virtual sempre seja alocada com uma porcentagem
maior de recursos físicos do que outras máquinas virtuais.
n Compartilhamentos de alocação de recursos
n Reserva de alocação de recursos
n Limite de alocação de recursos
n Sugestões de configurações de alocação de recursos
n Editar configurações
n Alterando as configurações de alocação de recursos - exemplo
n Controle de admissão
Compartilhamentos de alocação de recursos

Os compartilhamentos especificam a importância relativa de uma máquina virtual (ou pool de
recursos). Se uma máquina virtual tiver o dobro de compartilhamentos de um recurso como
outra máquina virtual, ela terá o direito de consumir o dobro desses recursos quando essas duas
máquinas virtuais estiverem competindo por recursos.

Os compartilhamentos geralmente são especificados como Alto(High), Normal(Normal) ou

Baixo(Low), e esses valores especificam valores de compartilhamento com uma proporção de
4:2:1, respectivamente. Você também pode selecionar Personalizado(Custom) para atribuir um
número específico de compartilhamentos (que expressa um peso proporcional) a cada máquina
virtual.
Especificar compartilhamentos só faz sentido em relação a máquinas virtuais irmãos ou pools de

recursos, ou seja, máquinas virtuais ou pools de recursos com o mesmo pai na hierarquia do pool
de recursos. Os irmãos compartilham recursos de acordo com seus valores de compartilhamento
relativos, limitados pela reserva e pelo limite. Ao atribuir compartilhamentos a uma máquina
virtual, você sempre especifica a prioridade para essa máquina virtual em relação a outras
máquinas virtuais ligadas.
A tabela a seguir mostra os valores padrão de compartilhamento de CPU e memória para uma
máquina virtual. Para pools de recursos, os valores de compartilhamento de memória e CPU
padrão são os mesmos, mas devem ser multiplicados como se o pool de recursos fosse uma
máquina virtual com quatro CPUs virtuais e 16 GB de memória.
Tabela 2-1. Valores de compartilhamento
Configuração Valores de compartilhamento de CPU Valores de compartilhamento de memória
Alto 2000 compartilhamentos por CPU virtual 20 compartilhamentos por megabyte de memória
de máquina virtual configurada.
Normal 1000 compartilhamentos por CPU virtual 10 compartilhamentos por megabyte de memória
de máquina virtual configurada.
Baixo 500 compartilhamentos por CPU virtual 5 compartilhamentos por megabyte de memória de
máquina virtual configurada.
Por exemplo, uma máquina virtual SMP com duas CPUs virtuais e 1 GB de RAM com
compartilhamentos de CPU e memória definidos como Normal (Normal) tem 2x1000 = 2000
compartilhamentos de CPU e 10x1024 = 10240 compartilhamentos de memória.
As máquinas virtuais com mais de uma CPU virtual são chamadas de máquinas virtuais SMP
(multiprocessamento simétrico).
A prioridade relativa representada por cada compartilhamento é alterada quando uma nova
máquina virtual é ligada. Isso afeta todas as máquinas virtuais no mesmo pool de recursos. Todas
as máquinas virtuais têm o mesmo número de CPUs virtuais. Considere os exemplos a seguir.
n Duas máquinas virtuais vinculadas à CPU são executadas em um host com 8 GHz de
capacidade de CPU agregada. Seus compartilhamentos de CPU são definidos como Normal
(Normal) e têm 4 GHz cada.
n Uma terceira máquina virtual vinculada à CPU está ligada. Seu valor de compartilhamentos
de CPU está definido como Alto (High), o que significa que ele deve ter o dobro de
compartilhamentos que as máquinas definidas como Normal (Normal). A nova máquina
virtual recebe 4 GHz e as outras duas máquinas recebem apenas 2 GHz cada. O mesmo
resultado ocorrerá se o usuário especificar um valor de compartilhamento personalizado de
2000 para a terceira máquina virtual.

Reserva de alocação de recursos

Uma reserva especifica a alocação mínima garantida para uma máquina virtual.
vCenter Server ou ESXi permite que você ligue uma máquina virtual somente se houver recursos
não reservados suficientes para satisfazer a reserva da máquina virtual. O servidor garante essa
quantidade mesmo quando o servidor físico está muito carregado. A reserva é expressa em
unidades concretas (megahertz ou megabytes).
Por exemplo, suponha que você tenha 2 GHz disponíveis e especifique uma reserva de 1 GHz
para a VM1 e 1 GHz para a VM2. Agora, cada máquina virtual tem a garantia de obter 1GHz se ela
precisar. No entanto, se a VM1 estiver usando apenas 500 MHz, a VM2 poderá usar 1,5 GHz.
Padrões de reserva para 0. Você poderá especificar uma reserva se precisar garantir que
as quantidades mínimas necessárias de CPU ou memória sempre estejam disponíveis para a
máquina virtual.
Limite de alocação de recursos

Limite especifica um limite superior para CPU, memória ou recursos de E / S de armazenamento
que podem ser alocados para uma máquina virtual.
Um servidor pode alocar mais do que a reserva para uma máquina virtual, mas nunca aloca mais
do que o limite, mesmo se houver recursos não utilizados no sistema. O limite é expresso em
unidades concretas (megahertz, megabytes ou operações de E / S por segundo).
A CPU, a memória e os recursos de E / S de armazenamento limitam o padrão a ilimitado.

Quando o limite de memória é ilimitado, a quantidade de memória configurada para a máquina
virtual quando ela foi criada se torna seu limite efetivo.
Na maioria dos casos, não é necessário especificar um limite. Há vantagens e desvantagens:
n Benefícios - Atribuir um limite é útil se você começar com um pequeno número de máquinas
virtuais e quiser gerenciar as expectativas do usuário. O desempenho se deteriora à medida
que você adiciona mais máquinas virtuais. Você pode simular a disponibilidade de menos
recursos especificando um limite.
n Desvantagens - Você pode desperdiçar recursos ociosos se especificar um limite. O sistema

não permite que as máquinas virtuais usem mais recursos do que o limite, mesmo quando o
sistema está subutilizado e recursos ociosos estão disponíveis. Especifique o limite somente
se você tiver boas razões para fazê-lo.
Sugestões de configurações de alocação de recursos

Selecione as configurações de alocação de recursos (reserva, limite e compartilhamentos)
apropriadas para o seu ambiente ESXi.

As diretrizes a seguir podem ajudá-lo a obter melhor desempenho para suas máquinas virtuais.
n Use a Reserva (Reservation) para especificar a quantidade mínima aceitável de CPU ou

memória, e não a quantidade que você deseja ter disponível. A quantidade de recursos
concretos representados por uma reserva não muda quando você altera o ambiente, como
adicionando ou removendo máquinas virtuais. O host atribui recursos adicionais conforme
disponíveis com base no limite da sua máquina virtual, no número de compartilhamentos e na
demanda estimada.
n Ao especificar as reservas para máquinas virtuais, não confirme todos os recursos (planeje
deixar pelo menos 10% sem reserva). À medida que você se aproxima da reserva total de
toda a capacidade no sistema, torna-se cada vez mais difícil fazer alterações nas reservas
e na hierarquia do pool de recursos sem violar o controle de admissão. Em um cluster
habilitado para DRS, as reservas que confirmam totalmente a capacidade do cluster ou de
hosts individuais no cluster podem impedir que o DRS migre máquinas virtuais entre hosts.
n Se você espera alterações frequentes no total de recursos disponíveis, use

Compartilhamentos (Shares) para alocar recursos de forma justa nas máquinas virtuais.
Se você usar Compartilhamentos (Shares) e atualizar o host, por exemplo, cada máquina
virtual permanecerá na mesma prioridade (mantém o mesmo número de compartilhamentos),
mesmo que cada compartilhamento represente uma quantidade maior de memória, CPU ou
recursos de E / S de armazenamento.
Editar configurações
Use a caixa de diálogo Editar configurações para alterar as alocações de recursos de memória e
CPU.
Procedimentos
1 Navegue até a máquina virtual no vSphere Client.
2 Clique com o botão direito do mouse e selecione Editar configurações (Edit Settings).
3 Edite os recursos da CPU.
Opção Descrição
Compartilhamentos Compartilhamentos de CPU para este pool de recursos em relação ao

total do principal. Os pools de recursos irmãos compartilham recursos de
acordo com seus valores de compartilhamento relativos delimitados pela
reserva e pelo limite. Selecione Baixa (Low), Normal (Normal) ou Alta
(High), que especificam valores de compartilhamento, respectivamente, em
uma proporção de 1: 2: 4. Selecione Personalizada (Custom) para atribuir
a cada máquina virtual um número específico de compartilhamentos, o que
expressa um peso proporcional.
Reserva Alocação de CPU garantida para este pool de recursos.
Limite Limite superior para a alocação de CPU deste pool de recursos. Selecione
Ilimitado (Unlimited) para especificar nenhum limite máximo.

4 Edite os recursos de memória.
Opção Descrição
Compartilhamentos Compartilhamentos de memória para este pool de recursos em relação ao

total do principal. Os pools de recursos irmãos compartilham recursos de
acordo com seus valores de compartilhamento relativos delimitados pela
reserva e pelo limite. Selecione Baixa (Low), Normal (Normal) ou Alta
(High), que especificam valores de compartilhamento, respectivamente, em
uma proporção de 1: 2: 4. Selecione Personalizada (Custom) para atribuir
a cada máquina virtual um número específico de compartilhamentos, o que
expressa um peso proporcional.
Reserva Alocação de memória garantida para este pool de recursos.
Limite Limite superior para a alocação de memória deste pool de recursos.

Selecione Ilimitado (Unlimited) para especificar nenhum limite máximo.
5 Clique em Okey(OK).
Alterando as configurações de alocação de recursos -

exemplo
O exemplo a seguir ilustra como você pode alterar as configurações de alocação de recursos
para melhorar o desempenho da máquina virtual.
Suponha que em um host ESXi, você tenha criado duas novas máquinas virtuais, uma para cada
um dos seus departamentos de QA (VM-QA) e Marketing (VM-Marketing).
Figura 2-1. Único host com duas máquinas virtuais
host
VM-QA VM-Marketing
No exemplo a seguir, suponha que o controle de qualidade de VM consuma muita memória

e, portanto, você deseja alterar as configurações de alocação de recursos das duas máquinas
virtuais para:
n Especifique que, quando a memória do sistema é supercomprometida, o VM-QA pode usar

o dobro de recursos de CPU e memória do que a máquina virtual de Marketing. Defina os
compartilhamentos de CPU e compartilhamentos de memória para VM-QA como Alta (High)
e para VM-Marketing defina-os como Normal (Normal).
n Certifique-se de que a máquina virtual de marketing tenha uma certa quantidade de recursos
de CPU garantidos. Você pode fazer isso usando uma configuração de reserva.

Procedimentos
1 Navegue até as máquinas virtuais no vSphere Client.
2 Clique com o botão direito do mouse em VM-QA (VM-QA), a máquina virtual para a qual você
deseja alterar os compartilhamentos e selecione Editar Configurações (Edit Settings).
3 Em Hardware Virtual (Virtual Hardware), expanda CPU e selecione Alta (High) no menu
suspenso Compartilhamentos (Shares).
4 Em Hardware Virtual (Virtual Hardware), expanda Memória e selecione Alta (High) no menu
suspenso Compartilhamentos (Shares).
6 Clique com o botão direito do mouse na máquina virtual de marketing ( VM-Marketing (VM-
Marketing)) e selecione Editar configurações (Edit Settings).
7 Em Hardware Virtual (Virtual Hardware), expanda CPU e altere o valor de Reserva

(Reservation) para o número desejado.
Controle de admissão
Quando você liga uma máquina virtual, o sistema verifica a quantidade de recursos de CPU e
memória que ainda não foram reservados. Com base nos recursos não reservados disponíveis, o
sistema determina se pode garantir a reserva para a qual a máquina virtual está configurada (se
houver). Esse processo é chamado de controle de admissão.
Se CPU e memória não reservadas suficientes estiverem disponíveis, ou se não houver reserva,
a máquina virtual será ligada. Caso contrário, um aviso de Recursos insuficientes será
exibido.
Observação Além da reserva de memória especificada pelo usuário, para cada máquina virtual
também há uma quantidade de memória de sobrecarga. Esse compromisso de memória extra
está incluído no cálculo de controle de admissão.
Quando o recurso vSphere DPM está ativado, os hosts podem ser colocados no modo de espera
(ou seja, desligados) para reduzir o consumo de energia. Os recursos não reservados fornecidos
por esses hosts são considerados disponíveis para controle de admissão. Se uma máquina virtual
não puder ser ligada sem esses recursos, será feita uma recomendação para ligar hosts em
espera suficientes. Para obter mais informações, consulte Gerenciamento de recursos de energia.

Noções básicas de virtualização
de CPU 3
A virtualização da CPU enfatiza o desempenho e é executada diretamente no processador
sempre que possível. Os recursos físicos subjacentes são usados sempre que possível e a
camada de virtualização executa instruções apenas conforme necessário para fazer com que as
máquinas virtuais operem como se estivessem sendo executadas diretamente em uma máquina
física.
A virtualização de CPU não é a mesma coisa que emulação. ESXi não usa emulação para
executar CPUs virtuais. Com a emulação, todas as operações são executadas no software
por um emulador. Um emulador de software permite que os programas sejam executados em
um sistema de computador diferente daquele para o qual eles foram originalmente escritos.
O emulador faz isso ao emular ou reproduzir o comportamento do computador original,
aceitando os mesmos dados ou entradas e obtendo os mesmos resultados. A emulação fornece
portabilidade e executa o software projetado para uma plataforma em várias plataformas.
Quando os recursos de CPU são supercomprometidos, o host ESXi divide em tempo os

processadores físicos em todas as máquinas virtuais para que cada máquina virtual seja
executada como se tivesse seu número especificado de processadores virtuais. Quando um host
ESXi executa várias máquinas virtuais, ele aloca a cada máquina virtual um compartilhamento
dos recursos físicos. Com as configurações de alocação de recursos padrão, todas as máquinas
virtuais associadas ao mesmo host recebem um compartilhamento igual de CPU por CPU virtual.
Isso significa que as máquinas virtuais de processador único recebem apenas metade dos
recursos de uma máquina virtual de processador duplo.
n Virtualização de CPU baseada em software
n Virtualização de CPU Assistida por Hardware
n Virtualização e comportamento específico do processador
n Implicações de desempenho da virtualização de CPU
Virtualização de CPU baseada em software

Com a virtualização de CPU baseada em software, o código do aplicativo guest é executado
diretamente no processador, enquanto o código com privilégios guest é traduzido e o código
traduzido é executado no processador.

O código traduzido é um pouco maior e geralmente é executado mais lentamente do que

a versão nativa. Como resultado, os aplicativos guest, que têm um pequeno componente
de código privilegiado, são executados com velocidades muito próximas das nativas. Os
aplicativos com um componente de código privilegiado significativo, como chamadas do sistema,
interceptações ou atualizações da tabela de páginas, podem ser executados mais devagar no
ambiente virtualizado.
Virtualização de CPU Assistida por Hardware

Certos processadores fornecem assistência de hardware para virtualização de CPU.
Ao usar essa assistência, o guest pode usar um modo separado de execução chamado modo
guest. O código guest, seja código de aplicativo ou código privilegiado, é executado no modo
guest. Em determinados eventos, o processador sai do modo guest e entra no modo raiz. O
hipervisor é executado no modo raiz, determina o motivo da saída, toma as ações necessárias e
reinicia o guest no modo guest.
Quando você usa a assistência de hardware para virtualização, não há necessidade de converter
o código. Como resultado, as chamadas de sistema ou as cargas de trabalho com uso intenso
de interceptação são executadas muito perto da velocidade nativa. Algumas cargas de trabalho,
como as que envolvem atualizações em tabelas de páginas, levam a um grande número de
saídas do modo guest para o modo raiz. Dependendo do número de saídas e do tempo total
gasto em saídas, a virtualização da CPU assistida por hardware pode acelerar a execução
significativamente.
Virtualização e comportamento específico do processador

Embora o software VMware virtualize a CPU, a máquina virtual detecta o modelo específico do
processador no qual está sendo executada.
Os modelos de processador podem diferir nos recursos de CPU que eles oferecem, e os
aplicativos em execução na máquina virtual podem fazer uso desses recursos. Portanto, não
®
é possível usar vMotion para migrar máquinas virtuais entre sistemas em execução em
processadores com conjuntos de recursos diferentes. Você pode evitar essa restrição, em alguns
casos, usando o Enhanced vMotion Compatibility (EVC) com processadores compatíveis com
esse recurso. Consulte a documentação vCenter Server e Gerenciamento de host para obter mais
informações.
Implicações de desempenho da virtualização de CPU

A virtualização de CPU adiciona quantidades variáveis de sobrecarga, dependendo da carga de
trabalho e do tipo de virtualização usada.

Um aplicativo é vinculado à CPU se ele passa a maior parte do tempo executando instruções
em vez de aguardar eventos externos, como interação do usuário, entrada do dispositivo
ou recuperação de dados. Para esses aplicativos, a sobrecarga de virtualização da CPU
inclui as instruções adicionais que devem ser executadas. Essa sobrecarga leva o tempo de
processamento da CPU que o próprio aplicativo pode usar. A sobrecarga de virtualização da
CPU geralmente se traduz em uma redução no desempenho geral.
Para aplicativos que não são vinculados à CPU, a virtualização da CPU provavelmente se traduz
em um aumento no uso da CPU. Se a capacidade sobressalente da CPU estiver disponível para
absorver a sobrecarga, ela ainda poderá oferecer um desempenho comparável em termos de
taxa de transferência geral.
O ESXi oferece suporte a até 128 processadores virtuais (CPUs) para cada máquina virtual.
Observação Implante aplicativos de thread único em máquinas virtuais de processador único,

em vez de em máquinas virtuais SMP que tenham várias CPUs, para melhor desempenho e uso
de recursos.
Os aplicativos de thread único podem tirar proveito apenas de uma única CPU. A implantação
desses aplicativos em máquinas virtuais de processador duplo não acelera o aplicativo. Em vez
disso, ela faz com que a segunda CPU virtual use recursos físicos que outras máquinas virtuais
poderiam usar.

Administrando recursos de CPU
4
Você pode configurar máquinas virtuais com um ou mais processadores virtuais, cada um com
seu próprio conjunto de registros e estruturas de controle.
Quando uma máquina virtual é agendada, seus processadores virtuais são agendados para
execução em processadores físicos. O VMkernel Resource Manager agenda as CPUs virtuais em
CPUs físicas, gerenciando assim o acesso da máquina virtual aos recursos físicos da CPU. O ESXi
é compatível com máquinas virtuais com até 128 CPUs virtuais.
Observação Neste capítulo, "Memória" pode se referir a RAM física ou Memória persistente.
n Exibir informações do processador
n Especificando a configuração da CPU
n Processadores multicore
n Hyperthreading
n Usando a afinidade de CPU
n Políticas de gerenciamento de energia do host
Exibir informações do processador

Você pode acessar informações sobre a configuração atual da CPU no vSphere Client.
Procedimentos
1 Navegue até o host no vSphere Client.
2 Em Hardware (Hardware), expanda CPU (CPU) para exibir as informações sobre o número e
o tipo de processadores físicos e o número de processadores lógicos.
Observação Em sistemas hyperthread, cada thread de hardware é um processador lógico.

Por exemplo, um processador de núcleo duplo com hyperthreading habilitado tem dois
núcleos e quatro processadores lógicos.

Especificando a configuração da CPU

Você pode especificar a configuração da CPU para melhorar o gerenciamento de recursos.
No entanto, se você não personalizar a configuração da CPU, o host ESXi usará padrões que
funcionam bem na maioria das situações.
Você pode especificar a configuração da CPU das seguintes maneiras:
n Use os atributos e recursos especiais disponíveis por meio do vSphere Client. O vSphere
Client permite que você se conecte ao host ESXi ou a um sistema vCenter Server.
n Use configurações avançadas em determinadas circunstâncias.
n Use o vSphere SDK para alocação de CPU com script.
n Use hyperthreading.
Processadores multicore
Os processadores multicore oferecem muitas vantagens para um host executando multitarefa de
máquinas virtuais.
Observação Neste tópico, "Memória" pode se referir a RAM física ou Memória persistente.
A Intel e a AMD desenvolveram processadores que combinam dois ou mais núcleos de

processador em um único circuito integrado (muitas vezes chamado de pacote ou soquete).
VMware usa o termo soquete para descrever um único pacote que pode ter um ou mais núcleos
de processador com um ou mais processadores lógicos em cada núcleo.
Um processador de núcleo duplo, por exemplo, fornece quase o dobro do desempenho de um

processador de núcleo único, permitindo que duas CPUs virtuais sejam executadas ao mesmo
tempo. Os núcleos no mesmo processador são normalmente configurados com um cache de
último nível compartilhado usado por todos os núcleos, reduzindo potencialmente a necessidade
de acessar a memória principal mais lenta. Um barramento de memória compartilhada que
conecta um processador físico à memória principal pode limitar o desempenho de seus
processadores lógicos quando as máquinas virtuais em execução neles executam cargas de
trabalho com uso intensivo de memória que competem pelos mesmos recursos de barramento
de memória.
Cada processador lógico de cada núcleo de processador é usado de forma independente pelo
agendador de CPU ESXi para executar máquinas virtuais, fornecendo recursos semelhantes
aos sistemas SMP. Por exemplo, uma máquina virtual bidirecional pode ter seus processadores
virtuais em execução em processadores lógicos que pertencem ao mesmo núcleo ou em
processadores lógicos em diferentes núcleos físicos.
O agendador da CPU ESXi pode detectar a topologia do processador e os relacionamentos entre

os núcleos do processador e os processadores lógicos neles. Ele usa essas informações para
agendar máquinas virtuais e otimizar o desempenho.

O agendador da CPU ESXi pode interpretar a topologia do processador, incluindo a relação

entre soquetes, núcleos e processadores lógicos. O agendador usa informações de topologia
para otimizar o posicionamento de CPUs virtuais em diferentes soquetes. Essa otimização pode
maximizar o uso geral do cache e melhorar a afinidade de cache, minimizando as migrações de
CPU virtual.
Hyperthreading
A tecnologia Hyperthreading permite que um único núcleo de processador físico se comporte
como dois processadores lógicos. O processador pode executar dois aplicativos independentes
ao mesmo tempo. Para evitar confusão entre processadores lógicos e físicos, a Intel se refere
a um processador físico como um soquete, e a discussão neste capítulo também usa essa
terminologia.
A Intel Corporation desenvolveu a tecnologia hyperthreading para melhorar o desempenho de

suas linhas de processador Xium e Pentium IV. A tecnologia Hyperthreading permite que um
único núcleo de processador execute dois threads independentes simultaneamente.
Embora o hyperthreading não duplique o desempenho de um sistema, ele pode aumentar o

desempenho ao utilizar melhor os recursos ociosos, o que resulta em maior taxa de transferência
para determinados tipos de carga de trabalho importantes. Um aplicativo em execução em um
processador lógico de um núcleo ocupado pode esperar um pouco mais da metade da taxa
de transferência obtida durante a execução isolada em um processador não hyperthread. As
melhorias de desempenho do hyperthreading são altamente dependentes do aplicativo, e alguns
aplicativos podem sofrer degradação do desempenho com o hyperthreading porque muitos
recursos do processador (como o cache) são compartilhados entre processadores lógicos.
Observação Em processadores com a tecnologia Intel Hyper-Threading, cada núcleo pode ter
dois processadores lógicos que compartilham a maioria dos recursos do núcleo, como caches
de memória e unidades funcionais. Esses processadores lógicos são geralmente chamados de
threads.
Muitos processadores não oferecem suporte ao hyperthreading e, como resultado, têm apenas
um thread por núcleo. Para esses processadores, o número de núcleos também corresponde
ao número de processadores lógicos. Os seguintes processadores oferecem suporte ao
hyperthreading e têm dois threads por núcleo.
n Processadores baseados na microarquitetura do processador Intel Xeon 5500.
n Intel Pentium 4 (habilitado para HT)
n Intel Pentium EE 840 (habilitado para HT)
Hyperthreading e ESXi hosts

Um host habilitado para hyperthreading deve se comportar de forma semelhante a um host
sem hyperthreading. No entanto, talvez você precise considerar alguns fatores se ativar o
hyperthreading.

Os hosts ESXi gerenciam o tempo do processador de forma inteligente para garantir que a carga
seja distribuída sem problemas pelos núcleos do processador no sistema. Os processadores
lógicos no mesmo núcleo têm números de CPU consecutivos, de modo que as CPUs 0 e 1
estão no primeiro núcleo juntas, as CPUs 2 e 3 estão no segundo núcleo e assim por diante. As
máquinas virtuais são preferencialmente agendadas em dois núcleos diferentes em vez de em
dois processadores lógicos no mesmo núcleo.
Se não houver trabalho para um processador lógico, ele será colocado em um estado
interrompido, o que libera seus recursos de execução e permite que a máquina virtual em
execução no outro processador lógico no mesmo núcleo use todos os recursos de execução
do núcleo. O VMware agendador contabiliza corretamente esse tempo de interrupção e
carrega uma máquina virtual em execução com todos os recursos de uma núcleo mais do
que uma máquina virtual em execução em meio núcleo. Essa abordagem ao gerenciamento
do processador garante que o servidor não viole nenhuma das regras padrão de alocação de
recursos ESXi.
Considere suas necessidades de gerenciamento de recursos antes de habilitar a afinidade de

CPU em hosts usando hyperthreading. Por exemplo, se você associar uma máquina virtual de
alta prioridade à CPU 0 e outra máquina virtual de alta prioridade à CPU 1, as duas máquinas
virtuais terão que compartilhar o mesmo núcleo físico. Nesse caso, pode ser impossível atender
às demandas de recursos dessas máquinas virtuais. Certifique-se de que qualquer configuração
de afinidade personalizada faça sentido para um sistema hyperthread.
Habilitar Hyperthreading
Para ativar o hyperthreading, primeiro você deve habilitá-lo nas configurações de BIOS do seu
sistema e, em seguida, ativá-lo no vSphere Client. O Hyperthreading é ativado por padrão.
Consulte a documentação do sistema para determinar se a sua CPU suporta hyperthreading.
Procedimentos
1 Certifique-se de que seu sistema seja compatível com a tecnologia hyperthreading.
2 Habilite o hyperthreading no BIOS do sistema.
Alguns fabricantes rotulam essa opção como Processador lógico (Logical Processor),
enquanto outros a chamam Ativar Hyperthreading (Enable Hyperthreading).
3 Certifique-se de que o hyperthreading esteja habilitado para o host ESXi.
a Navegue até o host no vSphere Client.
b Clique em Configurar(Configure).
c Em Sistema (System), clique em Configurações avançadas do sistema

(Advanced System Settings) e selecione VMkernel.Boot.hyperthreading
(VMkernel.Boot.hyperthreading).
Você deve reiniciar o host para que a configuração entre em vigor. O Hyperthreading
será ativado se o valor for verdadeiro .

4 Em Hardware (Hardware), clique em Processadores (Processors) para visualizar o número

de processadores lógicos.
Resultados
O Hyperthreading está ativado.
Usando a afinidade de CPU

Ao especificar uma configuração de afinidade de CPU para cada máquina virtual, você pode
restringir a atribuição de máquinas virtuais a um subconjunto dos processadores disponíveis em
sistemas de multiprocessadores. Ao usar esse recurso, você pode atribuir cada máquina virtual a
processadores no conjunto de afinidades especificado.
A afinidade de CPU especifica restrições de posicionamento de máquina virtual para processador

e é diferente da relação criada por uma regra de afinidade de VM-VM ou VM-Host, que
especifica as restrições de posicionamento de máquina virtual para host de máquina virtual.
Nesse contexto, o termo CPU refere-se a um processador lógico em um sistema hyperthread e

refere-se a um núcleo em um sistema não hyperthread.
A configuração de afinidade de CPU para uma máquina virtual se aplica a todas as CPUs virtuais
associadas à máquina virtual e a todos os outros threads (também conhecidos como mundos)
associados à máquina virtual. Esses threads de máquina virtual executam o processamento
necessário para emular mouse, teclado, tela, CD-ROM e diversos dispositivos legados.
Em alguns casos, como cargas de trabalho com exibição intensa, uma comunicação significativa
pode ocorrer entre as CPUs virtuais e esses outros threads da máquina virtual. O desempenho
poderá diminuir se a configuração de afinidade da máquina virtual impedir que esses threads
adicionais sejam agendados simultaneamente com as CPUs virtuais da máquina virtual. Exemplos
disso incluem uma máquina virtual com processador único com afinidade para uma única CPU ou
uma máquina virtual SMP bidirecional com afinidade para apenas duas CPUs.
Para obter o melhor desempenho, ao usar as configurações de afinidade manual, VMware

recomenda que você inclua pelo menos uma CPU física adicional na configuração de afinidade
para permitir que pelo menos um dos threads da máquina virtual seja agendado ao mesmo
tempo que suas CPUs virtuais. . Exemplos disso incluem uma máquina virtual de unprocessador
com afinidade com pelo menos duas CPUs ou uma máquina virtual SMP bidirecional com
afinidade com pelo menos três CPUs.
Atribuir uma máquina virtual a um processador específico

Usando a afinidade de CPU, você pode atribuir uma máquina virtual a um processador específico.
Isso permite que você restrinja a atribuição de máquinas virtuais a um processador específico
disponível em sistemas multiprocessadores.

Procedimentos
a Para localizar uma máquina virtual, selecione um centro de dados, uma pasta, um cluster,
um pool de recursos ou um host.
b Selecione VMs (VMs).
2 Clique com o botão direito do mouse na máquina virtual e clique em Editar Configurações
(Edit Settings).
3 Em Hardware Virtual, expanda CPU (CPU).
4 Em Agendamento de Afinidade, selecione a afinidade de processador físico para a máquina

virtual.
Use '-' para intervalos e ',' para separar valores.

Por exemplo, "0, 2, 4-7" indicaria os processadores 0, 2, 4, 5, 6 e 7.
5 Selecione os processadores onde deseja que a máquina virtual seja executada e clique em
OK (OK).
Problemas potenciais com afinidade de CPU

Antes de usar a afinidade de CPU, talvez você precise considerar alguns problemas.
Os possíveis problemas com afinidade de CPU incluem:
n Para sistemas com vários processadores, os sistemas do ESXi executam o balanceamento

de carga automático. Evite a especificação manual da afinidade da máquina virtual para
melhorar a capacidade do agendador de balancear a carga entre os processadores.
n A afinidade pode interferir na capacidade do host do ESXi de atender à reserva e aos

compartilhamentos especificados para uma máquina virtual.
n Como o controle de admissão da CPU não considera a afinidade, uma máquina virtual com
configurações de afinidade manual pode nem sempre receber sua reserva completa.
As máquinas virtuais que não têm configurações de afinidade manual não são afetadas
negativamente por máquinas virtuais com configurações de afinidade manual.
n Quando você move uma máquina virtual de um host para outro, a afinidade pode não se
aplicar mais porque o novo host pode ter um número diferente de processadores.
n O agendador NUMA pode não ser capaz de gerenciar uma máquina virtual que já esteja
atribuída a determinados processadores usando afinidade. Para obter mais informações,
consulte Capítulo 16 Usando sistemas NUMA com o ESXi.
n A afinidade pode afetar a capacidade do host de agendar máquinas virtuais em

processadores multicore ou hyperthreaded para aproveitar ao máximo os recursos
compartilhados nesses processadores.

Políticas de gerenciamento de energia do host

Você pode aplicar vários recursos de gerenciamento de energia em ESXi que o hardware do
host fornece para ajustar o equilíbrio entre desempenho e energia. Você pode controlar como
ESXi usa esses recursos selecionando uma política de gerenciamento de energia.
A seleção de uma política de alto desempenho fornece um desempenho mais absoluto, mas
com menor eficiência e desempenho por watt. Políticas de baixa energia fornecem desempenho
menos absoluto, mas com maior eficiência.
Você pode selecionar uma política para o host que gerencia usando o VMware Host Client. Se
você não selecionar uma política, ESXi usará Balanceado por padrão.
Tabela 4-1. Políticas de gerenciamento de energia da CPU
Política de gerenciamento de energia Descrição
Alto desempenho Não use nenhum recurso de gerenciamento de energia.
Balanceado (padrão) Reduza o consumo de energia com o comprometimento

mínimo do desempenho
Baixa potência Reduza o consumo de energia com risco de desempenho

inferior
Personalizado Política de gerenciamento de energia definida pelo

usuário. A configuração avançada fica disponível.
Quando uma CPU é executada em menor frequência, ela também pode ser executada em menor
voltagem, o que economiza energia. Esse tipo de gerenciamento de energia é normalmente
chamado de Dynamic Voltage and Frequency Dimensioning (DVFS). ESXi tenta ajustar as
frequências da CPU para que o desempenho da máquina virtual não seja afetado.
Quando uma CPU está ociosa, ESXi pode aplicar estados de interrupção profunda, também
conhecidos como estados C. Quanto mais profundo o estado C, menos energia a CPU usa, mas
também leva mais tempo para que a CPU comece a funcionar novamente. Quando uma CPU
se torna ociosa, ESXi aplica um algoritmo para prever a duração do estado ocioso e escolhe
um estado C apropriado para inserir. Em políticas de gerenciamento de energia que não usam
estados C profundos, ESXi usa apenas o estado de parada mais raso para CPUs ociosas, C1.
Selecione uma política de gerenciamento de energia da CPU

Você define a política de gerenciamento de energia da CPU para um host usando o vSphere
Client.

Pré-requisitos
Verifique se as configurações do BIOS no sistema host permitem que o sistema operacional

controle o gerenciamento de energia (por exemplo, SO controlado (OS Controlled)).
Observação Alguns sistemas têm a tecnologia Processor Clocking Control (PCC), que permite
que ESXi gerencie a energia do sistema host, mesmo que as configurações do BIOS do host
não especifiquem o modo Controlado pelo sistema operacional. Com essa tecnologia, ESXi não
gerencia P-estados diretamente. Em vez disso, o host coopera com o BIOS para determinar
a taxa de relógio do processador. Os sistemas HP que suportam essa tecnologia têm uma
configuração de BIOS chamada Gerenciamento de energia cooperativa que é ativada por
padrão.
Se o hardware do host não permitir que o sistema operacional gerencie a energia, apenas
a política Sem suporte estará disponível. (Em alguns sistemas, apenas a política de Alto
Desempenho está disponível.)
Procedimentos
2 Clique em Configurar(Configure).
3 Em Hardware, selecione Gerenciamento de energia (Power Management) e clique no botão

Editar (Edit).
4 Selecione uma política de gerenciamento de energia para o host e clique em OK (OK).
A seleção de política é salva na configuração do host e pode ser usada novamente no

momento da inicialização. Você pode alterá-lo a qualquer momento e ele não requer uma
reinicialização do servidor.
Configurar parâmetros de política personalizados para o

gerenciamento de energia do host
Quando você usa a política Personalizada para o gerenciamento de energia do host, ESXi baseia
sua política de gerenciamento de energia nos valores de vários parâmetros de configuração
avançados.
Pré-requisitos
Selecione Personalizado (Custom) para a política de gerenciamento de energia, conforme

descrito em Selecione uma política de gerenciamento de energia da CPU.
Procedimentos
3 Em Sistema (System), selecione Configurações avançadas do sistema (Advanced System

Settings).

4 No painel direito, você pode editar os parâmetros de gerenciamento de energia que afetam a
política Personalizada.
Os parâmetros de gerenciamento de energia que afetam a política personalizada têm

descrições que começam com Na política personalizada (In Custom policy). Todos os outros
parâmetros de energia afetam todas as políticas de gerenciamento de energia.
5 Selecione o parâmetro e clique no botão Editar (Edit).
Observação Os valores padrão dos parâmetros de gerenciamento de energia

correspondem à política Balanceada.
Parâmetro Descrição
Power.UsePStates Use os estados P da ACPI para economizar energia quando o processador

estiver ocupado.
Power.MaxCpuLoad Use os estados P para economizar energia em uma CPU somente quando
a CPU estiver ocupada por menos do que a porcentagem especificada de
tempo real.
Power.MinFreqPct Não use nenhum estado P mais lento que a porcentagem determinada da
velocidade total da CPU.
Power.UseStallCtr Use um estado P mais profundo quando o processador estiver

frequentemente parado aguardando eventos, como erros de cache.
Power.TimerHz Controla quantas vezes por segundo ESXi reavalia em qual estado P cada
CPU deve estar.
Power.UseCStates Use estados C profundos da ACPI (C2 ou inferior) quando o processador

estiver ocioso.
Power.CStateMaxLatency Não use estados C cuja latência seja maior que esse valor.
Power.CStateResidencyCoef Quando uma CPU ficar ociosa, escolha o estado C mais profundo cuja
latência multiplicada por esse valor seja menor do que a previsão do host
de quanto tempo a CPU permanecerá ociosa. Valores maiores tornam ESXi
mais conservador sobre o uso de estados C profundos, enquanto valores
menores são mais agressivos.
Power.CStatePredictedCoef Um parâmetro no algoritmo ESXi para prever por quanto tempo uma CPU
que fica ociosa permanecerá ociosa. Não é recomendável alterar este valor.
Power.PerfBias Dica de enviesamento de energia de desempenho (somente Intel). Define

um MSR nos processadores Intel como um valor recomendado pela Intel. A
Intel recomenda 0 para alto desempenho, 6 para balanceado e 15 para baixo
consumo de energia. Outros valores não são definidos.

Conceitos básicos de virtualização
de memória 5
Antes de gerenciar recursos de memória, você deve entender como eles estão sendo
virtualizados e usados por ESXi.
O VMkernel gerencia toda a RAM física no host. O VMkernel dedica parte dessa RAM física
gerenciada para uso próprio. O restante está disponível para uso por máquinas virtuais.
O espaço de memória virtual e física é dividido em blocos chamados páginas. Quando a

memória física está cheia, os dados das páginas virtuais que não estão presentes na memória
física são armazenados no disco. Dependendo da arquitetura do processador, as páginas têm
normalmente 4 KB ou 2 MB. Consulte Atributos avançados de memória.
n Memória da máquina virtual
n Comprometimento excessivo da memória
n Compartilhamento de memória
n Virtualização de memória
n Suporte para tamanhos de página grandes
Memória da máquina virtual

Cada máquina virtual consome memória com base em seu tamanho configurado, além de
sobrecarga de memória adicional para virtualização.
O tamanho configurado é a quantidade de memória que é apresentada ao sistema operacional

convidado. Isso é diferente da quantidade de RAM física que é alocada para a máquina virtual. O
último depende das configurações de recursos (compartilhamentos, reserva, limite) e do nível de
pressão de memória no host.

Por exemplo, considere uma máquina virtual com um tamanho configurado de 1 GB. Quando o
sistema operacional guest é inicializado, ele detecta que está sendo executado em uma máquina
dedicada com 1 GB de memória física. Em alguns casos, a máquina virtual pode receber 1 GB
completo. Em outros casos, pode receber uma alocação menor. Independentemente da alocação
real, o sistema operacional guest continua a se comportar como se estivesse sendo executado
em uma máquina dedicada com 1 GB de memória física.
Compartilhamentos
Especifique a prioridade relativa para uma máquina virtual se mais do que a reserva estiver
disponível.
Reserva
É um limite inferior garantido para a quantidade de RAM física que o host reserva para a
máquina virtual, mesmo quando a memória é supercomprometida. Defina a reserva para um
nível que garanta que a máquina virtual tenha memória suficiente para executar de forma
eficiente, sem paginação excessiva.
Depois que uma máquina virtual consome toda a memória dentro de sua reserva, ela tem
permissão para reter essa quantidade de memória e essa memória não é recuperada,
mesmo se a máquina virtual se tornar ociosa. Alguns sistemas operacionais convidados (por
exemplo, Linux) podem não acessar toda a memória configurada imediatamente após a
inicialização. Até que as máquinas virtuais consumam toda a memória em sua reserva, o
VMkernel pode alocar qualquer parte não utilizada de sua reserva para outras máquinas
virtuais. No entanto, depois que a carga de trabalho do convidado aumenta e a máquina
virtual consome sua reserva completa, é permitido manter essa memória.
Limite
É um limite superior da quantidade de RAM física que o host pode alocar para a máquina
virtual. A alocação de memória da máquina virtual também é implicitamente limitada pelo
tamanho configurado.
Comprometimento excessivo da memória

Para cada máquina virtual em execução, o sistema reserva RAM física para a reserva da máquina
virtual (se houver) e para sua sobrecarga de virtualização.
O tamanho total da memória configurada de todas as máquinas virtuais pode exceder a

quantidade de memória física disponível no host. No entanto, isso não significa necessariamente
que a memória esteja comprometida demais. A memória é supercomprometida quando o espaço
de memória de trabalho combinado de todas as máquinas virtuais excede o dos tamanhos de
memória do host.

Devido às técnicas de gerenciamento de memória que o host ESXi usa, suas máquinas virtuais
podem usar mais RAM virtual do que a RAM física disponível no host. Por exemplo, você pode ter
um host com 2 GB de memória e executar quatro máquinas virtuais com 1 GB de memória cada.
Nesse caso, a memória está comprometida demais. Por exemplo, se todas as quatro máquinas
virtuais estiverem ociosas, a memória consumida combinada poderá estar bem abaixo de 2 GB.
No entanto, se todas as máquinas virtuais de 4 GB estiverem consumindo memória ativamente,
seu espaço de memória poderá exceder 2 GB e o host ESXi ficará comprometido demais.
O comprometimento excessivo faz sentido porque, normalmente, algumas máquinas virtuais são
pouco carregadas, enquanto outras são mais pesadamente carregadas, e os níveis de atividade
relativa variam ao longo do tempo.
Para melhorar a utilização da memória, o host ESXi transfere a memória de máquinas virtuais
ociosas para máquinas virtuais que precisam de mais memória. Use o parâmetro Reserva ou
Compartilhamentos para alocar preferencialmente a memória a máquinas virtuais importantes.
Essa memória permanecerá disponível para outras máquinas virtuais se não estiver em uso.
O ESXi implementa vários mecanismos, como balonamento, compartilhamento de memória,
compactação e troca de memória para fornecer um desempenho razoável, mesmo se o host
não estiver muito comprometido em termos de memória.
Um host ESXi pode ficar sem memória se as máquinas virtuais consumirem toda a memória
reservável em um ambiente com excesso de memória. Embora as máquinas virtuais ligadas não
sejam afetadas, uma nova máquina virtual pode falhar ao ser ligada devido à falta de memória.
Observação Toda a sobrecarga de memória da máquina virtual também é considerada

reservada.
Além disso, a compactação de memória é ativada por padrão em ESXi hosts para melhorar o
desempenho da máquina virtual quando a memória é supercomprometida, conforme descrito em
Compressão de memória.
Compartilhamento de memória
O compartilhamento de memória é uma técnica proprietária ESXi que pode ajudar a obter maior
densidade de memória em um host.
O compartilhamento de memória depende da observação de que várias máquinas virtuais

podem estar executando instâncias do mesmo sistema operacional guest. Essas máquinas
virtuais podem ter os mesmos aplicativos ou componentes carregados ou conter dados
comuns. Nesses casos, um host usa uma técnica proprietária de Compartilhamento de
página transparente (TPS) para eliminar cópias redundantes de páginas de memória. Com o
compartilhamento de memória, uma carga de trabalho em execução em uma máquina virtual
geralmente consome menos memória do que quando em execução em máquinas físicas. Como
resultado, níveis mais altos de comprometimento excessivo podem ser suportados de forma

eficiente. A quantidade de memória salva pelo compartilhamento de memória depende se a

carga de trabalho consiste em máquinas quase idênticas que podem liberar mais memória. Uma
carga de trabalho mais diversificada pode resultar em uma porcentagem menor de economia de
memória.
Observação Devido a preocupações de segurança, o compartilhamento de páginas

transparentes entre máquinas virtuais é desativado por padrão, e o compartilhamento de
páginas está sendo restrito ao compartilhamento de memória dentro da máquina virtual. O
compartilhamento de página não ocorre em máquinas virtuais e ocorre somente dentro de
uma máquina virtual. Consulte Compartilhando memória entre máquinas virtuais para obter mais
informações.
Virtualização de memória
Devido ao nível extra de mapeamento de memória introduzido pela virtualização, ESXi pode
gerenciar efetivamente a memória em todas as máquinas virtuais.
Uma parte da memória física de uma máquina virtual pode ser mapeada para páginas
compartilhadas ou para páginas não mapeadas ou trocadas.
Um host executa o gerenciamento de memória virtual sem o conhecimento do sistema

operacional convidado e sem interferir com o próprio subsistema de gerenciamento de memória
do sistema operacional convidado.
O VMM de cada máquina virtual mantém um mapeamento das páginas de memória física
do sistema operacional convidado para as páginas de memória física na máquina subjacente.
(VMware refere-se às páginas físicas do host subjacente como páginas de "máquina" e as
páginas físicas do sistema operacional convidado como páginas "físicas".)
Cada máquina virtual vê um espaço de memória física endereçável, com base em zero e
contíguo. A memória da máquina subjacente no servidor usada por cada máquina virtual não
é necessariamente contígua.
Os endereços físicos virtuais de guest para guest são gerenciados pelo sistema operacional
guest. O hipervisor é responsável apenas pela conversão dos endereços físicos guest em
endereços de máquina. A virtualização de memória assistida por hardware utiliza a instalação
de hardware para gerar os mapeamentos combinados com as tabelas de página do guest e as
tabelas de página aninhadas mantidas pelo hipervisor.
O diagrama ilustra a ESXi implementação da virtualização de memória.

Figura 5-1. ESXi Mapeamento de Memória

virtual machine virtual machine
1 2
a b c b guest virtual memory
a b b c guest physical memory
a b b c machine memory
n As caixas representam páginas e as setas mostram os diferentes mapeamentos de memória.
n As setas da memória virtual guest para a memória física guest mostram o mapeamento
mantido pelas tabelas de páginas no sistema operacional guest. (O mapeamento da memória
virtual para a memória linear para processadores com arquitetura x86 não é mostrado.)
n As setas da memória física guest para a memória da máquina mostram o mapeamento

mantido pelo VMM.
n As setas tracejadas mostram o mapeamento da memória virtual de convidado para a

memória da máquina nas tabelas de páginas de sombra também mantidas pelo VMM. O
processador subjacente que executa a máquina virtual usa os mapeamentos de tabela da
página de sombra.
Virtualização de memória assistida por hardware

Algumas CPUs, como a AMD SVM-V e a série Intel Xeon 5500, oferecem suporte de hardware
para virtualização de memória usando duas camadas de tabelas de página.
Observação Neste tópico, "Memória" pode se referir a RAM física ou Memória persistente. ()
A primeira camada de tabelas de páginas armazena as traduções de virtual para físicas

convidadas, enquanto a segunda camada de tabelas de páginas armazena a tradução de física
para máquina convidada. O TLB (buffer de observação de tradução) é um cache de traduções
mantidas pelo hardware da unidade de gerenciamento de memória (MMU) do processador. Uma
falta de TLB é uma falta neste cache e o hardware precisa ir para a memória (possivelmente
várias vezes) para encontrar a tradução necessária. Para uma falta de TLB para um determinado
endereço virtual convidado, o hardware examina as duas tabelas de página para converter o
endereço virtual convidado em endereço de máquina. A primeira camada de tabelas de páginas
é mantida pelo sistema operacional guest. O VMM mantém apenas a segunda camada de tabelas
de páginas.
Considerações de desempenho
Ao usar a assistência de hardware, você elimina a sobrecarga da virtualização de memória de
software. Em particular, a assistência de hardware elimina a sobrecarga necessária para manter
as tabelas de páginas de sombra em sincronização com as tabelas de páginas de convidados. No
entanto, a latência de falta de TLB ao usar a assistência de hardware é significativamente maior.

Por padrão, o hipervisor usa páginas grandes em modos assistidos por hardware para reduzir o
custo de erros de TLB. Como resultado, se uma carga de trabalho se beneficia ou não usando a
assistência de hardware depende principalmente da sobrecarga que a virtualização de memória
causa ao usar a virtualização de memória de software. Se uma carga de trabalho envolver
uma pequena quantidade de atividade da tabela de páginas (como a criação de processos,
o mapeamento da memória ou as alternâncias de contexto), a virtualização de software não
causará uma sobrecarga significativa. Por outro lado, cargas de trabalho com uma grande
quantidade de atividade de tabela de páginas provavelmente se beneficiarão da assistência de
hardware.
Por padrão, o hipervisor usa páginas grandes em modos assistidos por hardware para reduzir
o custo de erros de TLB. O melhor desempenho é obtido com o uso de páginas grandes nas
conversões de endereços de guest virtual para físico e guest para máquinas.
A opção LPage.LPageAlwaysTenteForNPT pode alterar a política para o uso de páginas

grandes em conversões de endereço físico para máquina. Para obter mais informações, consulte
Atributos avançados de memória.
Suporte para tamanhos de página grandes

ESXi fornece suporte limitado para tamanhos de página grandes.
A arquitetura x86 permite que o software do sistema use páginas de 4 KB, 2 MB e 1 GB.
Referimo-nos a páginas de 4KB como páginas pequenas, enquanto páginas de 2 MB e 1 GB
são chamadas de páginas grandes. As páginas grandes aliviam a pressão do buffer de tradução
(TLS) e reduzem o custo das andadas da tabela de páginas, o que resulta em um melhor
desempenho da carga de trabalho.
Em ambientes virtualizados, as páginas grandes podem ser usadas pelo hipervisor e pelo sistema
operacional convidado de forma independente. Embora o maior impacto sobre o desempenho
seja obtido se páginas grandes forem usadas pelo guest e pelo hipervisor, na maioria dos casos,
um impacto sobre o desempenho poderá ser observado, mesmo que páginas grandes sejam
usadas apenas no nível do hipervisor.
O hipervisor ESXi usa 2 MB de páginas para fazer backup da vRAM guest por padrão. O vSphere
6.7 ESXi oferece suporte limitado para o backup da vRAM guest com páginas de 1 GB. Para obter
mais informações, consulte Backing Guest vRAM with 1GB Pages .

Administrando recursos de
memória 6
Usando o vSphere Client, você pode visualizar informações sobre e fazer alterações nas
configurações de alocação de memória. Para administrar seus recursos de memória de forma
eficaz, você também deve estar familiarizado com a sobrecarga de memória, o imposto de
memória ociosa e como ESXi os hosts recuperam memória.
Ao administrar recursos de memória, você pode especificar a alocação de memória. Se você não
personalizar a alocação de memória, o host ESXi usará padrões que funcionam bem na maioria
das situações.
Você pode especificar a alocação de memória de várias maneiras.
n Use os atributos e recursos especiais disponíveis por meio do vSphere Client (). O vSphere
Client permite que você se conecte ao host ESXi ou ao sistema vCenter Server.
n Use configurações avançadas.
n Use o vSphere SDK para alocação de memória com script.
n Entendendo a sobrecarga de memória
n Como os hosts ESXi alocam memória
n Recuperação de memória
n Usando arquivos de permuta
n Compartilhando memória entre máquinas virtuais
n Compressão de memória
n Medindo e diferenciando tipos de uso de memória
n Confiabilidade da Memória
n Sobre a permuta do sistema
Entendendo a sobrecarga de memória

A virtualização de recursos de memória tem alguma sobrecarga associada.

ESXi máquinas virtuais podem gerar dois tipos de sobrecarga de memória.
n O tempo adicional para acessar a memória em uma máquina virtual.
n O espaço extra necessário pelo host ESXi para seu próprio código e estruturas de dados,
além da memória alocada a cada máquina virtual.
ESXi virtualização de memória adiciona pouco tempo de sobrecarga aos acessos à memória.
Como o hardware de paginação do processador usa tabelas de páginas (tabelas de páginas
de sombra para abordagem baseada em software ou tabelas de página de dois níveis para
abordagem assistida por hardware) diretamente, a maioria dos acessos de memória na máquina
virtual pode ser executada sem sobrecarga de conversão de endereços.
A sobrecarga de espaço de memória tem dois componentes.
n Uma sobrecarga fixa em todo o sistema para o VMkernel.
n Sobrecarga adicional para cada máquina virtual.
A sobrecarga de memória inclui espaço reservado para o buffer de quadro da máquina virtual e
várias estruturas de dados de virtualização, como tabelas de páginas de sombra. A sobrecarga
de memória depende do número de CPUs virtuais e da memória configurada para o sistema
operacional convidado.
Memória de sobrecarga em máquinas virtuais

As máquinas virtuais exigem uma certa quantidade de memória de sobrecarga disponível para
serem ligadas. Você deve estar ciente da quantidade dessa sobrecarga.
A tabela a seguir lista a quantidade de memória de sobrecarga necessária para ligar uma
máquina virtual. Depois que uma máquina virtual está em execução, a quantidade de memória
adicional que ela usa pode ser diferente da quantidade listada na tabela. Os valores de amostra
foram coletados com a troca VMX ativada e a MMU de hardware ativada para a máquina virtual.
(A troca VMX é ativada por padrão.)
Observação A tabela fornece uma amostra de valores de memória de sobrecarga e não

tenta fornecer informações sobre todas as configurações possíveis. Você pode configurar uma
máquina virtual para ter até 64 CPUs virtuais, dependendo do número de CPUs licenciadas no
host e do número de CPUs que o sistema operacional convidado suporta.
Tabela 6-1. Amostra de memória sobrecarga em máquinas virtuais
Memória (MB) 1 VCPU 2 VCPUs 4 VCPUs 8 VCPUs
256 20,29 24,28 32,23 48,16
1024 25,90 29,91 37,86 53,82
4096 48,64 52,72 60,67 76,78
16384 139,62 143,98 151,93 168,60

Como os hosts ESXi alocam memória

Um host aloca a memória especificada pelo parâmetro Limit para cada máquina virtual, a
menos que a memória seja supercomprometida. ESXi nunca aloca mais memória para uma
máquina virtual do que seu tamanho de memória física especificado.
Por exemplo, uma máquina virtual de 1 GB pode ter o limite padrão (ilimitado) ou um limite
especificado pelo usuário (por exemplo, 2 GB). Em ambos os casos, o host ESXi nunca aloca mais
de 1 GB, o tamanho da memória física que foi especificado para ele.
Quando a memória é supercomprometida, cada máquina virtual recebe uma quantidade de

memória em algum lugar entre o que é especificado pela Reserva (Reservation) e o que é
especificado pelo Limite (Limit). A quantidade de memória concedida a uma máquina virtual
acima de sua reserva geralmente varia com a carga de memória atual.
Um host determina as alocações para cada máquina virtual com base no número de
compartilhamentos alocados a ela e em uma estimativa do tamanho do seu conjunto de trabalho
recente.
n Compartilhamentos - Os hosts ESXi usam uma política de alocação de memória de

compartilhamento proporcional modificada. Os compartilhamentos de memória autorizam
uma máquina virtual a uma fração da memória física disponível.
n Tamanho do conjunto de trabalho - ESXi hosts estimam o conjunto de trabalho para uma
máquina virtual monitorando a atividade de memória durante períodos sucessivos de tempo
de execução da máquina virtual. As estimativas são atenuadas ao longo de vários períodos
de tempo usando técnicas que respondem rapidamente a aumentos no tamanho do conjunto
de trabalho e mais lentamente a diminuições no tamanho do conjunto de trabalho.
Essa abordagem garante que uma máquina virtual da qual a memória ociosa é recuperada
possa aumentar rapidamente para sua alocação completa baseada em compartilhamento
quando começar a usar sua memória de forma mais ativa.
A atividade de memória é monitorada para estimar os tamanhos dos conjuntos de trabalho

para um período padrão de 60 segundos. Para modificar esse padrão, ajuste a configuração
avançada Mem.SamplePeriod. Consulte Definir atributos de host avançados.
Imposto de memória para máquinas virtuais ociosas

Se uma máquina virtual não estiver usando ativamente toda a sua memória alocada atualmente,
ESXi cobrará mais pela memória ociosa do que pela memória que está em uso. Isso é feito para
ajudar a impedir que as máquinas virtuais acumulem memória ociosa.
O imposto de memória ociosa é aplicado de forma progressiva. A taxa de imposto efetiva

aumenta à medida que a proporção de memória ociosa em relação à memória ativa da máquina
virtual aumenta. (Em versões anteriores de ESXi que não eram compatíveis com pools de
recursos hierárquicos, toda a memória ociosa de uma máquina virtual era tributada da mesma
forma.)

Você pode modificar a taxa de imposto de memória ociosa com a opção Mem.IdleTax. Use
essa opção, juntamente com o atributo avançado Mem.SamplePeriod, para controlar como o
sistema determina as alocações de memória de destino para as máquinas virtuais. Consulte
Definir atributos de host avançados.
Observação Na maioria dos casos, as alterações em Mem.IdleTax não são necessárias nem
apropriadas.
Arquivos de permuta VMX

Os arquivos de permuta de máquina virtual (VMX) executáveis permitem que o host reduza
significativamente a quantidade de memória de sobrecarga reservada para o processo VMX.
Observação Os arquivos de permuta VMX não estão relacionados ao recurso de cache de

permuta de permuta para host ou a arquivos de permuta normais no nível do host.
ESXi reserva memória por máquina virtual para vários fins. A memória para as necessidades de
determinados componentes, como o monitor de máquina virtual (VMM) e dispositivos virtuais, é
totalmente reservada quando uma máquina virtual é ligada. No entanto, parte da memória de
sobrecarga reservada para o processo VMX pode ser trocada. O recurso de permuta VMX reduz
significativamente a reserva de memória VMX (por exemplo, de cerca de 50 MB ou mais por
máquina virtual para cerca de 10 MB por máquina virtual). Isso permite que a memória restante
seja trocada quando a memória do host for supercomitida, reduzindo a reserva de memória de
sobrecarga para cada máquina virtual.
O host cria arquivos de permuta VMX automaticamente, desde que haja espaço livre em disco
suficiente no momento em que uma máquina virtual é ligada.
Recuperação de memória
ESXi hosts podem recuperar memória de máquinas virtuais.
Um host aloca a quantidade de memória especificada por uma reserva diretamente para uma
máquina virtual. Qualquer coisa além da reserva é alocada usando os recursos físicos do host ou,
quando os recursos físicos não estão disponíveis, são manipulados usando técnicas especiais,
como balonismo ou troca. Os hosts podem usar duas técnicas para expandir ou contrair
dinamicamente a quantidade de memória alocada às máquinas virtuais.
n Os sistemas ESXi usam um driver de balão de memória (vmmemctl), carregado no sistema

operacional guest em execução em uma máquina virtual. Consulte Driver de Balão de
Memória.
n O sistema ESXi troca uma página de uma máquina virtual para um arquivo de permuta de
servidor sem qualquer envolvimento do sistema operacional guest. Cada máquina virtual tem
seu próprio arquivo de permuta.

Driver de Balão de Memória

O driver de balão de memória (vmmemctl) colabora com o servidor para recuperar páginas que
são consideradas menos valiosas pelo sistema operacional guest.
O driver usa uma técnica de balão proprietária que fornece um desempenho previsível que se
aproxima do comportamento de um sistema nativo sob restrições de memória semelhantes.
Essa técnica aumenta ou diminui a pressão da memória no sistema operacional guest, fazendo
com que o guest use seus próprios algoritmos de gerenciamento de memória nativa. Quando
a memória está fraca, o sistema operacional guest determina quais páginas devem ser
recuperadas e, se necessário, as troca para seu próprio disco virtual.
Figura 6-1. Balão de memória no sistema operacional guest
memory
swap space
memory
swap space
memory
Observação Você deve configurar o sistema operacional guest com espaço de troca suficiente.
Alguns sistemas operacionais convidados têm limitações adicionais.
Se necessário, você pode limitar a quantidade de memória vmmemctl recuperada definindo

o parâmetro Sched.mem.maxmemctl (sched.mem.maxmemctl) para uma máquina virtual
específica. Essa opção especifica a quantidade máxima de memória que pode ser recuperada de
uma máquina virtual em megabytes (MB). Consulte Definir atributos de máquina virtual avançada.
Usando arquivos de permuta

Você pode especificar a localização do seu arquivo de permuta guest, reservar espaço de
permuta quando a memória é supercomprometida e excluir um arquivo de permuta.
Os hosts ESXi usam a troca para recuperar forçosamente a memória de uma máquina virtual
quando o driver vmmemctl não está disponível ou não responde.
n Ele nunca foi instalado.

n Ele está explicitamente desativado.
n Ele não está em execução (por exemplo, enquanto o sistema operacional guest está sendo
inicializado).
n É temporariamente incapaz de recuperar a memória com rapidez suficiente para satisfazer as

demandas atuais do sistema.
n Está funcionando corretamente, mas o tamanho máximo do balão foi atingido.
As técnicas de paginação por demanda padrão alternam as páginas quando a máquina virtual
precisa delas.
Localização do arquivo de permuta

Por padrão, o arquivo de permuta é criado no mesmo local que o arquivo de configuração da
máquina virtual, que pode estar em um repositório de dados VMFS, um repositório de dados
vSAN ou um repositório de dados VMware vSphere® Virtual VolumesTM. Em um repositório de
dados vSAN ou um repositório de dados vVols, o arquivo de permuta é criado como um objeto
vSAN ou vVols separado.
O host ESXi cria um arquivo de permuta quando uma máquina virtual é ligada. Se esse arquivo
não puder ser criado, a máquina virtual não poderá ser ligada. Em vez de aceitar o padrão, você
também pode:
n Use as opções de configuração por máquina virtual para alterar o repositório de dados para
outro local de armazenamento compartilhado.
n Use a permuta host-local, que permite que você especifique um datastore armazenado
localmente no host. Isso permite a troca em um nível por host, economizando espaço na
SAN. No entanto, isso pode levar a uma leve degradação no desempenho do vSphere
vMotion porque as páginas trocadas para um arquivo de permuta local no host de origem
devem ser transferidas pela rede para o host de destino. Atualmente, vSAN e os datastores
de vVols não podem ser especificados para a permuta host-local.
Ativar permuta host-local para um cluster do DRS

A permuta host-local permite que você especifique um datastore armazenado localmente no
host como a localização do arquivo de permuta. Você pode ativar a permuta host-local para um
cluster do DRS.
Procedimentos
1 Navegue até o cluster no vSphere Client.
3 Em Configuração (Configuration), selecione Geral (General) para exibir a localização do

arquivo de permuta e clique em Editar (Edit) para alterá-la.
4 Selecione a opção Datastore especificado pelo host (Datastore specified by host) e clique
em OK (OK).

5 Navegue até um dos hosts do cluster no vSphere Client.
7 Em Máquinas Virtuais, selecione Alternar local do arquivo (Swap file location).
8 Clique em Editar e selecione o datastore local a ser usado e clique em OK (OK).
9 Repita Etapa 5 a Etapa 8 para cada host no cluster.
Resultados
A permuta host-local agora está habilitada para o cluster do DRS.
Habilitar permuta host-local para um host autônomo

A permuta host-local permite que você especifique um datastore armazenado localmente no
host como a localização do arquivo de permuta. Você pode ativar a permuta host-local para um
host autônomo.
Procedimentos
3 Em Máquinas Virtuais (Virtual Machines), selecione Alternar local do arquivo (Swap file
location).
4 Clique em Editar (Edit) e selecione Repositório de dados selecionado (Selected Datastore).
5 Selecione um datastore local na lista e clique em OK (OK).
Resultados
A permuta host-local agora está ativada para o host independente.
Excesso de compromissos de espaço de permuta e memória

Você deve reservar espaço de permuta para qualquer memória de máquina virtual não
reservada (a diferença entre a reserva e o tamanho da memória configurada) em arquivos de
permuta por máquina virtual.
Essa reserva de permuta é necessária para garantir que o host ESXi possa preservar a memória
da máquina virtual em quaisquer circunstâncias. Na prática, apenas uma pequena fração do
espaço de permuta no nível do host pode ser usada.

Se você estiver comprometendo demais a memória com ESXi, para oferecer suporte à troca
entre convidados induzida por balonismo, certifique-se de que seus sistemas operacionais
convidados também tenham espaço de troca suficiente. Esse espaço de permuta no nível de
convidado deve ser maior ou igual à diferença entre o tamanho da memória configurada da
máquina virtual e sua Reserva.
Cuidado Se a memória for supercomprometida e o sistema operacional convidado estiver

configurado com espaço de troca insuficiente, o sistema operacional convidado na máquina
virtual poderá falhar.
Para evitar falhas na máquina virtual, aumente o tamanho do espaço de permuta nas suas
máquinas virtuais.
n Sistemas operacionais convidados Windows - Os sistemas operacionais Windows se referem

ao espaço de permuta como arquivos de paginação. Alguns sistemas operacionais Windows
tentam aumentar o tamanho dos arquivos de paginação automaticamente, se houver espaço
livre em disco suficiente.
Consulte a documentação do Microsoft Windows ou pesquise nos arquivos de ajuda do

Windows "arquivos de paginação". Siga as instruções para alterar o tamanho do arquivo de
paginação da memória virtual.
n Sistema operacional convidado Linux - Os sistemas operacionais Linux se referem ao espaço

de permuta como arquivos de permuta. Para obter informações sobre o aumento de
arquivos de permuta, consulte as seguintes páginas do manual do Linux:
n mkswap - Configura uma área de permuta do Linux.
n swapon - Ativa dispositivos e arquivos para paginação e troca.
Os sistemas operacionais convidados com muita memória e pequenos discos virtuais (por
exemplo, uma máquina virtual com 8 GB de RAM e um disco virtual de 2 GB) são mais suscetíveis
a ter espaço de permuta insuficiente.
Observação Não armazene arquivos de permuta em LUNs com provisionamento dinâmico. A

execução de uma máquina virtual com um arquivo de permuta armazenado em um LUN com
provisionamento dinâmico pode causar falha no crescimento do arquivo de permuta, o que pode
levar ao encerramento da máquina virtual.
Quando você cria um arquivo de permuta grande (por exemplo, maior que 100 GB), o tempo
necessário para a máquina virtual ser ligada pode aumentar significativamente. Para evitar isso,
defina uma reserva alta para máquinas virtuais grandes.
Você também pode colocar arquivos de permuta em um armazenamento menos dispendioso

usando arquivos de permuta de host local.

Configurar as propriedades do arquivo de permuta da máquina

virtual para o host
Configure uma localização de arquivo de permuta para o host para determinar a localização
padrão para os arquivos de permuta da máquina virtual no vSphere Client.
Por padrão, os arquivos de permuta para uma máquina virtual estão localizados em um
repositório de dados na pasta que contém os outros arquivos da máquina virtual. No entanto,
você pode configurar seu host para colocar arquivos de permuta da máquina virtual em um
repositório de dados alternativo.
Você pode usar essa opção para colocar arquivos de permuta da máquina virtual em um
armazenamento de baixo custo ou desempenho superior. Você também pode substituir essa
configuração de nível de host para máquinas virtuais individuais.
Definir uma localização alternativa do arquivo de permuta pode fazer com que as migrações
com o vMotion sejam concluídas mais lentamente. Para obter o melhor desempenho do vMotion,
armazene a máquina virtual em um repositório de dados local em vez de no mesmo diretório
que os arquivos de permuta da máquina virtual. Se a máquina virtual estiver armazenada em um
repositório de dados local, o armazenamento do arquivo de permuta com os outros arquivos da
máquina virtual não melhorará o vMotion.
Pré-requisitos
Privilégio necessário: Máquina host . Configuração . Configuração da partição de

armazenamento
Procedimentos
3 Em Máquinas Virtuais (Virtual Machines), clique em Alternar local do arquivo (Swap file
location).
A localização do arquivo de permuta selecionado é exibida. Se a configuração do local do

arquivo de permuta não tiver suporte no host selecionado, a guia indicará que o recurso não
tem suporte.
Se o host fizer parte de um cluster, e as configurações do cluster especificarem que os

arquivos de permuta devem ser armazenados no mesmo diretório da máquina virtual, não
será possível editar a localização do arquivo de permuta do host em Configurar (Configure).
Para alterar a localização do arquivo de permuta para esse host, edite as configurações do
cluster.
4 Clique em Editar(Edit).

5 Selecione onde armazenar o arquivo de permuta.
Opção Descrição
Diretório da máquina virtual Armazena o arquivo de permuta no mesmo diretório que o arquivo de
configuração da máquina virtual.
Usar um repositório de dados Armazena o arquivo de permuta na localização especificada.

específico Se o swapfile não puder ser armazenado no repositório de dados
especificado pelo host, o swapfile será armazenado na mesma pasta que
a máquina virtual.
6 (Opcional) Se você selecionar Usar um datastore específico (Use a specific datastore),

selecione um datastore na lista.
Resultados
O arquivo de permuta da máquina virtual é armazenado no local selecionado.
Configurar uma localização de arquivo de permuta da máquina

virtual para um cluster
Por padrão, os arquivos de permuta para uma máquina virtual estão em um repositório de dados
na pasta que contém os outros arquivos de máquina virtual. No entanto, você pode configurar os
hosts no seu cluster para colocar arquivos de permuta de máquina virtual em um repositório de
dados alternativo de sua escolha.
Você pode configurar um local de arquivo de permuta alternativo para colocar arquivos de
permuta de máquina virtual em um armazenamento de baixo custo ou de alto desempenho,
dependendo de suas necessidades.
Pré-requisitos
Antes de configurar uma localização de arquivo de permuta de máquina virtual para um cluster,
você deve configurar as localizações de arquivo de permuta de máquina virtual para os hosts
no cluster, conforme descrito em Configurar as propriedades do arquivo de permuta da máquina
virtual para o host.
Procedimentos
3 Selecione Configuração (Configuration) > Geral (General).
4 Ao lado de para trocar o local do arquivo, clique em Editar (Edit).

5 Selecione onde armazenar o arquivo de permuta.
Opção Descrição
Diretório da máquina virtual Armazena o arquivo de permuta no mesmo diretório que o arquivo de
configuração da máquina virtual.
Datastore especificado pelo host Armazena o arquivo de permuta na localização especificada na configuração
do host.
Se o arquivo de permuta não puder ser armazenado no datastore
especificado pelo host, o arquivo de permuta será armazenado na mesma
pasta que a máquina virtual.
Apagar arquivos de permuta

Se um host falhar, e esse host tiver máquinas virtuais em execução que estavam usando arquivos
de permuta, esses arquivos de permuta continuarão a existir e consumirão muitos gigabytes de
espaço em disco. Você pode excluir os arquivos de permuta para eliminar esse problema.
Procedimentos
1 Reinicie a máquina virtual que estava no host que falhou.
2 Pare a máquina virtual.
Resultados
O arquivo de permuta para a máquina virtual é excluído.
Compartilhando memória entre máquinas virtuais

Muitas ESXi cargas de trabalho apresentam oportunidades para compartilhar memória entre
máquinas virtuais (bem como em uma única máquina virtual).
ESXi compartilhamento de memória é executado como uma atividade em segundo plano que
procura oportunidades de compartilhamento ao longo do tempo. A quantidade de memória
salva varia ao longo do tempo. Para uma carga de trabalho razoavelmente constante, a
quantidade geralmente aumenta devagar até que todas as oportunidades de compartilhamento
sejam exploradas.
Para determinar a eficácia do compartilhamento de memória para uma determinada carga de

trabalho, tente executá-la e use resxtop ou esxtop para observar a economia real. Encontre as
informações no campo PSHARE do modo interativo na página Memória.
Use as configurações avançadas Mem.ShareScanTime e Mem.ShareScanGHz para controlar a

taxa na qual o sistema verifica a memória para identificar oportunidades de compartilhamento de
memória.
Você também pode configurar o compartilhamento para máquinas virtuais individuais definindo a
opção sched.mem.pshare.enable .

Devido a preocupações de segurança, o compartilhamento de páginas transparentes entre

máquinas virtuais é desativado por padrão, e o compartilhamento de páginas está sendo
restrito ao compartilhamento de memória dentro da máquina virtual. Isso significa que o
compartilhamento de páginas não ocorre entre máquinas virtuais e ocorre apenas dentro de
uma máquina virtual. O conceito de salga foi introduzido para ajudar a resolver problemas que os
administradores de sistema podem ter sobre as implicações de segurança do compartilhamento
transparente de páginas. A salga pode ser usada para permitir um gerenciamento mais granular
das máquinas virtuais que participam do compartilhamento de página transparente do que
era anteriormente possível. Com as novas configurações de salga, as máquinas virtuais podem
compartilhar páginas somente se o valor e o conteúdo das páginas forem idênticos. Uma nova
opção de configuração do host Mem.ShareForceSalting pode ser configurada para ativar ou
desativar a salga.
Consulte Capítulo 17 Atributos avançados para obter informações sobre como definir opções
avançadas.
Compressão de memória
ESXi fornece um cache de compactação de memória para melhorar o desempenho da máquina
virtual quando você usa o comprometimento excessivo da memória. A compactação de memória
está ativada por padrão. Quando a memória de um host fica supercomprometida, ESXi compacta
as páginas virtuais e as armazena na memória.
Como o acesso à memória compactada é mais rápido do que o acesso à memória que é
trocada para o disco, a compactação de memória em ESXi permite que você comprometa
demais a memória sem prejudicar significativamente o desempenho. Quando uma página virtual
precisa ser trocada, ESXi primeiro tenta compactar a página. As páginas que podem ser
compactadas para 2 KB ou menos são armazenadas no cache de compactação da máquina
virtual, aumentando a capacidade do host.
Você pode definir o tamanho máximo para o cache de compactação e desativar a compactação
de memória usando a caixa de diálogo Configurações avançadas no vSphere Client.
Ativar ou desativar o cache de compactação de memória

A compactação de memória está ativada por padrão. Você pode usar as Configurações
avançadas do sistema no vSphere Client para ativar ou desativar a compactação de memória
para um host.
Procedimentos

Settings).
4 Localize Mem.MemZipEnable e clique no botão Editar (Edit).

5 Insira 1 para ativar ou 0 para desativar o cache de compactação de memória.
Definir o tamanho máximo do cache de compactação de memória

Você pode definir o tamanho máximo do cache de compactação de memória para as máquinas
virtuais do host.
Você define o tamanho do cache de compactação como uma porcentagem do tamanho da

memória da máquina virtual. Por exemplo, se você inserir 20 e o tamanho da memória de uma
máquina virtual for 1000 MB, ESXi poderá usar até 200 MB de memória do host para armazenar
as páginas compactadas da máquina virtual.
Se você não definir o tamanho do cache de compactação, ESXi usará o valor padrão de 10 por
cento.
Procedimentos

Settings).
4 Localize Mem.MemZipMaxPct e clique no botão Editar (Edit).
O valor desse atributo determina o tamanho máximo do cache de compactação para a

máquina virtual.
5 Insira o tamanho máximo para o cache de compactação.
O valor é uma porcentagem do tamanho da máquina virtual e deve estar entre 5 e 100 por
cento.
Medindo e diferenciando tipos de uso de memória

A guia Desempenho (Performance) do vSphere Client exibe várias métricas que podem ser
usadas para analisar o uso da memória.
Algumas dessas métricas de memória medem a memória física do convidado, enquanto outras
medem a memória da máquina. Por exemplo, dois tipos de uso de memória que você pode
examinar usando métricas de desempenho são a memória física guest e a memória da máquina.
Você mede a memória física do convidado usando a métrica Memória concedida (para uma
máquina virtual) ou Memória compartilhada (para um host). Para medir a memória da máquina,
no entanto, use Memória consumida (para uma máquina virtual) ou Memória compartilhada
comum (para um host). É importante compreender a diferença conceitual entre esses tipos de
uso de memória para saber o que essas métricas estão medindo e como interpretá-las.

O VMkernel mapeia a memória física do convidado para a memória da máquina, mas elas
nem sempre são mapeadas de um para um. Várias regiões da memória física guest podem
ser mapeadas para a mesma região da memória da máquina (quando o compartilhamento de
memória) ou regiões específicas da memória física guest podem não ser mapeadas para a
memória da máquina (quando o VMkernel troca ou balança a memória física guest). Nessas
situações, os cálculos do uso de memória física do convidado e do uso de memória da máquina
para uma máquina virtual individual ou um host são diferentes.
Considere o exemplo da figura a seguir, que mostra duas máquinas virtuais em execução em
um host. Cada bloco representa 4 KB de memória e cada cor / letra representa um conjunto
diferente de dados em um bloco.
Figura 6-2. Exemplo de uso de memória

virtual machine virtual machine
1 2
a b c a c b d f e guest virtual memory
a b a c c b d f e guest physical memory
a b c d e f machine memory
As métricas de desempenho para as máquinas virtuais podem ser determinadas da seguinte

maneira:
n Para determinar a Memória concedida (a quantidade de memória física convidada que é

mapeada para a memória da máquina) para a máquina virtual 1, conte o número de blocos na
memória física convidada da máquina virtual 1 que tenham setas na memória da máquina e
multiplique por 4 KB. Como há cinco blocos com setas, a Memória concedida é de 20 KB.
n Memória consumida é a quantidade de memória da máquina alocada para a máquina virtual,

representando economia da memória compartilhada. Primeiro, conte o número de blocos na
memória da máquina que têm setas da memória física convidada da máquina virtual 1. Há três
desses blocos, mas um bloco é compartilhado com a máquina virtual 2. Portanto, conte dois
blocos completos mais a metade do terceiro e multiplique por 4 KB para um total de 10 KB de
memória consumida.
A diferença importante entre essas duas métricas é que a Memória concedida conta o número
de blocos com setas no nível da memória física do convidado e Memória consumida conta o
número de blocos com setas no nível de memória da máquina. O número de blocos difere entre
os dois níveis devido ao compartilhamento de memória e, portanto, a Memória concedida e a
Memória consumida diferem. A memória está sendo salva por meio do compartilhamento ou de
outras técnicas de recuperação.

Um resultado semelhante é obtido ao determinar a Memória Compartilhada e a Memória

Compartilhada Comum para o host.
n A Memória Compartilhada para o host é a soma da Memória Compartilhada de cada máquina

virtual. Calcule a memória compartilhada observando a memória física convidada de cada
máquina virtual e contando o número de blocos que têm setas para blocos de memória de
máquina que possuem mais de uma seta apontando para eles. Há seis desses blocos no
exemplo, então a Memória Compartilhada para o host tem 24 KB.
n Memória comum compartilhada é a quantidade de memória da máquina compartilhada por

máquinas virtuais. Para determinar a memória comum, observe a memória da máquina e
conte o número de blocos que têm mais de uma seta apontando para eles. Há três desses
blocos, portanto, Memória Compartilhada Comum é de 12 KB.
A memória compartilhada se preocupa com a memória física do convidado e examina a origem

das setas. A Memória Compartilhada Comum, no entanto, lida com a memória da máquina e
examina o destino das setas.
As métricas de memória que medem a memória física do convidado e a memória da máquina

podem parecer contraditórias. Na verdade, eles estão medindo diferentes aspectos do uso de
memória de uma máquina virtual. Ao compreender as diferenças entre essas métricas, você
pode usá-las melhor para diagnosticar problemas de desempenho.
Confiabilidade da Memória
A confiabilidade da memória, também conhecida como isolamento de erro, permite que ESXi
pare de usar partes da memória quando determina que uma falha pode ocorrer, bem como
quando ocorreu uma falha.
Quando erros corrigidos suficientes são relatados em um endereço específico, ESXi para de usar
esse endereço para evitar que o erro corrigido se torne um erro não corrigido.
A confiabilidade da memória fornece melhor confiabilidade do VMkernel, apesar dos erros

corrigidos e não corrigidos na RAM. Ele também permite que o sistema evite o uso de páginas de
memória que podem conter erros.
Corrigindo uma notificação de isolamento de erro

Com a confiabilidade da memória, o VMkernel para de usar páginas que recebem uma
notificação de isolamento de erro.
O usuário recebe um evento no vSphere Client quando o VMkernel se recupera de um erro de

memória não corrigível, quando o VMkernel retira uma porcentagem significativa da memória do
sistema devido a um grande número de erros corrigíveis ou se há um grande número de páginas
que não conseguem aposentar.
Procedimentos
1 Desative o host.

2 Migre as máquinas virtuais.
3 Execute testes de hardware relacionados à memória.
Sobre a permuta do sistema

A troca do sistema é um processo de recuperação de memória que pode tirar proveito dos
recursos de memória não utilizados em todo o sistema.
A troca do sistema permite que o sistema recupere memória de consumidores de memória que
não são máquinas virtuais. Quando a troca do sistema está ativada, você tem uma compensação
entre o impacto de recuperar a memória de outro processo e a capacidade de atribuir a memória
a uma máquina virtual que pode usá-la. A quantidade de espaço necessária para a troca do
sistema é de 1 GB.
A memória é recuperada retirando dados da memória e gravando-os no armazenamento em

segundo plano. Acessar os dados do armazenamento em segundo plano é mais lento do que
acessar dados da memória, por isso é importante selecionar cuidadosamente onde armazenar os
dados trocados.
ESXi determina automaticamente onde a permuta do sistema deve ser armazenada. Esta é a
localização do arquivo de permuta preferencial (Preferred swap file location). Essa decisão
pode ser auxiliada selecionando um determinado conjunto de opções. O sistema seleciona a
melhor opção ativada possível. Se nenhuma das opções for viável, a troca do sistema não será
ativada.
As opções disponíveis são:
n Datastore - Permite o uso do datastore especificado. Observe que um repositório de dados

vSAN ou VMware vSphere® Virtual VolumesTM não pode ser especificado para arquivos de
permuta do sistema.
n Host Swap Cache - Permite o uso de parte do host swap cache.
n Local do arquivo de permuta preferido - Permite o uso do local do arquivo de permuta

preferido configurado para o host.
Configurar a permuta do sistema

Você pode personalizar as opções que determinam a localização de troca do sistema.
Pré-requisitos
Marque a caixa de seleção Ativado (Enabled) na caixa de diálogo Editar configurações de

permuta do sistema .
Procedimentos

3 Em Sistema (System), selecione Troca de Sistema (System Swap).
5 Marque as caixas de seleção para cada opção que você deseja ativar.
6 Se você selecionar a opção Repositório de dados (datastore), selecione um repositório de

dados no menu suspenso.

Memória persistente
7
A memória persistente (PMem), também conhecida como memória não volátil (NVM), é capaz de
manter dados mesmo após uma queda de energia. O PMem pode ser usado por aplicativos que
são sensíveis ao tempo de inatividade e exigem alto desempenho.
As VMs podem ser configuradas para usar o PMem em um host autônomo ou em um

cluster. PMem é tratado como um armazenamento de dados local. A memória persistente
reduz significativamente a latência de armazenamento. No ESXi, você pode criar VMs que
são configuradas com o PMem, e os aplicativos dentro dessas VMs podem tirar proveito
dessa velocidade maior. Quando uma VM é ligada inicialmente, o PMem é reservado para ela,
independentemente de estar ligada ou desligada. Este PMem permanece reservado até que a
VM seja migrada ou removida.
A memória persistente pode ser consumida por máquinas virtuais em dois modos diferentes. Os
sistemas operacionais convidados legados ainda podem tirar proveito do recurso de disco de
memória persistente virtual.
n Memória Persistente Virtual (vPMem) (Virtual Persistent Memory (vPMem))
Usando o vPMem, a memória é exposta a um sistema operacional convidado como um

NVDIMM virtual. Isso permite que o sistema operacional convidado use o PMem no modo
aleatório endereçável por bytes.
Observação Você deve usar o hardware da VM versão 14 e um sistema operacional

convidado que ofereça suporte à tecnologia NVM.
Observação Você deve usar o hardware da VM versão 19 ao configurar o vSphere HA para

VMs do PMem. Para obter mais informações, consulte Configurar vSphere HA para VMs de
PMem.
n Disco de memória persistente virtual (vPMemDisk) (Virtual Persistent Memory Disk

(vPMemDisk))
Usando o vPMemDisk, a memória pode ser acessada pelo sistema operacional convidado
como um dispositivo SCSI virtual, mas o disco virtual é armazenado em um datastore PMem.
Quando você cria uma VM com o PMem, a memória é reservada para ela no momento da criação
do disco rígido. O controle de admissão também é feito no momento da criação do disco rígido.
Para obter mais informações, consulte vSphere HA Controle de admissão PMem Reserva.

Em um cluster, cada VM tem alguma capacidade para PMem. A quantidade total de PMem não
deve ser maior que a quantidade total disponível no cluster. O consumo de PMem inclui VMs
ligadas e desligadas. Se uma VM estiver configurada para usar o PMem e você não usar o DRS,
deverá escolher manualmente um host que tenha PMem suficiente para colocar a VM.
NVDIMM e armazenamento tradicional (NVDIMM and traditional storage)
O NVDIMM é acessado como memória. Quando você usa o armazenamento tradicional, existe
software entre aplicativos e dispositivos de armazenamento, o que pode causar um atraso no
tempo de processamento. Quando você usa o PMem, os aplicativos usam o armazenamento
diretamente. Isso significa que o desempenho do PMem é melhor do que o armazenamento
tradicional. O armazenamento é local para o host. No entanto, como o software do sistema não
pode rastrear as alterações, soluções como backups não funcionam atualmente com o PMem.
Soluções como vSphere HA terão escopo limitado se o vPMem for usado em um modo que
não seja de gravação para um armazenamento de dados não-PMem. Quando vSphere HA está
ativado para VMs do vPMem com failover ativado, a VM pode ser transferida para um host
diferente. Quando isso acontece, a VM está usando os recursos do PMem no novo host. Para
liberar os recursos no host antigo, um coletor de lixo periodicamente identifica e libera esses
recursos para uso por outras VMs.
Namespaces (Name spaces)
Espaços de nomes para PMem são configurados antes do início de ESXi. Os espaços de nome
são semelhantes aos discos no sistema. ESXi lê espaços de nome e combina vários espaços de
nome em um volume lógico gravando cabeçalhos GPT. Ele é formatado automaticamente por
padrão, se você não o tiver configurado anteriormente. Se já tiver sido formatado, o ESXi tentará
montar o PMem.
Tabelas GPT (GPT tables)
Se os dados no armazenamento do PMem estiverem corrompidos, o ESXi poderá falhar. Para

evitar isso, o ESXi verifica se há erros nos metadados durante o tempo de montagem do PMem.
PMem regiões (PMem regions)
As regiões PMem são um fluxo contínuo de bytes que representam um único vNVDimm ou
vPMemDisk. Cada volume PMem pertence a um único host. Isso pode ser difícil de gerenciar se
um administrador tiver que gerenciar cada host em um cluster com um grande número de hosts.
No entanto, você não precisa gerenciar cada repositório de dados individual. Em vez disso, você
pode pensar em toda a capacidade do PMem no cluster como um armazenamento de dados.
O VC e o DRS automatizam o posicionamento inicial de datastores PMem. Selecione um perfil de

armazenamento de PMem local quando a VM for criada ou quando o dispositivo for adicionado à
VM. O restante da configuração é automatizado. Uma limitação é que ESXi não permite que você
coloque a VM home em um datastore PMem. Isso ocorre porque ele ocupa um espaço valioso
para armazenar arquivos de log e estatísticas da VM. Essas regiões são usadas para representar
os dados da VM e podem ser expostas como nvDimms endereçáveis por byte ou discos VpMem.
Migração(Migration)

Como o PMem é um armazenamento de dados local, se você quiser mover uma VM, deverá usar
o Storage vMotion. Uma VM com vPMem só pode ser migrada para um host ESX com recurso
PMem. Uma VM com vPMemDisk pode ser migrada para um host ESX sem um recurso PMem.
Tratamento de erros e gerenciamento de NVDimm (Error handling and NVDimm management)
Falhas de host podem resultar em perda de disponibilidade em VMs do vPMem que não estão no
modo write-through. No caso de erros catastróficos, você pode perder todos os dados e deve
tomar medidas manuais para reformatar o PMem.
Memória persistente do vSphere com o vSphere Client

Para uma breve introdução conceitual à memória persistente, consulte:
Memória persistente do vSphere com o vSphere Client
(http://link.brightcove.com/services/player/bcpid2296383276001?
bctid=ref:video_vsphere67U2_pmem)
Aprimoramentos para trabalhar com o PMEM no vSphere

Client
Para obter uma breve visão geral dos aprimoramentos no vSphere Client baseado em HTML5 ao
trabalhar com o PMem, consulte:
Aprimoramentos para trabalhar com o PMEM no vSphere Client
bctid=ref:video_vsphere67_PMEM1)
Migrando e clonando VMs usando o PMEM no vSphere

Client
Para obter uma breve visão geral da migração e clonagem de máquinas virtuais que usam o
PMem, consulte:
Migrando e clonando VMs usando o PMEM no vSphere Client
bctid=ref:video_vsphere67_clonePMEM)
n Configurar vSphere HA para VMs de PMem
n vSphere HA Controle de admissão PMem Reserva
n Monitoramento e correção de memória do vSphere
Configurar vSphere HA para VMs de PMem

Você pode configurar o vSphere HA para VMs de PMem no modo write-through, para que,
quando um host falhar, as VMs possam ser restauradas em outro host em funcionamento.

Pré-requisitos
n Você deve selecionar a versão 19 do hardware.
n Não há suporte para VMs de PMem com vPMemDisks.
Procedimentos
1 Ao criar uma nova VM no assistente de Nova Máquina Virtual , selecione Personalizar

hardware (Customize hardware).
a Clique em ADICIONAR NOVO DISPOSITIVO (ADD NEW DEVICE) e selecione Adicionar

NVDIMM (Add NVDIMM) no menu suspenso.
b Clique na caixa de seleção Allow failover on another host for all NVDIMM devices (Allow
failover on another host for all NVDIMM devices).
c Clique em NEXT (NEXT) e conclua o assistente New Virtual Machine .
Em caso de falha do host, os dados NVDIMM PMem não podem ser recuperados. Por
padrão, o HA não tentará reiniciar esta máquina virtual em outro host. Permitir que o HA
em caso de falha do host faça o failover da máquina virtual reiniciará a máquina virtual em
outro host com um novo NVDIMM vazio.
2 Para habilitar o HA em uma VM existente, navegue até a VM.
a Em VM Hardware (VM Hardware), clique em EDIT (EDIT).
b Selecione o NVDIMM.
c Clique na caixa de seleção Allow failover on another host for all NVDIMM devices (Allow
failover on another host for all NVDIMM devices).
d Clique em Okey(OK).
Em caso de falha do host, o HA reiniciará esta máquina virtual em outro host com
NVDIMMs novos e vazios.
vSphere HA Controle de admissão PMem Reserva

O controle de admissão é uma política usada pelo vSphere HA para garantir a capacidade de
failover em um cluster.
Aumentar o número de possíveis falhas de host a serem toleradas aumentará as restrições de

disponibilidade e a capacidade reservada. Você pode reservar uma porcentagem da memória
persistente para a capacidade de failover do host. Esta é a capacidade de armazenamento real
que está bloqueada e deve ser considerada para desligar o host.
Em Edit Cluster Settings , você pode selecionar Admission Control (Admission Control) para
especificar o número de falhas que o host tolerará.

Se você selecionar reserva de CPU / memória definida por:
n Porcentagem de recursos do cluster (Cluster resource percentage), alguma quantidade de

capacidade de memória persistente no cluster é dedicada para fins de failover, mesmo se
as máquinas virtuais no cluster não estiverem usando memória persistente no momento.
Essa porcentagem pode ser especificada por meio de uma substituição ou é calculada
automaticamente de acordo com a configuração de falhas de host para tolerar (host failures
to tolerate). Quando o controle de admissão do PMem está ativado, a capacidade do PMem
é reservada em todo o cluster, mesmo se houver VMs usando o PMem como discos.
n Política de Slot (VMs ligadas) (Slot Policy (powered-on VMs)), o controle de admissão
de memória persistente substitui a Política de Slot pela política de Porcentagem de
Recurso de Cluster, somente para recursos de memória persistente. O valor percentual
é calculado automaticamente a partir da configuração host failures cluster (host failures
cluster tolerates) e não pode ser substituído.
n Hosts de failover dedicados (Dedicated failover hosts), a memória persistente dos hosts de
failover dedicados é dedicada para fins de failover e você não pode provisionar máquinas
virtuais com memória persistente nesses hosts.
Observação Depois de selecionar uma política de controle de admissão, você também deve
clicar na caixa de seleção Reserve Persistent Memory failover capacity (Reserve Persistent
Memory failover capacity) para habilitar o controle de admissão do PMem.
Monitoramento e correção de memória do vSphere

O vMMR coleta dados e fornece visibilidade das estatísticas de desempenho para que você
possa determinar se a carga de trabalho do aplicativo é regredida devido ao modo de memória.
A Memória Persistente Intel Optane pode ser configurada nas configurações do BIOS no Modo
Direto do Aplicativo ou no Modo de Memória. No modo App Direct, a memória persistente pode
ser acessada como memória persistente endereçável em bytes juntamente com a DRAM. No
modo de memória, a DRAM se torna o cache de hardware e o PMem maior se torna volátil e
aparece como memória do sistema.
O modo de memória é invisível e transparente para as VMs. Depois de configurar o sistema

no modo de memória, o sistema aparece como um sistema tradicional com DRAM. Um
cluster pode ter uma combinação de hosts com diferentes configurações. O vSphere mostra
informações adicionais sobre o sistema estar no modo de memória. O ESXi programa contadores
de desempenho que coletam informações sobre estatísticas de nível de host e VM. Essas
estatísticas de desempenho são usadas para criar alarmes. As estatísticas também são
rastreadas em gráficos de desempenho.
Você pode descobrir se o sistema está no Modo de Memória na guia Resumo (Summary)
do host, Camada de Memória: Hardware com alguns detalhes adicionais (Memory Tiering:
Hardware with some additional details).

Você também pode visualizar o tamanho da DRAM e do PMEM em Configurar (Configure) >
Hardware (Hardware) > Visão geral (Overview) > Memória (Memory).
ESXi reúne e expõe dois tipos de estatísticas de memória:
n Estatísticas de nível de host: um subcomponente de memória mede o desempenho de DRAM

e PMem programando contadores de desempenho. As estatísticas de nível de host são total,
largura de banda de leitura / gravação, latência de leitura / gravação e taxa de falha para os
diferentes tipos de memória (DRAM, PMem).
n Estatísticas de nível de VM: o vSphere monitora os contadores de desempenho para obter

dados na largura de banda de leitura de DRAM e PMEM da VM.
O host e a VM têm um novo painel de memória em gráficos de desempenho. Isso mostra os

detalhes da memória, como a utilização da memória e a recuperação da memória, juntamente
com novas estatísticas. No nível do host ESXi, você pode monitorar os gráficos de Largura
de banda de memória e Taxa de perda de memória. No nível da VM, você pode visualizar a
largura de banda de leitura do PMem e a largura de banda de leitura da DRAM. Os gráficos de
desempenho avançados podem ser usados para traçar seletivamente qualquer nova estatística.
Por exemplo, você pode monitorar a latência de leitura / gravação e a taxa de erros.

Na guia VMs (VMs) de um host do ESXi, você pode visualizar uma lista contendo informações
de desempenho sobre todas as máquinas virtuais que residem no host. Para exibir informações
sobre o impacto do Modo de Memória em uma máquina virtual, clique no ícone de exibição de
colunas ( ) e selecione as métricas Memória Ativa, Largura de Banda de Leitura de DRAM e

Largura de Banda de Leitura de PMem ...
Há dois alarmes padrão pré-configurados, um no nível do host (Modo de memória do host

High Active DRAM Usage) e outro no nível da VM (Virtual Machine High PMem Bandwidth
Usage). Se a condição de alarme for atendida, um evento será publicado para disparar o
alarme correspondente. Você também pode criar alarmes personalizados com base em métricas
de desempenho. Os alarmes do vMMR só funcionam em hosts configurados com o modo de
memória.
Quando o DRS está ativado e totalmente automatizado no cluster, se a utilização da memória

ativa do host estiver acima de uma determinada porcentagem do tamanho do cache DRAM, o
DRS poderá mover algumas VMs para fora do host para equilibrar a carga.
Para obter mais informações, consulte vSphere Monitoring and Performance .
Observação O vMMR é compatível com as plataformas Intel Broadwell, Skylake, Cascade Lake
e Ice Lake. As estatísticas de DRAM de nível de host estão disponíveis nessas plataformas. As
estatísticas de nível de host e VM PMem estão disponíveis apenas nos hosts Cascade Lake e Ice
Lake configurados no modo de memória.

Configurando gráficos virtuais
8
Você pode editar as configurações de gráficos para implementações de gráficos compatíveis.
O vSphere oferece suporte a várias implementações de gráficos.
n VMware é compatível com soluções de gráficos 3D da AMD, Intel e NVIDIA.
n Suporte para NVIDIA GRID.
n Permite que o único NVIDIA vib suporte as implementações vSGA e vGPU.
n Fornece gráficos de desempenho do vCenter GPU para Intel e NVIDIA.
n Habilita gráficos para Horizon View áreas de trabalho VDI.
Você pode definir as configurações de gráficos do host e personalizar as configurações de

gráficos do vGPU por VM.
n Exibir estatísticas de GPU
n Adicionar uma vGPU do NVIDIA GRID a uma máquina virtual
n Configurando gráficos do host
n Configuração de dispositivos gráficos
Exibir estatísticas de GPU

Você pode visualizar informações detalhadas para uma placa gráfica do host.
Você pode ver a temperatura da GPU, a utilização e o uso de memória.
Observação Essas estatísticas são exibidas apenas quando o driver GPU está instalado no host.
Procedimentos
1 No vSphere Client, navegue até o host.
2 Clique na guia Monitor (Monitor) e clique em Desempenho (Performance).
3 Clique em Avançado (Advanced) e selecione GPU (GPU) no menu suspenso.

Adicionar uma vGPU do NVIDIA GRID a uma máquina virtual

Se um host ESXi tiver um dispositivo gráfico NVIDIA GRID GPU, você poderá configurar uma
máquina virtual para usar a tecnologia de GPU virtual (vGPU) NVIDIA GRID.
Os dispositivos gráficos NVIDIA GRID GPU são projetados para otimizar operações gráficas
complexas e permitir que eles sejam executados com alto desempenho sem sobrecarregar a
CPU.
Pré-requisitos
n Verifique se um dispositivo gráfico NVIDIA GRID GPU com um driver apropriado está
instalado no host. Consulte a documentação do vSphere Upgrade .
n Verifique se a máquina virtual é compatível com o ESXi 6.0 e versões posteriores.
Procedimentos
1 Clique com o botão direito do mouse em uma máquina virtual e selecione Editar
configurações (Edit Settings).
2 Na guia Hardware virtual (Virtual Hardware), selecione Adicionar novo dispositivo (Add
New Device) e selecione Novo dispositivo PCI (New PCI Device) no menu suspenso.
3 Expanda Novo dispositivo PCI (New PCI device) e selecione o dispositivo de passagem da
vGPU NVIDIA GRID ao qual deseja conectar sua máquina virtual.
Observação A reserva de memória completa será aplicada automaticamente, é necessária

para o dispositivo PCI.
4 Selecione um perfil de GPU.
Um perfil de GPU representa o tipo de vGPU.
Resultados
A máquina virtual pode acessar o dispositivo.
Configurando gráficos do host

Você pode personalizar as opções de gráficos por host.
Pré-requisitos
As máquinas virtuais devem ser desligadas.
Procedimentos
1 Selecione um host e selecione Configurar (Configure) > Gráficos (Graphics).
2 Em Gráficos do Host (Host Graphics), selecione Editar (Edit).

3 Na janela Editar configurações de gráficos do host , selecione:
Opção Descrição
Compartilhado VMware gráficos virtuais compartilhados
Compartilhado direto Gráficos de passagem compartilhados do fornecedor
4 Selecione uma política de atribuição de GPU de passagem compartilhada.
a Espalhar VMs entre GPUs (melhor desempenho)
b Agrupar VMs na GPU até ficarem cheias (Consolidação de GPU)
Próximo passo
Depois de clicar em OK (OK), você deve reiniciar o Xorg no host.
Configuração de dispositivos gráficos

Você pode editar o tipo de gráficos para uma placa de vídeo.
Pré-requisitos
As máquinas virtuais devem ser desligadas.
Procedimentos
1 Em Dispositivos gráficos (Graphics Devices), selecione uma placa gráfica e clique em Editar
(Edit).
a Selecione Compartilhado (Shared) para VMware gráficos virtuais compartilhados.
b Selecione Compartilhado Direto (Shared Direct) para gráficos de passagem

compartilhada pelo fornecedor.
Resultados
Se você selecionar um dispositivo, ele mostrará quais máquinas virtuais estão usando esse
dispositivo se estiverem ativas.
Próximo passo
Depois de clicar em OK (OK), você deve reiniciar o Xorg no host.

Gerenciando recursos de E / S do
armazenamento 9
O vSphere Storage I/O Control permite a priorização de E / S de armazenamento em todo o
cluster, o que permite uma melhor consolidação da carga de trabalho e ajuda a reduzir os custos
adicionais associados ao provisionamento em excesso.
Storage I/O Control estende as construções de compartilhamentos e limites para manipular

recursos de E / S de armazenamento. Você pode controlar a quantidade de E / S de
armazenamento alocada às máquinas virtuais durante períodos de congestionamento de E / S, o
que garante que as máquinas virtuais mais importantes tenham preferência sobre as máquinas
virtuais menos importantes para a alocação de recursos de E / S.
Quando você habilita Storage I/O Control em um datastore, ESXi começa a monitorar a latência
do dispositivo que os hosts observam ao se comunicar com esse datastore. Quando a latência
do dispositivo excede um limite, o datastore é considerado congestionado, e cada máquina
virtual que acessa esse datastore recebe recursos de E / S alocados na proporção de seus
compartilhamentos. Você define compartilhamentos por máquina virtual. Você pode ajustar o
número para cada um com base na necessidade.
A estrutura de filtro de E / S (VAIO) permite que VMware e seus parceiros desenvolvam filtros
que interceptam E / S para cada VMDK e fornecem a funcionalidade desejada na granularidade
do VMDK. O VAIO funciona junto com o Gerenciamento Baseado em Política de Armazenamento
(SPBM), que permite que você defina as preferências de filtro por meio de uma política de
armazenamento anexada aos VMDKs.
A configuração de Storage I/O Control é um processo de duas etapas:
1 Habilite Storage I/O Control para o datastore.
2 Defina o número de compartilhamentos de E / S de armazenamento e o limite máximo de

operações de E / S por segundo (IOPS) permitido para cada máquina virtual.
Por padrão, todos os compartilhamentos de máquina virtual são definidos como Normal (1000)
com IOPS ilimitado.
Observação Storage I/O Control é habilitado por padrão em clusters de armazenamento de

dados habilitados para DRS de armazenamento.

n Sobre as políticas de armazenamento de máquina virtual
n Sobre os filtros de E / S
n Requisitos do Storage I/O Control
n Storage I/O Control Compartilhamentos de recursos e limites
n Definir Storage I/O Control compartilhamentos e limites de recursos
n Habilitar o Storage I/O Control
n Definir valor do limite Storage I/O Control
n Integração do Storage DRS com perfis de armazenamento
Sobre as políticas de armazenamento de máquina virtual

As políticas de armazenamento de máquina virtual são essenciais para o provisionamento de
máquina virtual. As políticas controlam qual tipo de armazenamento é fornecido para a máquina
virtual, como a máquina virtual é colocada no armazenamento e quais serviços de dados são
oferecidos para a máquina virtual.
O vSphere inclui políticas de armazenamento padrão. No entanto, você pode definir e atribuir
novas políticas.
Você usa a interface de Políticas de Armazenamento da VM para criar uma política de

armazenamento. Ao definir a política, você especifica vários requisitos de armazenamento para
aplicativos que são executados em máquinas virtuais. Você também pode usar políticas de
armazenamento para solicitar serviços de dados específicos, como cache ou replicação, para
discos virtuais.
Você aplica a política de armazenamento ao criar, clonar ou migrar a máquina virtual. Depois de
aplicar a política de armazenamento, o mecanismo de Gerenciamento Baseado em Política de
Armazenamento (SPBM) coloca a máquina virtual em um repositório de dados correspondente e,
em determinados ambientes de armazenamento, determina como os objetos de armazenamento
da máquina virtual são provisionados e alocados dentro do recurso de armazenamento para
garantir o necessário nível de serviço. O SPBM também habilita os serviços de dados solicitados
para a máquina virtual. vCenter Server monitora a conformidade da política e envia um alerta se
a máquina virtual estiver violando a política de armazenamento atribuída.
Consulte vSphere Storage para obter mais informações.
Sobre os filtros de E / S
Os filtros de E / S associados a discos virtuais obtêm acesso direto ao caminho de E / S da
máquina virtual, independentemente da topologia de armazenamento subjacente.

O VMware oferece determinadas categorias de filtros de E / S. Além disso, os filtros de E /

S podem ser criados por terceiros. Normalmente, eles são distribuídos como pacotes que
fornecem um instalador para implantar componentes de filtro em vCenter Server e ESXi clusters
de host.
Quando os filtros de E / S são implantados no cluster ESXi, o vCenter Server configura e registra
automaticamente um provedor de armazenamento de filtro de E / S, também chamado de
provedor VASA, para cada host no cluster. Os provedores de armazenamento se comunicam
com vCenter Server e tornam os serviços de dados oferecidos pelo filtro de E / S visíveis na
interface de Políticas de Armazenamento da VM. Você pode fazer referência a esses serviços de
dados ao definir regras comuns para uma política de VM. Depois de associar os discos virtuais a
essa política, os filtros de E / S são ativados nos discos virtuais.
Consulte vSphere Storage para obter mais informações.
Requisitos do Storage I/O Control

Storage I/O Control tem vários requisitos e limitações.
n Os repositórios de dados habilitados para Storage I/O Control devem ser gerenciados por um
único sistema vCenter Server.
n Storage I/O Control tem suporte no armazenamento conectado ao Fibre Channel, conectado
ao iSCSI e ao NFS. O Raw Device Mapping (RDM) não é compatível.
n O Storage I/O Control não é compatível com repositórios de dados com várias extensões.
n Antes de usar Storage I/O Control em repositórios de dados com suporte de matrizes com
recursos automatizados de armazenamento em camadas, verifique o VMware Storage / SAN
Compatibility Guide para verificar se o seu armazenamento em camadas automatizado foi
certificado para ser compatível com { Storage I/O Control.
Camada de armazenamento automatizada é a capacidade de uma matriz (ou grupo de

matrizes) de migrar LUNs / volumes ou partes de LUNs / volumes para diferentes tipos
de mídia de armazenamento (SSD, FC, SAS, SATA) com base em políticas definidas pelo
usuário e I atual Padrões de / O. Nenhuma certificação especial é necessária para matrizes
que não têm esses recursos de migração / camadas automáticos, incluindo aqueles que
fornecem a capacidade de migrar manualmente dados entre diferentes tipos de mídia de
armazenamento.
Storage I/O Control Compartilhamentos de recursos e

limites
Você aloca o número de compartilhamentos de E / S de armazenamento e o limite máximo
de operações de E / S por segundo (IOPS) permitido para cada máquina virtual. Quando um
congestionamento de E / S de armazenamento é detectado para um datastore, as cargas de
trabalho de E / S das máquinas virtuais que acessam esse datastore são ajustadas de acordo
com a proporção de compartilhamentos de máquinas virtuais que cada máquina virtual tem.

Os compartilhamentos de E / S de armazenamento são semelhantes aos compartilhamentos

usados para alocação de recursos de memória e CPU, descritos em Compartilhamentos de
alocação de recursos. Esses compartilhamentos representam a importância relativa de uma
máquina virtual em relação à distribuição de recursos de E / S de armazenamento. Em contenção
de recursos, as máquinas virtuais com valores de compartilhamento mais altos têm maior acesso
à matriz de armazenamento. Ao alocar recursos de E / S de armazenamento, você pode limitar o
IOPS permitido para uma máquina virtual. Por padrão, o IOPS é ilimitado.
Os benefícios e as desvantagens de definir limites de recursos estão descritos em Limite de

alocação de recursos. Se o limite que você deseja definir para uma máquina virtual for em termos
de MB por segundo em vez de IOPS, você poderá converter MB por segundo em IOPS com base
no tamanho de E / S típico para essa máquina virtual. Por exemplo, para restringir um aplicativo
de backup com E / S de 64 KB a 10 MB por segundo, defina um limite de 160 IOPS.
Visualizar Storage I/O Control compartilhamentos e limites

Você pode exibir os compartilhamentos e os limites para todas as máquinas virtuais em
execução em um repositório de dados. Visualizar essas informações permite comparar as
configurações de todas as máquinas virtuais que estão acessando o repositório de dados,
independentemente do cluster no qual elas estão em execução.
Procedimentos
1 Navegue até o datastore no vSphere Client.
2 Clique na guia VMs (VMs).
A guia exibe cada máquina virtual em execução no repositório de dados e o valor dos
compartilhamentos associados e a porcentagem de compartilhamentos do repositório de
dados.
Monitorar compartilhamentos Storage I/O Control

Use a guia Desempenho Desempenho (Performance) do datastore para monitorar como
Storage I/O Control lida com as cargas de trabalho de E / S das máquinas virtuais que acessam
um datastore com base em seus compartilhamentos.
Os gráficos de desempenho do repositório de dados permitem monitorar as seguintes

informações:
n Latência média e IOPS agregado no repositório de dados
n Latência entre os hosts
n Profundidade da fila entre hosts
n IOPS de leitura / gravação entre hosts
n Latência de leitura / gravação entre discos de máquina virtual
n IOPS de leitura / gravação entre discos de máquina virtual

Procedimentos
2 Na guia Monitor (Monitor), clique em Desempenho (Performance).
3 Selecione Avançado (Advanced).
Definir Storage I/O Control compartilhamentos e limites de

recursos
Aloque recursos de E / S de armazenamento a máquinas virtuais com base na importância
atribuindo uma quantidade relativa de compartilhamentos à máquina virtual.
A menos que as cargas de trabalho da máquina virtual sejam muito semelhantes, os

compartilhamentos não determinam necessariamente a alocação em termos de operações de E /
S ou megabytes por segundo. Compartilhamentos mais altos permitem que uma máquina virtual
mantenha mais operações de E / S simultâneas pendentes no dispositivo de armazenamento ou
no repositório de dados em comparação a uma máquina virtual com compartilhamentos mais
baixos. Duas máquinas virtuais podem experimentar taxa de transferência diferente com base
em suas cargas de trabalho.
Pré-requisitos
Consulte vSphere Storage para obter informações sobre como criar políticas de armazenamento
de VM e definir regras comuns para políticas de armazenamento de VM.
Procedimentos
b Clique na guia VMs (VMs).
(Edit Settings).
3 Clique na guia Hardware virtual (Virtual Hardware) e selecione um disco rígido virtual na
lista. Expandir Disco rígido (Hard disk).
4 Selecione uma política de armazenamento de VM (VM storage policy) no menu suspenso.
Se você selecionar uma política de armazenamento, não configure manualmente (Shares)

Compartilhamentos e Limite - IOPS (Limit - IOPS).
5 Em Compartilhamentos (Shares), clique no menu suspenso e selecione a quantidade relativa

de compartilhamentos a serem alocados para a máquina virtual (Baixa, Normal ou Alta).
Você pode selecionar Personalizado (Custom) para inserir um valor de compartilhamentos

definido pelo usuário.

6 Em Limite - IOPS (Limit - IOPS), clique no menu suspenso e insira o limite superior dos
recursos de armazenamento a serem alocados à máquina virtual.
IOPS são o número de operações de E / S por segundo. Por padrão, o IOPS é ilimitado. Você
seleciona Baixo (500), Normal (1000) ou Alto (2000) ou pode selecionar Personalizado para
inserir um número de compartilhamentos definido pelo usuário.
Habilitar o Storage I/O Control

Quando você habilita Storage I/O Control, ESXi monitora a latência do datastore e limita a carga
de E / S se a latência média do datastore exceder o limite.
Procedimentos
2 Clique na guia Configurar (Configure).
3 Clique em Configurações (Settings) e clique em Geral (General).
4 Clique em Editar (Edit) para Recursos de Repositório de Dados (Datastore Capabilities).
5 Marque a caixa de seleção Habilitar Storage I/O Control .
Resultados
Em Recursos do Repositório de Dados (Datastore Capabilities), Storage I/O Control está

habilitado para o repositório de dados.
Definir valor do limite Storage I/O Control

O valor do limite de congestionamento para um repositório de dados é o limite superior de
latência permitido para um repositório de dados antes que Storage I/O Control comece a atribuir
importância às cargas de trabalho da máquina virtual de acordo com seus compartilhamentos.
Você não precisa ajustar a configuração de limite na maioria dos ambientes.
Cuidado Storage I/O Control pode não funcionar corretamente se você compartilhar os mesmos
spindles em dois repositórios de dados diferentes.
Se você alterar a configuração de limite de congestionamento, defina o valor com base nas
seguintes considerações.
n Um valor mais alto normalmente resulta em maior taxa de transferência agregada e

isolamento mais fraco. A limitação não ocorrerá a menos que a latência média geral seja
maior do que o limite.

n Se a taxa de transferência for mais crítica do que a latência, não defina o valor como muito
baixo. Por exemplo, para discos Fibre Channel, um valor abaixo de 20 ms poderia diminuir o
pico da taxa de transferência do disco. Um valor muito alto (acima de 50 ms) pode permitir
uma latência muito alta sem qualquer ganho significativo na taxa de transferência geral.
n Um valor mais baixo resultará em menor latência do dispositivo e mais isolamento de

desempenho de E / S da máquina virtual. Um isolamento mais forte significa que os controles
de compartilhamento são aplicados com mais frequência. A menor latência do dispositivo se
traduz em menor latência de E / S para as máquinas virtuais com os compartilhamentos mais
altos, à custa de uma latência de E / S mais alta experimentada pelas máquinas virtuais com
menos compartilhamentos.
n Um valor muito baixo (inferior a 20 ms) resultará em menor latência e isolamento do

dispositivo entre E / Ss, com o custo potencial de uma diminuição na taxa de transferência
agregada do armazenamento de dados.
n Definir o valor como extremamente alto ou extremamente baixo resulta em isolamento

deficiente.
Pré-requisitos
Verifique se Storage I/O Control está habilitado.
Procedimentos
2 Clique na guia Configurar (Configure) e clique em Configurações (Settings).
3 Clique em Geral(General).
4 Clique em Editar (Edit) para Recursos de Repositório de Dados (Datastore Capabilities).
5 Marque a caixa de seleção Habilitar Storage I/O Control .
Storage I/O Control define automaticamente o limite de latência que corresponde à latência
estimada quando o repositório de dados está operando em 90% de sua taxa de transferência
de pico.
6 (Opcional) Ajuste o Limite de congestionamento (Congestion Threshold).
u Selecione um valor no menu suspenso Porcentagem de pico de taxa de transferência

(Percentage of peak throughput).
A porcentagem do valor de pico de taxa de transferência indica o limite de latência estimado
quando o repositório de dados está usando essa porcentagem de sua taxa de transferência
de pico estimada.
u Selecione um valor no menu suspenso Manual (Manual).
O valor deve estar entre 5 ms e 100 ms. Definir valores de limite de congestionamento
incorretos pode ser prejudicial para o desempenho das máquinas virtuais no repositório de
dados.

7 (Opcional) Clique em Redefinir para padrões (Reset to defaults) para restaurar a

configuração de limite de congestionamento para o valor padrão (30 ms).
Integração do Storage DRS com perfis de armazenamento

O Gerenciamento Baseado em Política de Armazenamento (SPBM) permite que você especifique
a política para uma máquina virtual que é aplicada pelo Storage DRS. Um cluster de repositório
de dados pode ter um conjunto de repositórios de dados com diferentes perfis de capacidade.
Se as máquinas virtuais tiverem perfis de armazenamento associados, o Storage DRS poderá
impor o posicionamento com base nos recursos do repositório de dados subjacente. ()
Como parte da integração do Storage DRS com perfis de armazenamento, a opção avançada
de nível de cluster Storage DRS EnforceStorageProfiles é introduzida. A opção avançada
EnforceStorageProfiles adota um destes valores de número inteiro: 0,1 ou 2. O valor padrão
é 0. Quando a opção é definida como 0, isso indica que não há perfil de armazenamento ou
aplicação de política no cluster do Storage DRS. Quando a opção é definida como 1, isso indica
que há um perfil de armazenamento ou aplicação flexível de política no cluster do Storage
DRS. Isso é análogo às regras flexíveis do DRS. O DRS de armazenamento obedecerá ao perfil
ou à política de armazenamento no nível ideal. O DRS de armazenamento violará o perfil de
armazenamento em conformidade se for necessário fazê-lo. As regras de afinidade de DRS de
armazenamento terão maior precedência sobre os perfis de armazenamento somente quando
a imposição do perfil de armazenamento for definida como 1. Quando a opção é definida como
2, isso indica que há um perfil de armazenamento ou aplicação rígida de política no cluster do
Storage DRS. Isso é análogo às regras rígidas do DRS. O DRS de armazenamento não violará
o perfil de armazenamento ou a política compatível. Os perfis de armazenamento terão maior
precedência sobre as regras de afinidade. O DRS de armazenamento gerará falha: não pôde
corrigir a violação da regra de antiafinidade
Pré-requisitos
Por padrão, o DRS de Armazenamento não aplicará políticas de armazenamento associadas

a uma máquina virtual. Configure a opção EnforceStorageProfiles de acordo com suas
necessidades. As opções são Padrão (0), Suave (1) ou Rígida (2).
Procedimentos
1 Faça login no vSphere Client como Administrador.
2 No vSphere Client, clique no cluster Storage DRS e selecione Gerenciar (Manage) >
Configurações (Settings) > Storage DRS (Storage DRS).
3 Clique em Editar (Edit) > Opções Avançadas (Advanced Options) > Parâmetros de
configuração (Configuration parameters) e selecione Adicionar (Add).
4 Clique na área sob o título Opção e digite EnforceStorageProfiles

5 Clique na área sob o título Valor à direita do nome da opção avançada inserido anteriormente
e digite o valor de 0, 1 ou 2.

Gerenciando pools de recursos
10
Um pool de recursos é uma abstração lógica para o gerenciamento flexível de recursos. Os pools
de recursos podem ser agrupados em hierarquias e usados para particionar hierarquicamente
recursos disponíveis de CPU e memória.
Cada host autônomo e cada cluster DRS tem um pool de recursos raiz (invisível) que agrupa os
recursos desse host ou cluster. O pool de recursos raiz não aparece porque os recursos do host
(ou cluster) e do pool de recursos raiz são sempre os mesmos.
Os usuários podem criar pools de recursos filho do pool de recursos raiz ou de qualquer pool
de recursos filho criado pelo usuário. Cada pool de recursos filho possui alguns dos recursos do
pai e, por sua vez, pode ter uma hierarquia de pools de recursos filho para representar unidades
sucessivamente menores de capacidade computacional.
Um pool de recursos pode conter pools de recursos filho, máquinas virtuais ou ambos. Você
pode criar uma hierarquia de recursos compartilhados. Os pools de recursos em um nível
superior são chamados de pools de recursos principais. Pools de recursos e máquinas virtuais
que estão no mesmo nível são chamados de irmãos. O próprio cluster representa o pool de
recursos raiz. Se você não criar pools de recursos filho, apenas os pools de recursos raiz
existirão.
No exemplo a seguir, RP-QA é o pool de recursos pai para RP-QA-UI. RP-Marketing e RP-QA são
irmãos. As três máquinas virtuais imediatamente abaixo do RP-Marketing também são irmãos.
Figura 10-1. Pais, filhos e irmãos na hierarquia do pool de recursos
root resource pool siblings
siblings
parent resource pool
child resource pool
Para cada pool de recursos, especifique reserva, limite, compartilhamentos e se a reserva deve
ser expansível. Os recursos do pool de recursos estão disponíveis para pools de recursos filho e
máquinas virtuais.

n Por que usar pools de recursos?
n Criar um pool de recursos
n Editar um pool de recursos
n Adicionar uma máquina virtual a um pool de recursos
n Remover uma máquina virtual de um pool de recursos
n Remover um pool de recursos
n Controle de admissão do pool de recursos
Por que usar pools de recursos?

Os pools de recursos permitem delegar controle sobre os recursos de um host (ou de
um cluster), mas os benefícios são evidentes quando você usa pools de recursos para
compartimentar todos os recursos em um cluster. Crie vários pools de recursos como filhos
diretos do host ou cluster e configure-os. Em seguida, você pode delegar o controle sobre os
pools de recursos para outras pessoas ou organizações.
O uso de pools de recursos pode resultar nos seguintes benefícios.
n Organização hierárquica flexível - Adicione, remova ou reorganize pools de recursos ou altere

as alocações de recursos conforme necessário.
n Isolamento entre pools, compartilhamento dentro de pools: os administradores de nível

superior podem disponibilizar um pool de recursos para um administrador de nível de
departamento. As alterações de alocação internas a um pool de recursos departamentais
não afetam injustamente outros pools de recursos não relacionados.
n Controle de acesso e delegação - Quando um administrador de nível superior disponibiliza

um pool de recursos para um administrador de nível de departamento, ele pode realizar toda
a criação e o gerenciamento de máquinas virtuais dentro dos limites dos recursos aos quais
o pool de recursos tem direito pelo compartilhamentos, reservas e configurações de limite. A
delegação geralmente é feita em conjunto com as configurações de permissões.
n Separação de recursos do hardware - se você estiver usando clusters habilitados para DRS,
os recursos de todos os hosts serão sempre atribuídos ao cluster. Isso significa que os
administradores podem realizar o gerenciamento de recursos independentemente dos hosts
reais que contribuem para os recursos. Se você substituir três hosts de 2 GB por dois hosts
de 3 GB, não será necessário fazer alterações nas alocações de recursos.
Essa separação permite que os administradores pensem mais sobre a capacidade de

computação agregada e menos sobre hosts individuais.

n Gerenciamento de conjuntos de máquinas virtuais executando um serviço de várias camadas

- Agrupe máquinas virtuais para um serviço de várias camadas em um pool de recursos.
Você não precisa definir recursos em cada máquina virtual. Em vez disso, você pode
controlar a alocação agregada de recursos ao conjunto de máquinas virtuais alterando as
configurações em seu pool de recursos anexo.
Por exemplo, suponha que um host tenha um número de máquinas virtuais. O departamento de
marketing usa três das máquinas virtuais e o departamento de QA usa duas máquinas virtuais.
Como o departamento de controle de qualidade precisa de maiores quantidades de CPU e
memória, o administrador cria um pool de recursos para cada grupo. O administrador define
Compartilhamentos de CPU (CPU Shares) como Alto (High) para o pool de departamentos de
QA e como Normal (Normal) para o pool de departamentos de Marketing para que os usuários
do departamento de QA possam executar testes automatizados. O segundo pool de recursos
com menos recursos de CPU e memória é suficiente para a carga mais leve da equipe de
marketing. Sempre que o departamento de controle de qualidade não estiver usando totalmente
sua alocação, o departamento de marketing poderá usar os recursos disponíveis.
Os números na figura a seguir mostram as alocações efetivas para os pools de recursos.
Figura 10-2. Alocando recursos a pools de recursos
Criar um pool de recursos

Você pode criar um pool de recursos filho de qualquer host ESXi, pool de recursos ou cluster
DRS.
Observação Se um host tiver sido adicionado a um cluster, você não poderá criar pools de
recursos filho desse host. Se o cluster estiver ativado para DRS, você poderá criar pools de
recursos filho do cluster.

Quando você cria um pool de recursos filho, são solicitadas informações de atributo do
pool de recursos. O sistema usa o controle de admissão para garantir que você não possa
alocar recursos que não estão disponíveis. Se você quiser que seus compartilhamentos
sejam dimensionados dinamicamente ao adicionar ou remover VMs, poderá selecionar
compartilhamentos escaláveis.
Observação Os compartilhamentos são dimensionados no nível principal. Todos os pools

de recursos descendentes criados de um pai com compartilhamentos dimensionáveis têm
compartilhamentos dimensionáveis por padrão.
Pré-requisitos
O vSphere Client está conectado ao sistema vCenter Server.
Procedimentos
1 No vSphere Client, selecione um objeto pai para o pool de recursos (um host, outro pool de
recursos ou um cluster DRS).
2 Clique com o botão direito do mouse no objeto e selecione Novo Pool de Recursos (New
Resource Pool).
3 Digite um nome para identificar o pool de recursos.
4 Marque a caixa de seleção se desejar habilitar compartilhamentos sclalable.
5 Especifique como alocar recursos de CPU e memória.
Os recursos de CPU do seu pool de recursos são os recursos físicos garantidos que o host
reserva para um pool de recursos. Normalmente, você aceita o padrão e deixa o host lidar
com a alocação de recursos.
Opção Descrição
Compartilhamentos Especifique os compartilhamentos para este pool de recursos em relação ao

total de recursos do principal. Os pools de recursos irmãos compartilham
recursos de acordo com seus valores de compartilhamento relativos
delimitados pela reserva e pelo limite.
n Selecione Baixa (Low), Normal (Normal) ou Alta (High) para especificar
os valores de compartilhamento, respectivamente, em uma proporção
de 1: 2: 4.
n Selecione Personalizada (Custom) para atribuir a cada máquina virtual
um número específico de compartilhamentos, o que expressa um peso
proporcional.
Reserva Especifique uma alocação de CPU ou memória garantida para este pool de
recursos. O padrão é 0.
Uma reserva diferente de zero é subtraída dos recursos não reservados do
pai (host ou pool de recursos). Os recursos são considerados reservados,
independentemente de as máquinas virtuais estarem associadas ao pool de
recursos.

Opção Descrição
Reserva expansível Quando a caixa de seleção está marcada (padrão), as reservas expansíveis
são consideradas durante o controle de admissão.
Se você ligar uma máquina virtual nesse pool de recursos, e as reservas
combinadas das máquinas virtuais forem maiores que a reserva do pool de
recursos, o pool de recursos poderá usar recursos de seus principais ou
ancestrais.
Limite Especifique o limite superior para a alocação de CPU ou memória deste

pool de recursos. Você normalmente pode aceitar o padrão ( Ilimitado
(Unlimited)).
Para especificar um limite, desmarque a caixa de seleção Ilimitado
(Unlimited).
Resultados
Depois de criar um pool de recursos, você pode adicionar máquinas virtuais a ele. Os
compartilhamentos de uma máquina virtual são relativos a outras máquinas virtuais (ou pools
de recursos) com o mesmo pool de recursos pai.
Exemplo: Criando pools de recursos

Suponha que você tenha um host que forneça 6 GHz de CPU e 3 GB de memória que deve
ser compartilhada entre seus departamentos de QA e de marketing. Você também deseja
compartilhar os recursos de forma irregular, dando a um departamento (QA) uma prioridade
mais alta. Isso pode ser feito criando um pool de recursos para cada departamento e usando o
atributo Compartilhamentos (Shares) para priorizar a alocação de recursos.
O exemplo mostra como criar um pool de recursos com o host ESXi como o recurso pai.
1 Na caixa de diálogo Novo Pool de Recursos (New Resource Pool), digite um nome para o
pool de recursos do departamento de QA (por exemplo, RP-QA).
2 Especifique Compartilhamentos (Shares) de Alto (High) para os recursos de CPU e memória

do RP-QA.
3 Crie um segundo pool de recursos, RP-Marketing.
Deixe os compartilhamentos em Normal (Normal) para CPU e memória.
Se houver contenção de recursos, o RP-QA receberá 4 GHz e 2 GB de memória e o RP-Marketing

2 GHz e 1 GB. Caso contrário, eles podem receber mais do que essa atribuição. Esses recursos
serão disponibilizados para as máquinas virtuais nos respectivos pools de recursos.
Editar um pool de recursos

Depois de criar o pool de recursos, você pode editar suas configurações de recursos de CPU e
memória.

Procedimentos
1 Navegue até o pool de recursos no vSphere Client.
2 Selecione Editar configurações de recurso (Edit Resource Settings) no menu suspenso

Ações (Actions).
3 (Opcional) Você pode alterar todos os atributos do pool de recursos selecionado, conforme
descrito em Criar um pool de recursos.
n Marque a caixa de seleção se desejar habilitar compartilhamentos sclalable.
Observação Os compartilhamentos são dimensionados no nível principal. Todos

os pools de recursos descendentes criados de um pai com compartilhamentos
dimensionáveis têm compartilhamentos dimensionáveis por padrão.
n Em CPU (CPU), selecione Configurações de recursos da CPU.

u Em Memória (Memory), selecione as configurações de recursos de memória.
4 Clique em OK(OK) para salvar as alterações.
Adicionar uma máquina virtual a um pool de recursos

Ao criar uma máquina virtual, você pode especificar uma localização de pool de recursos como
parte do processo de criação. Você também pode adicionar uma máquina virtual existente a um
pool de recursos.
Quando você move uma máquina virtual para um novo pool de recursos:
n A reserva e o limite da máquina virtual não são alterados.
n Se os compartilhamentos da máquina virtual forem altos, médios ou baixos, a porcentagem

de compartilhamentos será ajustada para refletir o número total de compartilhamentos em
uso no novo pool de recursos.
n Se a máquina virtual tiver compartilhamentos personalizados atribuídos, o valor do

compartilhamento será mantido.
Observação Como as alocações de compartilhamento são relativas a um pool de recursos,

talvez você precise alterar manualmente os compartilhamentos de uma máquina virtual ao
movê-los para um pool de recursos para que os compartilhamentos da máquina virtual sejam
consistentes com os valores relativos no novo pool de recursos. Um aviso será exibido se
uma máquina virtual receber uma porcentagem muito grande (ou muito pequena) do total de
compartilhamentos.

n No Monitor (Monitor), as informações exibidas na guia Reserva de Recursos (Resource

Reservation) sobre os recursos de CPU e memória reservadas e não reservadas do pool
de recursos são alteradas para refletir as reservas associadas à máquina virtual (se houver).
Observação Se uma máquina virtual tiver sido desligada ou suspensa, ela poderá ser
movida, mas os recursos gerais disponíveis (como CPU e memória reservados e não
reservados) para o pool de recursos não serão afetados.
Procedimentos
2 Clique com o botão direito do mouse na máquina virtual e clique em Migrar (Migrate).
n Você pode mover a máquina virtual para outro host.
n Você pode mover o armazenamento da máquina virtual para outro repositório de dados.
n Você pode mover a máquina virtual para outro host e mover seu armazenamento para
outro repositório de dados.
3 Selecione um pool de recursos no qual executar a máquina virtual.
4 Revise as seleções e clique em Finalizar(Finish).
Resultados
Se uma máquina virtual estiver ligada e o pool de recursos de destino não tiver CPU ou memória
suficiente para garantir a reserva da máquina virtual, a movimentação falhará porque o controle
de admissão não a permite. Uma caixa de diálogo de erro exibe os recursos disponíveis e
solicitados, para que você possa considerar se um ajuste pode resolver o problema.
Remover uma máquina virtual de um pool de recursos

Você pode remover uma máquina virtual de um pool de recursos movendo a máquina virtual
para outro pool de recursos ou excluindo-o.
Quando você remove uma máquina virtual de um pool de recursos, o número total de
compartilhamentos associados ao pool de recursos diminui, para que cada compartilhamento
restante represente mais recursos. Por exemplo, suponha que você tenha um pool com direito
a 6 GHz, contendo três máquinas virtuais com compartilhamentos definidos como Normal
(Normal). Supondo que as máquinas virtuais sejam vinculadas à CPU, cada uma recebe uma
alocação igual de 2 GHz. Se uma das máquinas virtuais for movida para um pool de recursos
diferente, as duas máquinas virtuais restantes receberão uma alocação igual de 3GHz.

Procedimentos
1 Navegue até o pool de recursos no vSphere Client.
2 Escolha um dos seguintes métodos para remover a máquina virtual de um pool de recursos.
n Clique com o botão direito do mouse na máquina virtual e selecione Mover para ... (Move
To...) para mover a máquina virtual para outro pool de recursos.
Você não precisa desligar a máquina virtual antes de movê-la.
n Clique com o botão direito do mouse na máquina virtual e selecione Excluir do Disco
(Delete from Disk).
Você deve desligar a máquina virtual antes de poder removê-la completamente.
Remover um pool de recursos

Você pode remover um pool de recursos do inventário.
Procedimentos
1 No vSphere Client, clique com o botão direito do mouse no pool de recursos e selecione
Excluir (Delete).
É exibida uma caixa de diálogo de confirmação.
2 Clique em Sim (Yes) para remover o pool de recursos.
Controle de admissão do pool de recursos

Quando você liga uma máquina virtual em um pool de recursos ou tenta criar um pool de
recursos filho, o sistema executa um controle de admissão adicional para garantir que as
restrições do pool de recursos não sejam violadas.
Antes de ligar uma máquina virtual ou criar um pool de recursos, verifique se há recursos
suficientes disponíveis usando a guia Reserva de Recursos (Resource Reservation) na vSphere
Client. O valor de Reserva Disponível (Available Reservation) para CPU e memória exibe os
recursos que não são reservados.
A forma como os recursos de CPU e memória disponíveis são computados e se as ações são
executadas depende do Tipo de Reserva (Reservation Type).

Tabela 10-1. Tipos de reserva
Tipo de reserva Descrição
Corrigido (Fixed) O sistema verifica se o pool de recursos selecionado tem recursos não reservados
suficientes. Se isso acontecer, a ação poderá ser executada. Se não aparecer, uma
mensagem será exibida e a ação não poderá ser executada.
Expansível (Expandable) O sistema considera os recursos disponíveis no pool de recursos selecionado e seu
(padrão) pool de recursos pai direto. Se o pool de recursos pai também tiver a opção Reserva
expansível (Expandable Reservation) selecionada, ele poderá emprestar recursos do
pool de recursos pai. A solicitação de recursos emprestada ocorre recursivamente
dos ancestrais do pool de recursos atual, desde que a opção Reserva expansível
(Expandable Reservation) esteja selecionada. Deixar essa opção selecionada oferece
mais flexibilidade, mas, ao mesmo tempo, fornece menos proteção. Um proprietário
de pool de recursos filho pode reservar mais recursos do que o previsto.
O sistema não permite que você viole as configurações de Reserva (Reservation) ou Limite
(Limit) pré-configuradas. Toda vez que você reconfigurar um pool de recursos ou ligar uma
máquina virtual, o sistema valida todos os parâmetros para que todas as garantias de nível de
serviço ainda possam ser atendidas.
Exemplo de reservas expansíveis 1

Este exemplo mostra como um pool de recursos com reservas expansíveis funciona.
Suponha que um administrador gerencia o pool P e define dois pools de recursos filho, S1 e S2,
para dois usuários diferentes (ou grupos).
O administrador sabe que os usuários desejam ligar máquinas virtuais com reservas, mas não
sabe quanto cada usuário precisará reservar. Tornar as reservas para S1 e S2 expansíveis permite
que o administrador compartilhe e herde de forma mais flexível a reserva comum para o pool P.
Sem reservas expansíveis, o administrador precisa alocar explicitamente S1 e S2 uma quantidade

específica. Essas alocações específicas podem ser inflexíveis, especialmente em hierarquias de
pool de recursos profundos e podem complicar a configuração de reservas na hierarquia de
pools de recursos.
Reservas expansíveis causam uma perda de isolamento estrito. O S1 pode começar a usar toda a
reserva de P, para que nenhuma memória ou CPU esteja diretamente disponível para o S2.
Exemplo de reservas expansíveis 2

Este exemplo mostra como um pool de recursos com reservas expansíveis funciona.
Suponha o seguinte cenário, conforme mostrado na figura.
n O pool principal RP-MOM tem uma reserva de 6 GHz e uma máquina virtual em execução
VM-M1 que reserva 1 GHz.
n Você cria um pool de recursos filho RP-KID com uma reserva de 2 GHz e com Reserva
Expansível (Expandable Reservation) selecionada.

n Você adiciona duas máquinas virtuais, VM-K1 e VM-K2, com reservas de 2 GHz cada ao pool
de recursos filho e tenta ligá-las.
n A VM-K1 pode reservar os recursos diretamente do RP-KID (que tem 2 GHz).
n Nenhum recurso local está disponível para o VM-K2, portanto, ele empresta recursos do
pool de recursos pai, RP-MOM. O RP-MOM tem 6 GHz menos 1 GHz (reservado pela máquina
virtual) menos 2 GHz (reservado pelo RP-KID), o que deixa o 3GHz sem reserva. Com o 3GHz
disponível, você pode ligar a máquina virtual de 2 GHz.
Figura 10-3. Controle de admissão com pools de recursos expansíveis: ativação bem-
sucedida
6GHz RP-MOM
VM-M1, 1GHz
2GHz RP-KID
VM-K1, 2GHz VM-K2, 2GHz
Agora, considere outro cenário com VM-M1 e VM-M2.
n Ligue duas máquinas virtuais no RP-MOM com uma reserva total de 3GHz.
n Você ainda pode ligar a VM-K1 no RP-KID porque 2 GHz estão disponíveis localmente.
n Quando você tenta ligar o VM-K2, o RP-KID não tem capacidade de CPU não reservada,
então ele verifica seu pai. O RP-MOM tem apenas 1 GHz de capacidade não reservada
disponível (5 GHz de RP-MOM já estão em uso - 3GHz reservado pelas máquinas virtuais
locais e 2 GHz reservados pelo RP-KID). Como resultado, você não pode ligar a VM-K2, que
requer uma reserva de 2 GHz.
Figura 10-4. Controle de admissão com pools de recursos expansíveis: ativação impedida
6GHz RP-MOM
VM-M1, 1GHz VM-M2, 2GHz
2GHz RP-KID
VM-K1, 2GHz VM-K2, 2GHz

Criando um cluster DRS
11
Um cluster é uma coleção de ESXi hosts e máquinas virtuais associadas com recursos
compartilhados e uma interface de gerenciamento compartilhada. Antes de obter os benefícios
do gerenciamento de recursos em nível de cluster, você deve criar um cluster e habilitar o DRS.
Dependendo se o Enhanced vMotion Compatibility (EVC) está ou não ativado, o DRS se

comporta de forma diferente quando você usa máquinas virtuais do vSphere Fault Tolerance
(vSphere FT) no seu cluster.
Tabela 11-1. Comportamento do DRS com máquinas virtuais vSphere FT e EVC
EVC DRS (balanceamento de carga) DRS (colocação inicial)
Ativado Ativado (VMs primárias e secundárias) Ativado (VMs primárias e secundárias)
Desativado Desativado (VMs primárias e secundárias) Desativado (VMs primárias)

Totalmente automatizado (VMs secundárias)
n vSphere Cluster Services (vCLS)
n Controle de admissão e colocação inicial
n Migração de máquina virtual
n Requisitos de cluster do DRS
n Configurando o DRS com o Virtual Flash
n Criar um cluster
n Editar configurações do cluster
n Definir um nível de automação personalizado para uma máquina virtual
n Desativar DRS
n Restaurar uma árvore do pool de recursos
n Reconhecimento de DRS do cluster estendido do vSAN

vSphere Cluster Services (vCLS)

O vSphere Cluster Services (vCLS) é habilitado por padrão e é executado em todos os clusters
do vSphere. O vCLS garante que, se vCenter Server ficar indisponível, os serviços de cluster
permanecerão disponíveis para manter os recursos e a integridade das cargas de trabalho que
são executadas nos clusters. vCenter Server ainda é necessário para executar o DRS e o HA.
O vCLS é ativado quando você atualiza para o vSphere 7.0 U3 ou quando você tem uma nova
implantação do vSphere 7.0 U3. O vCLS é atualizado como parte da atualização do vCenter
Server.
O vCLS usa máquinas virtuais de agente para manter a integridade dos serviços de cluster. As
máquinas virtuais do agente do vCLS (VMs do vCLS) são criadas quando você adiciona hosts
aos clusters. São necessárias até três VMs do vCLS para serem executadas em cada cluster
do vSphere, distribuídas dentro de um cluster. O vCLS também está ativado em clusters que
contêm apenas um ou dois hosts. Nesses clusters, o número de VMs do vCLS é um e dois,
respectivamente.
Novas regras de antiafinidade são aplicadas automaticamente. A cada três minutos, uma
verificação é realizada. Se várias VMs do vCLS estiverem localizadas em um único host, elas
serão automaticamente redistribuídas para hosts diferentes.
Tabela 11-2. Número de VMs do vCLS Agent em clusters
Número de hosts em um cluster Número de VMs do vCLS Agent
1 1
2 2
3 ou mais 3
As VMs do vCLS são executadas em todos os clusters, mesmo se os serviços de cluster, como
o vSphere DRS ou o vSphere HA, não estiverem habilitados no cluster. As operações de ciclo
de vida das VMs do vCLS são gerenciadas por serviços do vCenter, como ESX Agent Manager e
Workload Control Plane. As VMs do vCLS não oferecem suporte a cartões de NiC.
Um cluster habilitado com vCLS pode conter hosts ESXi de versões diferentes se as versões de
ESXi forem compatíveis com o vCenter Server. O vCLS funciona com clusters gerenciados por
vLCM e VUM e é executado em todos os clusters de SKU de licença do vSphere.
vSphere DRS
O vSphere DRS é um recurso crítico do vSphere necessário para manter a integridade das cargas
de trabalho em execução no vSphere Cluster. O DRS depende da disponibilidade de VMs do
vCLS.

Observação Se você tentar habilitar o DRS em um cluster no qual há problemas com as VMs do
vCLS, uma mensagem de aviso será exibida na página Resumo do Cluster (Cluster Summary).
Observação Se o DRS estiver ativado, mas houver problemas com as VMs do vCLS, você
deverá resolver esses problemas para que o DRS funcione. Uma mensagem de aviso é exibida na
página Resumo do cluster (Cluster Summary).
Se o DRS não estiver funcional, isso não significa que o DRS esteja desativado. As configurações
e pools de recursos existentes do DRS sobrevivem em um quórum de VMs do vCLS perdido. A
integridade do vCLS torna-se não íntegra (Unhealthy) somente em um cluster habilitado para
DRS quando as VMs do vCLS não estão em execução e a primeira instância do DRS é ignorada
por causa disso. A integridade do vCLS permanecerá degradada ( Degraded) em um cluster não
habilitado para DRS quando pelo menos uma VM do vCLS não estiver em execução.
Seleção de datastore para VMs do vCLS

O datastore para VMs do vCLS é selecionado automaticamente com base na classificação de
todos os datastores conectados aos hosts dentro do cluster. É mais provável que um datastore
seja selecionado se houver hosts no cluster com slots DRS reservados livres conectados
ao datastore. O algoritmo tenta colocar VMs do vCLS em um armazenamento de dados
compartilhado, se possível, antes de selecionar um armazenamento de dados local. É preferível
um armazenamento de dados com mais espaço livre e o algoritmo tenta não colocar mais de
uma VM do vCLS no mesmo armazenamento de dados. Você só pode alterar o armazenamento
de dados das VMs do vCLS depois que elas são implantadas e ligadas.
Se você quiser mover os VMDKs para VMs do vCLS para um armazenamento de dados diferente
ou anexar uma política de armazenamento diferente, poderá reconfigurar as VMs do vCLS. Uma
mensagem de aviso é exibida quando você executa esta operação.

Você pode realizar um vMotion de armazenamento para migrar VMs do vCLS para um
armazenamento de dados diferente. Você pode marcar VMs do vCLS ou anexar atributos
personalizados se quiser agrupá-las separadamente das VMs de carga de trabalho, por exemplo,
se você tiver uma estratégia de metadados específica para todas as VMs que são executadas
em um centro de dados.
Observação Quando um armazenamento de dados é colocado no modo de manutenção, se o

armazenamento de dados hospedar VMs do vCLS, você deverá aplicar manualmente o vMotion
de armazenamento às VMs do vCLS para movê-las para um novo local ou colocar o cluster no
modo de retirada. Uma mensagem de aviso é exibida.
A tarefa de entrada no modo de manutenção será iniciada, mas não poderá ser concluída porque
há uma máquina virtual residente no armazenamento de dados. Você sempre pode cancelar a
tarefa em suas Tarefas Recentes se decidir continuar.
O datastore selecionado pode estar armazenando VMs do vSphere Cluster Services que não podem
ser desligadas. Para garantir a integridade do vSphere Cluster Services, essas VMs devem ser
manualmente vMotioned para um datastore diferente dentro do cluster antes de desativar esse
datastore para manutenção. Consulte este artigo KB: KB 79892.
Marque a caixa de seleção Deixe-me migrar o armazenamento para todas as máquinas

virtuais e continuar entrando no modo de manutenção após a migração. para
prosseguir.
Posicionamento do datastore do vCLS

Você pode substituir o posicionamento padrão do repositório de dados da VM do vCLS.
A localização do repositório de dados da VM do vSphere Cluster Services (vCLS) é escolhida por

uma lógica de seleção de repositório de dados padrão. Para substituir o posicionamento padrão
do repositório de dados da VM do vCLS para um cluster, você pode especificar um conjunto
de repositórios de dados permitidos navegando até o cluster e clicando em ADD (ADD) em
Configure (Configure ) > vSphere Cluster Repositório de dados de (vSphere Cluster Service) >
serviço (Datastores). Alguns datastores não podem ser selecionados para o vCLS porque são
bloqueados por soluções como o SRM ou o modo de manutenção do vSAN, em que o vCLS não
pode ser configurado. Os usuários não podem adicionar ou remover datastores bloqueados de
solução para VMs do vCLS.
Monitorando o vSphere Cluster Services

Você pode monitorar os recursos consumidos pelas VMs do vCLS e seu status de integridade.

As VMs do vCLS não são exibidas na árvore de inventário na guia Hosts e Clusters (Hosts and
Clusters). As VMs do vCLS de todos os clusters em um centro de dados são colocadas dentro
de uma pasta separada de VMs e modelos chamada vCLS (vCLS). Esta pasta e as VMs do vCLS
são visíveis apenas na guia VMs e Modelos (VMs and Templates ) do vSphere Client. Essas VMs
são identificadas por um ícone diferente das VMs de carga de trabalho regulares. Você pode
visualizar informações sobre a finalidade das VMs do vCLS na guia Resumo (Summary) das VMs
do vCLS.
Você pode monitorar os recursos consumidos pelas VMs do vCLS na guia Monitor (Monitor).
Tabela 11-3. Alocação de recursos de VM do vCLS
Propriedade Tamanho
Tamanho do VMDK 245 MB (disco fino)
Memória 128 MB
CPU 1 vCPU
Disco rígido 2 GB
Armazenamento no repositório de dados 480 MB (disco fino)
Observação Cada VM do vCLS tem capacidade de 100MHz e 100MB reservada no cluster.

Dependendo do número de VMs do vCLS em execução no cluster, um máximo de 400 MHz e
400 MB de capacidade podem ser reservados para essas VMs.
Você pode monitorar o status de integridade do vCLS no portlet Serviços de Cluster exibido na
guia Resumo (Summary) do cluster.
Tabela 11-4. Status de integridade do vCLS
Status Código de cores Resumo
Íntegro Implementação Se houver pelo menos uma VM vCLS

em execução, o status permanecerá
íntegro, independentemente do
número de hosts no cluster.
Degradado Implementação Se não houver nenhuma VM do

vCLS em execução por menos de 3
minutos (180 segundos), o status será
degradado.
Não íntegro Vermelho Se não houver nenhuma VM vCLS em

execução por 3 minutos ou mais, o
status será não íntegro em um cluster
habilitado para DRS.
Mantendo a integridade do vSphere Cluster Services

As VMs do vCLS estão sempre ligadas porque o vSphere DRS depende da disponibilidade
dessas VMs. Essas VMs devem ser tratadas como VMs do sistema. Somente os administradores

podem realizar operações seletivas em VMs do vCLS. Para evitar a falha dos serviços de cluster,
evite realizar qualquer configuração ou operações nas VMs do vCLS.
As VMs do vCLS são protegidas contra exclusão acidental. As VMs e pastas de cluster são
protegidas contra modificações por usuários, incluindo administradores.
Somente os usuários que fazem parte do grupo de SSO de administradores podem realizar as
seguintes operações:
n Acesso somente leitura para VMs do vCLS
n Acesso do console a VMs do vCLS
n Realoque as VMs do vCLS para um novo armazenamento, recurso de processamento ou

ambos usando a migração a frio ou a quente
n Use tags e atributos personalizados para VMs do vCLS
Operações que podem interromper o funcionamento íntegro das VMs do vCLS:
n Alterar o estado de energia das VMs do vCLS
n Reconfiguração de recursos das VMs do vCLS, como alteração de CPU, memória, tamanho
do disco e posicionamento do disco
n Criptografia da VM
n Como disparar o vMotion das VMs do vCLS
n Alterando o BIOS
n Removendo as VMs do vCLS do inventário
n Excluindo as VMs do vCLS do disco
n Habilitando o FT de VMs do vCLS
n Clonando VMs do vCLS
n Configurando o PMem
n Movendo a VM do vCLS para uma pasta diferente
n Renomeando as VMs do vCLS
n Renomeando as pastas do vCLS
n Habilitando regras e substituições de DRS em VMs do vCLS
n Habilitando a política de controle de admissão de alta disponibilidade em VMs do vCLS
n Habilitando substituições de HA em VMs do vCLS
n Movendo VMs do vCLS para um pool de recursos
n Recuperando VMs do vCLS de um snapshot
Quando você executa qualquer operação de interrupção nas VMs do vCLS, uma caixa de diálogo
de aviso é exibida.

Solução de problemas:
A integridade das VMs do vCLS, incluindo o estado de energia, é gerenciada pelos serviços EAM
e WCP. Em caso de falha ao ligar as VMs do vCLS ou se a primeira instância do DRS para um
cluster for ignorada devido à falta de quorum de VMs do vCLS, um banner será exibido na página
de resumo do cluster, juntamente com um link para um artigo da Base de Conhecimento para
ajudar solucionar o estado de erro.
Como as VMs do vCLS são tratadas como VMs do sistema, você não precisa fazer backup ou
snapshot dessas VMs. O estado de integridade dessas VMs é gerenciado pelos serviços do
vCenter.
Colocando um cluster no modo de retirada

Quando um datastore é colocado no modo de manutenção, se o datastore hospedar VMs do
vCLS, você deverá armazenar manualmente as VMs do vCLS em um novo local ou colocar o
cluster no modo de retirada.
Esta tarefa explica como colocar um cluster no modo de retirada.
Procedimentos
1 Faça login no vSphere Client.
2 Navegue até o cluster no qual o vCLS deve ser desativado.
3 Copie o ID de domínio do cluster da URL do navegador. Deve ser semelhante a domain-c

(number) .
4 Navegue até a guia vCenter Server Configurar (Configure).
5 Em Configurações avançadas (Advanced Settings), clique no botão Editar configurações

(Edit Settings).
6 Adicione uma nova entrada config.vcls.clusters.domain-c (number) .enabled . Use

o ID de domínio copiado na etapa 3.
7 Defina o Valor (Value) como Falso .
8 Clique em Salvar(Save).
Resultados
O serviço de monitoramento do vCLS é executado a cada 30 segundos. Dentro de 1 minuto,

todas as VMs do vCLS no cluster serão limpas e a integridade dos Cluster Services (Cluster
Services) será definida como Degraded (Degraded). Se o cluster tiver o DRS ativado, ele para
de funcionar e um aviso adicional será exibido no Resumo do Cluster (Cluster Summary). O DRS
não funcionará, mesmo se estiver ativado, até que o vCLS seja reconfigurado, removendo-o do
modo de retirada.
vSphere HA não executa o posicionamento ideal durante um cenário de falha do host. HA

depende do DRS para recomendações de posicionamento. O HA ainda ligará as VMs, mas essas
VMs podem ser ligadas em um host menos ideal.

Para remover o modo de retirada do cluster, altere o valor na etapa 7 para True .
Recuperando a senha para VMs do vCLS

Você pode recuperar a senha para fazer login nas VMs do vCLS.
Para garantir a integridade dos serviços de cluster, evite acessar as VMs do vCLS. Este
documento destina-se a diagnósticos explícitos em VMs do vCLS.
Procedimentos
1 Use o SSH para fazer login no vCenter Server Appliance.
2 Execute o seguinte script python:
/usr/lib/vmware-wcp/decrypt_clustervm_pw.py
3 Leia a saída para a senha.
pwd-script-output
Read key from file
Connected to PSQL
PWD: (password displayed here)
Resultados
Com a senha recuperada, você pode fazer login nas VMs do vCLS.
Políticas antiafinidade de VM do vCLS

O vSphere oferece suporte à antiafinidade entre as VMs do vCLS e outro grupo de VMs de carga
de trabalho.
As políticas de processamento fornecem uma maneira de especificar como o vSphere

Distributed Resource Scheduler (DRS) deve colocar VMs em hosts em um pool de recursos.
Use o editor vSphere Compute Policies para criar e excluir políticas de processamento. Você
pode criar ou excluir, mas não modificar, uma política de processamento. Se você excluir uma
tag de categoria usada na definição da política, a política também será excluída. Abra a página
VM Summary (VM Summary) no vSphere para visualizar as políticas de processamento que se
aplicam a uma VM e seu status de conformidade com cada política. Você pode criar uma política
de processamento para um grupo de VMs de carga de trabalho que seja antiafeita para o grupo
de VMs do vCLS. Uma política antiafinidade do vCLS pode ter uma única tag visível ao usuário
para um grupo de VMs de carga de trabalho, e o outro grupo de VMs do vCLS é reconhecido
internamente.
Criar ou excluir uma política antiafinidade de VM do vCLS

Uma política antiafinidade de VM do vCLS descreve um relacionamento entre uma categoria de
VMs e VMs do sistema vCLS.

Uma política antiafinidade de VM do vCLS desencoraja o posicionamento de VMs do vCLS e VMs

de aplicativo no mesmo host. Esse tipo de política pode ser útil quando você não deseja que as
VMs do vCLS e as máquinas virtuais que executam cargas de trabalho críticas sejam executadas
no mesmo host. Algumas práticas recomendadas para a execução de cargas de trabalho críticas,
como o SAP HANA, exigem hosts dedicados. Depois que a política é criada, o mecanismo de
posicionamento tenta colocar VMs do vCLS nos hosts onde as VMs de política não estão em
execução.
A aplicação de uma política antiafinidade de VM do vCLS pode ser afetada de várias maneiras:
n Se a política se aplicar a várias VMs em hosts diferentes e não for possível ter hosts
suficientes para distribuir VMs do vCLS, as VMs do vCLS serão consolidadas nos hosts sem as
VMs de política.
n Se uma operação de provisionamento especificar um host de destino, essa especificação

será sempre respeitada, mesmo se violar a política. O DRS tentará mover as VMs do vCLS
para um host em conformidade em um ciclo de correção subsequente.
Procedimentos
1 Crie uma categoria e uma tag para cada grupo de VMs que você deseja incluir em uma
política antiafinidade de VM do vCLS.
2 Marque as VMs que você deseja incluir.
3 Crie uma política antiafinidade de VM do vCLS.
a No vSphere, clique em Policies and Profiles (Policies and Profiles) > Compute Policies
(Compute Policies).
b Clique em Adicionar (Add) para abrir o assistente de Nova política de processamento .
c Preencha o Nome da política (Name) e escolha vCLS VM anti-Affinity (vCLS VM anti

affinity) no controle suspenso Policy type (Policy type).
O Nome (Name) da política deve ser exclusivo.
d Forneça uma Descrição (Description) da política e, em seguida, use a tag da VM (VM

tag) para escolher a Categoria (Category) e a Tag (Tag) à qual a política se aplica.
A menos que você tenha várias tags de VM associadas a uma categoria, o assistente
preenche a tag da VM depois que você seleciona a tag Categoria (Category).
e Clique em Criar (Create) para criar a política.
4 (Opcional) Para excluir uma política de processamento, abra o vSphere, clique em Policies
and Profiles (Policies and Profiles) > Compute Policies (Compute Policies) para mostrar
cada política como um cartão. Clique em DELETE para excluir uma política.

Controle de admissão e colocação inicial

Quando você tenta ligar uma única máquina virtual ou um grupo de máquinas virtuais em um
cluster habilitado para DRS, vCenter Server executa o controle de admissão. Ele verifica se há
recursos suficientes no cluster para oferecer suporte às máquinas virtuais.
Se o cluster não tiver recursos suficientes para ligar uma única máquina virtual ou qualquer uma
das máquinas virtuais em uma tentativa de inicialização de grupo, será exibida uma mensagem.
Caso contrário, para cada máquina virtual, o DRS gera uma recomendação de um host no qual a
máquina virtual é executada e executa uma das seguintes ações
n Executa automaticamente a recomendação de posicionamento.
n Exibe a recomendação de posicionamento, que o usuário pode optar por aceitar ou

substituir.
Observação Nenhuma recomendação de posicionamento inicial é fornecida para máquinas

virtuais em hosts independentes ou em clusters não DRS. Quando ligadas, elas são colocadas
no host onde residem atualmente.
n O DRS considera a largura de banda da rede. Ao calcular a saturação da rede do host, o DRS
pode tomar melhores decisões de posicionamento. Isso pode ajudar a evitar a degradação
do desempenho de máquinas virtuais com uma compreensão mais abrangente do ambiente.
Ligar uma única máquina virtual

Em um cluster do DRS, você pode ligar uma única máquina virtual e receber recomendações de
posicionamento inicial.
Ao ligar uma única máquina virtual, você tem dois tipos de recomendações de posicionamento
inicial:
n Uma única máquina virtual está sendo ligada e nenhuma etapa de pré-requisito é necessária.
O usuário é apresentado com uma lista de recomendações de posicionamento inicial

mutuamente exclusivas para a máquina virtual. Você pode selecionar apenas um.
n Uma única máquina virtual está sendo ligada, mas são necessárias ações de pré-requisito.
Essas ações incluem ligar um host no modo de espera ou a migração de outras máquinas
virtuais de um host para outro. Nesse caso, as recomendações fornecidas têm várias linhas,
mostrando cada uma das ações de pré-requisito. O usuário pode aceitar essa recomendação
inteira ou cancelar a ativação da máquina virtual.
Ligar o grupo
Você pode tentar ligar várias máquinas virtuais ao mesmo tempo (ligar o grupo).

As máquinas virtuais selecionadas para uma tentativa de inicialização de grupo não precisam
estar no mesmo cluster do DRS. Eles podem ser selecionados entre clusters, mas devem estar no
mesmo centro de dados. Também é possível incluir máquinas virtuais localizadas em clusters não
DRS ou em hosts autônomos. Essas máquinas virtuais são ligadas automaticamente e não são
incluídas em nenhuma recomendação de posicionamento inicial.
As recomendações de posicionamento inicial para tentativas de ativação do grupo são

fornecidas por cluster. Se todas as ações relacionadas ao posicionamento para uma tentativa
de ativação de grupo estiverem no modo automático, as máquinas virtuais serão ligadas sem
nenhuma recomendação de posicionamento inicial. Se as ações relacionadas ao posicionamento
para qualquer uma das máquinas virtuais estiverem no modo manual, a ativação de todas as
máquinas virtuais (incluindo as máquinas virtuais que estão no modo automático) será manual.
Essas ações estão incluídas em uma recomendação de posicionamento inicial.
Para cada cluster do DRS ao qual pertencem as máquinas virtuais que estão sendo
ligadas, há uma única recomendação, que contém todos os pré-requisitos (ou nenhuma
recomendação). Todas essas recomendações específicas do cluster são apresentadas juntas na
guia Recomendações de Ligação (Power On Recommendations).
Quando uma tentativa de inicialização de grupo não automático é feita, e as máquinas virtuais
não sujeitas a uma recomendação de posicionamento inicial (ou seja, as máquinas virtuais
em hosts independentes ou em clusters não DRS) são incluídas, vCenter Server tenta ligá-las
automaticamente . Se essas inicializações forem bem-sucedidas, elas serão listadas na guia
Ligações Iniciadas (Started Power-Ons). Todas as máquinas virtuais que falham ao ligar são
listadas na guia Falha ao ligar (Failed Power-Ons).
Exemplo: Ligar o grupo

O usuário seleciona três máquinas virtuais no mesmo centro de dados para uma tentativa de
ativação de grupo. As duas primeiras máquinas virtuais (VM1 e VM2) estão no mesmo cluster
DRS (Cluster1), enquanto a terceira máquina virtual (VM3) está em um host autônomo. A VM1
está no modo automático e a VM2 está no modo manual. Para esse cenário, o usuário recebe
uma recomendação de posicionamento inicial para o Cluster1 (na guia Recomendações de
Ligação (Power On Recommendations)) que consiste em ações para ligar a VM1 e a VM2. É
feita uma tentativa de ligar a VM3 automaticamente e, se bem-sucedida, ela é listada na guia
Ligações Iniciadas (Started Power-Ons). Se essa tentativa falhar, ela será listada na guia Falha
na inicialização (Failed Power-Ons).
Migração de máquina virtual

Embora o DRS realize posicionamentos iniciais para que a carga seja balanceada no cluster, as
alterações na carga da máquina virtual e na disponibilidade de recursos podem fazer com que
o cluster fique desbalanceado. Para corrigir esses desequilíbrios, o DRS gera recomendações de
migração.

Se o DRS estiver ativado no cluster, a carga poderá ser distribuída de forma mais uniforme para
reduzir o grau desse desequilíbrio. Por exemplo, os três hosts no lado esquerdo da figura a
seguir estão desbalanceados. Suponha que o Host 1, o Host 2 e o Host 3 tenham capacidade
idêntica e que todas as máquinas virtuais tenham a mesma configuração e carga (o que inclui
reserva, se definido). No entanto, como o Host 1 tem seis máquinas virtuais, seus recursos podem
ser usados em excesso, enquanto amplos recursos estão disponíveis no Host 2 e no Host 3. O
DRS migra (ou recomenda a migração de) máquinas virtuais do Host 1 para o Host 2 e o Host
3. No lado direito do diagrama, a configuração do balanceamento de carga adequada dos hosts
que resulta é exibida.
Figura 11-1. Balanceamento de Carga
VM1 VM2 VM3 VM1 VM2 VM3
VM4 VM5 VM6

Host 1 Host 1
VM7 VM7 VM4 VM5
Host 2 Host 2
VM8 VM9 VM8 VM9 VM6
Host 3 Host 3
Quando um cluster fica desbalanceado, o DRS faz recomendações ou migra máquinas virtuais,
dependendo do nível de automação padrão:
n Se o cluster ou qualquer uma das máquinas virtuais envolvidas for manual ou parcialmente
automatizada, vCenter Server não executará ações automáticas para balancear recursos. Em
vez disso, a página Resumo indica que as recomendações de migração estão disponíveis, e a
página Recomendações do DRS exibe recomendações para alterações que fazem o uso mais
eficiente dos recursos em todo o cluster.
n Se o cluster e as máquinas virtuais envolvidas forem totalmente automatizados, o vCenter

Server migrará as máquinas virtuais em execução entre os hosts conforme necessário para
garantir o uso eficiente dos recursos do cluster.
Observação Mesmo em uma configuração de migração automática, os usuários podem

migrar explicitamente máquinas virtuais individuais, mas vCenter Server pode mover essas
máquinas virtuais para outros hosts para otimizar os recursos do cluster.

Por padrão, o nível de automação é especificado para todo o cluster. Você também pode
especificar um nível de automação personalizado para máquinas virtuais individuais.
Limite de migração do DRS

O limite de migração do DRS permite que você especifique quais recomendações são geradas e,
em seguida, aplicadas (quando as máquinas virtuais envolvidas na recomendação estão no modo
totalmente automatizado) ou mostradas (se estiver no modo manual). Esse limite é uma medida
de como o DRS é agressivo ao recomendar migrações para melhorar a felicidade da VM.
Você pode mover o controle deslizante de limite para usar uma das cinco configurações,
variando de Conservador a Agressivo. Quanto maior a configuração de agressividade, mais
frequentemente o DRS pode recomendar migrações para melhorar a satisfação da VM. A
configuração do Conservador gera apenas recomendações de prioridade um (recomendações
obrigatórias).
Depois que uma recomendação recebe um nível de prioridade, esse nível é comparado ao
limite de migração definido. Se o nível de prioridade for menor ou igual à configuração do
limite, a recomendação será aplicada (se as máquinas virtuais relevantes estiverem no modo
totalmente automatizado) ou exibida ao usuário para confirmação (se estiver no modo manual ou
parcialmente automatizado).
Pontuação DRS
Cada recomendação de migração é calculada usando a métrica de felicidade da VM que mede
a eficiência de execução. Essa métrica é exibida como Pontuação do DRS na guia Resumo
do cluster no vSphere Client. As recomendações de balanceamento de carga do DRS tentam
melhorar a pontuação do DRS de uma VM. A pontuação do DRS do Cluster é uma média
ponderada das Escores do DRS de VM de todas as VMs ligadas no cluster. A Pontuação do
DRS do Cluster é mostrada no componente de medidor. A cor da seção preenchida muda
dependendo do valor para corresponder à barra correspondente no histograma de Pontuação
do DRS da VM. As barras no histograma mostram a porcentagem de VMs que têm uma
Pontuação DRS nesse intervalo. Você pode visualizar a lista com classificação e filtragem do
lado do servidor selecionando a guia Monitorar do cluster e selecionando o vSphere DRS, que
mostra uma lista das VMs no cluster classificadas pela pontuação do DRS em ordem crescente.
Recomendações de migração
Se você criar um cluster com um modo manual padrão ou parcialmente automatizado, vCenter
Server exibirá as recomendações de migração na página Recomendações do DRS.
O sistema fornece quantas recomendações forem necessárias para impor regras e equilibrar os
recursos do cluster. Cada recomendação inclui a máquina virtual a ser movida, o host atual (de
origem) e o host de destino e um motivo para a recomendação. O motivo pode ser um dos
seguintes:
n Equilibre as cargas ou reservas médias de CPU.
n Equilibre as cargas de memória ou reservas médias.

n Satisfazer reservas de pool de recursos.
n Satisfazer uma regra de afinidade.
n O host está entrando no modo de manutenção ou no modo de espera.
Observação Se você estiver usando o recurso vSphere Distributed Power Management (DPM),
além das recomendações de migração, o DRS fornecerá recomendações de estado de energia
do host.
Requisitos de cluster do DRS

Os hosts que são adicionados a um cluster DRS devem atender a certos requisitos para usar os
recursos de cluster com êxito.
Observação O vSphere DRS é um recurso crítico do vSphere que é necessário para manter a
integridade das cargas de trabalho em execução no vSphere Cluster. A partir do vSphere 7.0
Update 1, o DRS depende da disponibilidade de VMs do vCLS. Consulte vSphere Cluster Services
(vCLS) para obter mais informações.
Requisitos de armazenamento compartilhado

Um cluster do DRS tem certos requisitos de armazenamento compartilhado.
Certifique-se de que os hosts gerenciados usem o armazenamento compartilhado. O

armazenamento compartilhado normalmente está em uma SAN, mas também pode ser
implementado usando o armazenamento compartilhado do NAS.
Consulte a documentação do vSphere Storage para obter informações sobre outro

armazenamento compartilhado.
Requisitos de volume de VMFS compartilhado

Um cluster DRS tem certos requisitos de volume VMFS compartilhado.
Configure todos os hosts gerenciados para usar volumes VMFS compartilhados.
n Coloque os discos de todas as máquinas virtuais em volumes VMFS acessíveis por hosts de
origem e de destino.
n Certifique-se de que o volume VMFS seja suficientemente grande para armazenar todos os
discos virtuais para suas máquinas virtuais.

n Certifique-se de que todos os volumes VMFS nos hosts de origem e de destino usem nomes
de volume e que todas as máquinas virtuais usem esses nomes de volume para especificar os
discos virtuais.
Observação Os arquivos de permuta da máquina virtual também precisam estar em um VMFS

acessível aos hosts de origem e de destino (assim como .vmdk arquivos de disco virtual).
Esse requisito não se aplica se todos os hosts de origem e de destino forem ESX Server 3.5
ou superior e estiverem usando permuta host-local. Nesse caso, o vMotion com arquivos de
permuta em armazenamento não compartilhado é compatível. Os arquivos de permuta são
colocados em um VMFS por padrão, mas os administradores podem substituir o local do arquivo
usando as opções de configuração avançada da máquina virtual.
Requisitos de compatibilidade do processador

Um cluster DRS tem certos requisitos de compatibilidade de processador.
Para evitar limitar os recursos do DRS, você deve maximizar a compatibilidade do processador
de hosts de origem e de destino no cluster.
O vMotion transfere o estado arquitetônico em execução de uma máquina virtual entre os hosts
ESXi subjacentes. A compatibilidade do vMotion significa que os processadores do host de
destino devem ser capazes de retomar a execução usando as instruções equivalentes onde os
processadores do host de origem foram suspensos. As velocidades de clock e tamanhos de
cache do processador podem variar, mas os processadores devem ser da mesma classe de
fornecedor (Intel versus AMD) e da mesma família de processadores para serem compatíveis
com a migração com o vMotion.
As famílias de processadores são definidas pelos fornecedores de processadores. Você pode

distinguir diferentes versões de processador dentro da mesma família, comparando o modelo
dos processadores, o nível de etapa e os recursos estendidos.
Às vezes, os fornecedores de processadores têm introduzido alterações arquitetônicas

significativas na mesma família de processadores (como extensões de 64 bits e SSE3). VMware
identifica essas exceções se não puder garantir uma migração bem-sucedida com o vMotion.
O vCenter Server fornece recursos que ajudam a garantir que as máquinas virtuais migradas com
o vMotion atendam aos requisitos de compatibilidade do processador. Esses recursos incluem:
n Enhanced vMotion Compatibility (EVC) - Você pode usar o EVC para ajudar a garantir a
compatibilidade do vMotion para os hosts em um cluster. O EVC garante que todos os hosts
em um cluster apresentem o mesmo conjunto de recursos de CPU para máquinas virtuais,
mesmo se as CPUs reais nos hosts forem diferentes. Isso impede que as migrações com o
vMotion falhem devido a CPUs incompatíveis.
Configure o EVC na caixa de diálogo Configurações do Cluster. Os hosts em um cluster

devem atender a certos requisitos para que o cluster use o EVC. Para obter informações
sobre os requisitos de EVC e EVC, consulte a documentação do vCenter Server e
Gerenciamento de Host .

n Máscaras de compatibilidade de CPU - vCenter Server compara os recursos de CPU

disponíveis para uma máquina virtual com os recursos de CPU do host de destino para
determinar se deseja permitir ou não migrações com o vMotion. Ao aplicar máscaras de
compatibilidade de CPU a máquinas virtuais individuais, você pode ocultar certos recursos da
CPU da máquina virtual e, potencialmente, impedir que as migrações com o vMotion falhem
devido a CPUs incompatíveis.
Requisitos do vMotion para clusters do DRS

Um cluster DRS tem certos requisitos do vMotion.
Para habilitar o uso de recomendações de migração do DRS, os hosts no seu cluster devem fazer
parte de uma rede do vMotion. Se os hosts não estiverem na rede do vMotion, o DRS ainda
poderá fazer recomendações iniciais de posicionamento.
Para ser configurado para o vMotion, cada host no cluster deve atender aos seguintes requisitos:
n O vMotion não oferece suporte a discos não processados ou à migração de aplicativos

clusterizados usando o Microsoft Cluster Service (MSCS).
n O vMotion requer uma rede de migração de Gigabit Ethernet privada entre todos os
hosts gerenciados habilitados para vMotion. Quando o vMotion estiver ativado em um host
gerenciado, configure um objeto de identidade de rede exclusivo para o host gerenciado e
conecte-o à rede de migração privada.
Configurando o DRS com o Virtual Flash

O DRS pode gerenciar máquinas virtuais que têm reservas de flash virtual.
A capacidade do flash virtual aparece como uma estatística que é relatada regularmente do host
para o vSphere Client. Cada vez que o DRS é executado, ele usa o valor de capacidade mais
recente relatado.
Você pode configurar um recurso de flash virtual por host. Isso significa que, durante o tempo de
inicialização da máquina virtual, o DRS não precisa selecionar entre diferentes recursos de flash
virtual em um determinado host.
O DRS seleciona um host que tenha capacidade de flash virtual disponível suficiente para iniciar
a máquina virtual. Se o DRS não puder satisfazer a reserva de flash virtual de uma máquina
virtual, ela não poderá ser ligada. O DRS trata uma máquina virtual ligada com uma reserva de
flash virtual como tendo uma afinidade suave com seu host atual. O DRS não recomendará essa
máquina virtual para o vMotion, exceto por motivos obrigatórios, como colocar um host no modo
de manutenção ou para reduzir a carga em um host muito utilizado.
Criar um cluster
Um cluster é um grupo de hosts. Quando um host é adicionado a um cluster, os recursos do host
se tornam parte dos recursos do cluster. O cluster gerencia os recursos de todos os hosts dentro
dele.

Os clusters permitem as soluções vSphere High Availability (HA) e vSphere Distributed Resource
Scheduler (DRS).
Pré-requisitos
n Verifique se você tem permissões suficientes para criar um objeto de cluster.
n Verifique se existe um centro de dados no inventário.
n Se você quiser usar o vSAN, ele deverá ser habilitado antes de configurar o vSphere HA.
Procedimentos
1 Navegue até um centro de dados no vSphere Client.
2 Clique com o botão direito do mouse no centro de dados e selecione Novo Cluster (New
Cluster).
3 Insira um nome para o cluster.
4 Selecione DRS e vSphere HA recursos de cluster.
Opção Descrição
Para usar o DRS com este cluster a Marque a caixa de seleção DRS Ativar (Turn ON).
b Selecione um nível de automação e um limite de migração.
Para usar a HA com este cluster a Marque a caixa de seleção vSphere HA Ativar (Turn ON).
b Selecione se deseja ativar o monitoramento do host e o controle de
admissão.
c Se o controle de admissão estiver ativado, especifique uma política.
d Selecione uma opção de Monitoramento de VM.
e Especifique a sensibilidade de monitoramento da máquina virtual.
5 Selecione uma configuração de Compatibilidade aprimorada do vMotion (EVC).
O EVC garante que todos os hosts em um cluster apresentem o mesmo conjunto de recursos
de CPU para máquinas virtuais, mesmo se as CPUs reais nos hosts forem diferentes. Isso
impede que as migrações com o vMotion falhem devido a CPUs incompatíveis.
Resultados
O cluster é adicionado ao inventário.

Próximo passo
Adicione hosts e pools de recursos ao cluster.
Observação Na página Resumo do Cluster (Cluster Summary), você pode ver Serviços de
Cluster (Cluster Services) que exibe o status de integridade dos Serviços de Cluster do vSphere.
Editar configurações do cluster

Quando você adiciona um host a um cluster do DRS, os recursos do host tornam-se parte dos
recursos do cluster. Além dessa agregação de recursos, com um cluster do DRS, você pode
oferecer suporte a pools de recursos de todo o cluster e impor políticas de alocação de recursos
no nível do cluster.
Os seguintes recursos de gerenciamento de recursos no nível do cluster também estão

disponíveis.
Balanceamento de Carga
A distribuição e o uso de recursos de CPU e memória para todos os hosts e máquinas

virtuais no cluster são monitorados continuamente. O DRS compara essas métricas com o
uso ideal de recursos, dados os atributos dos pools de recursos e das máquinas virtuais
do cluster, a demanda atual e o destino do desequilíbrio. O DRS fornece recomendações
ou executa migrações de máquina virtual de acordo. Consulte Migração de máquina virtual.
Quando você liga uma máquina virtual no cluster, o DRS tenta manter o balanceamento
de carga adequado colocando a máquina virtual em um host apropriado ou fazendo uma
recomendação. Consulte Controle de admissão e colocação inicial.
Gerenciamento de energia
Quando o recurso vSphere Distributed Power Management (DPM) está ativado, o DRS
compara a capacidade de cluster e de nível de host com as demandas das máquinas virtuais
do cluster, incluindo a demanda histórica recente. Em seguida, o DRS recomenda colocar
os hosts no modo de espera ou coloca os hosts no modo de energia em espera quando
for encontrado excesso de capacidade. O DRS liga os hosts se a capacidade for necessária.
Dependendo das recomendações de estado de energia do host resultantes, as máquinas
virtuais também podem precisar ser migradas de e para os hosts. Consulte Gerenciamento
de recursos de energia.
Regras de Afinidade
Você pode controlar o posicionamento de máquinas virtuais em hosts em um cluster,

atribuindo regras de afinidade. Consulte Usando regras de afinidade do DRS.

Pré-requisitos
Você pode criar um cluster sem uma licença especial, mas deve ter uma licença para habilitar um
cluster para o vSphere DRS ou o vSphere HA.
Procedimentos
1 Navegue até um cluster no vSphere Client.
2 Clique na guia Configurar (Configure) e clique em Serviços (Services).
3 Em vSphere DRS (vSphere DRS), clique em Editar (Edit).
4 Em Automação do DRS (DRS Automation), selecione um nível de automação padrão para o

DRS.
Nível de automação Ação
Manual n Posicionamento inicial: O host recomendado é exibido.

n Migração: a recomendação é exibida.
Parcialmente automatizado n Posicionamento inicial: Automático.

n Migração: a recomendação é exibida.
Totalmente automatizado n Posicionamento inicial: Automático.

n Migração: a recomendação é executada automaticamente.
5 Defina o Limite de Migração (Migration Threshold) para DRS.
6 Marque a caixa de seleção Predictive DRS (Predictive DRS). Além das métricas em tempo
real, o DRS responde às métricas previstas fornecidas pelo servidor vRealize Operations.
Você também deve configurar o DRS Preditivo (Predictive DRS) em uma versão de vRealize
Operations compatível com esse recurso.
7 Marque a caixa de seleção Automação de Máquina Virtual (Virtual Machine Automation)

para ativar os níveis individuais de automação de máquina virtual.
A substituição de máquinas virtuais individuais pode ser definida na página Substituições de

VM.

8 Em Opções adicionais (Additional Options), marque a caixa de seleção para aplicar uma das
políticas padrão.
Opção Descrição
Distribuição de VM Para verificar a disponibilidade, distribua um número mais par de máquinas

virtuais entre hosts. Isso é secundário ao balanceamento de carga do DRS.
Métrica de memória para Balanceamento de carga com base na memória consumida de máquinas
balanceamento de carga virtuais em vez da memória ativa. Essa configuração é recomendada apenas
para clusters onde a memória do host não está comprometida demais.
Observação Essa configuração não é mais compatível e não será exibida

no vCenter 7.0.
Comprometimento excessivo da Controlar o comprometimento excessivo da CPU no cluster.

CPU
Compartilhamentos dimensionáveis Habilite os compartilhamentos dimensionáveis para os pools de recursos

neste cluster.
9 Em Gerenciamento de energia (Power Management), selecione Nível de automação.
10 Se o DPM estiver ativado, defina o Limite do DPM (DPM Threshold).
Próximo passo
Observação Na página Resumo do Cluster (Cluster Summary), você pode ver Serviços de
Cluster (Cluster Services) que exibe o status de integridade dos Serviços de Cluster do vSphere.
Você pode visualizar a utilização da memória para DRS no vSphere Client. Para saber mais,
consulte:
Exibindo a utilização da memória do Agendador de Recursos Distribuídos
bctid=ref:video_vsphere67_drs)
Definir um nível de automação personalizado para uma

máquina virtual
Depois de criar um cluster do DRS, você pode personalizar o nível de automação de máquinas
virtuais individuais para substituir o nível de automação padrão do cluster.
Por exemplo, você pode selecionar Manual (Manual) para máquinas virtuais específicas em um
cluster com automação completa ou Parcialmente Automatizado (Partially Automated) para
máquinas virtuais específicas em um cluster manual.
Se uma máquina virtual estiver definida como Desativado (Disabled), vCenter Server não
migrará essa máquina virtual nem fornecerá recomendações de migração para ela.

Procedimentos
3 Em Serviços, selecione vSphere DRS (vSphere DRS) e clique em Editar (Edit). Expanda
Automação do DRS.
4 Marque a caixa de seleção Habilitar níveis de automação de máquina virtual individual

(Enable individual virtual machine automation levels).
5 Para desativar temporariamente qualquer substituição de máquina virtual individual,

desmarque a caixa de seleção Ativar níveis de automação de máquina virtual individuais
(Enable individual virtual machine automation levels).
As configurações da máquina virtual são restauradas quando a caixa de seleção é marcada

novamente.
6 Para suspender temporariamente todas as atividades do vMotion em um cluster, coloque o

cluster no modo manual e desmarque a caixa de seleção Ativar níveis de automação de
máquina virtual individuais (Enable individual virtual machine automation levels).
7 Selecione uma ou mais máquinas virtuais.
8 Clique na coluna Nível de automação (Automation Level) e selecione um nível de automação

no menu suspenso.
Opção Descrição
Manual As recomendações de posicionamento e migração são exibidas, mas não

são executadas até que você aplique manualmente a recomendação.
Totalmente automatizado As recomendações de posicionamento e migração são executadas

automaticamente.
Parcialmente automatizado O posicionamento inicial é realizado automaticamente. As recomendações

de migração são exibidas, mas não são executadas.
Desativado vCenter Server não migra a máquina virtual nem fornece recomendações de
migração para ela.
Resultados
Observação Outros VMware produtos ou recursos, como o vSphere vApp e o vSphere Fault
Tolerance, podem substituir os níveis de automação de máquinas virtuais em um cluster DRS.
Consulte a documentação específica do produto para obter detalhes.
Desativar DRS
Você pode desativar o DRS para um cluster.

Quando o DRS está desativado, as regras de afinidade e hierarquia do pool de recursos do

cluster não são restabelecidas quando o DRS é ativado novamente. Se você desativar o DRS, os
pools de recursos serão removidos do cluster. Para evitar a perda dos pools de recursos, salve
um snapshot da árvore do pool de recursos na máquina local. Você pode usar o snapshot para
restaurar o pool de recursos ao habilitar o DRS.
Procedimentos
3 Em vSphere DRS (vSphere DRS), clique em Editar (Edit).
4 Desmarque a caixa de seleção Ativar vSphere DRS (Turn On vSphere DRS).
5 Clique em OK (OK) para desativar o DRS.
6 (Opcional) Escolha uma opção para salvar o pool de recursos.
n Clique em Sim (Yes) para salvar um instantâneo da árvore do pool de recursos em uma
máquina local.
n Clique em Não (No) para desativar o DRS sem salvar um instantâneo da árvore do pool
de recursos.
Resultados
O DRS está desativado.
Restaurar uma árvore do pool de recursos

Você pode restaurar um snapshot de árvore do pool de recursos salvo anteriormente.
Pré-requisitos
n O vSphere DRS deve estar ativado.
n Você pode restaurar um snapshot apenas no mesmo cluster em que ele foi tirado.
n Nenhum outro pool de recursos está presente no cluster.
Procedimentos
2 Clique com o botão direito do mouse no cluster e selecione Restaurar Árvore do Pool de
Recursos (Restore Resource Pool Tree).

3 Clique em Procurar (Browse) e localize o arquivo de snapshot na máquina local.
4 Clique em Abrir(Open).
5 Clique em OK (OK) para restaurar a árvore do pool de recursos.
Reconhecimento de DRS do cluster estendido do vSAN

O reconhecimento de DRS do vSAN Stretched Cluster está disponível em clusters estendidos
com o DRS ativado usando o vSphere 7.0 U2. Um cluster estendido do vSAN tem localidade
de leitura, onde a VM lê dados de um site local. A obtenção de leituras de um site remoto
pode afetar o desempenho da VM. Em versões anteriores ao vSphere 7.0 U2, o DRS não
tinha conhecimento da localidade de leitura para clusters estendidos do vSAN e podia colocar
inadvertidamente uma VM em um site remoto sem localidade de leitura. Com o reconhecimento
do DRS do cluster estendido do vSAN, o DRS agora está totalmente ciente da localidade de
leitura da VM e colocará a VM em um site que possa satisfazer totalmente a localidade de leitura.
Isso é automático, não há opções configuráveis. O reconhecimento do DRS do cluster estendido
do vSAN funciona com as regras de afinidade existentes. Ele funciona com o vSphere 7.0 U2 e o
VMware Cloud on AWS.
O vSAN Stretched Cluster com vSphere HA e o vSphere DRS fornecem resiliência ao ter duas
cópias de dados espalhados por dois domínios de falha e um nó testemunha em um terceiro
domínio de falha em caso de falhas. Os dois domínios de falha ativos fornecem replicação de
dados para que ambos os domínios de falha tenham uma cópia atual dos dados.
O cluster estendido do vSAN fornece um método automatizado de movimentação de cargas de

trabalho nos dois domínios de falha. Em caso de falhas no site completo, as VMs são reiniciadas
no site secundário por vSphere HA. Isso garante que não haja tempo de inatividade para cargas
de trabalho de produção críticas. Quando o site primário estiver online novamente, o DRS
imediatamente reequilibra as VMs de volta para o site primário com hosts de afinidade flexível.
Esse processo faz com que a VM leia e grave no site secundário enquanto os componentes de
dados da VM ainda estão sendo recriados e pode reduzir o desempenho da VM.
Em versões anteriores ao vSphere 7.0 U2, recomendamos que você altere o DRS do modo
totalmente automatizado para o modo parcialmente automatizado, para evitar a migração de
VMs enquanto a ressincronização está em andamento para o site primário. Defina o DRS de volta
para totalmente automatizado somente após a ressincronização ser concluída.
Com o vSphere 7.0 U2, o DRS Awareness of vSAN Stretched Cluster apresenta uma solução
de localidade de leitura totalmente automatizada para a recuperação de falhas em um cluster
estendido do vSAN. As informações de localidade lidas indicam os hosts aos quais a VM
tem acesso total, e o DRS usa essas informações ao colocar uma VM em um host em
clusters estendidos do vSAN. O DRS impede que as VMs retornem ao site primário quando
a ressincronização do vSAN ainda estiver em andamento durante a fase de recuperação do
site. O DRS migra automaticamente uma VM de volta para o site afinado primário quando seus
componentes de dados atingem a localidade de leitura completa. Isso permite que você opere o
DRS no modo totalmente automático em caso de falhas no site completo.

Em caso de falhas parciais do site, se uma VM perder a localidade de leitura devido à perda
de componentes de dados maiores ou iguais às suas Falhas no vSphere, o DRS identificará as
VMs que consomem uma largura de banda de leitura muito alta e tentará reequilibrá-las para
o site secundário . Isso garante que as VMs com cargas de trabalho pesadas de leitura não
sofram durante falhas parciais do site. Depois que o site primário estiver online novamente e os
componentes de dados tiverem concluído a ressincronização, a VM será movida de volta para o
site ao qual está associada.

Funcionalidade do modo de
manutenção do DRS com licença
empresarial ROBO
12
No vSphere 6.7 U2, a licença corporativa do Remote Office Branch Office (ROBO) de VMware é
compatível com evacuações automáticas de VM quando um host entra no modo de manutenção.
Em um cluster ROBO Enterprise, o DRS é desativado por padrão e você não pode fazer
alterações na configuração do DRS. Quando um host em um cluster ROBO Enterprise entra em
modo de manutenção, as VMs são automaticamente evacuadas do host pelo DRS. Antes de
evacuar as VMs do host, o DRS cria mapeamentos de afinidade de host de VM para rastrear
onde as VMs foram colocadas. Quando o host sai do modo de manutenção, as VMs que estavam
em execução no host são migradas de volta para o host. Os mapeamentos de afinidade de host
de VM são limpos após a migração.
n Limitações do modo de manutenção do DRS com licença empresarial ROBO
n Usando o modo de manutenção DRS com a licença empresarial ROBO
n Solucionando problemas do modo de manutenção do DRS com a licença empresarial ROBO
Limitações do modo de manutenção do DRS com licença

empresarial ROBO
A funcionalidade DRS com a licença empresarial ROBO não é uma funcionalidade DRS completa.
Você deve estar ciente de algumas limitações antes de iniciar o modo de manutenção em um
cluster ROBO Enterprise. Em um cluster ROBO Enterprise, o DRS é desativado por padrão.
Se você tiver migrado de uma licença compatível com DRS para uma licença empresarial
ROBO, poderá ter VMs com regras de afinidade ou antiafinidade presentes no sistema. Você
deve desativar ou excluir VMs com regras de afinidade ou antiafinidade, ou a operação
do modo de manutenção do ROBO Enterprise está desativada. A operação do modo de
manutenção ROBO Enterprise será desativada se o DRS não estiver definido como o modo
totalmente automatizado. O nível de automação do DRS deve ser definido no modo totalmente
automatizado para evacuar as VMs automaticamente por meio do fluxo de trabalho de
manutenção do host. Se uma VM substituir o modo totalmente automatizado do DRS, você
deverá evacuar a VM manualmente.

Usando o modo de manutenção DRS com a licença

empresarial ROBO
O vSphere 6.7 U2 oferece suporte à funcionalidade limitada do modo de manutenção DRS com a
licença empresarial ROBO.
Pré-requisitos
n Verifique se todos os hosts em um cluster têm a Licença Empresarial ROBO instalada. Caso
contrário, você deverá instalar a licença.
n Verifique se alguma regra de DRS está configurada e ativada. Se estiverem, desative-os ou

exclua-os para usar a operação do modo de manutenção do ROBO Enterprise.
Procedimentos
1 Para que o Modo de Manutenção DRS funcione com a Licença Empresarial ROBO, certifique-
se de que cada host no cluster tenha a Licença Empresarial ROBO instalada.
n Se a licença não estiver instalada, vá para a etapa 2.
n Se a licença estiver instalada, vá para a etapa 3.
2 Instalar a licença empresarial ROBO
a Navegue até o host no vSphere Client.
b Na guia Configurar (Configure), selecione Licenciamento (Licensing).
c Clique em ATRIBUIR LICENÇA (ASSIGN LICENSE).
d Insira sua chave de licença empresarial ROBO e clique em OK (OK).
Você deve repetir essas etapas para todos os hosts no cluster.
3 Selecione o host no cluster, clique com o botão direito do mouse e selecione Entrar no Modo
de Manutenção (Enter Maintenance Mode) e clique em OK (OK).
As VMs no host são evacuadas automaticamente.
Resultados
Depois que o host sair do modo de manutenção, as VMs serão migradas automaticamente de
volta para o host. O host é restaurado para o estado original. No entanto, se um host estiver
sobrecarregado, o DRS não poderá migrar as VMs de volta para o host original. O DRS tenta
restaurar o host para o estado original, mas não pode tornar um host sobrecarregado.
Próximo passo
Se você precisar desativar o Modo de Manutenção DRS com a Licença Empresarial ROBO,
poderá editar o arquivo vpxd.cfg. Abra o arquivo vpxd.cfg. Na opção <cluster> ,
altere <roboMMEnabled> true </roboMMEnabled> para <roboMMEnabled> false </
roboMMEnabled> . Essa é a configuração do tempo de execução, portanto, você não precisa
reiniciar o vpxd após atualizar a configuração.

Solucionando problemas do modo de manutenção do DRS

com a licença empresarial ROBO
Se você tiver problemas ao usar o modo de manutenção com seu cluster ROBO Enterprise,
considere o seguinte.
Para que o modo de manutenção funcione corretamente com um cluster ROBO Enterprise:
n Verifique se todos os hosts em um cluster têm a Licença Empresarial ROBO instalada. Caso
contrário, você deverá instalar a licença.
n Verifique se alguma regra de DRS está configurada e ativada. Se estiverem, desative-os ou

exclua-os para usar a operação do modo de manutenção do ROBO Enterprise.
n Se a verificação de compatibilidade falhar, verifique se os outros hosts são compatíveis com

a VM.

Usando clusters do DRS para
gerenciar recursos 13
Depois de criar um cluster do DRS, você pode personalizá-lo e usá-lo para gerenciar recursos.
Para personalizar seu cluster do DRS e os recursos que ele contém, você pode configurar regras
de afinidade e adicionar e remover hosts e máquinas virtuais. Quando as configurações e os
recursos de um cluster tiverem sido definidos, você deverá garantir que ele seja e continue
sendo um cluster válido. Você também pode usar um cluster DRS válido para gerenciar recursos
de energia e interoperar com vSphere HA.
n Adicionando hosts a um cluster
n Adicionando máquinas virtuais a um cluster
n Removendo máquinas virtuais de um cluster
n Removendo um host de um cluster
n Validade do cluster do DRS
n Gerenciamento de recursos de energia
n Usando regras de afinidade do DRS
Adicionando hosts a um cluster

O procedimento para adicionar hosts a um cluster é diferente para hosts gerenciados pelo
mesmo vCenter Server (hosts gerenciados) do que para hosts não gerenciados por esse
servidor.
Depois que um host é adicionado, as máquinas virtuais implantadas no host tornam-se parte do
cluster, e o DRS pode recomendar a migração de algumas máquinas virtuais para outros hosts no
cluster.

Adicionar um host gerenciado a um cluster

Quando você adiciona um host autônomo já sendo gerenciado por vCenter Server a um cluster
do DRS, os recursos do host tornam-se associados ao cluster.
Você pode decidir se deseja associar máquinas virtuais e pools de recursos existentes ao pool de
recursos raiz do cluster ou enxertar a hierarquia do pool de recursos.
Observação Se um host não tiver pools de recursos filho ou máquinas virtuais, os recursos do
host serão adicionados ao cluster, mas nenhuma hierarquia de pool de recursos com um pool de
recursos de nível superior será criada.
Procedimentos
2 Clique com o botão direito do mouse no host e selecione Mover para ... (Move To...).
3 Selecione um cluster.
4 Clique em OK (OK) para aplicar as alterações.
5 Selecione o que fazer com as máquinas virtuais e os pools de recursos do host.
n Colocar as máquinas virtuais deste host no pool de recursos raiz do cluster (Put this
host’s virtual machines in the cluster’s root resource pool)
vCenter Server remove todos os pools de recursos existentes do host e as máquinas

virtuais na hierarquia do host estão todas anexadas à raiz. Como as alocações de
compartilhamento são relativas a um pool de recursos, talvez você precise alterar
manualmente os compartilhamentos de uma máquina virtual depois de selecionar essa
opção, o que destrói a hierarquia do pool de recursos.
n Crie um pool de recursos para as máquinas virtuais e pools de recursos deste host
(Create a resource pool for this host’s virtual machines and resource pools)
vCenter Server cria um pool de recursos de nível superior que se torna um filho direto
do cluster e adiciona todos os filhos do host a esse novo pool de recursos. Você
pode fornecer um nome para esse novo pool de recursos de nível superior. O padrão
é Grafado de <host_name> (Grafted from <host_name>).
Resultados
O host é adicionado ao cluster.
Adicionar um host não gerenciado a um cluster

Você pode adicionar um host não gerenciado a um cluster. No momento, esse host não é
gerenciado pelo mesmo sistema vCenter Server que o cluster e não está visível no vSphere
Client.

Procedimentos
2 Clique com o botão direito do mouse no cluster e selecione Adicionar Host (Add Host).
3 Digite o nome do host, o nome de usuário e a senha e clique em Avançar (Next).
4 Visualize as informações de resumo e clique em Avançar (Next).
5 Atribua uma chave de licença nova ou existente e clique em Avançar (Next).
6 (Opcional) Você pode ativar o modo de bloqueio para impedir que usuários remotos façam
login diretamente no host.
Se você não ativar o modo de bloqueio, poderá configurar essa opção mais tarde editando o
Perfil de segurança nas configurações do host.
7 Selecione o que fazer com as máquinas virtuais e os pools de recursos do host.
n Colocar as máquinas virtuais deste host no pool de recursos raiz do cluster (Put this
host’s virtual machines in the cluster’s root resource pool)
vCenter Server remove todos os pools de recursos existentes do host e as máquinas

virtuais na hierarquia do host estão todas anexadas à raiz. Como as alocações de
compartilhamento são relativas a um pool de recursos, talvez você precise alterar
manualmente os compartilhamentos de uma máquina virtual depois de selecionar essa
opção, o que destrói a hierarquia do pool de recursos.
n Crie um pool de recursos para as máquinas virtuais e pools de recursos deste host
(Create a resource pool for this host’s virtual machines and resource pools)
vCenter Server cria um pool de recursos de nível superior que se torna um filho direto
do cluster e adiciona todos os filhos do host a esse novo pool de recursos. Você
pode fornecer um nome para esse novo pool de recursos de nível superior. O padrão
é Grafado de <host_name> (Grafted from <host_name>).
8 Revise as configurações e clique em Concluir (Finish).
Resultados
O host é adicionado ao cluster.
Adicionando máquinas virtuais a um cluster

Você pode adicionar uma máquina virtual a um cluster de várias maneiras.
n Quando você adiciona um host a um cluster, todas as máquinas virtuais nesse host são
adicionadas ao cluster.
n Quando uma máquina virtual é criada, o assistente de Nova Máquina Virtual solicita a
localização da máquina virtual. Você pode selecionar um host autônomo ou um cluster e
pode selecionar qualquer pool de recursos dentro do host ou cluster.

n Você pode migrar uma máquina virtual de um host autônomo para um cluster ou de um
cluster para outro cluster usando o assistente Migrar Máquina Virtual . Para iniciar esse
assistente, clique com o botão direito do mouse no nome da máquina virtual e selecione
Migrar (Migrate).
Mover uma máquina virtual para um cluster

Você pode mover uma máquina virtual para um cluster.
Procedimentos
1 Encontre a máquina virtual em vSphere Client.
2 Clique com o botão direito do mouse na máquina virtual e selecione Mover para ... (Move
To...).
3 Selecione um cluster.
Removendo máquinas virtuais de um cluster

Você pode remover máquinas virtuais de um cluster.
Você pode remover uma máquina virtual de um cluster de duas maneiras.
n Quando você remove um host de um cluster, todas as máquinas virtuais desligadas que você
não migra para outros hosts também são removidas. Você pode remover um host somente
se ele estiver no modo de manutenção ou desconectado. Se você remover um host de um
cluster do DRS, o cluster poderá ficar amarelo porque está comprometido demais.
n Você pode migrar uma máquina virtual de um cluster para um host autônomo ou de um
cluster para outro cluster usando o assistente Migrar . Para iniciar esse assistente, clique com
o botão direito do mouse no nome da máquina virtual e selecione Migrar (Migrate).
Mover uma máquina virtual de um cluster

Você pode mover uma máquina virtual de um cluster.
Procedimentos

2 Clique com o botão direito do mouse na máquina virtual e selecione Migrar (Migrate).
3 Selecione Alterar datastore (Change datastore) e clique em Próximo (Next).
4 Selecione um datastore e clique em Avançar (Next).
5 Clique em Concluir(Finish).
Se a máquina virtual for um membro de um grupo de regras de cluster DRS, vCenter Server
exibirá um aviso antes de permitir que a migração prossiga. O aviso indica que as máquinas
virtuais dependentes não são migradas automaticamente. Você precisa confirmar o aviso
antes que a migração possa prosseguir.
Removendo um host de um cluster

Ao remover um host de um cluster do DRS, você afeta hierarquias de pool de recursos, máquinas
virtuais e pode criar clusters inválidos. Considere os objetos afetados antes de remover o host.
n Hierarquias do pool de recursos - Quando você remove um host de um cluster, o host retém
apenas o pool de recursos raiz, mesmo se você tiver usado um cluster DRS e tiver decidido
implementar o pool de recursos do host quando adicionar o host ao cluster. Nesse caso, a
hierarquia permanece com o cluster. Você pode criar uma hierarquia de pool de recursos
específica do host.
Observação Certifique-se de remover o host do cluster, primeiro colocando-o no modo de

manutenção. Se você desconectar o host antes de removê-lo do cluster, o host manterá o
pool de recursos que reflete a hierarquia do cluster.
n Máquinas virtuais - Um host deve estar no modo de manutenção antes que você possa
removê-lo do cluster e, para que um host entre no modo de manutenção, todas as máquinas
virtuais ligadas devem ser migradas desse host. Quando você solicita que um host entre
no modo de manutenção, você também é perguntado se deseja migrar todas as máquinas
virtuais desligadas nesse host para outros hosts no cluster.
n Clusters Inválidos - Quando você remove um host de um cluster, os recursos disponíveis

para o cluster diminuem. Se o cluster tiver recursos suficientes para satisfazer as reservas
de todas as máquinas virtuais e pools de recursos no cluster, o cluster ajustará a alocação
de recursos para refletir a quantidade reduzida de recursos. Se o cluster não tiver recursos
suficientes para satisfazer as reservas de todos os pools de recursos, mas houver recursos
suficientes para satisfazer as reservas para todas as máquinas virtuais, um alarme será
emitido e o cluster será marcado em amarelo. O DRS continua a ser executado.
Colocar um host no modo de manutenção

Você coloca um host no modo de manutenção quando precisa repará-lo, por exemplo, para
instalar mais memória. Um host entra ou sai do modo de manutenção apenas como resultado de
uma solicitação do usuário.

As máquinas virtuais que estão em execução em um host que entra no modo de manutenção
precisam ser migradas para outro host (manual ou automaticamente pelo DRS) ou desligadas. O
host está em um estado de Entrando no Modo de Manutenção (Entering Maintenance Mode)
até que todas as máquinas virtuais em execução sejam desligadas ou migradas para hosts
diferentes. Não é possível ligar máquinas virtuais ou migrar máquinas virtuais para um host que
entra no modo de manutenção.
Quando não houver mais máquinas virtuais em execução no host, o ícone do host mudará para
incluir em manutenção (under maintenance) e o painel Resumo do host indicará o novo estado.
Enquanto estiver no modo de manutenção, o host não permite que você implante ou ligue uma
máquina virtual.
Observação O DRS não recomenda (ou executa, no modo totalmente automatizado) qualquer
migração de máquina virtual de um host que entre no modo de manutenção ou de espera se o
nível de failover vSphere HA for violado depois que o host entrar no modo solicitado.
Procedimentos
2 Clique com o botão direito do mouse no host e selecione Modo de Manutenção

(Maintenance Mode) > Entrar no Modo de Manutenção (Enter Maintenance Mode).
n Se o host fizer parte de um cluster do DRS parcialmente automatizado ou manual,

navegue até Cluster (Cluster) > Monitor (Monitor) > DRS (DRS) > Recomendações
( Recommendations) e clique em Aplicar recomendações (Apply Recommendations).
n Se o host fizer parte de um cluster do DRS automatizado, as máquinas virtuais serão

migradas para diferentes hosts quando o host entrar no modo de manutenção.
3 Se aplicável, clique em Sim (Yes).
Resultados
O host está no modo de manutenção até que você selecione Modo de Manutenção
(Maintenance Mode) > Sair do Modo de Manutenção (Exit Maintenance Mode).
Remover um host de um cluster

Você pode remover hosts de um cluster.
Procedimentos
2 Clique com o botão direito do mouse no host e selecione Maintenance Mode (Maintenance
Mode) > Enter Maintenance Mode (Enter Maintenance Mode).
Quando o host estiver no modo de manutenção, mova-o para um local de inventário

diferente, o centro de dados de nível superior ou para um cluster diferente.
3 Clique com o botão direito do mouse no host e selecione Mover para ... (Move To...).

4 Selecione um novo local para o host e clique em OK (OK).
Resultados
Quando você move o host, seus recursos são removidos do cluster. Se você enxertou a
hierarquia do pool de recursos do host no cluster, essa hierarquia permanecerá com o cluster.
Próximo passo
Depois de remover um host de um cluster, você pode realizar as seguintes tarefas.
n Remova o host de vCenter Server.
n Execute o host como um host independente em vCenter Server.
n Mova o host para outro cluster.
Usando o modo de espera

Quando uma máquina host é colocada no modo de espera, ela é desligada.
Normalmente, os hosts são colocados no modo de espera pelo recurso do vSphere DPM
para otimizar o uso de energia. Você também pode colocar um host no modo de espera
manualmente. No entanto, o DRS pode desfazer (ou recomendar desfazer) sua alteração na
próxima vez que ela for executada. Para forçar um host para permanecer desligado, coloque-o
no modo de manutenção e desligue-o.
Validade do cluster do DRS

O vSphere Client indica se um cluster DRS é válido, supercomprometido (amarelo) ou inválido
(vermelho).
Os clusters DRS ficam comprometidos demais ou são inválidos por vários motivos.
n Um cluster pode ficar supercomprometido se um host falhar.
n Um cluster se tornará inválido se vCenter Server estiver indisponível e você ligar as máquinas
virtuais usando o vSphere Client.
n Um cluster se tornará inválido se o usuário reduzir a reserva em um pool de recursos pai

enquanto uma máquina virtual estiver em processo de failover.
n Se forem feitas alterações em hosts ou máquinas virtuais usando o vSphere Client enquanto
vCenter Server estiver indisponível, essas alterações entrarão em vigor. Quando vCenter
Server estiver disponível novamente, você poderá descobrir que os clusters ficaram
vermelhos ou amarelos porque os requisitos do cluster não são mais atendidos.
Ao considerar os cenários de validade do cluster, você deve compreender esses termos.
Reserva
Uma alocação fixa e garantida para a entrada do pool de recursos pelo usuário.
Reserva usada

A soma da reserva ou reserva usada (o que for maior) para cada pool de recursos filho,
adicionada recursivamente.
Sem reserva
Esse número não negativo difere de acordo com o tipo de pool de recursos.
n Nenhum pools de recursos expansíveis: reserva menos reserva usada.
n Pools de recursos expansíveis: (reserva menos reserva usada) mais quaisquer recursos
não reservados que podem ser emprestados de seus pools de recursos ancestrais.
Clusters de DRS válidos

Um cluster válido tem recursos suficientes para atender a todas as reservas e oferecer suporte a
todas as máquinas virtuais em execução.
A figura a seguir mostra um exemplo de um cluster válido com pools de recursos fixos e como
seus recursos de CPU e memória são computados.
Figura 13-1. Cluster válido com pools de recursos fixos
cluster
Total Capacity: 12G
Reserved Capacity: 11G
Available Capacity: 1G
RP1 RP2 RP3

Reservation: 4G Reservation: 4G Reservation: 3G
Reservation Used: 4G Reservation Used: 3G Reservation Used: 3G
Unreserved: 0G Unreserved: 1G Unreserved: 0G
VM1, 2G VM6, 2G VM2, 2G VM3, 3G VM5, 2G
VM7, 2G VM4, 1G VM8, 2G
O cluster tem as seguintes características:
n Um cluster com recursos totais de 12 GHz.
n Três pools de recursos, cada um do tipo Fixo (Fixed) ( Reserva Expansível (Expandable
Reservation) não está selecionado).
n A reserva total dos três pools de recursos combinados é de 11 GHz (4 + 4 + 3 GHz). O total é
mostrado no campo Capacidade Reservada (Reserved Capacity) para o cluster.

n O RP1 foi criado com uma reserva de 4GHz. Duas máquinas virtuais. (VM1 e VM7) de 2 GHz
cada estão ligadas ( Reserva Usada (Reservation Used): 4GHz). Não há recursos restantes
para ligar máquinas virtuais adicionais. VM6 é mostrado como não ligado. Ele não consome
nenhuma reserva.
n O RP2 foi criado com uma reserva de 4GHz. Duas máquinas virtuais de 1 GHz e 2 GHz estão
ligadas ( Reserva Usada (Reservation Used): 3GHz). 1 GHz permanece sem reserva.
n O RP3 foi criado com uma reserva de 3GHz. Uma máquina virtual com 3GHz está ligada. Não
há recursos disponíveis para ligar máquinas virtuais adicionais.
A figura a seguir mostra um exemplo de um cluster válido com alguns pools de recursos (RP1 e
RP3) usando o tipo de reserva Expansível (Expandable).
Figura 13-2. Cluster válido com pools de recursos expansíveis
cluster
Total Capacity: 16G
RP1 (expandable) RP2 RP3 (expandable)

VM7, 2G VM4, 1G VM8, 2G
Um cluster válido pode ser configurado da seguinte maneira:
n Um cluster com recursos totais de 16 GHz.
n RP1 e RP3 são do tipo expansível (Expandable), RP2 é do tipo Fixo.
n A reserva total usada dos três pools de recursos combinados é 16 GHz (6 GHz para RP1, 5
GHz para RP2 e 5 GHz para RP3). 16 GHz aparece como a Capacidade Reservada (Reserved
Capacity) para o cluster no nível superior.

n O RP1 foi criado com uma reserva de 4GHz. Três máquinas virtuais de 2 GHz cada estão
ligadas. Duas dessas máquinas virtuais (por exemplo, VM1 e VM7) podem usar reservas do
RP1, enquanto a terceira máquina virtual (VM6) pode usar reservas do pool de recursos do
cluster. (Se o tipo desse pool de recursos fosse Fixo (Fixed), você não conseguiria ligar a
máquina virtual adicional.)
n O RP2 foi criado com uma reserva de 5 GHz. Duas máquinas virtuais de 1 GHz e 2 GHz estão
ligadas ( Reserva Usada (Reservation Used): 3GHz). 2 GHz permanece sem reserva.
O RP3 foi criado com uma reserva de 5 GHz. Duas máquinas virtuais de 3GHz e 2GHz estão
ligadas. Mesmo que esse pool de recursos seja do tipo Expansível (Expandable), nenhuma
máquina virtual de 2 GHz adicional pode ser ligada porque os recursos extras do pai já estão
sendo usados pelo RP1.
Clusters de DRS supercomprometidos

Um cluster fica comprometido demais (amarelo) quando a árvore de pools de recursos e
máquinas virtuais é internamente consistente, mas o cluster não tem a capacidade de oferecer
suporte a todos os recursos reservados pelos pools de recursos filho.
Sempre haverá recursos suficientes para oferecer suporte a todas as máquinas virtuais em
execução porque, quando um host fica indisponível, todas as suas máquinas virtuais ficam
indisponíveis. Um cluster normalmente fica amarelo quando a capacidade do cluster é reduzida
repentinamente, por exemplo, quando um host no cluster fica indisponível. VMware recomenda
que você deixe recursos de cluster adicionais adequados para evitar que o cluster fique amarelo.
Figura 13-3. Cluster amarelo
cluster
X
Total Capacity:12G 8G

VM4, 1G VM7, 0G

Neste exemplo:
n Um cluster com recursos totais de 12 GHz provenientes de três hosts de 4 GHz cada.
n Três pools de recursos reservando um total de 12 GHz.
n A reserva total usada pelos três pools de recursos combinados é de 12 GHz (4 + 5 + 3 GHz).
Isso aparece como a Capacidade Reservada (Reserved Capacity) no cluster.
n Um dos hosts de 4 GHz fica indisponível, então o total de recursos é reduzido para 8 GHz.
n Ao mesmo tempo, VM4 (1 GHz) e VM3 (3GHz), que estavam em execução no host que falhou,
não estão mais em execução.
n O cluster agora está executando máquinas virtuais que exigem um total de 6 GHz. O cluster
ainda tem 8 GHz disponíveis, o que é suficiente para atender aos requisitos da máquina
virtual.
As reservas do pool de recursos de 12 GHz não podem mais ser atendidas, portanto o cluster
está marcado como amarelo.
Clusters de DRS inválidos

Um cluster habilitado para DRS se torna inválido (vermelho) quando a árvore não é mais
consistente internamente, ou seja, as restrições de recursos não são observadas.
A quantidade total de recursos no cluster não afeta se o cluster está vermelho. Um cluster pode
ser vermelho, mesmo se houver recursos suficientes no nível raiz, se houver uma inconsistência
em um nível filho.
Você pode resolver um problema de cluster DRS vermelho desligando uma ou mais máquinas
virtuais, movendo máquinas virtuais para partes da árvore que têm recursos suficientes
ou editando as configurações do pool de recursos na parte vermelha. Adicionar recursos
normalmente ajuda somente quando você está no estado amarelo.
Um cluster também pode ficar vermelho se você reconfigurar um pool de recursos enquanto
uma máquina virtual está fazendo failover. Uma máquina virtual com failover é desconectada e
não conta para a reserva usada pelo pool de recursos pai. Você pode reduzir a reserva do pool
de recursos pai antes que o failover seja concluído. Após a conclusão do failover, os recursos da
máquina virtual são cobrados novamente no pool de recursos pai. Se o uso do pool se tornar
maior do que a nova reserva, o cluster ficará vermelho.
Se um usuário puder iniciar uma máquina virtual (sem suporte) com uma reserva de 3GHz no
pool de recursos 2, o cluster ficará vermelho, conforme mostrado na figura a seguir.

Figura 13-4. Cluster vermelho
cluster
Total Capacity:12G
Reserved Capacity: 12G 15G

Reservation Used: 4G Reservation Used:2G 5G Reservation Used: 2G
Unreserved: 0G Unreserved: 0G Unreserved:4G 0G
VM1, 1G VM2, 3G VM3, 1G VM4, 1G VM5, 1G VM6, 1G
VM7, 3G
Gerenciamento de recursos de energia

O recurso vSphere Distributed Power Management (DPM) permite que um cluster DRS reduza
seu consumo de energia ativando e desativando hosts com base na utilização de recursos do
cluster.
O vSphere DPM monitora a demanda cumulativa de todas as máquinas virtuais no cluster por
recursos de memória e CPU e compara isso com a capacidade total de recursos disponíveis de
todos os hosts no cluster. Se for encontrado excesso de capacidade, o vSphere DPM colocará
um ou mais hosts no modo de espera e os desligará após a migração de suas máquinas virtuais
para outros hosts. Por outro lado, quando a capacidade é considerada inadequada, o DRS tira os
hosts do modo de espera (os liga) e usa o vMotion para migrar máquinas virtuais para eles. Ao
fazer esses cálculos, o vSphere DPM considera não apenas a demanda atual, mas também honra
todas as reservas de recursos da máquina virtual especificadas pelo usuário.
Se você habilitar Métricas previstas (Forecasted Metrics) ao criar um cluster DRS, o DPM emitirá
as propostas com antecedência, dependendo da janela de previsão contínua selecionada.
Observação ESXi hosts não podem ser automaticamente retirados do modo de espera, a
menos que estejam em execução em um cluster gerenciado por vCenter Server.

O vSphere DPM pode usar um dos três protocolos de gerenciamento de energia para tirar um
host do modo de espera: Intelligent Platform Management Interface (IPMI), Intelligent Platform
Management-out (iLO) ou Wake-On-LAN (WOL). Cada protocolo requer seu próprio suporte e
configuração de hardware. Se um host não for compatível com qualquer um desses protocolos,
ele não poderá ser colocado no modo de espera pelo vSphere DPM. Se um host suportar vários
protocolos, eles serão usados na seguinte ordem: IPMI, iLO, WOL.
Observação Não desconecte um host no modo de espera ou mova-o para fora do cluster DRS
sem primeiro ligá-lo, caso contrário, vCenter Server não poderá ligar o host novamente.
Definir as configurações de IPMI ou iLO para o vSphere DPM

O IPMI é uma especificação de nível de hardware e o Hewlett-Packard iLO é uma tecnologia de
gerenciamento de servidor incorporado. Cada um deles descreve e fornece uma interface para
monitoramento e controle de computadores remotamente.
Você deve realizar o seguinte procedimento em cada host.
Pré-requisitos
Tanto o IPMI quanto o iLO exigem um BMC (Baseboard Management Controller) de hardware
para fornecer um gateway para acessar funções de controle de hardware e permitir que a
interface seja acessada de um sistema remoto usando conexões seriais ou LAN. O BMC é ligado,
mesmo quando o host em si é desligado. Se ativado corretamente, o BMC poderá responder aos
comandos de ativação remota.
Se você planeja usar o IPMI ou o iLO como um protocolo de ativação, deverá configurar o BMC.
As etapas de configuração do BMC variam de acordo com o modelo. Consulte a documentação
do seu fornecedor para obter mais informações. Com o IPMI, você também deve garantir que o
canal de LAN da BMC esteja configurado para estar sempre disponível e permitir comandos com
privilégios de operador. Em alguns sistemas IPMI, quando você habilita "IPMI sobre LAN", deve
configurar isso no BIOS e especificar uma conta IPMI específica.
O vSphere DPM que usa apenas IPMI oferece suporte à autenticação baseada em MD5 e em
texto sem formatação, mas a autenticação baseada em MD2 não é compatível. vCenter Server
usa MD5 se o BMC de um host relatar que ele é compatível e habilitado para a função de
Operador. Caso contrário, a autenticação baseada em texto sem formatação será usada se o
BMC informar que ela é compatível e habilitada. Se nem o MD5 nem a autenticação de texto
sem formatação estiverem habilitados, o IPMI não poderá ser usado com o host e vCenter Server
tentará usar o recurso Ativar na LAN.
Procedimentos
3 Em Sistema (System), clique em Gerenciamento de energia (Power Management).

5 Insira as seguintes informações.
n Nome de usuário e senha para uma conta BMC. (O nome de usuário deve ter a
capacidade de ligar remotamente o host.)
n Endereço IP do NIC associado ao BMC, como distinto do endereço IP do host. O

endereço IP deve ser estático ou um endereço DHCP com concessão infinita.
n Endereço MAC da NIC associada ao BMC.
Testar a ativação na LAN para o vSphere DPM

O uso do Wake-on-LAN (WOL) para o recurso vSphere DPM é totalmente compatível, se você
o configurar e testar com êxito de acordo com as diretrizes VMware. Você deve realizar essas
etapas antes de habilitar o vSphere DPM para um cluster pela primeira vez ou em qualquer host
que esteja sendo adicionado a um cluster que esteja usando o vSphere DPM.
Pré-requisitos
Antes de testar o WOL, verifique se o cluster atende aos pré-requisitos.
n Seu cluster deve conter pelo menos dois hosts que são a versão ESX 3.5 (ou ESX 3i versão
3.5) ou posterior.
n O link de rede do vMotion de cada host deve estar funcionando corretamente. A rede
do vMotion também deve ser uma única sub-rede IP, não várias sub-redes separadas por
roteadores.
n O NIC do vMotion em cada host deve oferecer suporte ao WOL. Para verificar o suporte
ao WOL, primeiro determine o nome do adaptador de rede físico correspondente à porta
VMkernel selecionando o host no painel de inventário do vSphere Client, selecionando a
guia Configuração (Configuration) e clicando em Rede (Networking). Depois de obter essas
informações, clique em Adaptadores de Rede (Network Adapters) e localize a entrada
correspondente ao adaptador de rede. A coluna Wake On LAN Supported (Wake On LAN
Supported) para o adaptador relevante deve mostrar Sim.
n Para exibir o status de compatibilidade do WOL para cada NIC em um host, selecione o host
no painel de inventário do vSphere Client, selecione a guia Configuração (Configuration) e
clique em Adaptadores de Rede (Network Adapters). O NIC deve mostrar Sim na coluna
Wake On LAN Supported (Wake On LAN Supported).
n A porta do switch na qual cada NIC do vMotion compatível com WOL deve ser conectada
deve ser definida para negociar automaticamente a velocidade do link e não para uma
velocidade fixa (por exemplo, 1000 Mb / s). Muitas NICs suportam WOL somente se puderem
alternar para 100 Mb / s ou menos quando o host estiver desligado.

Depois de verificar esses pré-requisitos, teste cada ESXi host que usará o WOL para oferecer
suporte ao vSphere DPM. Ao testar esses hosts, certifique-se de que o recurso do vSphere DPM
esteja desativado para o cluster.
Cuidado Certifique-se de que qualquer host sendo adicionado a um cluster do vSphere

DPM que usa o WOL como um protocolo de ativação seja testado e desativado do uso do
gerenciamento de energia se ele falhar no teste. Se isso não for feito, o vSphere DPM poderá
desligar os hosts que, subsequentemente, não poderão ser ativados.
Procedimentos
2 Clique com o botão direito do mouse no host e selecione Energia (Power) > Entrar no modo
de espera (Enter Standby Mode)
Essa ação desliga o host.
3 Clique com o botão direito do mouse no host e selecione Ligar (Power) > Ligar (Power On)
para tentar tirá-lo do modo de espera.
4 Observe se o host é ligado ou não com êxito.
5 Para qualquer host que não saia do modo de espera com êxito, execute as seguintes etapas.
a Selecione o host em vSphere Client e selecione a guia Configurar (Configure).
b Em Hardware (Hardware) > Gerenciamento de Energia (Power Management), clique em

Editar (Edit) para ajustar a política de gerenciamento de energia.
Depois de fazer isso, o vSphere DPM não considera esse host um candidato para ser
desligado.
Habilitando o vSphere DPM para um cluster do DRS

Depois de executar as etapas de configuração ou teste exigidas pelo protocolo de ativação que
você está usando em cada host, você pode habilitar o vSphere DPM.
Configure as substituições de nível de automação de gerenciamento de energia, limite e nível de

host. Essas configurações são definidas em Gerenciamento de energia (Power Management) na
caixa de diálogo Configurações do cluster.
Você também pode criar tarefas agendadas para ativar e desativar o DPM para um cluster
usando o assistente Agendar tarefa: alterar configurações de energia do cluster .
Observação Se um host no seu cluster DRS tiver dispositivos USB conectados, desative o DPM
para esse host. Caso contrário, o DPM pode desligar o host e interromper a conexão entre o
dispositivo e a máquina virtual que o estava usando.

Nível de automação
Se o estado de energia do host e as recomendações de migração geradas pelo vSphere DPM
são executadas automaticamente ou não, depende do nível de automação de gerenciamento de
energia selecionado para o recurso.
O nível de automação é configurado em Gerenciamento de energia (Power Management) na

caixa de diálogo Configurações do cluster.
Observação O nível de automação do gerenciamento de energia não é o mesmo que o nível de

automação do DRS.
Tabela 13-1. Nível de automação do gerenciamento de energia
Opção Descrição
Off O recurso está desativado e nenhuma recomendação é feita.
Manual A operação de energia do host e as recomendações de migração de máquina virtual

relacionadas são feitas, mas não são executadas automaticamente.
Automático As operações de energia do host serão executadas automaticamente se as migrações de

máquina virtual relacionadas puderem ser executadas automaticamente.
Limite do vSphere DPM

As recomendações de estado de energia (ativação ou desativação do host) geradas pelo
recurso do vSphere DPM recebem prioridades que variam de recomendações de prioridade 1
a 5.
Essas classificações de prioridade são baseadas na quantidade de sobre ou subutilização

encontrada no cluster do DRS e na melhoria esperada da alteração de estado de energia do host
pretendida. Uma recomendação de prioridade um é obrigatória, enquanto uma recomendação
de prioridade cinco traz apenas pequenas melhorias.
O limite é configurado em Gerenciamento de energia (Power Management) na caixa de diálogo

Configurações do cluster. Cada nível que você move o controle deslizante Limite do vSphere
DPM para a direita permite a inclusão de mais um nível inferior de prioridade no conjunto
de recomendações que são executadas automaticamente ou aparecem como recomendações
a serem executadas manualmente. Na configuração Conservadora, o vSphere DPM só gera
recomendações de prioridade um, o próximo nível à direita, apenas a prioridade dois e superior,
e assim por diante, até o nível Agressivo, que gera recomendações de prioridade cinco e
superiores (ou seja, todas as recomendações .)
Observação O limite do DRS e o limite do vSphere DPM são essencialmente independentes.

Você pode diferenciar a agressividade das recomendações de migração e estado de energia do
host que elas fornecem.

Substituições no nível do host

Quando você habilita o vSphere DPM em um cluster DRS, por padrão, todos os hosts no cluster
herdam seu nível de automação do vSphere DPM.
Você pode substituir esse padrão para um host individual selecionando a página Opções de
Host da caixa de diálogo Configurações do cluster e clicando na configuração Gerenciamento de
Energia (Power Management). Você pode alterar essa configuração para as seguintes opções:
n Desativado
n Manual
n Automático
Observação Não altere a configuração de Gerenciamento de Energia de um host se ela tiver

sido definida como Desativado devido a falha no teste do modo de espera de saída.
Depois de habilitar e executar o vSphere DPM, você pode verificar se ele está funcionando
corretamente exibindo as informações de Última Espera na Última Hora (Last Time Exited
Standby) de cada host, exibidas na página Opções do Host na caixa de diálogo Configurações
do cluster e nos Hosts { (Hosts) guia para cada cluster. Este campo mostra um carimbo de data /
hora e se vCenter Server teve êxito ou falhou na última vez em que ele tentou tirar o host do
modo de espera. Se nenhuma dessas tentativas tiver sido feita, o campo exibirá Nunca.
Observação Os horários da caixa de texto Última saída em espera (Last Time Exited Standby)
são derivados do log de eventos vCenter Server. Se esse log for limpo, os horários serão
redefinidos para Nunca.
Monitorando o vSphere DPM

Você pode usar alarmes baseados em evento em vCenter Server para monitorar o vSphere DPM.
O erro potencial mais grave que você enfrenta ao usar o vSphere DPM é a falha de um host
para sair do modo de espera quando sua capacidade é necessária pelo cluster DRS. Você
pode monitorar instâncias quando esse erro ocorre usando o alarme Sair do erro de espera
(Exit Standby Error) pré-configurado em vCenter Server. Se o vSphere DPM não puder tirar um
host do modo de espera (vCenter Server evento DrsExitStandbyModeFailedEvent), você poderá
configurar esse alarme para enviar um e-mail de alerta ao administrador ou para enviar uma
notificação usando uma interceptação SNMP. Por padrão, esse alarme é apagado depois que
vCenter Server consegue se conectar com êxito a esse host.
Para monitorar a atividade do vSphere DPM, você também pode criar alarmes para os vCenter
Server eventos a seguir.

Tabela 13-2. vCenter Server Eventos
Tipo de evento Nome do evento
Como entrar no modo de espera (prestes a desligar o host) DrsEnteringStandbyModeEvent
Modo de espera inserido com êxito (desligamento do host DrsEnteredStandbyModeEvent

bem-sucedido)
Saindo do modo de espera (prestes a ligar o host) DrsExitingStandbyModeEvent
O modo de espera saiu com êxito (ativação bem-sucedida) DrsExitedStandbyModeEvent
Para obter mais informações sobre como criar e editar alarmes, consulte a documentação do
Monitoramento e Desempenho do vSphere .
Se você usar um software de monitoramento diferente de vCenter Server, e esse software

disparar alarmes quando os hosts físicos forem desligados inesperadamente, você poderá ter
uma situação em que alarmes falsos sejam gerados quando o vSphere DPM colocar um host no
modo de espera. Se você não quiser receber esses alarmes, trabalhe com seu fornecedor para
implantar uma versão do software de monitoramento que está integrada com vCenter Server.
Você também pode usar o vCenter Server em si como sua solução de monitoramento, pois, a
partir do vSphere 4.x, ele é inerentemente ciente do vSphere DPM e não dispara esses alarmes
falsos.
Usando regras de afinidade do DRS

Você pode controlar o posicionamento de máquinas virtuais em hosts em um cluster usando
regras de afinidade.
Você pode criar dois tipos de regras.
n Usado para especificar afinidade ou antiafinidade entre um grupo de máquinas virtuais e um

grupo de hosts. Uma regra de afinidade especifica que os membros de um grupo DRS de
máquina virtual selecionado podem ou devem ser executados nos membros de um grupo
DRS de host específico. Uma regra de antiafinidade especifica que os membros de um grupo
DRS de máquina virtual selecionado não podem ser executados nos membros de um grupo
DRS de host específico.
Consulte Regras de Afinidade de Host da VM para obter informações sobre como criar e usar
esse tipo de regra.
n Usado para especificar afinidade ou antiafinidade entre máquinas virtuais individuais. Uma
regra que especifica a afinidade faz com que o DRS tente manter as máquinas virtuais
especificadas juntas no mesmo host, por exemplo, por motivos de desempenho. Com uma
regra de antiafinidade, o DRS tenta manter as máquinas virtuais especificadas separadas,
por exemplo, para que, quando ocorrer um problema com um host, você não perca as duas
máquinas virtuais.
Consulte Regras de Afinidade entre VMs e VMs para obter informações sobre como criar e
usar esse tipo de regra.

Quando você adiciona ou edita uma regra de afinidade e o estado atual do cluster viola a
regra, o sistema continua a operar e tenta corrigir a violação. Para clusters de DRS manuais
e parcialmente automatizados, as recomendações de migração baseadas no cumprimento de
regras e no balanceamento de carga são apresentadas para aprovação. Você não é obrigado
a cumprir as regras, mas as recomendações correspondentes permanecem até que as regras
sejam cumpridas.
Para verificar se alguma regra de afinidade ativada está sendo violada e não pode ser corrigida
pelo DRS, selecione a guia DRS (DRS) do cluster e clique em Falhas (Faults). Qualquer regra
sendo violada no momento tem uma falha correspondente nesta página. Leia a falha para
determinar por que o DRS não é capaz de satisfazer a regra específica. As violações de regras
também produzem um evento de log.
Observação As regras de afinidade de VM-VM e VM-Host são diferentes das regras de

afinidade de CPU de um host individual.
Criar um grupo de DRS de host

Uma regra de afinidade de Host da VM estabelece uma relação de afinidade (ou antiafinidade)
entre um grupo de DRS de máquina virtual com um grupo de DRS de host. Você deve criar esses
dois grupos antes de criar uma regra que os vincule.
Procedimentos
3 Em Configuração (Configuration), selecione Grupos de VM / Host (VM/Host Groups) e

clique em Adicionar (Add).
4 Na caixa de diálogo Criar Grupo de VM / Host (Create VM/Host Group), digite um nome para
o grupo.
5 Selecione Grupo de hosts (Host Group) na caixa suspensa Tipo (Type) e clique em Adicionar
(Add).
6 Clique na caixa de seleção ao lado de um host para adicioná-lo. Continue esse processo até
que todos os hosts desejados tenham sido adicionados.
Próximo passo
Usando esse grupo de DRS de host, você pode criar uma regra de afinidade de Host de VM que
estabelece uma relação de afinidade (ou antiafinidade) com um grupo de DRS de máquina virtual
apropriado.
Criar um grupo DRS de máquina virtual
Criar uma Regra de Afinidade de Host da VM

Criar um grupo DRS de máquina virtual

As regras de afinidade estabelecem uma relação de afinidade (ou antiafinidade) entre os grupos
DRS. Você deve criar grupos DRS antes de criar uma regra que os vincule.
Procedimentos
3 Em Configuração (Configuration), selecione Grupos de VM / Host (VM/Host Groups) e

clique em Adicionar (Add).
4 Na caixa de diálogo Criar Grupo de VM / Host (Create VM/Host Group), digite um nome para
o grupo.
5 Selecione Grupo de VM (VM Group) na caixa suspensa Tipo (Type) e clique em Adicionar
(Add).
6 Clique na caixa de seleção ao lado de uma máquina virtual para adicioná-la. Continue esse
processo até que todas as máquinas virtuais desejadas tenham sido adicionadas.
Próximo passo
Criar um grupo de DRS de host
Criar uma regra de afinidade de VM-VM
Regras de Afinidade entre VMs e VMs

Uma regra de afinidade de VM-VM especifica se as máquinas virtuais individuais selecionadas
devem ser executadas no mesmo host ou devem ser mantidas em hosts separados. Esse tipo de
regra é usado para criar afinidade ou antiafinidade entre máquinas virtuais individuais que você
selecionar.
Quando uma regra de afinidade é criada, o DRS tenta manter as máquinas virtuais especificadas
juntas no mesmo host. Você pode querer fazer isso, por exemplo, por motivos de desempenho.
Com uma regra de antiafinidade, o DRS tenta manter as máquinas virtuais especificadas
separadas. Você poderia usar essa regra se quiser garantir que determinadas máquinas virtuais
estejam sempre em hosts físicos diferentes. Nesse caso, se ocorrer um problema com um host,
nem todas as máquinas virtuais seriam colocadas em risco.

Criar uma regra de afinidade de VM-VM

Você pode criar regras de afinidade de VM-VM para especificar se as máquinas virtuais
individuais selecionadas devem ser executadas no mesmo host ou devem ser mantidas em hosts
separados.
Observação Se você usar a política de controle de admissão vSphere HA Especificar Hosts

de Failover e designar vários hosts de failover, as regras de afinidade de VM-VM não serão
suportadas.
Procedimentos
3 Em Configuração (Configuration), clique em Regras de VM / Host (VM/Host Rules).
4 Clique em Adicionar(Add).
5 Na caixa de diálogo Criar Regra de VM / Host (Create VM/Host Rule), digite um nome para a
regra.
6 No menu suspenso Tipo (Type), selecione Manter as máquinas virtuais juntas (Keep Virtual
Machines Together) ou Máquinas virtuais separadas (Separate Virtual Machines).
8 Selecione pelo menos duas máquinas virtuais às quais a regra será aplicada e clique em OK
(OK).
Conflitos de regra de afinidade de VM-VM

Você pode criar e usar várias regras de afinidade VM-VM. No entanto, isso pode levar a
situações em que as regras entram em conflito umas com as outras.
Se duas regras de afinidade de VM-VM estiverem em conflito, você não poderá habilitar ambas.
Por exemplo, se uma regra mantém duas máquinas virtuais juntas e outra regra mantém as
mesmas duas máquinas virtuais separadas, você não pode habilitar ambas as regras. Selecione
uma das regras a ser aplicada e desative ou remova a regra conflitante.
Quando duas regras de afinidade VM-VM entram em conflito, a mais antiga tem precedência e
a regra mais recente é desativada. O DRS tenta apenas satisfazer as regras ativadas e as regras
desativadas são ignoradas. O DRS oferece maior precedência para evitar violações de regras de
antiafinidade do que violações de regras de afinidade.
Regras de Afinidade de Host da VM

Uma regra de afinidade de Host da VM especifica se os membros de um grupo DRS de máquina
virtual selecionado podem ou não ser executados nos membros de um grupo DRS de host
específico.

Ao contrário de uma regra de afinidade de VM-VM, que especifica a afinidade (ou antiafinidade)
entre máquinas virtuais individuais, uma regra de afinidade de Host da VM especifica um
relacionamento de afinidade entre um grupo de máquinas virtuais e um grupo de hosts. Existem
regras 'obrigatórias' (designadas por "deve") e regras 'preferenciais' (designadas por "devem".)
Uma regra de afinidade de Host da VM inclui os seguintes componentes.
n Um grupo de DRS de máquina virtual.
n Um grupo de DRS de host.
n Uma designação de se a regra é um requisito ("deve") ou uma preferência ("deve") e se é

afinidade ("executar em") ou antiafinidade ("não executar em").
Como as regras de afinidade de Host da VM são baseadas em cluster, as máquinas virtuais

e os hosts incluídos em uma regra devem residir no mesmo cluster. Se uma máquina virtual
for removida do cluster, ela perderá sua afiliação de grupo do DRS, mesmo se for retornada
posteriormente ao cluster.

Você pode criar regras de afinidade de Host da VM para especificar se os membros de um grupo
DRS de máquina virtual selecionado podem ou não ser executados nos membros de um grupo
DRS de host específico.
Pré-requisitos
Crie a máquina virtual e os grupos de DRS de host aos quais a regra de afinidade de Host da VM
se aplica.
Procedimentos
3 Em Configuração (Configuration), clique em Regras de VM / Host (VM/Host Rules).
5 Na caixa de diálogo Criar Regra de VM / Host (Create VM/Host Rule), digite um nome para a
regra.
6 No menu suspenso Tipo (Type), selecione Máquinas Virtuais para Hosts (Virtual Machines
to Hosts).
7 Selecione o grupo DRS da máquina virtual e o grupo DRS de host ao qual a regra se aplica.
8 Selecione uma especificação para a regra.
n Deve ser executado nos hosts do grupo (Must run on hosts in group). As máquinas
virtuais no Grupo de VMs 1 devem ser executadas nos hosts do Grupo de Hosts A.

n Deve ser executado nos hosts do grupo (Should run on hosts in group). As máquinas
virtuais no Grupo de VMs 1 devem, mas não são necessárias, para serem executadas nos
hosts do Grupo de Hosts A.
n Não deve ser executado em hosts no grupo (Must not run on hosts in group). As
máquinas virtuais no Grupo de VMs 1 nunca devem ser executadas no host do Grupo de
Hosts A.
n Não deve ser executado em hosts no grupo (Should not run on hosts in group). As
máquinas virtuais no Grupo de VMs 1 não devem, mas podem, ser executadas em hosts
no Grupo de Hosts A.
Usando regras de afinidade de host de VM

Você usa uma regra de afinidade de Host da VM para especificar uma relação de afinidade entre
um grupo de máquinas virtuais e um grupo de hosts. Ao usar regras de afinidade de Host da VM,
você deve estar ciente de quando elas podem ser mais úteis, como os conflitos entre as regras
são resolvidos e a importância do cuidado ao definir as regras de afinidade necessárias.
Se você criar mais de uma regra de afinidade de Host da VM, as regras não serão classificadas,
mas serão aplicadas igualmente. Esteja ciente de que isso tem implicações na forma como as
regras interagem. Por exemplo, uma máquina virtual que pertence a dois grupos DRS, cada um
dos quais pertence a uma regra necessária diferente, pode ser executada apenas em hosts que
pertencem a ambos os grupos de DRS de host representados nas regras.
Quando você cria uma regra de afinidade de Host da VM, sua capacidade de funcionar em
relação a outras regras não é verificada. Portanto, é possível criar uma regra que entre em
conflito com as outras regras que você está usando. Quando duas regras de afinidade de Host
da VM entram em conflito, a mais antiga tem precedência e a regra mais recente é desativada. O
DRS tenta apenas satisfazer as regras ativadas e as regras desativadas são ignoradas.
O DRS, vSphere HA e o vSphere DPM nunca realizam nenhuma ação que resulte na violação
das regras de afinidade necessárias (aquelas em que o grupo DRS da máquina virtual 'deve
ser executado em' ou 'não deve ser executado' no grupo DRS do host). Portanto, você deve
ter cuidado ao usar esse tipo de regra devido ao seu potencial de afetar adversamente o
funcionamento do cluster. Se usadas incorretamente, as regras de afinidade de Host da VM
necessárias podem fragmentar o cluster e impedir o funcionamento adequado do DRS, vSphere
HA e do vSphere DPM.
Várias funções de cluster não são executadas se isso violar uma regra de afinidade necessária.
n O DRS não evacua as máquinas virtuais para colocar um host no modo de manutenção.
n O DRS não coloca máquinas virtuais para máquinas virtuais de inicialização ou balanceamento
de carga.
n vSphere HA não realiza failover.

n O vSphere DPM não otimiza o gerenciamento de energia colocando os hosts no modo de

espera.
Para evitar essas situações, tenha cuidado ao criar mais de uma regra de afinidade necessária
ou considere usar regras de afinidade de Host da VM que são apenas preferenciais (aquelas em
que o grupo DRS da máquina virtual 'deve ser executado em' ou 'não deve ser executado' no
DRS do host grupo). Certifique-se de que o número de hosts no cluster ao qual cada máquina
virtual está afinada seja grande o suficiente para que a perda de um host não resulte em uma
falta de hosts nos quais a máquina virtual possa ser executada. As regras preferenciais podem
ser violadas para permitir o funcionamento adequado do DRS, vSphere HA e do vSphere DPM.
Observação Você pode criar um alarme baseado em evento que é acionado quando uma
máquina virtual viola uma regra de afinidade de Host da VM. Adicione um novo alarme para a
máquina virtual e selecione A VM está violando a Regra de Afinidade de Host da VM (VM is
violating VM-Host Affinity Rule) como o gatilho de evento. Para obter mais informações sobre
como criar e editar alarmes, consulte a documentação de monitoramento e desempenho do
vSphere.

Criando um cluster de repositório
de dados 14
Um cluster de repositório de dados é um conjunto de repositórios de dados com recursos
compartilhados e uma interface de gerenciamento compartilhada. Os clusters de datastore são
para repositórios de dados o que os clusters são para hosts. Ao criar um cluster de repositório
de dados, você pode usar vSphere Storage DRS para gerenciar recursos de armazenamento.
Observação Os clusters de datastore são chamados de pods de armazenamento no vSphere

API.
Quando você adiciona um datastore a um cluster de datastore, os recursos do datastore se

tornam parte dos recursos do cluster de datastore. Assim como acontece com os clusters de
hosts, você usa clusters de repositório de dados para agregar recursos de armazenamento,
o que permite oferecer suporte a políticas de alocação de recursos no nível do cluster de
repositório de dados. Os seguintes recursos de gerenciamento de recursos também estão
disponíveis por cluster de repositório de dados.
Balanceamento de carga de utilização de espaço
Você pode definir um limite para o uso do espaço. Quando o uso de espaço em um
repositório de dados excede o limite, o Storage DRS gera recomendações ou realiza Storage
vMotion migrações para equilibrar o uso de espaço no cluster de repositório de dados.
Balanceamento de carga de latência de E / S
Você pode definir um limite de latência de E / S para evitar gargalos. Quando a latência
de E / S em um datastore excede o limite, o Storage DRS gera recomendações ou realiza
migrações Storage vMotion para ajudar a aliviar a alta carga de E / S.
Regras de antiafinidade
Você pode criar regras de antiafinidade para discos de máquina virtual. Por exemplo, os
discos virtuais de uma determinada máquina virtual devem ser mantidos em repositórios de
dados diferentes. Por padrão, todos os discos virtuais de uma máquina virtual são colocados
no mesmo repositório de dados.
n Posicionamento inicial e balanceamento em andamento
n Recomendações de migração de armazenamento

n Criar um cluster de repositório de dados
n Ativar e desativar DRS de armazenamento
n Definir o nível de automação para clusters de datastore
n Definindo o nível de agressividade para DRS de armazenamento
n Requisitos de cluster de repositório de dados
n Adicionando e removendo repositórios de dados de um cluster de repositório de dados
Posicionamento inicial e balanceamento em andamento

O Storage DRS fornece recomendações de posicionamento e balanceamento contínuos iniciais
para repositórios de dados em um cluster de repositório de dados ativado para DRS de
armazenamento.
O posicionamento inicial ocorre quando o Storage DRS seleciona um datastore em um cluster de

datastore no qual colocar um disco de máquina virtual. Isso acontece quando a máquina virtual
está sendo criada ou clonada, quando um disco da máquina virtual está sendo migrado para
outro cluster de repositório de dados ou quando você adiciona um disco a uma máquina virtual
existente.
As recomendações de posicionamento inicial são feitas de acordo com as restrições de espaço

e com relação aos objetivos de espaço e balanceamento de carga de E / S. Essas metas visam
minimizar o risco de provisionamento em excesso de um repositório de dados, gargalos de E / S
de armazenamento e impacto sobre o desempenho em máquinas virtuais.
O DRS de armazenamento é chamado na frequência configurada (por padrão, a cada oito horas)
ou quando um ou mais repositórios de dados em um cluster de repositório de dados excede os
limites de utilização de espaço configuráveis pelo usuário. Quando o Storage DRS é chamado,
ele verifica a utilização de espaço do repositório de dados e os valores de latência de E / S em
relação ao limite. Para a latência de E / S, o DRS de Armazenamento usa a latência de E / S do
percentil 90 medida ao longo de um dia para comparar com o limite.
Recomendações de migração de armazenamento

vCenter Server exibe recomendações de migração na página Recomendações de DRS de
Armazenamento para clusters de repositório de dados que têm o modo de automação manual.
O sistema fornece quantas recomendações forem necessárias para impor regras de DRS de
armazenamento e para equilibrar o espaço e os recursos de E / S do cluster de repositório de
dados. Cada recomendação inclui o nome da máquina virtual, o nome do disco virtual, o nome
do cluster de datastore, o datastore de origem, o datastore de destino e um motivo para a
recomendação.
n Equilibrar o uso do espaço do repositório de dados
n Balancear carga de E / S do repositório de dados

O Storage DRS faz recomendações obrigatórias para a migração nas seguintes situações:
n O repositório de dados está sem espaço.
n As regras de antiafinidade ou de afinidade estão sendo violadas.
n O datastore está entrando no modo de manutenção e deve ser evacuado.
Além disso, recomendações opcionais são feitas quando um repositório de dados está prestes a
ficar sem espaço ou quando ajustes devem ser feitos para o balanceamento de carga de espaço
e E / S.
O DRS de armazenamento considera mover máquinas virtuais que estão desligadas ou ligadas
para balanceamento de espaço. O DRS de armazenamento inclui máquinas virtuais desligadas
com snapshots nessas considerações.
Criar um cluster de repositório de dados

Você pode gerenciar recursos de cluster de repositório de dados usando o Storage DRS.
Procedimentos
1 Navegue até os centros de dados no vSphere Client.
2 Clique com o botão direito do mouse no objeto do centro de dados e selecione Novo Cluster
de Repositório de Dados (New Datastore Cluster).
3 Para concluir o assistente de Novo Cluster de Datastore , siga as instruções.
4 Clique em Concluir(Finish).
Ativar e desativar DRS de armazenamento

O Storage DRS permite gerenciar os recursos agregados de um cluster de repositório de
dados. Quando o Storage DRS está ativado, ele fornece recomendações para posicionamento
e migração de disco da máquina virtual para equilibrar o espaço e os recursos de E / S entre os
repositórios de dados no cluster de repositório de dados.
Ao ativar o Storage DRS, você habilita as seguintes funções.
n Espaço de balanceamento de carga entre repositórios de dados em um cluster de repositório

de dados.
n Balanceamento de carga de E / S entre repositórios de dados em um cluster de repositório

de dados.
n Posicionamento inicial para discos virtuais com base no espaço e na carga de trabalho de E /
S.
A caixa de seleção Habilitar DRS de Armazenamento na caixa de diálogo Configurações do

Cluster do Repositório de Dados habilita ou desabilita todos esses componentes de uma só
vez. Se necessário, você pode desativar as funções relacionadas à E / S do Storage DRS
independentemente das funções de balanceamento de espaço.

Quando você desativa o DRS de armazenamento em um cluster de repositório de dados,

as configurações do DRS de armazenamento são preservadas. Quando você ativa o DRS de
armazenamento, as configurações do cluster de repositório de dados são restauradas para o
ponto em que o DRS de armazenamento foi desativado.
Procedimentos
1 Navegue até o cluster de repositório de dados no vSphere Client.
3 Selecione DRS de armazenamento (Storage DRS) e clique em Editar (Edit).
4 Selecione Ativar vSphere DRS (Turn ON vSphere DRS) e clique em OK (OK).
5 (Opcional) Para desativar apenas as funções relacionadas à E / S do Storage DRS, deixando

os controles relacionados ao espaço ativados, execute as seguintes etapas.
a Em DRS de armazenamento (Storage DRS), selecione Editar (Edit).
b Desmarque a caixa de seleção Habilitar Métrica de E / S para DRS de Armazenamento

(Enable I/O metric for Storage DRS) e clique em OK (OK).
Definir o nível de automação para clusters de datastore

O nível de automação de um cluster de repositório de dados especifica se as recomendações de
posicionamento e migração do Storage DRS são aplicadas automaticamente.
Procedimentos
3 Selecione DRS (DRS) e clique em Editar (Edit).
4 Expanda DRS Automation e selecione um nível de automação.
Manual é o nível de automação padrão.
Opção Descrição
Sem automação (modo manual) As recomendações de posicionamento e migração são exibidas, mas não
Parcialmente automatizado As recomendações de posicionamento são executadas automaticamente e

as recomendações de migração são exibidas, mas não são executadas até
que você aplique manualmente a recomendação.

automaticamente.

Definindo o nível de agressividade para DRS de

armazenamento
A agressividade do Storage DRS é determinada especificando limites para o espaço usado e a
latência de E / S.
O DRS de armazenamento coleta informações de uso de recursos para os repositórios de

dados em um cluster de repositório de dados. vCenter Server usa essas informações para gerar
recomendações para o posicionamento de discos virtuais em repositórios de dados.
Quando você define um baixo nível de agressividade para um cluster de armazenamento de

dados, o Storage DRS recomenda Storage vMotion migrações somente quando absolutamente
necessário, por exemplo, se quando a carga de E / S, a utilização de espaço ou seu desequilíbrio
for alto. Quando você define um alto nível de agressividade para um cluster de repositório de
dados, o DRS de armazenamento recomenda migrações sempre que o cluster de repositório de
dados pode se beneficiar do balanceamento de carga de espaço ou E / S.
No vSphere Client, você pode usar os seguintes limites para definir o nível de agressividade para
o DRS de Armazenamento:
Utilização do espaço
O DRS de armazenamento gera recomendações ou realiza migrações quando a porcentagem

de utilização de espaço no repositório de dados é maior do que o limite definido no vSphere
Client.
Latência de E / S
O DRS de armazenamento gera recomendações ou executa migrações quando a latência de

E / S do percentil 90 medida ao longo de um dia para o repositório de dados é maior que o
limite.
Você também pode definir opções avançadas para configurar ainda mais o nível de
agressividade do Storage DRS.
Diferença de utilização de espaço
Esse limite garante que haja alguma diferença mínima entre a utilização do espaço da origem
e do destino. Por exemplo, se o espaço usado no datastore A for 82% e o datastore B
for 79%, a diferença será 3. Se o limite for 5, o Storage DRS não fará recomendações de
migração do datastore A para o datastore B.
Intervalo de invocação do balanceamento de carga de E / S
Após esse intervalo, o Storage DRS é executado para balancear a carga de E / S.
Limite de desbalanceamento de E / S

A redução desse valor torna o balanceamento de carga de E / S menos agressivo. O DRS de

armazenamento calcula uma métrica de equidade de E / S entre 0 e 1, sendo 1 a distribuição
mais justa. O balanceamento de carga de E / S é executado somente se a métrica computada
for menor que 1 - (limite de desequilíbrio de E / S / 100).
Definir regras de tempo de execução do DRS de armazenamento

Defina gatilhos do DRS de armazenamento e configure opções avançadas para o cluster de
repositório de dados.
Procedimentos
1 (Opcional) Marque ou desmarque a caixa de seleção Habilitar métrica de E / S para

recomendações do SDRS (Enable I/O metric for SDRS recommendations) para ativar ou
desativar a inclusão de métricas de E / S.
Quando você desativa essa opção, vCenter Server não considera as métricas de E / S ao
fazer recomendações de DRS de armazenamento. Ao desativar essa opção, você desativa os
seguintes elementos do Storage DRS:
n Balanceamento de carga de E / S entre repositórios de dados em um cluster de

n Posicionamento inicial para discos virtuais com base na carga de trabalho de E / S. O

posicionamento inicial é baseado apenas no espaço.
2 (Opcional) Defina os limites do DRS de armazenamento.
Você define o nível de agressividade do Storage DRS especificando limites para o espaço
usado e a latência de E / S.
n Use o controle deslizante Espaço utilizado para indicar a porcentagem máxima de espaço
consumido permitido antes que o DRS de armazenamento seja acionado. O DRS de
armazenamento faz recomendações e executa migrações quando o uso de espaço nos
repositórios de dados é maior do que o limite.
n Use o controle deslizante Latência de E / S para indicar a latência máxima de E /

S permitida antes que o DRS de armazenamento seja acionado. O Storage DRS faz
recomendações e realiza migrações quando a latência é maior que o limite.
Observação O limite de Latência de E / S do DRS de armazenamento para o cluster de

repositório de dados deve ser menor ou igual ao limite de congestionamento Storage I/O
Control.
3 (Opcional) Configure opções avançadas.
n Não há recomendações até que a diferença de utilização entre a origem e o destino seja:
Use o controle deslizante para especificar o limite de diferença de utilização do espaço. A
utilização é uso * 100 / capacidade.

Esse limite garante que haja alguma diferença mínima entre a utilização do espaço da
origem e do destino. Por exemplo, se o espaço usado no datastore A for 82% e o
datastore B for 79%, a diferença será 3. Se o limite for 5, o Storage DRS não fará
recomendações de migração do datastore A para o datastore B.
n Verificar desequilíbrios a cada: Especifique a frequência com que o Storage DRS deve
avaliar o espaço e o balanceamento de carga de E / S.
n Limite de desbalanceamento de E / S: use o controle deslizante para indicar a

agressividade do balanceamento de carga de E / S. A redução desse valor torna o
balanceamento de carga de E / S menos agressivo. O DRS de armazenamento calcula
uma métrica de equidade de E / S entre 0 e 1, sendo 1 a distribuição mais justa. O
balanceamento de carga de E / S é executado somente se a métrica computada for
menor que 1 - (limite de desequilíbrio de E / S / 100).
Requisitos de cluster de repositório de dados

Os repositórios de dados e os hosts associados a um cluster de repositório de dados devem
atender a certos requisitos para usar os recursos do cluster de repositório de dados com êxito.
Siga estas diretrizes ao criar um cluster de repositório de dados.
n Os clusters de repositório de dados devem conter repositórios de dados semelhantes ou

intercambiáveis.
Um cluster de repositório de dados pode conter um mix de repositórios de dados

com diferentes tamanhos e capacidades de E / S e pode ser de diferentes matrizes e
fornecedores. No entanto, os seguintes tipos de repositórios de dados não podem coexistir
em um cluster de repositório de dados.
n Os repositórios de dados NFS e VMFS não podem ser combinados no mesmo cluster de
n Repositórios de dados replicados não podem ser combinados com repositórios de dados
não replicados no mesmo cluster habilitado para DRS do Storage.
n Todos os hosts conectados aos repositórios de dados em um cluster de repositório de dados

devem ser ESXi 5.0 e posteriores. Se os repositórios de dados no cluster de repositório de
dados estiverem conectados ao ESX / ESXi 4.x e hosts anteriores, o Storage DRS não será
executado.
n Os repositórios de dados compartilhados em vários centros de dados não podem ser

incluídos em um cluster de repositório de dados.
n Como prática recomendada, não inclua repositórios de dados que tenham a aceleração de
hardware ativada no mesmo cluster de repositório de dados que repositórios de dados que
não têm a aceleração de hardware ativada. Os repositórios de dados em um cluster de
repositório de dados devem ser homogêneos para garantir o comportamento compatível
com a aceleração de hardware.

Adicionando e removendo repositórios de dados de um

cluster de repositório de dados
Você adiciona e remove repositórios de dados de e para um cluster de repositório de dados
existente.
Você pode adicionar a um cluster de repositório de dados qualquer repositório de dados

montado em um host no inventário vSphere Client, com as seguintes exceções:
n Todos os hosts conectados ao repositório de dados devem ser ESXi 5.0 e posteriores.
n O datastore não pode estar em mais de um centro de dados na mesma instância do vSphere
Client.
Quando você remove um datastore de um cluster de datastore, o datastore permanece no

inventário vSphere Client e não é desmontado do host.

Usando clusters de datastore
para gerenciar recursos de
armazenamento
15
Depois de criar um cluster de datastore, você pode personalizá-lo e usá-lo para gerenciar os
recursos de utilização de espaço e E / S de armazenamento.
n Usando o modo de manutenção do DRS de armazenamento
n Aplicando recomendações de DRS de armazenamento
n Alterar o nível de automação do DRS de armazenamento para uma máquina virtual
n Configurar o agendamento fora do horário de trabalho para DRS de armazenamento
n Regras de antiafinidade do DRS de armazenamento
n Limpar estatísticas de DRS de armazenamento
n Storage vMotion Compatibilidade com clusters de datastore
Usando o modo de manutenção do DRS de armazenamento

Você coloca um repositório de dados no modo de manutenção quando precisar removê-lo para
repará-lo. Um repositório de dados entra ou sai do modo de manutenção apenas como resultado
de uma solicitação do usuário.
O modo de manutenção está disponível para repositórios de dados em um cluster de repositório

de dados ativado para DRS de armazenamento. Os repositórios de dados autônomos não
podem ser colocados no modo de manutenção.
Os discos virtuais que estão localizados em um datastore que está entrando no modo de
manutenção devem ser migrados para outro datastore, manualmente ou usando o Storage DRS.
Quando você tenta colocar um datastore no modo de manutenção, a guia Recomendações
de Posicionamento (Placement Recommendations) exibe uma lista de recomendações de
migração, datastores no mesmo cluster de datastore no qual os discos virtuais podem ser
migrados. Na guia Falhas (Faults), vCenter Server exibe uma lista dos discos que não podem
ser migrados e os motivos. Se as regras de afinidade ou antiafinidade do DRS de armazenamento
impedirem que os discos sejam migrados, você poderá optar por ativar a opção Ignorar regras
de afinidade para manutenção.

O datastore fica em um estado de Como entrar no modo de manutenção até que todos os discos
virtuais tenham sido migrados.
Colocar um repositório de dados no modo de manutenção

Se você precisar tirar um datastore de serviço, poderá colocá-lo no modo de manutenção DRS
de armazenamento.
Pré-requisitos
O Storage DRS está habilitado no cluster de datastore que contém o datastore que está
entrando no modo de manutenção.
Nenhum arquivo de imagem de CD-ROM está armazenado no repositório de dados.
Há pelo menos dois repositórios de dados no cluster de repositório de dados.
Procedimentos
2 Clique com o botão direito do mouse no datastore e selecione Modo de Manutenção

(Maintenance Mode) > Entrar no Modo de Manutenção (Enter Maintenance Mode).
Uma lista de recomendações é exibida para a migração do modo de manutenção de

3 (Opcional) Na guia Recomendações de Posicionamento, desmarque as recomendações que

você não deseja aplicar.
Observação O datastore não pode entrar no modo de manutenção sem evacuar todos
os discos. Se você desmarcar as recomendações, deverá mover manualmente as máquinas
virtuais afetadas.
4 Se necessário, clique em Aplicar recomendações (Apply Recommendations).
vCenter Server usa Storage vMotion para migrar os discos virtuais do datastore de origem
para o datastore de destino e o datastore entra no modo de manutenção.
Resultados
O ícone do datastore pode não ser atualizado imediatamente para refletir o estado atual do
datastore. Para atualizar o ícone imediatamente, clique em Atualizar (Refresh).
Ignorar regras de afinidade de DRS de armazenamento para o modo

de manutenção
As regras de afinidade ou antiafinidade do DRS de armazenamento podem impedir que um
datastore entre no modo de manutenção. Você pode ignorar essas regras quando coloca um
datastore no modo de manutenção.

Quando você ativa a opção Ignorar Regras de Afinidade para Manutenção para um cluster de
repositório de dados, vCenter Server ignora as regras de afinidade e antiafinidade do DRS de
armazenamento que impedem que um repositório de dados entre no modo de manutenção.
As regras de DRS de armazenamento são ignoradas apenas para recomendações de evacuação.

vCenter Server não viola as regras ao fazer recomendações de espaço e balanceamento de
carga ou recomendações de posicionamento inicial.
Procedimentos
3 Selecione DRS (DRS) e clique em Editar (Edit).
4 Expanda Opções avançadas (Advanced Options) e clique em Adicionar (Add).
5 Na coluna Opção, digite IgnoreAffinityRulesForMaintenance .
6 Na coluna Valor, digite 1 para ativar a opção.
Digite 0 para desativar a opção.
Resultados
A opção Ignorar Regras de Afinidade para o Modo de Manutenção é aplicada ao cluster de

Aplicando recomendações de DRS de armazenamento

O DRS de armazenamento coleta informações de uso de recursos para todos os repositórios de
dados em um cluster de repositório de dados. O DRS de armazenamento usa as informações
para gerar recomendações para o posicionamento do disco da máquina virtual em repositórios
de dados em um cluster de repositório de dados.
As recomendações de DRS de armazenamento aparecem na guia DRS de armazenamento

(Storage DRS) na exibição do repositório de dados vSphere Client. As recomendações também
aparecem quando você tenta colocar um datastore no modo de manutenção do DRS de
armazenamento. Quando você aplica as recomendações do DRS de Armazenamento, o vCenter
Server usa o Storage vMotion para migrar os discos da máquina virtual para outros repositórios
de dados no cluster de repositório de dados para balancear os recursos.
Você pode aplicar um subconjunto das recomendações marcando a caixa de seleção Substituir
recomendações sugeridas do DRS e selecionando cada recomendação a ser aplicada.

Tabela 15-1. Recomendações de DRS de armazenamento
Rótulo Descrição
Prioridade Nível de prioridade (1-5) da recomendação. (Oculto por

padrão.)
Recomendação Ação recomendada pelo Storage DRS.
Motivo Por que a ação é necessária.
% De Utilização do Espaço Antes (origem) e (destino) Porcentagem de espaço usado nos datastores de origem
e de destino antes da migração.
% De Utilização de Espaço Depois (origem) e (destino) Porcentagem de espaço usado nos datastores de origem
e de destino após a migração.
Latência de E / S antes (origem) Valor da latência de E / S no repositório de dados de

origem antes da migração.
Latência de E / S antes (destino) Valor da latência de E / S no repositório de dados de

destino antes da migração.
Atualizar recomendações de DRS de armazenamento

As recomendações de migração do DRS de armazenamento aparecem na guia DRS de
armazenamento (Storage DRS) no vSphere Client. Você pode atualizar essas recomendações
executando o Storage DRS.
Pré-requisitos
Pelo menos um cluster de repositório de dados deve existir no inventário vSphere Client.
Ative o DRS de armazenamento para o cluster de repositório de dados. A guia Storage DRS
(Storage DRS) será exibida somente se o Storage DRS estiver ativado.
Procedimentos
1 Na exibição de datastore vSphere Client, selecione o cluster de datastore e clique na guia

DRS de armazenamento (Storage DRS).
2 Selecione a exibição Recomendações (Recommendations) e clique no link Executar

armazenamento DRS (Run Storage DRS) no canto superior direito.
Resultados
As recomendações são atualizadas. O carimbo de data / hora da Última Atualização exibe a hora
em que as recomendações do DRS de Armazenamento foram atualizadas.
Alterar o nível de automação do DRS de armazenamento

para uma máquina virtual
Você pode substituir o nível de automação de todo o cluster de datastore para máquinas virtuais
individuais. Você também pode substituir as regras de afinidade de disco virtual padrão.

Procedimentos
2 Clique na guia Configurar (Configure) e clique em Configuração (Configuration).
3 Em Substituições de VM (VM Overrides), selecione Adicionar (Add).
4 Selecione uma máquina virtual.
5 Clique no menu suspenso Nível de automação e selecione um nível de automação para a

máquina virtual.
Opção Descrição
Padrão (Manual) As recomendações de posicionamento e migração são exibidas, mas não


automaticamente.
Desativado vCenter Server não migra a máquina virtual nem fornece recomendações de
migração para ela.
6 Clique no menu suspenso Manter VMDKs juntos (Keep VMDKs together) para substituir a
afinidade padrão do VMDK.
Consulte Substituir regras de afinidade do VMDK.
Configurar o agendamento fora do horário de trabalho para

DRS de armazenamento
Você pode criar uma tarefa agendada para alterar as configurações de DRS de armazenamento
para um cluster de repositório de dados para que as migrações para clusters de repositório de
dados totalmente automatizados tenham mais probabilidade de ocorrer fora do horário de pico.
Você pode criar uma tarefa agendada para alterar o nível de automação e o nível de
agressividade para um cluster de repositório de dados. Por exemplo, você pode configurar
o Storage DRS para executar menos agressivamente durante os horários de pico, quando o
desempenho é uma prioridade, para minimizar a ocorrência de migrações de armazenamento.
Fora do horário de pico, o DRS de armazenamento pode ser executado em um modo mais
agressivo e ser chamado com mais frequência.
Pré-requisitos
Ative o DRS de armazenamento.
Procedimentos

3 Em vSphere DRS (vSphere DRS), clique no botão Agendar DRS (Schedule DRS).
4 Na caixa de diálogo Editar Cluster do Repositório de Dados, clique em Agendamento SDRS

(SDRS Scheduling).
5 Expanda Automação do DRS (DRS Automation).
a Selecione um nível de automação.
b Defina o limite de migração.
Use o controle deslizante Migração para selecionar o nível de prioridade de vCenter

Server recomendações que ajustam o balanceamento de carga do cluster.
c Selecione se deseja ativar a Automação da Máquina Virtual.
A substituição de máquinas virtuais individuais pode ser definida na página Substituições

de VM.
6 Expanda Gerenciamento de energia (Power Managment).
a Selecione um nível de automação.
b Defina o limite do DPM.
Use o controle deslizante do DPM para selecionar as recomendações de energia que

vCenter Server aplicará.
7 Digite um nome de Tarefa.
8 Digite uma descrição da tarefa que você criou.
9 Em Agendador Configurado, clique em Alterar (Change) e selecione a hora para a execução

da tarefa e clique em OK (OK).
10 Digite um endereço de e-mail para enviar um e-mail de notificação quando a tarefa for
concluída.
Resultados
A tarefa agendada é executada no horário especificado.
Regras de antiafinidade do DRS de armazenamento

Você pode criar regras de antiafinidade de DRS de armazenamento para controlar quais discos
virtuais não devem ser colocados no mesmo repositório de dados em um cluster de repositório
de dados. Por padrão, os discos virtuais de uma máquina virtual são mantidos juntos no mesmo

Quando você cria uma regra de antiafinidade, ela se aplica aos discos virtuais relevantes no
cluster de repositório de dados. As regras de antiafinidade são impostas durante a migração
inicial de recomendações de DRS de posicionamento e armazenamento, mas não são aplicadas
quando uma migração é iniciada por um usuário.
Observação As regras de antiafinidade não se aplicam a arquivos de imagem ISO de CD-ROM

que são armazenados em um repositório de dados em um cluster de repositório de dados, nem
se aplicam a arquivos de permuta que são armazenados em locais definidos pelo usuário.
Regras de antiafinidade da VM
Especifique quais máquinas virtuais nunca devem ser mantidas no mesmo repositório de
dados. Consulte Criar regras de antiafinidade de VM.
Regras de antiafinidade do VMDK
Especifique quais discos virtuais associados a uma determinada máquina virtual devem ser
mantidos em diferentes repositórios de dados. Consulte Criar regras de antiafinidade do
VMDK.
Se você mover um disco virtual para fora do cluster de repositório de dados, a regra de afinidade
ou antiafinidade não se aplicará mais a esse disco.
Quando você move arquivos de disco virtual para um cluster de armazenamento de dados que
tem regras de afinidade e antiafinidade existentes, o seguinte comportamento se aplica:
n O Cluster de Datastore B tem uma regra de afinidade dentro da VM. Quando você move
um disco virtual do Datastore Cluster A para o Datastore Cluster B, qualquer regra aplicada
ao disco virtual para uma determinada máquina virtual no Datastore Cluster A não se aplica
mais. O disco virtual agora está sujeito à regra de afinidade dentro da VM no Datastore
Cluster B.
n O Cluster de Datastore B tem uma regra de antiafinidade de VM. Quando você move um
disco virtual do Datastore Cluster A para o Datastore Cluster B, qualquer regra aplicada ao
disco virtual para uma determinada máquina virtual no Datastore Cluster A não se aplica
mais. O disco virtual agora está sujeito à regra de antiafinidade da VM no Cluster de
Datastore B.
n O Cluster de Datastore B tem uma regra de antiafinidade do VMDK. Quando você move
um disco virtual do Cluster de Datastore A para o Cluster de Datastore B, a regra de
antiafinidade do VMDK não se aplica ao disco virtual de uma determinada máquina virtual
porque a regra é limitada a apenas discos virtuais especificados no Cluster de Datastore B.
Observação As regras de DRS de armazenamento podem impedir que um datastore entre no

modo de manutenção. Você pode optar por ignorar as regras de DRS de armazenamento para o
modo de manutenção ativando a opção Ignorar regras de afinidade para manutenção.

Criar regras de antiafinidade de VM

Você pode criar uma regra de antiafinidade para indicar que todos os discos virtuais de
determinadas máquinas virtuais devem ser mantidos em repositórios de dados diferentes. A
regra se aplica a clusters de repositórios de dados individuais.
As máquinas virtuais que participam de uma regra de antiafinidade de VM em um cluster de

datastore devem ser associadas a uma regra de afinidade dentro da VM no cluster de datastore.
As máquinas virtuais também devem estar em conformidade com a regra de afinidade dentro da
VM.
Se uma máquina virtual estiver sujeita a uma regra de antiafinidade de VM, o seguinte
comportamento se aplicará:
n O DRS de armazenamento coloca os discos virtuais da máquina virtual de acordo com a

regra.
n O DRS de armazenamento migra os discos virtuais usando o vMotion de acordo com a regra,
mesmo que a migração seja por um motivo obrigatório, como colocar um repositório de
dados no modo de manutenção.
n Se o disco virtual da máquina virtual violar a regra, o Storage DRS fará recomendações de
migração para corrigir o erro ou relatará a violação como uma falha se não puder fazer uma
recomendação que irá corrigir o erro.
Nenhuma regra de antiafinidade de VM é definida por padrão.
Procedimentos
3 Selecione Regras de VM / Host (VM/Host Rules).
5 Digite um nome para a regra.
6 No menu Tipo, selecione Antiafinidade de VM (VM anti-affinity).
8 Clique em Selecionar Máquina Virtual (Select Virtual Machine).
9 Selecione pelo menos duas máquinas virtuais e clique em OK (OK).
10 Clique em OK (OK) para salvar a regra.
Criar regras de antiafinidade do VMDK

Você pode criar uma regra de antiafinidade do VMDK para uma máquina virtual que indica quais
discos virtuais devem ser mantidos em repositórios de dados diferentes.

As regras de antiafinidade do VMDK se aplicam à máquina virtual para a qual a regra está
definida, não a todas as máquinas virtuais. A regra é expressa como uma lista de discos virtuais
que devem ser separados um do outro.
Se você tentar definir uma regra de antiafinidade do VMDK e uma regra de afinidade dentro da
VM para uma máquina virtual, vCenter Server rejeitará a regra definida mais recentemente.
Se uma máquina virtual estiver sujeita a uma regra de antiafinidade do VMDK, o seguinte
comportamento se aplicará:

regra.
mesmo que a migração seja por um motivo obrigatório, como colocar um datastore no modo
de manutenção.
Nenhuma regra de antiafinidade do VMDK é definida por padrão.
Procedimentos
3 Selecione Regras de VM / Host (VM/Host Rules).
5 Digite um nome para a regra.
6 No menu Tipo, selecione Antiafinidade do VMDK (VMDK anti-affinity).
8 Clique em Selecionar Máquina Virtual (Select Virtual Machine).
9 Selecione uma máquina virtual e clique em OK (OK).
10 Selecione pelo menos dois discos virtuais aos quais a regra se aplica e clique em OK (OK).
11 Clique em OK (OK) para salvar a regra.
Substituir regras de afinidade do VMDK

As regras de afinidade do VMDK indicam que todos os discos virtuais em um cluster de
repositório de dados associados a uma determinada máquina virtual estão localizados no mesmo
repositório de dados no cluster de repositório de dados. As regras se aplicam a clusters de
repositórios de dados individuais.

As regras de afinidade do VMDK são ativadas por padrão para todas as máquinas virtuais que
estão em um cluster de repositório de dados. Você pode substituir a configuração padrão para o
cluster de repositório de dados ou para máquinas virtuais individuais.
As máquinas virtuais que estão sujeitas às regras de afinidade do VMDK têm o seguinte
comportamento:

regra.
mesmo que a migração seja por um motivo obrigatório, como colocar um datastore no modo
de manutenção.
Quando você adiciona um repositório de dados a um cluster de repositório de dados que está
ativado para o DRS de armazenamento, a regra de afinidade do VMDK é desativada para
qualquer máquina virtual que tenha discos virtuais nesse repositório de dados se ela também
tiver discos virtuais em outros repositórios de dados.
Procedimentos
3 Selecione Substituições de VM (VM Overrides).
5 Use o botão + (+) para selecionar máquinas virtuais.
6 Clique no menu suspenso Manter VMDKs juntos (Keep VMDKs together) e selecione Não
(No).
Limpar estatísticas de DRS de armazenamento

Para diagnosticar problemas com o DRS de armazenamento, você pode limpar as estatísticas do
DRS de armazenamento antes de executar manualmente o DRS de armazenamento.
Importante Quando você ativa a opção para limpar as estatísticas do DRS de armazenamento,
as estatísticas são apagadas toda vez que o DRS de armazenamento é executado até que você
desative a opção. Sempre desative a opção depois de diagnosticar o problema de DRS de
armazenamento.

Pré-requisitos
Ative o DRS de armazenamento para o cluster de repositório de dados.
Procedimentos
1 Habilite a opção ClearIoStatsOnSdrsRun .
a Navegue até o cluster de repositório de dados no vSphere Client.
b Clique na guia Configuração (Configuration) e clique em Serviços (Services).
c Selecione vSphere DRS (vSphere DRS) e clique em Editar (Edit).
d Expanda Opções avançadas (Advanced Options) e clique em Adicionar (Add).
e Na coluna Opção, digite ClearIoStatsOnSdrsRun .
f Na caixa de texto Valor correspondente, digite 1 .
g Clique em Okey(OK).
2 Execute o DRS de Armazenamento no cluster do datastore.
As estatísticas atuais do DRS de Armazenamento para todos os repositórios de dados e

discos virtuais em todos os clusters de repositório de dados no inventário vSphere Client são
limpas, mas nenhuma nova estatística é coletada.
3 Altere o valor do sinalizador ClearIoStatsOnSdrsRun para 0 para desativá-lo.
4 Execute o DRS de Armazenamento novamente.
O DRS de armazenamento é executado normalmente. Aguarde várias horas para que a nova
configuração entre em vigor.
Storage vMotion Compatibilidade com clusters de datastore

®
Um cluster de repositório de dados tem certos requisitos do vSphere Storage vMotion .
n O host deve estar executando uma versão de ESXi compatível com Storage vMotion.
n O host deve ter acesso de gravação ao repositório de dados de origem e ao repositório de

dados de destino.
n O host deve ter recursos de memória livre suficientes para acomodar Storage vMotion.
n O datastore de destino deve ter espaço em disco suficiente.
n O datastore de destino não deve estar no modo de manutenção ou entrar no modo de

manutenção.

Usando sistemas NUMA com o
ESXi 16
O ESXi oferece suporte à otimização de acesso à memória para processadores Intel e AMD
Opteron em arquiteturas de servidor que oferecem suporte a NUMA (acesso não uniforme à
memória).
Depois de entender como o agendamento do ESXi NUMA é executado e como os algoritmos

do VMware NUMA funcionam, você pode especificar os controles do NUMA para otimizar o
desempenho das suas máquinas virtuais.
n O que é o NUMA?
n Como funciona o agendamento do ESXi NUMA
n VMware Algoritmos de Otimização do NUMA e Configurações
n Gerenciamento de recursos em arquiteturas NUMA
n Usando o Virtual NUMA
n Especificando controles NUMA
O que é o NUMA?
Os sistemas NUMA são plataformas de servidor avançadas com mais de um barramento do
sistema. Eles podem aproveitar um grande número de processadores em uma única imagem do
sistema com uma relação preço / desempenho superior.
Na última década, a velocidade do relógio do processador aumentou drasticamente. Uma CPU

de vários gigahertz, no entanto, precisa ser fornecida com uma grande quantidade de largura
de banda de memória para usar seu poder de processamento de forma eficaz. Até mesmo
uma única CPU executando uma carga de trabalho com uso intensivo de memória, como um
aplicativo de computação científica, pode ser restringida pela largura de banda da memória.
Esse problema é amplificado em sistemas de multiprocessamento simétrico (SMP), onde muitos

processadores devem competir pela largura de banda no mesmo barramento do sistema. Alguns
sistemas high-end muitas vezes tentam resolver esse problema criando um barramento de dados
de alta velocidade. No entanto, essa solução é cara e tem uma escalabilidade limitada.

O NUMA é uma abordagem alternativa que vincula vários nós pequenos e econômicos usando
uma conexão de alto desempenho. Cada nó contém processadores e memória, bem como
um pequeno sistema SMP. No entanto, um controlador de memória avançado permite que
um nó use memória em todos os outros nós, criando uma única imagem do sistema. Quando
um processador acessa a memória que não está dentro de seu próprio nó (memória remota),
os dados devem ser transferidos pela conexão NUMA, que é mais lenta do que acessar a
memória local. Os tempos de acesso à memória não são uniformes e dependem da localização
da memória e do nó do qual ela é acessada, como o nome da tecnologia implica.
Desafios para sistemas operacionais

Como uma arquitetura NUMA fornece uma única imagem do sistema, ela pode executar um
sistema operacional sem otimizações especiais.
A alta latência de acessos à memória remota pode deixar os processadores subutilizados,

aguardando constantemente a transferência de dados para o nó local, e a conexão NUMA pode
se tornar um gargalo para aplicativos com demandas de alta largura de banda de memória.
Além disso, o desempenho em tal sistema pode ser altamente variável. Isso varia, por exemplo,
se um aplicativo tem memória localizada localmente em uma execução de avaliação de
desempenho, mas uma execução subsequente coloca toda essa memória em um nó remoto.
Esse fenômeno pode dificultar o planejamento da capacidade.
Alguns sistemas UNIX de ponta oferecem suporte para otimizações de NUMA em seus
compiladores e bibliotecas de programação. Esse suporte requer que os desenvolvedores de
software ajustem e recompilem seus programas para obter o desempenho ideal. Não é garantido
que as otimizações de um sistema funcionem bem na próxima geração do mesmo sistema.
Outros sistemas permitiram que um administrador decidisse explicitamente sobre o nó no qual
um aplicativo deve ser executado. Embora isso possa ser aceitável para certos aplicativos que
exigem que 100% de sua memória seja local, ele cria uma carga administrativa e pode levar a um
desequilíbrio entre os nós quando as cargas de trabalho mudam.
Idealmente, o software do sistema fornece suporte NUMA transparente, para que os aplicativos
possam se beneficiar imediatamente sem modificações. O sistema deve maximizar o uso da
memória local e agendar programas de forma inteligente, sem exigir a intervenção constante do
administrador. Finalmente, deve responder bem às mudanças de condições sem comprometer a
equidade ou o desempenho.
Como funciona o agendamento do ESXi NUMA

ESXi usa um sofisticado agendador NUMA para balancear dinamicamente a carga do
processador e a localidade de memória ou o balanceamento de carga do processador.
1 Cada máquina virtual gerenciada pelo agendador NUMA recebe um nó inicial. Um nó inicial
é um dos nós NUMA do sistema que contém processadores e memória local, conforme
indicado pela Tabela de Alocação de Recursos do Sistema (SRAT).

2 Quando a memória é alocada a uma máquina virtual, o host ESXi a aloca preferencialmente
do nó inicial. As CPUs virtuais da máquina virtual são restritas a serem executadas no nó
inicial para maximizar a localidade de memória.
3 O agendador NUMA pode alterar dinamicamente o nó inicial de uma máquina virtual para
responder a alterações na carga do sistema. O agendador pode migrar uma máquina virtual
para um novo nó inicial para reduzir o desequilíbrio de carga do processador. Como isso
pode fazer com que mais memória seja remota, o agendador pode migrar a memória
da máquina virtual dinamicamente para seu novo nó inicial para melhorar a localidade da
memória. O agendador NUMA também pode trocar máquinas virtuais entre nós quando isso
melhora a localidade geral da memória.
Algumas máquinas virtuais não são gerenciadas pelo agendador ESXi NUMA. Por exemplo, se
você definir manualmente o processador ou a afinidade de memória para uma máquina virtual,
o agendador NUMA poderá não ser capaz de gerenciar essa máquina virtual. As máquinas
virtuais que não são gerenciadas pelo agendador NUMA ainda são executadas corretamente. No
entanto, eles não se beneficiam de ESXi otimizações NUMA.
As políticas de agendamento e posicionamento de memória do NUMA em ESXi podem gerenciar

todas as máquinas virtuais de forma transparente, para que os administradores não precisem
lidar com a complexidade de balancear máquinas virtuais entre nós explicitamente.
As otimizações funcionam perfeitamente, independentemente do tipo de sistema operacional

convidado. ESXi fornece suporte a NUMA mesmo para máquinas virtuais que não suportam
hardware NUMA, como o Windows NT 4.0. Como resultado, você pode aproveitar o novo
hardware, mesmo com sistemas operacionais legados.
Uma máquina virtual com mais processadores virtuais do que o número de núcleos
de processador físicos disponíveis em um único nó de hardware pode ser gerenciada
automaticamente. O agendador NUMA acomoda essa máquina virtual fazendo com que ela
abranja os nós NUMA. Ou seja, ele é dividido em vários clientes NUMA, cada um dos quais
é atribuído a um nó e, em seguida, gerenciado pelo agendador como um cliente normal e
não extensível. Isso pode melhorar o desempenho de determinadas cargas de trabalho com
uso intenso de memória com alta localidade. Para obter informações sobre como configurar o
comportamento desse recurso, consulte Atributos avançados de máquina virtual.
O ESXi 5.0 e posterior inclui suporte para expor a topologia NUMA virtual a sistemas
operacionais convidados. Para obter mais informações sobre o controle NUMA virtual, consulte
Usando o Virtual NUMA.
VMware Algoritmos de Otimização do NUMA e

Configurações
Esta seção descreve os algoritmos e as configurações usadas por ESXi para maximizar o
desempenho do aplicativo, mantendo as garantias de recursos.

Nós iniciais e posicionamento inicial

Quando uma máquina virtual é ligada, ESXi atribui a ela um nó inicial. Uma máquina virtual é
executada apenas em processadores dentro de seu nó inicial, e sua memória recém-alocada vem
do nó inicial também.
A menos que o nó inicial de uma máquina virtual seja alterado, ele usa apenas memória local,
evitando as penalidades de desempenho associadas a acessos de memória remota a outros nós
NUMA.
Quando uma máquina virtual é ligada, ela recebe um nó inicial inicial para que a carga geral
de CPU e memória entre os nós NUMA permaneça equilibrada. Como as latências internode
em um sistema NUMA grande podem variar muito, ESXi determina essas latências internode no
momento da inicialização e usa essas informações ao colocar inicialmente máquinas virtuais que
são mais amplas do que um único nó NUMA. Essas máquinas virtuais amplas são colocadas em
nós NUMA que estão próximos uns dos outros para obter as latências mais baixas de acesso à
memória.
As abordagens iniciais somente de posicionamento geralmente são suficientes para sistemas

que executam apenas uma única carga de trabalho, como uma configuração de avaliação de
desempenho que permanece inalterada enquanto o sistema estiver em execução. No entanto,
essa abordagem não é capaz de garantir bom desempenho e equidade para um sistema de
classe de datacenter que ofereça suporte a mudanças de cargas de trabalho. Portanto, além do
posicionamento inicial, o ESXi 5.0 faz a migração dinâmica de CPUs virtuais e memória entre nós
NUMA para melhorar o equilíbrio da CPU e aumentar a localidade da memória.
Balanceamento de carga dinâmico e migração de página

ESXi combina a abordagem de posicionamento inicial tradicional com um algoritmo de
rebalanceamento dinâmico. Periodicamente (a cada dois segundos por padrão), o sistema
examina as cargas dos vários nós e determina se deve rebalancear a carga movendo uma
máquina virtual de um nó para outro.
Esse cálculo leva em conta as configurações de recursos para máquinas virtuais e pools de
recursos para melhorar o desempenho sem violar a equidade ou os direitos de recursos.
O rebalanceador seleciona uma máquina virtual apropriada e altera seu nó inicial para o nó
menos carregado. Quando pode, o rebalanceador move uma máquina virtual que já tem
alguma memória localizada no nó de destino. A partir desse ponto (a menos que seja movida
novamente), a máquina virtual aloca memória em seu novo nó inicial e é executada apenas em
processadores no novo nó inicial.

O rebalanceamento é uma solução eficaz para manter a equidade e garantir que todos os nós
sejam totalmente usados. O rebalanceador pode precisar mover uma máquina virtual para um
nó no qual ela alocou pouca ou nenhuma memória. Nesse caso, a máquina virtual incorre em
uma penalidade de desempenho associada a um grande número de acessos à memória remota.
ESXi pode eliminar essa penalidade ao migrar de forma transparente a memória do nó original da
máquina virtual para seu novo nó inicial:
1 O sistema seleciona uma página (4KB de memória contígua) no nó original e copia seus
dados para uma página no nó de destino.
2 O sistema usa a camada de monitor da máquina virtual e o hardware de gerenciamento de

memória do processador para remapear perfeitamente a exibição de memória da máquina
virtual, para que ela use a página no nó de destino para todas as referências adicionais,
eliminando a penalidade de acesso à memória remota.
Quando uma máquina virtual é movida para um novo nó, o host ESXi começa imediatamente
a migrar sua memória dessa maneira. Ele gerencia a taxa para evitar sobrecarregar o sistema,
especialmente quando a máquina virtual tem pouca memória remota restante ou quando o nó
de destino tem pouca memória livre disponível. O algoritmo de migração de memória também
garante que o host ESXi não mova a memória desnecessariamente se uma máquina virtual for
movida para um novo nó por apenas um curto período.
Quando o posicionamento inicial, o rebalanceamento dinâmico e a migração inteligente de

memória funcionam em conjunto, eles garantem um bom desempenho de memória em sistemas
NUMA, mesmo na presença de mudanças nas cargas de trabalho. Quando ocorre uma grande
alteração na carga de trabalho, por exemplo, quando novas máquinas virtuais são iniciadas, o
sistema leva tempo para reajustar, migrando as máquinas virtuais e a memória para novos locais.
Após um curto período de tempo, normalmente segundos ou minutos, o sistema conclui seus
reajustes e atinge um estado estável.
Compartilhamento transparente de páginas otimizado para NUMA

Muitas ESXi cargas de trabalho apresentam oportunidades para compartilhar memória entre
máquinas virtuais.
Por exemplo, várias máquinas virtuais podem estar executando instâncias do mesmo sistema
operacional convidado, ter os mesmos aplicativos ou componentes carregados ou conter dados
comuns. Nesses casos, os sistemas ESXi usam uma técnica proprietária de compartilhamento de
página transparente para eliminar com segurança cópias redundantes de páginas de memória.
Com o compartilhamento de memória, uma carga de trabalho em execução em máquinas virtuais
geralmente consome menos memória do que consumiria em execução em máquinas físicas.
Como resultado, níveis mais altos de comprometimento excessivo podem ser suportados de
forma eficiente.

O compartilhamento transparente de páginas para sistemas ESXi também foi otimizado para uso
em sistemas NUMA. Em sistemas NUMA, as páginas são compartilhadas por nó, portanto, cada
nó NUMA tem sua própria cópia local de páginas muito compartilhadas. Quando as máquinas
virtuais usam páginas compartilhadas, elas não precisam acessar a memória remota.
Observação Esse comportamento padrão é o mesmo em todas as versões anteriores de ESX e

ESXi.
Gerenciamento de recursos em arquiteturas NUMA

Você pode executar o gerenciamento de recursos com diferentes tipos de arquitetura NUMA.
Com a proliferação de sistemas altamente multicore, as arquiteturas NUMA estão se tornando

mais populares, pois permitem um melhor dimensionamento de desempenho de cargas de
trabalho com uso intensivo de memória. Todos os sistemas modernos da Intel e da AMD têm
suporte a NUMA embutido nos processadores. Além disso, existem sistemas NUMA tradicionais,
como o IBM Enterprise X-Architecture, que estendem os processadores Intel e AMD com
comportamento NUMA com suporte de chipset especializado.
Normalmente, você pode usar as configurações do BIOS para ativar e desativar o

comportamento NUMA. Por exemplo, em servidores HP Proliant baseados em AMD Opteron,
o NUMA pode ser desativado ativando a intercalação de nós no BIOS. Se o NUMA estiver
ativado, o BIOS criará uma tabela de alocação de recursos do sistema (SRAT) que ESXi usa
para gerar as informações de NUMA usadas nas otimizações. Para fins de agendamento, as
otimizações de NUMA não estão habilitadas para sistemas com poucos núcleos por nó NUMA
ou poucos núcleos no geral. Você pode modificar as opções numa.rebalancecorestotal e
numa.rebalancecoresnode para alterar esse comportamento.
Usando o Virtual NUMA

O vSphere 5.0 e posterior inclui suporte para expor a topologia virtual do NUMA a sistemas
operacionais convidados, o que pode melhorar o desempenho facilitando as otimizações do
sistema operacional convidado e do NUMA do aplicativo.
A topologia do NUMA virtual está disponível para as máquinas virtuais da versão 8 do hardware
e é ativada por padrão quando o número de CPUs virtuais é maior que oito. Você também
pode influenciar manualmente a topologia do NUMA virtual usando opções de configuração
avançadas.
A primeira vez que uma máquina virtual habilitada para NUMA virtual é ligada, sua topologia
NUMA virtual é baseada na topologia NUMA do host físico subjacente. Depois que uma topologia
de NUMA virtual de máquinas virtuais é inicializada, ela não muda, a menos que o número de
vCPUs nessa máquina virtual seja alterado.
A topologia do NUMA virtual não considera a memória configurada para uma máquina virtual. A
topologia do NUMA virtual não é influenciada pelo número de soquetes virtuais e pelo número
de núcleos por soquete para uma máquina virtual.

Se a topologia do NUMA virtual precisar ser substituída, consulte Controles virtuais do NUMA.
Observação A ativação do HotAdd da CPU desativará o NUMA virtual. Consulte https://

kb.vmware.com/kb/2040375.
Controles virtuais do NUMA

Para máquinas virtuais com um consumo de memória desproporcionalmente grande, você pode
usar opções avançadas para substituir as configurações padrão da CPU virtual.
Você pode adicionar essas opções avançadas ao arquivo de configuração da máquina virtual.
Tabela 16-1. Opções avançadas para controles NUMA virtuais
Opção Descrição Valor Padrão
cpuid.coresPerSocket Determina o número de núcleos virtuais por soquete de 1

CPU virtual. Essa opção não afeta a topologia NUMA
virtual, a menos que uma.vcpu.followcorespersocket
esteja configurada.
numa.vcpu.maxPerVirtualNode Determina o número de nós NUMA virtuais dividindo 8

a contagem total de vCPU igualmente com esse valor
como seu divisor.
numa.autosize.once Quando você cria um modelo de máquina virtual com VERDADEIRO

essas configurações, as configurações permanecem as
mesmas sempre que você liga a máquina virtual com o
valor padrão VERDADEIRO. Se o valor for definido como
FALSE, a topologia virtual do NUMA será atualizada
toda vez que for ligada. A topologia do NUMA virtual
é reavaliada quando o número configurado de CPUs
virtuais na máquina virtual é modificado a qualquer
momento.
numa.vcpu.min O número mínimo de CPUs virtuais em uma máquina 9

virtual necessárias para gerar uma topologia NUMA
virtual. Uma máquina virtual é sempre UMA quando seu
tamanho é menor que numa.vcpu.min
numa.vcpu.followcorespersocket Se definido como 1, reverte para o comportamento 0

antigo de dimensionamento de nó virtual do NUMA
sendo vinculado a cpuid.coresPerSocket.
Especificando controles NUMA

Se você tiver aplicativos que usam muita memória ou têm um pequeno número de máquinas
virtuais, convém otimizar o desempenho especificando explicitamente o posicionamento da CPU
e da memória da máquina virtual.

Especificar controles é útil se uma máquina virtual executa uma carga de trabalho com
uso intenso de memória, como um banco de dados na memória ou um aplicativo de
computação científica com um grande conjunto de dados. Você também pode querer otimizar
posicionamentos NUMA manualmente se a carga de trabalho do sistema for conhecida
como simples e imutável. Por exemplo, é fácil otimizar explicitamente um sistema de oito
processadores executando oito máquinas virtuais com cargas de trabalho semelhantes.
Observação Na maioria das situações, as otimizações automáticas de NUMA do host ESXi

resultam em bom desempenho.
O ESXi fornece três conjuntos de controles para o posicionamento NUMA, para que os
administradores possam controlar o posicionamento do processador e da memória de uma
máquina virtual.
Você pode especificar as seguintes opções.
Afinidade de nó NUMA
Quando você define essa opção, o NUMA pode agendar uma máquina virtual somente nos
nós especificados na afinidade.
Afinidade de CPU
Quando você define essa opção, uma máquina virtual usa apenas os processadores
especificados na afinidade.
Afinidade de Memória
Quando você define essa opção, o servidor aloca memória apenas nos nós especificados.
Uma máquina virtual ainda é gerenciada pelo NUMA quando você especifica a afinidade de nó
NUMA, mas suas CPUs virtuais podem ser agendadas apenas nos nós especificados na afinidade
de nó NUMA. Da mesma forma, a memória pode ser obtida somente dos nós especificados na
afinidade do nó NUMA. Quando você especifica afinidades de CPU ou memória, uma máquina
virtual deixa de ser gerenciada pelo NUMA. O gerenciamento NUMA dessas máquinas virtuais é
eficaz quando você remove as restrições de afinidade de CPU e memória.
O posicionamento manual do NUMA pode interferir com ESXi algoritmos de gerenciamento

de recursos, que distribuem os recursos do processador de forma justa em um sistema. Por
exemplo, se você colocar manualmente 10 máquinas virtuais com cargas de trabalho com uso
intensivo de processador em um nó e manualmente colocar apenas 2 máquinas virtuais em outro
nó, será impossível para o sistema fornecer a todas as 12 máquinas virtuais partes iguais de
recursos do sistema.
Associar máquinas virtuais a processadores específicos

Você pode melhorar o desempenho dos aplicativos em uma máquina virtual fixando suas CPUs
virtuais em processadores fixos. Isso permite que você impeça que as CPUs virtuais migrem
entre os nós NUMA.

Procedimentos
(Edit Settings).
3 Selecione a guia Hardware virtual (Virtual Hardware) e expanda CPU (CPU).
4 Em Agendamento de afinidade, defina a afinidade de CPU para os processadores

preferenciais.
Observação Você deve selecionar manualmente todos os processadores no nó NUMA. A

afinidade de CPU é especificada por processador, não por nó.
Associar alocações de memória a nós NUMA específicos usando a

afinidade de memória
Você pode especificar que todas as alocações de memória futuras em uma máquina virtual usem
páginas associadas a nós NUMA específicos (também conhecidos como afinidade de memória
manual).
Observação Especifique os nós a serem usados para alocações de memória futuras somente se
você também tiver especificado a afinidade de CPU. Se você fizer alterações manuais apenas nas
configurações de afinidade de memória, o rebalanceamento NUMA automático não funcionará
corretamente.
Procedimentos
3 Clique em Configurações (Settings) e clique em Hardware da VM (VM Hardware).
5 Selecione a guia Hardware virtual (Virtual Hardware) e expanda Memória (Memory).
6 Em Afinidade de Memória NUMA, defina a afinidade de memória.
Exemplo: Vinculando uma máquina virtual a um único nó NUMA

O exemplo a seguir ilustra a associação manual das quatro últimas CPUs físicas a um único nó
NUMA para uma máquina virtual bidirecional em um servidor de oito vias.

As CPUs (por exemplo, 4, 5, 6 e 7) são os números físicos de CPU.
1 No vSphere Client, clique com o botão direito do mouse na máquina virtual e selecione Editar
2 Selecione Opções (Options) e clique em Avançado (Advanced).
3 Clique no botão Parâmetros de configuração (Configuration Parameters).
4 No vSphere Client, ative a afinidade de CPU para os processadores 4, 5, 6 e 7.
Em seguida, você deseja que esta máquina virtual seja executada apenas no nó 1.
1 No painel de inventário vSphere Client, selecione a máquina virtual e selecione Editar

2 Selecione Opções (Options) e clique em Avançado (Advanced).
3 Clique no botão Parâmetros de configuração (Configuration Parameters).
4 No vSphere Client, defina a afinidade de memória para o nó NUMA como 1.
A conclusão dessas duas tarefas garante que a máquina virtual seja executada apenas no nó
NUMA 1 e, quando possível, aloque memória do mesmo nó.
Associar máquinas virtuais a nós NUMA especificados

Ao associar um nó NUMA a uma máquina virtual para especificar a afinidade de nó NUMA, você
restringe o conjunto de nós NUMA nos quais o ESXi pode agendar a CPU e a memória virtual de
uma máquina virtual.
Observação Ao restringir as afinidades de nó NUMA, você pode interferir na capacidade

do agendador NUMA do ESXi de reequilibrar máquinas virtuais em nós NUMA para fins de
equidade. Especifique a afinidade do nó NUMA somente depois de considerar os problemas de
rebalanceamento.
Procedimentos
2 Clique na guia Configurar (Configure) e clique em Configurações (Settings).
3 Em VM Options (VM Options), clique no botão Edit (Edit).
4 Selecione a guia VM Options (VM Options) e expanda Advanced (Advanced).
5 Em Configuration Parameters (Configuration Parameters), clique no botão Edit

Configuration ( Edit Configuration).
6 Clique em Add Row (Add Row) para adicionar uma nova opção.
7
n Para especificar o nó NUMA para a máquina virtual, na coluna Nome, insira
numa.nodeAffinity .

n Para especificar o nó NUMA para um nó NUMA virtual específico na máquina virtual, na

coluna Nome, insira sched.nodeX.affinity , onde X é o número do nó NUMA virtual.
Por exemplo, sched.node0.affinity especifica o nó NUMA virtual 0 na máquina
virtual.
8 Na coluna Valor, insira os nós NUMA em que a máquina virtual ou o nó NUMA virtual pode
ser agendado.
Use uma lista separada por vírgulas para vários nós. Por exemplo, insira 0,1 para restringir o
agendamento de recursos da máquina virtual aos nós NUMA 0 e 1.
10 Clique em OK (OK) para fechar a caixa de diálogo Editar VM.

Atributos avançados
17
Você pode definir atributos avançados para hosts ou máquinas virtuais individuais para ajudar a
personalizar o gerenciamento de recursos.
Na maioria dos casos, ajustar as configurações básicas de alocação de recursos (reserva,

limite, compartilhamentos) ou aceitar as configurações padrão resulta na alocação de recursos
apropriada. No entanto, você pode usar atributos avançados para personalizar o gerenciamento
de recursos para um host ou uma máquina virtual específica.
n Definir atributos de host avançados
n Definir atributos de máquina virtual avançada
n Sensibilidade à latência
n Sobre a memória confiável
n Fazendo backup da vRAM guest com páginas de 1 GB
Definir atributos de host avançados

Você pode definir atributos avançados para um host.
Cuidado A alteração das opções avançadas é considerada sem suporte. Normalmente, as

configurações padrão produzem o melhor resultado. Altere as opções avançadas somente
quando você receber instruções específicas do VMware suporte técnico ou de um artigo da
base de conhecimento.
Procedimentos
3 Em Sistema (System), clique em Configurações avançadas do sistema (Advanced System

Settings).
4 Em Configurações avançadas do sistema, selecione o item apropriado.
5 Clique no botão Editar (Edit) e altere o valor.

Atributos avançados de memória

Você pode usar os atributos de memória avançados para personalizar o uso de recursos de
memória.
Tabela 17-1. Atributos avançados de memória
Atributo Descrição Padrão
Mem.ShareForceSalting Mem.ShareForceSalting 0: O comportamento de 2

compartilhamento de página transparente (TPS) entre máquinas
virtuais ainda é mantido. O valor da opção VMX
Sched.mem.pshare.salt é ignorado, mesmo se presente.
Mem.ShareForceSalting 1: Por padrão, o valor de salt é obtido de
Sched.mem.pshare.salt . Se não for especificado, ele retornará
ao comportamento antigo do TPS (entre VMs) considerando os
valores de sal para a máquina virtual como 0.
Mem.ShareForceSalting 2: por padrão, o valor de salt é obtido
de Sched.mem.pshare.salt se presente, ou vc.uuid . Se não
existir, o algoritmo de compartilhamento de página gerará um
valor aleatório e exclusivo para a adição de sal por máquina virtual,
que não é configurável pelos usuários.
Mem.SamplePeriod Especifica o intervalo de tempo periódico, medido em segundos 60

do tempo de execução da máquina virtual, durante o qual a
atividade de memória é monitorada para estimar os tamanhos dos
conjuntos de trabalho.
Mem.BalancePeriod Especifica o intervalo de tempo periódico, em segundos, para 15

realocações de memória automáticas. Alterações significativas na
quantidade de memória livre também acionam realocações.
Mem.IleTax Especifica a taxa de imposto de memória ociosa, como 75

uma porcentagem. Esse imposto efetivamente cobra mais das
máquinas virtuais pela memória ociosa do que pela memória que
elas estão usando ativamente. Uma taxa de imposto de 0% define
uma política de alocação que ignora conjuntos de trabalho e aloca
memória estritamente com base em compartilhamentos. Uma taxa
de imposto alta resulta em uma política de alocação que permite
que a memória ociosa seja realocada para longe de máquinas
virtuais que a estão improdutivamente acumulando.
Mem.ShareScanGHz Especifica a quantidade máxima de páginas de memória 4

a serem verificadas (por segundo) para oportunidades de
compartilhamento de página para cada GHz de recurso de CPU
do host disponível. Por exemplo, o padrão é 4 MB / s por 1 GHz.
Mem.ShareScanTime Especifica o tempo, em minutos, durante o qual uma máquina 60

virtual inteira é verificada em busca de oportunidades de
compartilhamento de páginas. O padrão é 60 minutos.

Tabela 17-1. Atributos avançados de memória (continuação)
Mem.CtlMaxPercent Limita a quantidade máxima de memória recuperada de qualquer 65

máquina virtual usando o driver de balão de memória (vmmemctl),
com base em uma porcentagem do seu tamanho de memória
configurado. Especifique 0 para desativar a recuperação para
todas as máquinas virtuais.
Mem.AllocGuestLargePage Permite o suporte de páginas grandes de convidados com páginas 1

grandes de host. Reduz erros de TLB e melhora o desempenho
em cargas de trabalho de servidor que usam páginas grandes de
convidados. 0 = desativar.
Mem.AllocUsePSharePool Reduz a fragmentação da memória, melhorando a probabilidade 15

e de fazer backup de páginas grandes de convidados com páginas
grandes de host. Se a memória do host estiver fragmentada, a
Mem.AllocUseGuestPool
disponibilidade de páginas grandes do host será reduzida. 0 =
desativar.
Mem.MemZipEnable Habilita a compactação de memória para o host. 0 = desativar. 1
Mem.MemZipMaxPct Especifica o tamanho máximo do cache de compactação em 10

termos da porcentagem máxima da memória de cada máquina
virtual que pode ser armazenada como memória compactada.
LPage.LPageDefragEnable Permite a desfragmentação de páginas grandes. 0 = desativar. 1
LPage.LPageDefragRateVM Número máximo de tentativas de desfragmentação de página 32

grande por segundo por máquina virtual. Os valores aceitos variam
de 1 a 1024.
LPage.LPageDefragRateTotal Número máximo de tentativas de desfragmentação de página 256

grande por segundo. Os valores aceitos variam de 1 a 10240.
LPage.LPageAlwaysTenteForNPT Tente alocar páginas grandes para tabelas de páginas aninhadas 1

(chamadas de 'RVI' pela AMD ou 'EPT' pela Intel). Se você habilitar
essa opção, toda a memória do convidado será apoiada com
páginas grandes em máquinas que usam tabelas de páginas
aninhadas (por exemplo, AMD Barcelona). Se o NPT não estiver
disponível, apenas uma parte da memória do convidado será
apoiada com páginas grandes. 0 = desativar.
Atributos avançados de NUMA

Você pode usar os atributos avançados do NUMA para personalizar o uso do NUMA.

Tabela 17-2. Atributos avançados de NUMA
Numa.RebalancePeriod Controla a frequência de períodos de rebalanceamento, 2000

especificados em milissegundos. Um rebalanceamento
mais frequente pode aumentar as sobrecargas da CPU,
especialmente em máquinas com um grande número de
máquinas virtuais em execução. Um rebalanceamento mais
frequente também pode melhorar a equidade.
Numa.MigImbalance Thruster O rebalanceador NUMA calcula o desbalanceamento de 10

CPU entre os nós, representando a diferença entre o
direito de tempo de CPU de cada máquina virtual e seu
consumo real. Essa opção controla o desequilíbrio de
carga mínimo entre os nós necessários para disparar uma
migração de máquina virtual, em porcentagem.
Numa.RebalanceEnable Habilite o rebalanceamento e a programação do NUMA. 1

Defina essa opção como 0 para desativar todo o
rebalanceamento NUMA e o posicionamento inicial das
máquinas virtuais, desativando efetivamente o sistema de
agendamento NUMA.
Numa.RebalanceCoresTotal Especifica o número mínimo de núcleos totais 4

de processador no host necessário para ativar o
rebalanceador NUMA.
Numa.RebalanceCoresNode Especifica o número mínimo de núcleos de processador 2

por nó necessários para ativar o rebalanceador NUMA.
Essa opção e o Numa.RebalanceCoresTotal são úteis
ao desativar o rebalanceamento NUMA em pequenas
configurações NUMA (por exemplo, hosts Opteron
bidirecionais), onde o pequeno número de processadores
totais ou por nó pode comprometer a equidade de
agendamento quando você habilita o rebalanceamento
NUMA.
Numa.AutoMemAffinity Defina automaticamente a afinidade de memória para 1

máquinas virtuais com afinidade de CPU definida.
Numa.PageMigEnable Migre automaticamente as páginas entre os nós NUMA 1

para melhorar a localidade da memória. As taxas de
migração de página definidas manualmente ainda estão em
vigor.
Definir atributos de máquina virtual avançada

Você pode definir atributos avançados para uma máquina virtual.

Procedimentos
2 Clique com o botão direito do mouse na máquina virtual e selecione Editar configurações
(Edit Settings).
3 Clique em Opções de VM (VM Options).
4 Expandir Avançado (Advanced).
5 Em Parâmetros de configuração, clique no botão Editar configuração ( Edit Configuration).
6 Na caixa de diálogo exibida, clique em Adicionar linha (Add Row) para inserir um novo
parâmetro e seu valor.
Atributos avançados de máquina virtual

Você pode usar os atributos avançados da máquina virtual para personalizar a configuração da
máquina virtual.
Tabela 17-3. Atributos avançados de máquina virtual
Sched.mem.maxmem Quantidade máxima de memória recuperada da -1 (Ilimitado)

ctl máquina virtual selecionada por balonismo, em
megabytes (MB). Se o host ESXi precisar recuperar
memória adicional, ele será forçado a trocar. Trocar é
menos desejável do que balonismo.
Sched.mem.pshare.en Habilita o compartilhamento de memória para uma Verdadeiro

able máquina virtual selecionada.
Esse valor booliano é padronizado como Verdadeiro.
Se você defini-la como Falso para uma máquina
virtual, isso desativará o compartilhamento de
memória.
Sched.mem.pshare.sa Um valor salt é uma opção configurável do VMX configurável pelo usuário
lt para cada máquina virtual. Se essa opção não estiver
presente no arquivo VMX da máquina virtual, o
valor de vc.uuid vmx será considerado o valor
padrão. Como o vc.uuid é exclusivo para cada
máquina virtual, por padrão, o compartilhamento de
página transparente ocorre apenas entre as páginas
pertencentes a uma determinada máquina virtual
(dentro da VM). Se um grupo de máquinas virtuais
for considerado confiável, será possível compartilhar
páginas entre elas definindo um valor de sal comum
para todas essas máquinas virtuais (entre VMs).

Tabela 17-3. Atributos avançados de máquina virtual (continuação)
Sched.swap.persist Especifica se os arquivos de permuta da máquina Falso

virtual devem persistir ou ser excluídos quando a
máquina virtual é desligada. Por padrão, o sistema
cria o arquivo de permuta para uma máquina virtual
quando a máquina virtual está ligada e exclui o
arquivo de permuta quando a máquina virtual está
desligada.
Sched.swap.dir Local do diretório do arquivo de permuta da máquina Igual a workingDir

virtual. O padrão é o diretório de trabalho da
máquina virtual, ou seja, o diretório que contém
seu arquivo de configuração. Esse diretório deve
permanecer em um host que seja acessível à
máquina virtual. Se você mover a máquina virtual (ou
quaisquer clones criados a partir dela), talvez seja
necessário redefinir esse atributo.
Atributos avançados de NUMA virtual

Você pode usar os atributos avançados do NUMA virtual para personalizar o uso do NUMA
virtual.
Tabela 17-4. Atributos avançados de NUMA
cpuid.coresPerSocket Determina o número de núcleos virtuais por soquete 1

de CPU virtual. Se o valor for maior que 1, o também
determinará o tamanho dos nós NUMA virtuais se uma
máquina virtual tiver uma topologia NUMA virtual. Você
pode definir essa opção se souber a topologia NUMA
virtual exata para cada host físico.
numa.autosize Quando você define essa opção, a topologia do NUMA FALSO

virtual tem o mesmo número de CPUs virtuais por nó
virtual do que há núcleos em cada nó físico.
numa.autosize.once Quando você cria um modelo de máquina virtual com VERDADEIR

essas configurações, as configurações são garantidas O
para permanecerem as mesmas sempre que você ligar
a máquina virtual posteriormente. A topologia do NUMA
virtual será reavaliada se o número configurado de CPUs
virtuais na máquina virtual for modificado.
numa.vcpu.maxPerVirtualNode Se cpuid.coresPerSocket for muito restritivo 8

como uma potência de dois, você poderá definir
numa.vcpu.maxPerVirtualNode diretamente. Nesse
caso, não defina cpuid.coresPerSocket.
numa.vcpu.min Número mínimo de CPUs virtuais em uma máquina virtual 9

necessárias para gerar uma topologia NUMA virtual.

Tabela 17-4. Atributos avançados de NUMA (continuação)
numa.vcpu.maxPerMachineNode Número máximo de CPUs virtuais que pertencem à mesma Número de

máquina virtual que pode ser agendada em um nó NUMA núcleos por
ao mesmo tempo. Use esse atributo para garantir a nó no host
largura de banda máxima, forçando diferentes clientes físico em
NUMA em diferentes nós NUMA. que uma
máquina
virtual está
em
execução.
numa.vcpu.maxPerClient Número máximo de CPUs virtuais em um cliente NUMA. Igual a

Um cliente é um grupo de CPUs virtuais gerenciadas numa.vcpu.
pelo NUMA como uma única entidade. Por padrão, cada maxPerMach
nó NUMA virtual é um cliente NUMA, mas se um nó ineNode
NUMA virtual for maior que um nó NUMA físico, um único
nó NUMA virtual poderá ser apoiado por vários clientes
NUMA.
numa.nodeAffinity Restringe o conjunto de nós NUMA nos quais a CPU e

a memória virtuais de uma máquina virtual podem ser
agendadas.
Observação Ao restringir as afinidades de nó NUMA,

você pode interferir com a capacidade do agendador
NUMA de rebalancear as máquinas virtuais nos nós NUMA
para fins de equidade. Especifique a afinidade de nó
NUMA somente depois de considerar os problemas de
rebalanceamento.
numa.mem.interleave Especifica se a memória alocada a uma máquina virtual Verdadeiro

é intercalada estaticamente em todos os nós NUMA
nos quais seus clientes NUMA constituintes estão em
execução e se não há nenhuma topologia NUMA virtual
exposta.
Sensibilidade à latência
Você pode ajustar a sensibilidade à latência de uma máquina virtual para otimizar o atraso de
agendamento para aplicativos sensíveis à latência.
ESXi é otimizado para oferecer alta taxa de transferência. Você pode otimizar sua máquina
virtual para atender aos requisitos de baixa latência de aplicativos sensíveis à latência. Exemplos
de aplicativos sensíveis à latência são aplicativos de VOIP ou media player, ou aplicativos que
exigem acesso frequente aos dispositivos de mouse ou teclado.
Ajustar a sensibilidade da latência

Você pode ajustar a sensibilidade à latência de uma máquina virtual.

Pré-requisitos
O ESXi 6.7 requer reserva de CPU completa para ligar uma VM com a versão de hardware 14
quando a Sensibilidade da Latência está definida como alta (high).
Procedimentos
(Edit Settings).
3 Clique em Opções de VM (VM Options) e clique em Avançado (Advanced).
4 Selecione uma configuração no menu suspenso Latência Sensibilidade (Latency Sensitivity).
Sobre a memória confiável

ESXi suporta memória confiável.
Alguns sistemas têm memória confiável, que é uma parte da memória com menor probabilidade
de ter erros de memória de hardware do que outras partes da memória no sistema. Se
o hardware expuser informações sobre os diferentes níveis de confiabilidade, ESXi poderá
conseguir uma maior confiabilidade do sistema.
Exibir memória confiável

Você pode ver se a licença permite ou não memória confiável.
Procedimentos
2 Clique na guia Configurar (Configure) e clique em Sistema (System).
3 Selecione Licenciamento (Licensing).
4 Em Recursos licenciados (Licensed Features), verifique se Memória confiável é exibida.
Próximo passo
Você pode procurar quanta memória é considerada confiável usando o comando ESXCLI
hardware memory get.
Fazendo backup da vRAM guest com páginas de 1 GB

O vSphere 6.7 ESXi oferece suporte limitado para o backup da vRAM guest com páginas de 1 GB.

Para usar páginas de 1 GB para fazer backup da memória de convidado, você deve aplicar
a opção Sched.mem.lpage.enable1GPage = "TRUE" para a VM. Você pode definir isso em
Opções avançadas ao selecionar Editar configurações (Edit Settings). Você só pode ativar
páginas de 1 GB em uma VM que está desligada.
Uma VM com páginas de 1 GB habilitadas deve ter reserva de memória completa. Caso contrário,
a VM não poderá ser ligada. Toda a vRAM para VMs com páginas de 1 GB habilitadas é pré-
alocada ao ligar. Como essas VMs têm reserva de memória completa, elas não são afetadas pela
recuperação de memória e seu consumo de memória permanece no nível máximo durante toda a
vida útil da VM.
O suporte de vRAM de página de 1 GB é oportunista e as páginas de 1 GB são alocadas com

base no melhor esforço. Isso inclui casos em que as CPUs do host não têm recursos de 1 GB. Para
maximizar as chances de ter o vRAM convidado com backup de páginas de 1 GB, recomendamos
iniciar VMs que exigem páginas de 1 GB em um host recém-inicializado, pois com o passar do
tempo a RAM do host está fragmentada.
Uma VM com páginas de 1 GB habilitadas pode ser migrada para um host diferente. No entanto,
o tamanho da página de 1 GB pode não ser alocado no host de destino na mesma quantidade
que estava no host de origem. Você também pode ver que parte do vRAM com backup com
uma página de 1 GB no host de origem não tem mais backup com uma página de 1 GB no host de
destino.
A natureza oportunista das páginas de 1 GB se estende aos serviços do vSphere, como HA e

DRS, que podem não preservar o suporte de vRAM de página de 1 GB. Esses serviços não têm
conhecimento dos recursos de 1 GB do host de destino e não levam em conta o suporte de
memória de 1 GB ao tomar decisões de posicionamento.

Definições de falha
18
As falhas do DRS indicam os motivos que impedem a geração de ações do DRS (ou a
recomendação dessas ações no modo manual).
As falhas do DRS são definidas nesta seção.
n A máquina virtual está fixada
n A máquina virtual não é compatível com nenhum host
n Regra de VM / VM DRS violada ao mover para outro host
n Host incompatível com máquina virtual
n O host tem uma máquina virtual que viola as regras de DRS de VM / VM
n O host tem capacidade insuficiente para a máquina virtual
n Host em estado incorreto
n O host tem um número insuficiente de CPUs físicas para a máquina virtual
n O host tem capacidade insuficiente para cada CPU de máquina virtual
n A máquina virtual está no vMotion
n Nenhum host ativo no cluster
n Recursos insuficientes
n Recursos insuficientes para satisfazer o nível de failover configurado para HA
n Nenhum host de afinidade rígida compatível
n Nenhum host de afinidade flexível compatível
n Correção de violação da regra flexível não é permitida
n Impacto da correção da violação da regra flexível

A máquina virtual está fixada

Essa falha ocorre quando o DRS não pode mover uma máquina virtual porque o DRS está
desativado nela. Ou seja, a máquina virtual é "fixada" em seu host registrado.
A máquina virtual não é compatível com nenhum host

Essa falha ocorre quando o DRS não consegue encontrar um host que possa executar a máquina
virtual.
Isso pode ocorrer, por exemplo, se nenhum host puder satisfazer as necessidades de recursos
de memória ou CPU da máquina virtual ou se nenhum host tiver atualmente acesso à rede ou ao
armazenamento necessário pela máquina virtual.
Para resolver esse problema, forneça um host que possa atender aos requisitos da máquina
virtual.
Regra de VM / VM DRS violada ao mover para outro host

Essa falha ocorre quando mais de uma máquina virtual em execução no mesmo host e que
compartilham regras de afinidade entre si não pode ser movida para outro host.
Isso pode ocorrer porque nem todas as máquinas virtuais podem desativar o vMotion do host
atual. Por exemplo, uma das máquinas virtuais no grupo está desativada para DRS.
Para evitar isso, verifique os motivos pelos quais algumas máquinas virtuais no grupo não podem
vMotion.
Host incompatível com máquina virtual

Essa falha ocorre quando o DRS considera a migração de uma máquina virtual para um host, mas
descobre que o host é incompatível com a máquina virtual especificada.
Isso pode ocorrer porque o host de destino não tem acesso à rede ou à conexão de
armazenamento necessária pela máquina virtual. Outro motivo pelo qual essa falha ocorre é
se o host de destino tem uma CPU que difere suficientemente do host atual para que o uso do
vMotion entre os hosts não seja suportado.
Para evitar isso, crie clusters de forma que todos os hosts sejam configurados de forma
consistente e o vMotion seja compatível entre os hosts.
Outro motivo pelo qual o host é incompatível com a máquina virtual é que há uma regra de DRS
de VM / Host necessária que instrui o DRS a nunca colocar essa máquina virtual nesse host.

O host tem uma máquina virtual que viola as regras de DRS

de VM / VM
Essa falha ocorre quando a máquina virtual, quando ligada ou movida ao iniciar o vMotion, pode
violar uma regra de DRS de VM / VM.
A máquina virtual ainda pode ser ligada ou movida manualmente com o vMotion, mas vCenter
Server não pode fazer isso automaticamente.
O host tem capacidade insuficiente para a máquina virtual

Essa falha ocorre quando o host não tem capacidade de CPU ou memória suficiente para
executar a máquina virtual.
Host em estado incorreto

Essa falha ocorre quando o host está entrando no estado de manutenção ou em espera quando
necessário para que a ação do DRS ocorra.
Para resolver essa falha, cancele a solicitação para que o host entre no modo de espera ou de
manutenção.
O host tem um número insuficiente de CPUs físicas para a

máquina virtual
Essa falha ocorre quando o hardware do host não tem CPUs suficientes (hyperthreads) para
oferecer suporte ao número de CPUs virtuais na máquina virtual.
O host tem capacidade insuficiente para cada CPU de

máquina virtual
Essa falha ocorre quando o host não tem capacidade de CPU suficiente para executar a máquina
virtual.
A máquina virtual está no vMotion

Essa falha ocorre quando o DRS não pode mover uma máquina virtual porque ela está no
vMotion.
Nenhum host ativo no cluster

Essa falha ocorre quando o cluster no qual a máquina virtual está sendo movida não contém
nenhum host que esteja conectado e em um estado de não manutenção.

Isso pode ocorrer, por exemplo, quando todos os hosts estão desconectados ou no modo de
manutenção.
Recursos insuficientes
Essa falha ocorre quando uma tentativa de operação está em conflito com uma política de
configuração de recurso.
Essa falha pode ocorrer, por exemplo, se uma operação de inicialização reserva mais memória
do que a alocada para um pool de recursos.
Repita a operação depois de ajustar os recursos para permitir mais memória.
Recursos insuficientes para satisfazer o nível de failover

configurado para HA
Essa falha ocorre quando a configuração de HA dos recursos de CPU ou memória reservados
para failover é violada ou é insuficiente para a operação do DRS.
Essa falha é relatada quando:
n O host é solicitado a entrar no modo de manutenção ou de espera.
n A máquina virtual viola o failover quando tenta ligar.
Nenhum host de afinidade rígida compatível

Nenhum host está disponível para a máquina virtual que satisfaça suas regras obrigatórias de
afinidade ou antiafinidade DRS de Host / VM.
Nenhum host de afinidade flexível compatível

Nenhum host está disponível para a máquina virtual que satisfez suas regras de afinidade ou
antiafinidade de DRS / host preferenciais.
Correção de violação da regra flexível não é permitida

O limite de migração do DRS é definido como obrigatório apenas.
Isso não permite a geração de ações DRS para corrigir regras de afinidade de VM / Host DRS não
obrigatórias.
Impacto da correção da violação da regra flexível

A correção da regra de afinidade não obrigatória de VM / Host DRS não ocorre porque afeta o
desempenho.

Informações de solução de
problemas do DRS 19
®
Essas informações descrevem os problemas do vSphere Distributed Resource Scheduler (DRS)
para categorias específicas: problemas de cluster, host e máquina virtual.
n Problemas de cluster
n Problemas do host
n Problemas da máquina virtual
Problemas de cluster
Os problemas de cluster podem impedir que o DRS tenha um desempenho ideal ou que
comunique falhas.
Carregar desequilíbrio no cluster

Um cluster tem um desequilíbrio de carga de recursos.
Problema
Um cluster pode ficar desbalanceado devido a demandas de recursos desiguais das máquinas
virtuais e capacidades desiguais dos hosts.
Causa
A seguir, são possíveis os motivos pelos quais o cluster tem um desequilíbrio de carga:
n O limite de migração é muito alto.
Um limite mais alto torna o cluster um candidato mais provável para desequilíbrio de carga.
n As regras de VM / VM ou VM / Host DRS impedem que as máquinas virtuais sejam movidas.
n O DRS está desativado para uma ou mais máquinas virtuais.
n Um dispositivo é montado em uma ou mais máquinas virtuais que impedem que o DRS mova
a máquina virtual para balancear a carga.

n As máquinas virtuais não são compatíveis com os hosts para os quais o DRS as moveria. Ou
seja, pelo menos um dos hosts no cluster é incompatível para as máquinas virtuais que seriam
migradas. Por exemplo, se a CPU do host A não for compatível com o vMotion com a CPU do
host B, o host A se tornará incompatível para máquinas virtuais ligadas em execução no host
B.
n Seria mais prejudicial para o desempenho da máquina virtual movê-la do que para executá-la
onde está localizada atualmente. Isso pode ocorrer quando as cargas são instáveis ou o
custo de migração é alto em comparação com o benefício obtido com a movimentação da
máquina virtual.
n O vMotion não está habilitado ou configurado para os hosts no cluster.
Solução
Resolva o problema que está causando o desequilíbrio de carga.
O cluster é amarelo
O cluster está amarelo devido à falta de recursos.
Problema
Se o cluster não tiver recursos suficientes para satisfazer as reservas de todos os pools de
recursos e máquinas virtuais, mas tiver recursos suficientes para satisfazer as reservas de todas
as máquinas virtuais em execução, o DRS continuará a ser executado e o cluster ficará amarelo.
Causa
Um cluster pode ficar amarelo se os recursos do host forem removidos do cluster (por exemplo,
se um host falhar).
Solução
Adicione recursos de host ao cluster ou reduza as reservas do pool de recursos.
O cluster está vermelho devido a um pool de recursos inconsistente

Um cluster DRS fica vermelho quando é inválido. Pode ficar vermelho porque a árvore do pool de
recursos não é internamente consistente.
Problema
Se a árvore do pool de recursos do cluster não for internamente consistente (por exemplo,
a soma das reservas subordinadas for maior que a reserva não expansível do pool pai), o
cluster não terá recursos suficientes para satisfazer as reservas de todas as máquinas virtuais
em execução, deixando o cluster vermelho .

Causa
Isso pode ocorrer se vCenter Server estiver indisponível ou se as configurações do pool de

recursos forem alteradas enquanto uma máquina virtual estiver em um estado de failover.
Solução
Reverta as alterações associadas ou revise as configurações do pool de recursos.
O cluster está vermelho porque a capacidade de failover está

violada
Um cluster DRS fica vermelho quando é inválido. Pode ficar vermelho porque a capacidade de
failover foi violada.
Problema
O cluster tentará fazer failover de máquinas virtuais se houver uma falha no host, mas não é
garantido que haja recursos suficientes disponíveis para fazer failover de todas as máquinas
virtuais cobertas pelos requisitos de failover.
Causa
Se um cluster habilitado para HA perder tantos recursos que ele não puder mais atender aos
requisitos de failover, uma mensagem será exibida e o status do cluster mudará para vermelho.
Solução
Revise a lista de problemas de configuração na caixa amarela na parte superior da página

Resumo do cluster e resolva o problema que está causando o problema.
Nenhum host é desligado quando a carga total do cluster é baixa

Os hosts não são desligados quando a carga total do cluster é baixa.
Problema
Os hosts não são desligados quando a carga total do cluster é baixa porque a capacidade extra
é necessária para reservas de failover de HA.
Causa
Os hosts podem não ser desligados pelos seguintes motivos:
n As MinPoweredOn{Cpu|Memory}Capacity configurações de opções avançadas precisam ser

atendidas.
n As máquinas virtuais não podem ser consolidadas em menos hosts devido a suas reservas
de recursos, regras de DRS de VM / Host, regras de DRS de VM / VM, não sendo habilitadas
para DRS ou não sendo compatíveis com os hosts com capacidade disponível.
n As cargas são instáveis.

n O limite de migração do DRS está na configuração mais alta e só permite movimentos

obrigatórios.
n O vMotion não pode ser executado porque não está configurado.
n O DPM está desativado nos hosts que podem estar desligados.
n Os hosts não são compatíveis para que as máquinas virtuais sejam movidas para outro host.
n O host não tem a tecnologia Wake On LAN, IPMI ou iLO. Qualquer um deles é necessário para
o DPM inserir um host no modo de espera.
Solução
Resolva o problema que impede que os hosts sejam desligados quando a carga total do cluster
estiver baixa.
Os hosts são desligados quando a carga total do cluster é alta

Os hosts são desligados quando a carga total do cluster é alta.
Problema
O DRS determinou que as máquinas virtuais podem ser executadas em menos hosts sem
degradar o desempenho do host ou da máquina virtual. O DRS também é impedido de mover
as máquinas virtuais em execução nos hosts altamente utilizados para os hosts agendados para
desligamento.
Causa
A carga total do cluster é muito alta.
Solução
Reduza a carga do cluster.
O DRS raramente ou nunca executa migrações do vMotion

O DRS raramente ou nunca realiza migrações do vMotion.
Problema
O DRS não executa migrações do vMotion.
Causa
O DRS nunca realiza migrações do vMotion quando um ou mais dos seguintes problemas estão
presentes no cluster.
n O DRS está desativado no cluster.
n Os hosts não têm armazenamento compartilhado.
n Os hosts no cluster não contêm uma rede do vMotion.

n O DRS é manual e ninguém aprovou a migração.
O DRS raramente executa o vMotion quando um ou mais dos seguintes problemas estão
presentes no cluster:
n As cargas são instáveis ou o vMotion leva muito tempo ou ambas. Uma movimentação não é
apropriada.
n O DRS raramente ou nunca migra máquinas virtuais.
n O limite de migração do DRS está definido muito alto.
O DRS move as máquinas virtuais pelos seguintes motivos:
n A evacuação do host solicitado por um usuário entra no modo de manutenção ou de espera.
n Regras de VM / Host DRS ou regras de VM / VM DRS.
n Violações de reserva.
n Desequilíbrio de carga.
n Gerenciamento de energia.
Solução
Resolva os problemas que estão fazendo com que o DRS evite realizar migrações do vMotion.
Problemas do host
Problemas do host podem fazer com que o DRS não funcione conforme o esperado.
O DRS recomenda que o host seja ligado para aumentar a

capacidade quando a carga total do cluster for baixa
O host deve estar ligado para ajudar a fornecer mais capacidade para o cluster ou ajudar os
hosts que estão sobrecarregados.
Problema
O DRS recomenda que o host esteja ligado para aumentar a capacidade quando a carga total do
cluster estiver baixa.
Causa
A recomendação pode ser feita porque:
n O cluster é um cluster DRS-HA. São necessários hosts ligados adicionais para fornecer mais
capacidade de failover.
n Alguns hosts estão sobrecarregados e as máquinas virtuais em hosts atualmente ligados

podem ser movidas para hosts no modo de espera para balancear a carga.
n A capacidade é necessária para atender às MinPoweredOn{Cpu|Memory}Capacity opções

avançadas.

Solução
Ligue o host.
A carga total do cluster é alta

A carga total do cluster é alta.
Problema
Quando a carga total do cluster é alta, o DRS não liga o host.
Causa
A seguir estão possíveis razões pelas quais o DRS não liga o host:
n As regras de VM / VM DRS ou de VM / Host DRS impedem que a máquina virtual seja movida
para esse host.
n As máquinas virtuais são fixadas em seus hosts atuais, portanto, o DRS não pode mover
essas máquinas virtuais para hosts no modo de espera para balancear a carga.
n O DRS ou o DPM está no modo manual e as recomendações não foram aplicadas.
n Nenhuma máquina virtual em hosts altamente usados é movida para esse host.
n O DPM está desativado no host devido a uma configuração do usuário ou a um host que
anteriormente falhou ao sair da espera.
Solução
Resolva esse problema que impede que o DRS ligue o host.
A carga total do cluster é baixa

A carga total do cluster é baixa.
Problema
Quando a carga total do cluster é baixa, o DRS não desliga o host.
Causa
A seguir estão possíveis razões pelas quais o DRS não desliga o host:
n O Gerenciamento de Energia Distribuída (DPM) detectou melhores candidatos para desligar.
n vSphere HA precisa de capacidade extra para failover.
n A carga não é baixa o suficiente para acionar o host para desligar.
n O DPM projeta que a carga aumentará.
n O DPM não está habilitado para o host.
n O limite do DPM está definido como muito alto.

n Embora o DPM esteja habilitado para o host, nenhum mecanismo de inicialização adequado
está presente para o host.
n O DRS não pode evacuar o host.
n O limite de migração do DRS está na configuração mais alta e só executa movimentos

obrigatórios.
Solução
Resolva o problema que está impedindo que o DRS desligue o host.
O DRS não evacua um host solicitado para entrar no modo de

manutenção ou de espera
O DRS não evacua um host solicitado para entrar no modo de manutenção ou no modo de
espera.
Problema
Quando você tenta colocar um host no modo de manutenção ou de espera, o DRS não evacua o
host conforme o esperado.
Causa
vSphere HA está habilitado e a evacuação deste host pode violar a capacidade de failover de
HA.
Solução
Não há solução. Se apropriado, desative vSphere HA antes de tentar colocar o host no modo de
manutenção ou no modo de espera.
O DRS não move nenhuma máquina virtual para um host

O DRS não move nenhuma máquina virtual para um host.
Problema
O DRS não recomenda a migração da máquina virtual para um host que foi adicionado a um
cluster habilitado para DRS.
Causa
Depois que um host é adicionado a um cluster habilitado para DRS, as máquinas virtuais
implantadas no host se tornam parte do cluster. O DRS pode recomendar a migração de algumas
máquinas virtuais para este host recém-adicionado ao cluster. Se isso não ocorrer, pode haver
problemas com o vMotion, a compatibilidade do host ou as regras de afinidade. Os seguintes
motivos são possíveis:
n O vMotion não está configurado ou ativado neste host.
n As máquinas virtuais em outros hosts não são compatíveis com este host.

n O host não tem recursos suficientes para nenhuma máquina virtual.
n Mover qualquer máquina virtual para este host violaria uma regra de DRS de VM / VM ou uma
regra de DRS de VM / host.
n Este host está reservado para capacidade de failover de HA.
n Um dispositivo é montado na máquina virtual.
n O limite do vMotion é muito alto.
n O DRS está desativado para as máquinas virtuais, portanto, a máquina virtual não pode ser
movida para o host de destino.
Solução
Resolva o problema que impede o DRS de mover máquinas virtuais para um host.
O DRS não move nenhuma máquina virtual de um host

O DRS não move nenhuma máquina virtual de um host.
Problema
As máquinas virtuais não são movidas deste host.
Causa
Isso pode ser devido a problemas com o vMotion, DRS ou compatibilidade de host. Estes são os
possíveis motivos:
n O vMotion não está configurado ou ativado neste host.
n O DRS está desativado para as máquinas virtuais neste host.
n As máquinas virtuais neste host não são compatíveis com nenhum outro host.
n Nenhum outro host tem recursos suficientes para nenhuma máquina virtual neste host.
n Mover qualquer máquina virtual deste host violaria uma regra de DRS de VM / VM ou uma
regra de DRS de VM / Host.
n O DRS está desativado para uma ou mais máquinas virtuais no host.
n Um dispositivo é montado na máquina virtual.
Solução
Resolva os problemas que estão impedindo que o DRS mova as máquinas virtuais do host.
Problemas da máquina virtual

Problemas da máquina virtual podem fazer com que o DRS não funcione conforme o esperado.

Recursos insuficientes de CPU ou memória

A máquina virtual não recebe recursos de CPU ou memória suficientes.
Problema
Em alguns casos, a demanda da máquina virtual é maior do que o direito a recursos. Quando isso
ocorre, a máquina virtual não recebe recursos suficientes de CPU ou memória.
Causa
As seções a seguir descrevem os fatores que influenciam o direito a uma máquina virtual.
O cluster é amarelo ou vermelho
Se o cluster for amarelo ou vermelho, a capacidade será insuficiente para atender às reservas
de recursos configuradas para todas as máquinas virtuais e pools de recursos no cluster. A
máquina virtual específica pode ser aquela que não está recebendo sua reserva. Verifique o
status do cluster (vermelho ou amarelo) e resolva a situação.
O limite de recursos é muito restritivo
A máquina virtual, seu pool de recursos pai ou seus ancestrais do pool de recursos podem
ter um limite de recursos configurado muito restritivo. Verifique se a demanda é igual ou
superior a quaisquer limites configurados.
O cluster está sobrecarregado
O cluster no qual a máquina virtual está em execução pode ter recursos insuficientes. Além
disso, o valor de compartilhamento da máquina virtual é tal que outras máquinas virtuais
recebem proporcionalmente mais recursos. Para determinar que a demanda é maior que a
capacidade, verifique as estatísticas do cluster.
O host está sobrecarregado
Para determinar se os recursos do host estão com excesso de inscrições, verifique as

estatísticas do host. Se eles estiverem com excesso de inscrições, considere por que o DRS
não está movendo nenhuma das máquinas virtuais em execução no host para outros hosts.
Essa condição pode existir pelos seguintes motivos:
n As regras de DRS de VM / VM e as regras de DRS de VM / Host exigem o mapeamento

atual de máquina virtual para host. Se tais regras estiverem configuradas no cluster,
considere desativar um ou mais deles. Em seguida, execute o DRS e verifique se a
situação está corrigida.
n O DRS não pode mover esta máquina virtual ou o suficiente das outras máquinas virtuais
para outros hosts para liberar capacidade. O DRS não moverá uma máquina virtual por
nenhum dos seguintes motivos:
n O DRS está desativado para a máquina virtual.
n Um dispositivo host é montado na máquina virtual.

n Qualquer uma das reservas de recursos é tão grande que a máquina virtual não pode
ser executada em nenhum outro host no cluster.
n A máquina virtual não é compatível com nenhum outro host no cluster.
Verifique se alguma dessas condições existe para a máquina virtual. Se não existir
nenhuma, as condições poderão existir para outras máquinas virtuais no cluster. Se esse
for o caso, o DRS não poderá balancear o cluster para atender à demanda da máquina
virtual.
n Diminua a configuração de limite de migração do DRS e verifique se a situação foi

resolvida.
n Aumente a reserva da máquina virtual.
Solução
Resolva o problema que está fazendo com que a máquina virtual não receba recursos suficientes
de CPU ou memória.
Regra de VM / DRS de VM ou regra de DRS de VM / host violada

As regras de DRS especificam em qual host uma máquina virtual deve ou não deve residir ou
quais máquinas virtuais devem ou não estar no mesmo host.
Problema
Uma regra de DRS de VM / VM ou uma regra de DRS de VM / host é violada.
Causa
As regras de VM / VM DRS especificam que as máquinas virtuais selecionadas devem ser

colocadas no mesmo host (afinidade) ou que as máquinas virtuais devem ser colocadas em hosts
diferentes (antiafinidade). As regras de VM / Host DRS especificam que as máquinas virtuais
selecionadas devem ser colocadas em hosts especificados (afinidade) ou que as máquinas
virtuais selecionadas não devem ser colocadas em hosts especificados (antiafinidade).
Quando uma regra de DRS de VM / VM ou uma regra de DRS de VM / host é violada, pode
ser porque o DRS não pode mover algumas ou todas as máquinas virtuais na regra. A reserva
da máquina virtual ou de outras máquinas virtuais na regra de afinidade, ou em seus pools de
recursos principais, pode impedir que o DRS localize todas as máquinas virtuais no mesmo host.
Solução
n Verifique o painel de falhas do DRS quanto a falhas associadas a regras de afinidade.
n Calcule a soma das reservas de todas as máquinas virtuais na regra de afinidade. Se esse
valor for maior que a capacidade disponível em qualquer host, a regra não poderá ser
satisfeita.

n Calcule a soma das reservas de seus pools de recursos principais. Se esse valor for maior que
a capacidade disponível de qualquer host, a regra não poderá ser satisfeita se os recursos
forem obtidos de um único host.
Falha na operação ao ligar a máquina virtual

É exibida uma mensagem de erro informando que a máquina virtual falha ao ligar.
Problema
A máquina virtual falha ao ligar.
Causa
A máquina virtual pode falhar ao ligar devido a recursos insuficientes ou porque não há hosts
compatíveis para a máquina virtual.
Solução
Se o cluster não tiver recursos suficientes para ligar uma única máquina virtual ou qualquer
uma das máquinas virtuais em uma tentativa de inicialização de grupo, verifique os recursos
necessários pela máquina virtual em relação aos disponíveis no cluster ou no pool de recursos
pai. Se necessário, reduza as reservas da máquina virtual a ser ligada, reduza as reservas de suas
máquinas virtuais irmãos ou aumente os recursos disponíveis no cluster ou no pool de recursos
pai.
O DRS não move a máquina virtual

O DRS não move a máquina virtual quando ela é ligada inicialmente, apesar dos recursos
insuficientes no host.
Problema
Quando você liga uma máquina virtual, o DRS não a migra conforme o esperado quando não há
recursos suficientes no host onde a máquina virtual está registrada.
Causa
A seguir estão as possíveis razões pelas quais o DRS não move a máquina virtual.
n O DRS está desativado na máquina virtual.
n A máquina virtual tem um dispositivo montado.
n A máquina virtual não é compatível com nenhum outro host.
n Nenhum outro host tem um número suficiente de CPUs físicas ou capacidade para cada CPU
para a máquina virtual.
n Nenhum outro host tem recursos de CPU ou memória suficientes para satisfazer as reservas
e a memória necessária desta máquina virtual.
n Mover a máquina virtual violará uma regra de afinidade ou antiafinidade.

n O nível de automação do DRS da máquina virtual é manual e o usuário não aprova a

recomendação de migração.
n O DRS não moverá máquinas virtuais habilitadas para tolerância a falhas.
Solução
Resolva o problema que impede o DRS de mover a máquina virtual.

Vsphere Esxi Vcenter Server 703 Resource Management Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Vsphere Esxi Vcenter Server 703 Resource Management Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Gerenciamento de

Este documento foi traduzido automaticamente do inglês. Se você observar

VMware, Inc. VMware Brasil

VMware, Inc. Traduzido automaticamente 2

Sobre o vSphere Resource Management 10

1 Introdução ao gerenciamento de recursos 11

2 Definindo as configurações de alocação de recursos 14

3 Noções básicas de virtualização de CPU 20

4 Administrando recursos de CPU 23

VMware, Inc. Traduzido automaticamente 3

5 Conceitos básicos de virtualização de memória 32

6 Administrando recursos de memória 38

8 Configurando gráficos virtuais 62

VMware, Inc. Traduzido automaticamente 4

Adicionar uma vGPU do NVIDIA GRID a uma máquina virtual 63

9 Gerenciando recursos de E / S do armazenamento 65

10 Gerenciando pools de recursos 74

11 Criando um cluster DRS 84

VMware, Inc. Traduzido automaticamente 5

Requisitos de cluster do DRS 97

12 Funcionalidade do modo de manutenção do DRS com licença empresarial ROBO

13 Usando clusters do DRS para gerenciar recursos 111

VMware, Inc. Traduzido automaticamente 6

Criar um grupo de DRS de host 129

14 Criando um cluster de repositório de dados 135

15 Usando clusters de datastore para gerenciar recursos de armazenamento 143

16 Usando sistemas NUMA com o ESXi 154

VMware, Inc. Traduzido automaticamente 7

Controles virtuais do NUMA 160

17 Atributos avançados 165

18 Definições de falha 174

19 Informações de solução de problemas do DRS 178

VMware, Inc. Traduzido automaticamente 8

O cluster é amarelo 179

VMware, Inc. Traduzido automaticamente 9

O Gerenciamento de Recursos do vSphere descreve o gerenciamento de recursos para os

Esta documentação se concentra nos tópicos a seguir.

n Conceitos de alocação e gerenciamento de recursos

n Atributos da máquina virtual e controle de admissão

n Pools de recursos e como gerenciá-los

n Clusters de armazenamento de dados, DRS de armazenamento, Storage I/O Control e como

n Opções avançadas de gerenciamento de recursos

VMware, Inc. Traduzido automaticamente 10

As configurações de alocação de recursos para uma máquina virtual (compartilhamentos,

Gerenciamento de recursos é a alocação de recursos dos provedores de recursos para os

A necessidade de gerenciamento de recursos surge do comprometimento excessivo dos

Observação Neste capítulo, "Memória" refere-se à RAM física.

Este capítulo inclui os seguintes tópicos:

n Objetivos do gerenciamento de recursos

Observação O ESXi gerencia a largura de banda da rede e os recursos de disco em uma

VMware, Inc. Traduzido automaticamente 11

Um cluster de repositório de dados é um grupo de repositórios de dados. Como os clusters do

n Limites de recursos definidos pelo usuário.

n Total de recursos disponíveis para o host ESXi (ou o cluster).

n Sobrecarga necessária para gerenciar a virtualização.

VMware, Inc. Traduzido automaticamente 12

Objetivos do gerenciamento de recursos

Além de resolver o comprometimento excessivo de recursos, o gerenciamento de recursos pode

n Isolamento do desempenho: evite que as máquinas virtuais monopolizem recursos e

n Uso eficiente: Explore recursos subcomprometidos e supercommit com degradação normal.

n Administração fácil: controle a importância relativa das máquinas virtuais, forneça o

VMware, Inc. Traduzido automaticamente 13

Use as configurações de alocação de recursos (compartilhamentos, reserva e limite) para

n Reserve os recursos físicos do host ou cluster.