Se você gerencia os hosts ESXi em seu ambiente com linhas de base ou com imagens, pode configurar o comportamento de vSphere Lifecycle Manager durante a remediação.

As configurações de remediação do vSphere Lifecycle Manager para hosts e clusters que usam linhas de base são diferentes das configurações de remediação para hosts e clusters que você gerencia com uma única imagem vSphere Lifecycle Manager. Por exemplo, permitir a instalação de software em hosts inicializados por PXE e a remoção de dispositivos de mídia antes do modo de manutenção são configurações que você pode definir apenas para hosts e clusters que usam linhas de base. As configurações de migração da máquina virtual, as configurações do modo de manutenção e Quick Boot são exemplos de configurações de remediação que você pode definir para hosts e clusters que usam linhas de base ou imagens.

Você poderá modificar as configurações padrão do vSphere Lifecycle Manager somente se tiver os privilégios apropriados. A permissão deve ser atribuída à instância vCenter Server em que vSphere Lifecycle Manager é executado. Para obter mais informações sobre como gerenciar usuários, grupos, funções e permissões, consulte a documentação vSphere Segurança. Para obter uma lista dos privilégios vSphere Lifecycle Manager e suas descrições, consulte Privilégios necessários para usar vSphere Lifecycle Manager e vSphere Configuration Profiles.

Se o seu sistema vCenter Server estiver conectado a outros sistemas vCenter Server por um domínio vCenter Single Sign-On comum, você poderá definir as configurações de remediação para cada instância vSphere Lifecycle Manager. As propriedades de configuração que você modifica são aplicadas somente à instância vSphere Lifecycle Manager que você especifica e não são propagadas para as outras instâncias no domínio.

Como as configurações de cluster afetam a correção?

Quando você remediar hosts ESXi que estão em um cluster, determinadas configurações de cluster podem causar falha de remediação. Você deve definir as configurações do cluster de forma a garantir uma correção bem-sucedida.
Agendador de Recursos Distribuídos (DRS)
As atualizações podem exigir que um host entre no modo de manutenção durante a correção. As máquinas virtuais não podem ser executadas quando um host está no modo de manutenção. Para garantir a disponibilidade, você pode ativar DRS para o cluster e configurá-lo para vSphere vMotion. Nesse caso, antes que o host seja colocado no modo de manutenção, o vCenter Server migra as máquinas virtuais para outro host ESXi dentro do cluster.

Para ajudar a garantir a compatibilidade vSphere vMotion entre os hosts no cluster, você pode habilitar a Compatibilidade aprimorada do vMotion (EVC). O EVC garante que todos os hosts no cluster apresentem o mesmo conjunto de recursos de CPU para máquinas virtuais, mesmo que as CPUs reais nos hosts sejam diferentes. O EVC evita falhas de migração devido a CPUs incompatíveis. Você pode habilitar o EVC somente em um cluster em que as CPUs do host atendam aos requisitos de compatibilidade. Para obter mais informações sobre o EVC e os requisitos que os hosts em um cluster do EVC devem atender, consulte a documentação vCenter Server e gerenciamento de host.

Gerenciamento de energia distribuída (DPM)
Se um host não tiver máquinas virtuais em execução, DPM poderá colocar o host no modo de espera, o que poderá interromper uma operação vSphere Lifecycle Manager. Portanto, para garantir que todas as operações vSphere Lifecycle Manager sejam concluídas com êxito, você deve desativar DPM durante essas operações.

Para uma correção bem-sucedida, você deve configurar vSphere Lifecycle Manager para desativar DPM. Após a conclusão da tarefa de correção, vSphere Lifecycle Manager restaura DPM. Se DPM já tiver colocado um host no modo de espera, vSphere Lifecycle Manager ligará o host antes das verificações de conformidade, remediação e preparação. Depois que a respectiva tarefa for concluída, vSphere Lifecycle Manager ativará DPM e permitirá que DPM coloque o host no modo de espera, se necessário. vSphere Lifecycle Manager não corrige hosts desligados.

Se um host for colocado no modo de espera e DPM for desativado manualmente por um motivo, vSphere Lifecycle Manager não remediará nem ligará o host.

Controle de admissão de alta disponibilidade
Em um cluster, você deve desativar o controle de admissão de alta disponibilidade temporariamente para permitir que vSphere vMotion prossiga. Essa ação evita o tempo de inatividade das máquinas nos hosts que você corrige. Você pode configurar o vSphere Lifecycle Manager para desativar o controle de admissão de alta disponibilidade durante a correção. Após a conclusão da correção de todo o cluster, vSphere Lifecycle Manager restaura as configurações de controle de admissão de alta disponibilidade. vSphere Lifecycle Manager desativa o controle de admissão de alta disponibilidade antes da correção, mas não antes das verificações de conformidade. Além disso, para clusters que você gerencia com linhas de base, o vSphere Lifecycle Manager desativa o controle de admissão de alta disponibilidade antes da preparação.
Observação:
A desativação do controle de admissão de alta disponibilidade antes de remediar um cluster de dois nós que usa uma única imagem vSphere Lifecycle Manager faz com que o cluster perca praticamente todas as suas garantias de alta disponibilidade. O motivo é que, quando um dos dois hosts entra no modo de manutenção, vCenter Server não pode fazer failover de máquinas virtuais para esse host e os failovers de alta disponibilidade nunca são bem-sucedidos. Para obter mais informações sobre o controle de admissão de alta disponibilidade, consulte a documentação vSphere Disponibilidade.
Tolerância a Falhas (FT)
Se o FT estiver ativado para qualquer uma das máquinas virtuais em um host em um cluster, você deverá desativar temporariamente o FT antes de executar qualquer operação vSphere Lifecycle Manager no cluster. Se o FT estiver ativado para qualquer uma das máquinas virtuais em um host, vSphere Lifecycle Manager não remediará esse host. Você deve remediar todos os hosts em um cluster com as mesmas atualizações, para que o FT possa ser reativado após a remediação. Uma máquina virtual primária e uma máquina virtual secundária não podem residir em hosts de diferentes versões ESXi e níveis de patch.