Dê a sua opinião sobre a experiência de download do PDF.

Documentação sobre virtualização

A virtualização no Windows Server é uma das tecnologias fundamentais necessárias
para criar sua infraestrutura definida por software. Juntamente com as funcionalidades
de rede e armazenamento, os recursos de virtualização oferecem a flexibilidade de que
você precisa para potencializar cargas de trabalho para seus clientes.

Contêineres do Windows

ｅ VISÃO GERAL

Contêineres do Windows

Sobre os contêineres no Windows

Contêineres vs. máquinas virtuais

Hyper-V no Windows 10

ｅ VISÃO GERAL

Visão geral do Hyper-V no Windows 10

Sobre o Hyper-V no Windows 10

ｂ COMEÇAR AGORA

Instalar o Hyper-V

Criar uma Máquina Virtual

Hyper-V no Windows Server

ｅ VISÃO GERAL

Hyper-V no Windows Server

Visão geral da tecnologia Hyper-V

ｉ REFERÊNCIA
Microsoft Hyper-V Server 2016

Requisitos do sistema para o Hyper-V no Windows Server

Comutador Virtual Hyper-V

ｅ VISÃO GERAL

Comutador Virtual Hyper-V

ｃ GUIA DE INSTRUÇÕES

Gerenciar o Comutador Virtual do Hyper-V

Usar uma Malha Protegida para fornecer um ambiente seguro para as

VMs

ｅ VISÃO GERAL

Malha protegida e VMs blindadas

Malha protegida e VMs blindadas
Artigo • 10/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Uma das metas mais importantes de fornecer um ambiente hospedado é garantir a

segurança das máquinas virtuais em execução no ambiente. Como um provedor de
serviços de nuvem ou um administrador de nuvem privada corporativa, você pode usar
uma malha protegida para fornecer um ambiente mais seguro para as VMs. Uma malha
protegida consiste em um HGS (Serviço de Guardião de Host), em geral, um cluster de
três nós, além de um ou mais hosts protegidos e um conjunto de VMs (máquinas
virtuais) protegidas.

） Importante

Verifique se você instalou todas a atualização cumulativa mais recente antes de

implantar as máquinas virtuais blindadas em produção.

Vídeos, blog e tópico de visão geral sobre

malhas protegidas e VMs blindadas
Vídeo: Como proteger sua malha de virtualização contra ameaças internas com o
Windows Server 2019
Vídeo: Introdução a máquinas virtuais blindadas no Windows Server 2016
Vídeo: Estudar as VMs blindadas com o Hyper-V do Windows Server 2016
Vídeo: Implantando VMs blindadas e uma Malha Protegida com o Windows Server
2016
Blog: Blog de segurança de nuvem privada e datacenter
Visão geral: Visão geral sobre malha protegida e VMs blindadas

Tópicos de planejamento
Guia de planejamento para hosts
Guia de planejamento para locatários

Tópicos de implantação
 Guia de Implantação
Início rápido
Implantar o HGS
Implantar hosts protegidos
Configurando a malha DNS para hosts que se tornarão hosts protegidos
Implantar um host protegido usando o modo AD
Implantar um host protegido usando o modo TPM
Confirmar se os hosts protegidos podem atestar
VMs blindadas – provedor de serviços de hospedagem implanta hosts
protegidos no VMM
Implantar VMs blindadas
Criar um modelo de VM blindado
Preparar um VHD auxiliar de blindagem de VM
Instalar o Microsoft Azure Pack
Criar um arquivo de dados de blindagem
Implantar uma VM blindada usando o Pacote do Microsoft Azure
Implantar uma VM blindada usando o Virtual Machine Manager

Tópico de operações e gerenciamento

Gerenciando o Serviço Guardião de Host
Visão geral da tecnologia Hyper-V
Artigo • 16/08/2024

Aplica-se a: Windows Server 2025 (visualização), Windows Server 2022, Windows

Server 2016, Microsoft Hyper-V Server 2016, Windows Server 2019, Microsoft
Hyper-V Server 2019

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

O Hyper-V é o produto de virtualização de hardware da Microsoft. Ele permite que você

crie e execute uma versão de software de um computador, chamada de máquina virtual.
Cada máquina virtual atua como um computador completo, que executa um sistema
operacional e programas. Quando você precisa de recursos de computação, as
máquinas virtuais oferecem mais flexibilidade, ajudam a economizar tempo e dinheiro e
são uma maneira mais eficiente de usar hardware do que apenas a execução de um
sistema operacional em hardware físico.

O Hyper-V executa cada máquina virtual em seu próprio espaço isolado, o que significa
que você pode executar mais de uma máquina virtual no mesmo hardware ao mesmo
tempo. Talvez você queira fazer isso para evitar problemas como uma falha que afete as
outras cargas de trabalho ou para dar a diferentes pessoas, grupos ou serviços acesso a
sistemas diferentes.

Algumas maneiras de o Hyper-V ajudar você

O Hyper-V pode ajudá-lo a:

Estabelecer ou expandir um ambiente de nuvem privada. Prestar serviços de TI

mais flexíveis sob demanda movendo ou expandindo o uso de recursos
compartilhados e ajustando a utilização à medida que a demanda muda.

Usar seu hardware com mais eficiência. Consolidar servidores e cargas de

trabalho em computadores físicos menos avançados para usar menos energia e
espaço físico.
 Melhorar a continuidade dos negócios. Minimizar o impacto do tempo de
inatividade programado e não programado de suas cargas de trabalho.

Estabelecer ou expandir uma infraestrutura de área de trabalho virtual (VDI).

Usar uma estratégia de área de trabalho centralizada com VDI ajuda a aumentar a
agilidade dos negócios e a segurança dos dados, bem como simplificar a
conformidade com as normas e gerenciar o sistema operacional e os aplicativos da
área de trabalho. Implantar o Hyper-V e o Host de Virtualização de Área de
Trabalho Remota no mesmo servidor para tornar áreas de trabalho virtuais
pessoais ou pools de área de trabalho virtual disponíveis para seus usuários.

Tornar o desenvolvimento e o teste mais eficientes. Reproduzir diferentes

ambientes de computação sem precisar comprar ou manter todos os hardwares
que seriam necessários se você usasse apenas sistemas físicos.

Hyper-V e outros produtos de virtualização

O Hyper-V no Windows e no Windows Server substitui produtos de virtualização de
hardware mais antigos, como o Microsoft Virtual PC, o Servidor Virtual da Microsoft e o
Windows Virtual PC. O Hyper-V oferece recursos de rede, desempenho, armazenamento
e segurança não disponíveis nesses produtos mais antigos.

O Hyper-V e a maioria dos aplicativos de virtualização de terceiros que exigem os

mesmos recursos de processador não são compatíveis. Isso ocorre porque os recursos
do processador, conhecidos como extensões de virtualização de hardware, foram
projetados para não serem compartilhados. Para obter detalhes, consulte Aplicativos de
virtualização não funcionam em conjunto com Hyper-V, Device Guard e Credential
Guard .

Quais recursos o Hyper-V tem?

O Hyper-V oferece muitos recursos. Esta é uma visão geral, agrupada pelo que os
recursos fornecem ou ajudam você a fazer.

Ambiente de computação – uma máquina virtual Hyper-V inclui as mesmas partes

básicas de um computador físico, como memória, processador, armazenamento e rede.
Todas essas partes têm recursos e opções que você pode configurar de diferentes
maneiras de atender a diferentes necessidades. O armazenamento e a rede podem ser
considerados categorias próprias, devido às várias maneiras de configurá-los.

Recuperação de desastre e backup – para recuperação de desastre, a Réplica do Hyper-

V cria cópias de máquinas virtuais, destinadas a serem armazenadas em outro local
físico, para que você possa restaurar a máquina virtual da cópia. Em relação ao backup,
o Hyper-V oferece dois tipos. Um usa estados salvos e o outro usa VSS (Serviço de
Cópias de Sombra de Volume) para que você possa fazer backups consistentes com o
aplicativo de programas que dão suporte ao VSS.

Otimização – cada sistema operacional convidado compatível tem um conjunto

personalizado de serviços e drivers, chamados de serviços de integração, que facilitam o
uso do sistema operacional em uma máquina virtual Hyper-V.

Portabilidade – recursos como migração dinâmica, migração de armazenamento e

importação/exportação facilitam a movimentação ou distribuição de uma máquina
virtual.

Conectividade remota – o Hyper-V inclui a Conexão de Máquina Virtual, uma

ferramenta de conexão remota para uso com o Windows e o Linux. Ao contrário da Área
de Trabalho Remota, essa ferramenta fornece acesso ao console, para que você possa
ver o que está acontecendo no convidado mesmo quando o sistema operacional ainda
não foi inicializado.

Segurança – a inicialização segura e as máquinas virtuais blindadas ajudam a proteger

contra malware e outros acessos não autorizados a uma máquina virtual e a seus dados.

Para obter um resumo dos recursos apresentados nessa versão, consulte Novidades no
Hyper-V no Windows Server. Alguns recursos ou partes têm um limite de quantos
podem ser configurados. Para obter detalhes, consulte Planejar a escalabilidade do
Hyper-V no Windows Server 2016.

Como obter o Hyper-V

O Hyper-V está disponível no Windows Server e no Windows como uma função de
servidor disponível para versões x64 do Windows Server. Para obter instruções de
servidor, consulte Instalar a função Hyper-V no Windows Server. No Windows, ele está
disponível como recurso em algumas versões de 64 bits do Windows. Ele também está
disponível como um produto de servidor autônomo para download , o Microsoft Hyper-
V Server .

Sistemas operacionais compatíveis

Muitos sistemas operacionais são executados em máquinas virtuais. Em geral, um
sistema operacional que usa uma arquitetura x86 será executado em uma máquina
virtual Hyper-V. No entanto, nem todos os sistemas operacionais que podem ser
executados são testados e compatíveis com a Microsoft. Para obter listas dos que têm
suporte, consulte:

Máquinas virtuais compatíveis do Linux e do FreeBSD para o Hyper-V no Windows

Sistemas operacionais convidados do Windows compatíveis com o Hyper-V no

Windows Server

Como o Hyper-V funciona

O Hyper-V é uma tecnologia de virtualização com base em hipervisor. O Hyper-V usa o
hipervisor do Windows, que requer um processador físico com recursos específicos. Para
obter detalhes de hardware, consulte Requisitos do sistema para o Hyper-V no Windows
Server.

Na maioria dos casos, o hipervisor gerencia as interações entre o hardware e as

máquinas virtuais. Esse acesso ao hardware controlado por hipervisor fornece às
máquinas virtuais o ambiente isolado no qual elas são executadas. Em algumas
configurações, uma máquina virtual ou o sistema operacional em execução na máquina
virtual tem acesso direto a elementos gráficos, rede ou hardware de armazenamento.

Do que consiste o Hyper-V?

O Hyper-V tem partes obrigatórias que funcionam juntas para que você possa criar e
executar máquinas virtuais. Juntas, essas partes são chamadas de plataforma de
virtualização. Elas são instaladas como um conjunto quando você instala a função
Hyper-V. As partes necessárias incluem hipervisor do Windows, o Serviço
Gerenciamento de Máquinas Virtuais do Hyper-V, o provedor WMI de virtualização, o
barramento VMbus, VSP (provedor de serviço de virtualização) e VID (unidade de
infraestrutura virtual).

O Hyper-V também tem ferramentas para gerenciamento e conectividade. Você pode

instalá-las no mesmo computador no qual a função Hyper-V está instalada e em
computadores sem a função Hyper-V instalada. Essas ferramentas são:

Gerenciador do Hyper-V
Módulo Hyper-V para o Windows PowerShell
Conexão de Máquina Virtual (às vezes chamada de VMConnect)
Windows PowerShell Direct

Tecnologias relacionadas
Estas são algumas tecnologias da Microsoft que geralmente são usadas com o Hyper-V:

Clustering de failover
Serviços de área de trabalho remota
System Center Virtual Machine Manager
Hyper-V Cliente

Várias tecnologias de armazenamento: volumes compartilhados de cluster, SMB 3.0,

espaços de armazenamento diretos

Os contêineres do Windows oferecem outra abordagem para virtualização. Consulte a

biblioteca Contêineres do Windows no MSDN.

Comentários
Esta página foi útil?  Yes  No
Visão geral da tecnologia Hyper-V
Artigo • 16/08/2024

Aplica-se a: Windows Server 2025 (visualização), Windows Server 2022, Windows

Server 2016, Microsoft Hyper-V Server 2016, Windows Server 2019, Microsoft
Hyper-V Server 2019

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

O Hyper-V é o produto de virtualização de hardware da Microsoft. Ele permite que você

crie e execute uma versão de software de um computador, chamada de máquina virtual.
Cada máquina virtual atua como um computador completo, que executa um sistema
operacional e programas. Quando você precisa de recursos de computação, as
máquinas virtuais oferecem mais flexibilidade, ajudam a economizar tempo e dinheiro e
são uma maneira mais eficiente de usar hardware do que apenas a execução de um
sistema operacional em hardware físico.

O Hyper-V executa cada máquina virtual em seu próprio espaço isolado, o que significa
que você pode executar mais de uma máquina virtual no mesmo hardware ao mesmo
tempo. Talvez você queira fazer isso para evitar problemas como uma falha que afete as
outras cargas de trabalho ou para dar a diferentes pessoas, grupos ou serviços acesso a
sistemas diferentes.

Algumas maneiras de o Hyper-V ajudar você

O Hyper-V pode ajudá-lo a:

Estabelecer ou expandir um ambiente de nuvem privada. Prestar serviços de TI

mais flexíveis sob demanda movendo ou expandindo o uso de recursos
compartilhados e ajustando a utilização à medida que a demanda muda.

Usar seu hardware com mais eficiência. Consolidar servidores e cargas de

trabalho em computadores físicos menos avançados para usar menos energia e
espaço físico.
 Melhorar a continuidade dos negócios. Minimizar o impacto do tempo de
inatividade programado e não programado de suas cargas de trabalho.

Estabelecer ou expandir uma infraestrutura de área de trabalho virtual (VDI).

Usar uma estratégia de área de trabalho centralizada com VDI ajuda a aumentar a
agilidade dos negócios e a segurança dos dados, bem como simplificar a
conformidade com as normas e gerenciar o sistema operacional e os aplicativos da
área de trabalho. Implantar o Hyper-V e o Host de Virtualização de Área de
Trabalho Remota no mesmo servidor para tornar áreas de trabalho virtuais
pessoais ou pools de área de trabalho virtual disponíveis para seus usuários.

Tornar o desenvolvimento e o teste mais eficientes. Reproduzir diferentes

ambientes de computação sem precisar comprar ou manter todos os hardwares
que seriam necessários se você usasse apenas sistemas físicos.

Hyper-V e outros produtos de virtualização

O Hyper-V no Windows e no Windows Server substitui produtos de virtualização de
hardware mais antigos, como o Microsoft Virtual PC, o Servidor Virtual da Microsoft e o
Windows Virtual PC. O Hyper-V oferece recursos de rede, desempenho, armazenamento
e segurança não disponíveis nesses produtos mais antigos.

O Hyper-V e a maioria dos aplicativos de virtualização de terceiros que exigem os

mesmos recursos de processador não são compatíveis. Isso ocorre porque os recursos
do processador, conhecidos como extensões de virtualização de hardware, foram
projetados para não serem compartilhados. Para obter detalhes, consulte Aplicativos de
virtualização não funcionam em conjunto com Hyper-V, Device Guard e Credential
Guard .

Quais recursos o Hyper-V tem?

O Hyper-V oferece muitos recursos. Esta é uma visão geral, agrupada pelo que os
recursos fornecem ou ajudam você a fazer.

Ambiente de computação – uma máquina virtual Hyper-V inclui as mesmas partes

básicas de um computador físico, como memória, processador, armazenamento e rede.
Todas essas partes têm recursos e opções que você pode configurar de diferentes
maneiras de atender a diferentes necessidades. O armazenamento e a rede podem ser
considerados categorias próprias, devido às várias maneiras de configurá-los.

Recuperação de desastre e backup – para recuperação de desastre, a Réplica do Hyper-

V cria cópias de máquinas virtuais, destinadas a serem armazenadas em outro local
físico, para que você possa restaurar a máquina virtual da cópia. Em relação ao backup,
o Hyper-V oferece dois tipos. Um usa estados salvos e o outro usa VSS (Serviço de
Cópias de Sombra de Volume) para que você possa fazer backups consistentes com o
aplicativo de programas que dão suporte ao VSS.

Otimização – cada sistema operacional convidado compatível tem um conjunto

personalizado de serviços e drivers, chamados de serviços de integração, que facilitam o
uso do sistema operacional em uma máquina virtual Hyper-V.

Portabilidade – recursos como migração dinâmica, migração de armazenamento e

importação/exportação facilitam a movimentação ou distribuição de uma máquina
virtual.

Conectividade remota – o Hyper-V inclui a Conexão de Máquina Virtual, uma

ferramenta de conexão remota para uso com o Windows e o Linux. Ao contrário da Área
de Trabalho Remota, essa ferramenta fornece acesso ao console, para que você possa
ver o que está acontecendo no convidado mesmo quando o sistema operacional ainda
não foi inicializado.

Segurança – a inicialização segura e as máquinas virtuais blindadas ajudam a proteger

contra malware e outros acessos não autorizados a uma máquina virtual e a seus dados.

Para obter um resumo dos recursos apresentados nessa versão, consulte Novidades no
Hyper-V no Windows Server. Alguns recursos ou partes têm um limite de quantos
podem ser configurados. Para obter detalhes, consulte Planejar a escalabilidade do
Hyper-V no Windows Server 2016.

Como obter o Hyper-V

O Hyper-V está disponível no Windows Server e no Windows como uma função de
servidor disponível para versões x64 do Windows Server. Para obter instruções de
servidor, consulte Instalar a função Hyper-V no Windows Server. No Windows, ele está
disponível como recurso em algumas versões de 64 bits do Windows. Ele também está
disponível como um produto de servidor autônomo para download , o Microsoft Hyper-
V Server .

Sistemas operacionais compatíveis

Muitos sistemas operacionais são executados em máquinas virtuais. Em geral, um
sistema operacional que usa uma arquitetura x86 será executado em uma máquina
virtual Hyper-V. No entanto, nem todos os sistemas operacionais que podem ser
executados são testados e compatíveis com a Microsoft. Para obter listas dos que têm
suporte, consulte:

Máquinas virtuais compatíveis do Linux e do FreeBSD para o Hyper-V no Windows

Sistemas operacionais convidados do Windows compatíveis com o Hyper-V no

Windows Server

Como o Hyper-V funciona

O Hyper-V é uma tecnologia de virtualização com base em hipervisor. O Hyper-V usa o
hipervisor do Windows, que requer um processador físico com recursos específicos. Para
obter detalhes de hardware, consulte Requisitos do sistema para o Hyper-V no Windows
Server.

Na maioria dos casos, o hipervisor gerencia as interações entre o hardware e as

máquinas virtuais. Esse acesso ao hardware controlado por hipervisor fornece às
máquinas virtuais o ambiente isolado no qual elas são executadas. Em algumas
configurações, uma máquina virtual ou o sistema operacional em execução na máquina
virtual tem acesso direto a elementos gráficos, rede ou hardware de armazenamento.

Do que consiste o Hyper-V?

O Hyper-V tem partes obrigatórias que funcionam juntas para que você possa criar e
executar máquinas virtuais. Juntas, essas partes são chamadas de plataforma de
virtualização. Elas são instaladas como um conjunto quando você instala a função
Hyper-V. As partes necessárias incluem hipervisor do Windows, o Serviço
Gerenciamento de Máquinas Virtuais do Hyper-V, o provedor WMI de virtualização, o
barramento VMbus, VSP (provedor de serviço de virtualização) e VID (unidade de
infraestrutura virtual).

O Hyper-V também tem ferramentas para gerenciamento e conectividade. Você pode

instalá-las no mesmo computador no qual a função Hyper-V está instalada e em
computadores sem a função Hyper-V instalada. Essas ferramentas são:

Gerenciador do Hyper-V
Módulo Hyper-V para o Windows PowerShell
Conexão de Máquina Virtual (às vezes chamada de VMConnect)
Windows PowerShell Direct

Tecnologias relacionadas
Estas são algumas tecnologias da Microsoft que geralmente são usadas com o Hyper-V:

Clustering de failover
Serviços de área de trabalho remota
System Center Virtual Machine Manager
Hyper-V Cliente

Várias tecnologias de armazenamento: volumes compartilhados de cluster, SMB 3.0,

espaços de armazenamento diretos

Os contêineres do Windows oferecem outra abordagem para virtualização. Consulte a

biblioteca Contêineres do Windows no MSDN.

Comentários
Esta página foi útil?  Yes  No
Novidades no Windows Server 2022
Artigo • 10/07/2024

Aplica-se a: Windows Server 2022

Este artigo descreve alguns dos novos recursos do Windows Server 2022. O Windows
Server 2022 é baseado nos sólidos alicerces do Windows Server 2019 e traz muitas
inovações sobre três temas principais: segurança, integração híbrida e gerenciamento
do Azure e plataforma de aplicativos.

Azure Edition
O Windows Server 2022 Datacenter: Azure Edition ajuda você a usar os benefícios da
nuvem para manter as VMs atualizadas, minimizando o tempo de inatividade. Essa
seção descreve alguns dos novos recursos no Windows Server 2022 Datacenter: Azure
Edition. Saiba como o Gerenciamento Automatizado do Azure para Windows Server
oferece essas novas funcionalidades ao Windows Server Azure Edition no artigo Serviços
do Gerenciamento Automatizado do Azure para Windows Server.

Windows Server 2022 Datacenter: o Azure Edition se baseia no Datacenter Edition para
fornecer um sistema operacional somente de VM que ajuda a usar os benefícios da
nuvem com recursos avançados, como SMB por QUIC, patch dinâmico e rede estendida
do Azure. Esta seção descreve alguns desses novos recursos.

Compare as diferenças nas edições no Windows Server 2022. Veja mais informações de
como o Gerenciamento Automatizado do Azure para Windows Server oferece essas
novas funcionalidades para o Windows Server Azure Edition no artigo Serviços do
Gerenciamento Automatizado do Azure para Windows Server.

Abril de 2022

Aplicação dinâmica de patch

Windows Server 2022 Datacenter: o Hotpatching do Azure Edition já em versão prévia
pública para a Experiência Desktop no Azure e como uma VM convidada com suporte
no Azure Stack HCI versão 22H2.

Setembro de 2022
Esta seção lista os recursos e os aprimoramentos que agora estão disponíveis no
Windows Server Datacenter: Azure Edition da atualização cumulativa de setembro de
2022 em diante para o sistema operacional do Microsoft Server versão 21H2 para
sistemas baseados em x64 (KB5017381 ). Após a instalação da atualização cumulativa,
o número de build do sistema operacional será 20348.1070 ou superior.

Compactação de réplica de armazenamento para transferência de

dados

Essa atualização inclui a compactação da réplica de armazenamento de dados

transferidos entre os servidores de origem e de destino. Essa nova funcionalidade
compacta os dados de replicação no sistema de origem, enviados pela rede e
descompactados e salvos no destino. A compactação resulta em menos pacotes de rede
para transferir a mesma quantidade de dados, aumentando a taxa de transferência e
reduzindo a utilização de rede. O aumento da taxa de transferência de dados também
deve resultar na redução do tempo de sincronização em momentos de maior
necessidade, por exemplo, em um cenário de recuperação de desastre.

Há novos parâmetros do PowerShell para réplica de armazenamento disponíveis para

comandos existentes. Examine a referência de réplica de armazenamento do Windows
PowerShell para saber mais. Para obter mais informações sobre a réplica de
armazenamento, confira a Visão geral da réplica de armazenamento.

Suporte para Azure Stack HCI

Com esta versão, você pode executar o Windows Server 2022 Datacenter: Azure Edition
como uma VM convidada com suporte no Azure Stack HCI versão 22H2. Com o Azure
Edition em execução no Azure Stack HCI, você poderá usar todos os recursos existentes,
incluindo o patch dinâmico para o Server Core e o SMB por QUIC em locais de
datacenter e de borda.

Comece a implantar o Windows Server 2022 Datacenter: Azure Edition usando o Azure
Marketplace no Azure Stack HCI habilitado para Arc ou usando uma ISO. Baixe a ISO
daqui:

ISO do Windows Server 2022 Datacenter: Azure Edition (EN-US)

ISO do Windows Server 2022 Datacenter: Azure Edition (ZH-CN)

Sua assinatura do Azure permite que você use o Windows Server Datacenter: Azure
Edition em qualquer instância de máquina virtual em execução no Azure Stack HCI. Para
obter mais informações, confira os Termos do Produto .
Saiba mais sobre os recursos mais recentes do Azure Stack HCI no artigo Novidades do
Azure Stack HCI, versão 22H2.

Implantação por meio do Azure Marketplace no Azure Stack HCI

habilitado para Arc (versão prévia)
As imagens do Windows Server 2022 Datacenter: Azure Edition estarão disponíveis no
Azure Marketplace do Azure Stack HCI habilitado para Arc, facilitando a avaliação, a
compra e a implantação usando imagens certificadas do Azure.

Saiba mais sobre a integração de Azure Marketplace para recursos do Azure Stack HCI
habilitados para Azure Arc no artigo Novidades no Azure Stack HCI, versão 22H2.

Azure Edition (versão inicial)

Esta seção lista os recursos e os aprimoramentos disponíveis no Windows Server
Datacenter: Azure Edition com lançamento em setembro de 2021.

Gerenciamento Automatizado do Azure – Patch dinâmico

A aplicação de patch dinâmica do Gerenciamento Automatizado do Azure é uma nova

maneira de instalar atualizações em novas VMs (máquinas virtuais) do Windows Server
Azure Edition que não exigem uma reinicialização após a instalação. Mais informações
podem ser encontradas na documentação dp Gerenciamento Automatizado do Azure.

SMB por QUIC

O SMB por QUIC atualiza o protocolo SMB 3.1.1 para usar o protocolo QUIC em vez de
TCP no Windows Server 2022 Datacenter: Azure Edition, Windows 11 e posteriores e em
clientes de terceiros compatíveis com essa opção. Usando o SMB sobre QUIC junto com
o TLS 1.3, os usuários e aplicativos podem acessar dados de maneira segura e confiável
de servidores de arquivos de borda em execução no Azure. Usuários móveis e de
telecomutação não precisam mais de uma VPN para acessar seus servidores de arquivos
por SMB quando estão Windows. Veja mais informações na Documentação do SMB por
QUIC e nas Práticas recomendadas do gerenciamento de SMB por QUIC de computador
com o Gerenciamento Automatizado.

Para saber mais sobre o QUIC, veja o RFC 9000 .

Rede estendida para o Azure

A Rede Estendida do Azure permite que você transfira uma sub-rede local no Azure
para permitir que as máquinas virtuais locais mantenham seus endereços IP privados
locais originais ao migrar para o Azure. Para saber mais, consulte Rede Estendida do
Azure.

Todas as edições
Essa seção descreve alguns dos novos recursos no Windows Server 2022 em todas as
edições. Para saber mais sobre as diferentes edições, leia o artigo Comparação entre as
edições Standard, Datacenter e Datacenter: Azure Edition do Windows Server 2022.

Segurança
Os novos recursos de segurança no Windows Server 2022 combinam outros recursos de
segurança no Windows Server de várias áreas para fornecer proteção com defesa
profunda contra ameaças avançadas. A segurança avançada em várias camadas no
Windows Server 2022 fornece a proteção abrangente de que os servidores precisam
atualmente.

Servidor de núcleo seguro

O hardware de servidor de núcleo seguro certificado de um parceiro OEM fornece
proteções de segurança adicionais que são úteis contra ataques sofisticados. Essa opção
oferece mais confiabilidade ao manipular dados críticos em alguns dos setores com
maior presença de dados confidenciais. Um servidor de núcleo seguro usa
funcionalidades de hardware, firmware e driver para habilitar recursos avançados de
segurança do Windows Server. Muitos desses recursos estão disponíveis em PCs do
Windows de núcleo seguro e agora também estão disponíveis com hardware de
servidor de núcleo seguro e com o Windows Server 2022. Para obter mais informações
sobre o Servidor de núcleo seguro, consulte Servidor de núcleo seguro.

Raiz de confiança do hardware

Usado por recursos como a criptografia de unidade BitLocker, os chips de processador

de criptografia segura TPM 2.0 (Trusted Platform Module 2.0) oferecem um
armazenamento seguro baseado em hardware para dados e chaves criptográficas
confidenciais, incluindo medidas de integridade do sistema. O TPM 2.0 pode verificar se
o servidor foi iniciado com código legítimo e se é confiável para a próxima execução de
código, o que é conhecido como hardware raiz de confiança.
Proteção de firmware

O firmware é executado com altos privilégios e geralmente é invisível para soluções

antivírus tradicionais, o que leva a um aumento no número de ataques baseados em
firmware. Os servidores de núcleo seguro medem e verificam os processos de
inicialização com a tecnologia DRTM (Raiz Dinâmica de Confiança para Medição). Os
servidores de núcleo seguro também podem isolar o acesso do driver à memória com a
proteção DMA (acesso direto à memória).

Inicialização segura UEFI

A inicialização segura da UEFI é um padrão de segurança que protege seus servidores

contra rootkits mal-intencionados. A inicialização segura garante que o servidor
inicialize somente firmware e software de confiança do fabricante do hardware. Quando
o servidor é iniciado, o firmware verifica a assinatura de cada componente de
inicialização, incluindo drivers de firmware e o sistema operacional. Se as assinaturas
forem válidas, o servidor será inicializado e o firmware passará o controle para o sistema
operacional.

Segurança baseada em virtualização (VBS)

Os servidores de núcleo seguro dão suporte à VBS (segurança baseada em virtualização)

e à HVCI (integridade de código baseada em hipervisor). O VBS usa recursos de
virtualização de hardware para criar e isolar uma região segura de memória do sistema
operacional normal, protegendo contra uma classe inteira de vulnerabilidades usadas
em ataques de mineração de criptografia. A VBS também permite o uso do Credential
Guard, em que as credenciais e os segredos do usuário são armazenados em um
contêiner virtual que o sistema operacional não pode acessar diretamente.

O HVCI usa a VBS para fortalecer significativamente a imposição da política de

integridade do código. A integridade do modo kernel impede que drivers de modo
kernel não assinados ou arquivos do sistema sejam carregados na memória do sistema.

A KDP (Proteção de Dados de Kernel) fornece proteção de memória somente leitura da

memória do kernel que contém dados não executáveis em que as páginas de memória
são protegidas pelo hipervisor. A KDP impede que estruturas de chave no runtime do
Windows Defender System Guard sejam adulteradas.

Conectividade segura
Transporte: HTTPS e TLS 1.3 habilitados por padrão no Windows
Server 2022

As conexões seguras estão no centro dos sistemas interconectados de hoje. O protocolo

TLS 1.3 é a versão mais recente do protocolo de segurança mais implantado da Internet,
que criptografa dados para fornecer um canal de comunicação seguro entre dois
pontos de extremidade. Agora, o HTTPS com TLS 1.3 está habilitado por padrão no
Windows Server 2022, protegendo os dados de clientes que se conectam ao servidor.
Ele elimina algoritmos criptográficos obsoletos, aprimora a segurança em relação a
versões mais antigas e tem como objetivo criptografar o máximo possível do
handshake. Saiba mais sobre as versões do TLS com suporte e sobre os pacotes de
codificação com suporte.

Embora o TLS 1.3 na camada de protocolo agora seja habilitado por padrão, os
aplicativos e serviços também precisam dar suporte a ele ativamente. Veja mais detalhes
sobre isso no blog da Segurança da Microsoft na postagem Como levar o protocolo TLS
(Transport Layer Security) para o próximo nível com o TLS 1.3 .

DNS seguro: solicitações de resolução de nome DNS

criptografadas com DNS sobre HTTPS

O Cliente DNS no Windows Server 2022 agora dá suporte ao DoH (DNS sobre HTTPS),
que criptografa consultas DNS usando o protocolo HTTPS. O DoH ajuda a manter o
tráfego o mais privado possível impedindo a espionagem e a manipulação dos dados
de DNS. Saiba mais sobre como configurar o cliente DNS para usar o DoH.

Protocolo SMB: criptografia SMB AES-256 para os mais atentos à

segurança

O Windows Server agora dá suporte aos pacotes criptográficos AES-256-GCM e AES-

256-CCM para criptografia SMB. O Windows negociará automaticamente esse método
de criptografia mais avançado ao se conectar a outro computador também compatível
com ele. Esse método também pode ser imposto por meio de Política de Grupo. O
Windows Server ainda dá suporte a AES-128 para compatibilidade de nível inferior. A
assinatura do AES-128-GMAC agora também acelera o desempenho de assinatura.

SMB: controles de criptografia SMB Leste-Oeste para

comunicações internas do cluster

Agora, os clusters de failover do Windows Server dão suporte ao controle granular de

criptografar e assinar comunicações de armazenamento dentro dos nós para CSVs
(Volumes Compartilhados Clusterizados) e a SBL (camada de barramento de
armazenamento). Ao usar o Espaços de Armazenamento Diretos, você pode optar por
criptografar ou assinar as comunicações leste-oeste dentro do próprio cluster para
aumentar a segurança.

Criptografia SMB Direct e RDMA

O SMB Direct e o RDMA fornecem uma malha de rede com alta largura de banda e
baixa latência para cargas de trabalho como os Espaços de Armazenamento Diretos, a
Réplica de Armazenamento, o Hyper-V, o Servidor de Arquivos de Escalabilidade
Horizontal e o SQL Server. Agora, o SMB Direct no Windows Server 2022 dá suporte à
criptografia. Anteriormente, a habilitação da criptografia SMB desabilitava o
posicionamento direto de dados. Isso era intencional, mas afetava gravemente o
desempenho. Agora, os dados são criptografados antes do posicionamento, levando a
uma degradação de desempenho muito menor ao adicionar a privacidade de pacote
protegido AES-128 e AES-256.

Mais informações sobre criptografia SMB, aceleração de assinatura, RDMA seguro e

suporte a cluster podem ser encontradas em Aprimoramentos de segurança SMB.

Funcionalidades híbridas do Azure

Você pode aumentar sua eficiência e agilidade com recursos híbridos integrados no
Windows Server 2022 que permitem estender seus data centers para o Azure com mais
facilidade do que nunca.

Windows Servers habilitados para o Azure Arc

Os servidores habilitados para Azure Arc com o Windows Server 2022 trazem Windows
Servers locais e multinuvem para o Azure com o Azure Arc. Essa experiência de
gerenciamento foi projetada para ser consistente com o seu modo de gerenciar
máquinas virtuais nativas do Azure. Quando um computador híbrido é conectado ao
Azure, ele se torna um computador conectado e é tratado como um recurso no Azure.
Mais informações podem ser encontradas na documentação Azure Arc habilita
servidores.

Adicionar Servidores Windows

A partir da atualização de KB5031364 , agora você pode adicionar Windows Servers

com um processo fácil e simples.
Para adicionar novos Windows Servers, vá para o ícone do Azure Arc no canto inferior
direito da barra de tarefas e inicie o programa de Instalação do Azure Arc para instalar e
configurar um Azure Connected Machine Agent. Depois de instalado, você pode usar o
Azure Connected Machine Agent sem custo adicional para sua conta do Azure. Depois
de habilitar o Azure Arc no servidor, você poderá ver as informações de status no ícone
da barra de tarefas.

Para saber mais, consulte Conectar computadores do Windows Server ao Azure por
meio da Instalação do Azure Arc.

Windows Admin Center

Aprimoramentos no Windows Admin Center para gerenciar o Windows Server 2022
incluem funcionalidades para relatar o estado atual dos recursos de núcleo seguro
mencionados acima e, quando aplicável, permitir que os clientes habilitam os recursos.
Mais informações sobre esses e muitos outros aprimoramentos no Windows Admin
Center podem ser encontradas na documentação do Windows Admin Center.

Plataforma de aplicativos
Há vários aprimoramentos de plataforma para contêineres Windows, incluindo a
compatibilidade do aplicativo e a experiência de Contêiner do Windows com o
Kubernetes.

Alguns dos novos recursos são:

A redução do tamanho da imagem do Contêiner do Windows em até 40%, o que

causa um tempo de inicialização 30% mais rápido e um desempenho aprimorado.

Os aplicativos agora podem usar o Azure Active Directory com gMSA (contas de
serviços gerenciados de grupo) sem ingressar no domínio do host do contêiner.
Os contêineres do Windows agora também dão suporte ao MSDTC (Coordenador
de Transações Distribuídas da Microsoft) e ao MSMQ (Enfileiramento de
Mensagens da Microsoft).

Os barramentos simples agora podem ser atribuídos a contêineres de processos

isolados do Windows Server. Aplicativos em execução em contêineres que
precisam falar por SPI, I2C, GPIO e UART/COM agora são capazes de fazer isso.

Estamos habilitando o suporte para aceleração de hardware de APIs do DirectX em

contêineres do Windows para dar suporte a cenários como a inferência de ML
(machine learning) usando o hardware de GPU (unidade de processamento
 gráfico) local. Para obter mais informações, confira a postagem no blog Trazendo a
aceleração de GPU para contêineres do Windows .

Há vários outros aprimoramentos que simplificam a experiência de Contêiner do

Windows com o Kubernetes. Esses aprimoramentos incluem suporte para
contêineres de processo de host para configuração de nó, IPv6 e implementação
de política de rede consistente com o Calico.

O Windows Admin Center foi atualizado para facilitar a conteinerização de

aplicativos .NET. Depois que o aplicativo está em um contêiner, você pode
hospedá-lo no Registro de Contêiner do Azure para implantá-lo em outros
serviços do Azure, incluindo o Serviço de Kubernetes do Azure.

Com suporte para processadores Intel Ice Lake, o Windows Server 2022 dá suporte
a aplicativos comercialmente críticos e de grande escala, que exigem até 48 TB de
memória e 2.048 núcleos lógicos em execução em 64 soquetes físicos. A
computação confidencial com o SGX (Secured Guard Extension) da Intel no Intel
Ice Lake aumenta a segurança do aplicativo, isolando os aplicativos uns dos outros
com memória protegida.

Para saber mais sobre os novos recursos, confira Novidades para contêineres do
Windows no Windows Server 2022.

Outros recursos principais

Virtualização de IP da Área de Trabalho Remota

A partir da atualização de KB5030216 , agora você pode usar a Virtualização de IP da
Área de Trabalho Remota.

A Virtualização de IP da Área de Trabalho Remota simula uma área de trabalho de

usuário único, dando suporte a virtualização de IP por sessão e por programa da Área
de Trabalho Remota para aplicativos Winsock. Para saber mais, consulte a Virtualização
de IP da Área de Trabalho Remota no Windows Server.

Agendador de Tarefas e Gerenciador do Hyper-V em instalações do

Server Core

Adicionamos mais duas ferramentas ao pacote de recursos sob demanda de

compatibilidade de aplicativos nesta versão: o Agendador de Tarefas ([Link]) e o
Gerenciador do Hyper-V ([Link]). Para saber mais, confira FOD (Recurso sob
demanda) de compatibilidade de aplicativos do Server Core.
Virtualização aninhada para processadores AMD
A virtualização aninhada é um recurso que permite executar o Hyper-V em uma VM
(máquina virtual) do Hyper-V. O Windows Server 2022 dá suporte à virtualização
aninhada usando processadores AMD, dando mais opções de hardware para seus
ambientes. É possível encontrar mais informações na documentação da virtualização
aninhada.

Navegador Microsoft Edge

O Microsoft Edge está incluído no Windows Server 2022, substituindo o Internet

Explorer. Ele se baseia no Chromium de software livre e conta com o suporte da
segurança e de inovação da Microsoft. Ele pode ser usado com as opções de instalação
Servidor com Experiência Desktop. Mais informações podem ser encontradas na
documentação do Microsoft Edge Enterprise. O Microsoft Edge, diferentemente do
restante do Windows Server, segue o ciclo de vida moderno para o ciclo de vida de
suporte. Para obter detalhes, confira a documentação sobre o ciclo de vida do Microsoft
Edge.

Desempenho de rede

Aprimoramentos no desempenho do UDP

O UDP está se tornando um protocolo muito popular que transporta cada vez mais
tráfego de rede devido à crescente popularidade dos protocolos de streaming e jogos
personalizados (UDP) e RTP. O protocolo QUIC, criado com base no UDP, equipara o
nível de desempenho do UDP ao do TCP. Vale ressaltar que o Windows Server 2022
inclui o USO (Descarregamento de Segmentação UDP). O USO move a maior parte do
trabalho necessário para enviar pacotes UDP da CPU para o hardware especializado do
adaptador de rede. Complementando o USO, temos o UDP RSC (UDP Receive Side
Coalescing), que une pacotes e reduz o uso da CPU para processamento do UDP. Além
disso, também fizemos centenas de aprimoramentos no caminho de dados do UDP para
transmitir e receber. O Windows Server 2022 e o Windows 11 têm essa nova
funcionalidade.

Aprimoramentos de desempenho de TCP

O Windows Server 2022 usa o TCP HyStart++ para reduzir a perda de pacotes durante
a início da conexão (especialmente em redes de alta velocidade) e RACK para reduzir
o RTO (Tempo Limite de Retransmissão). Esses recursos são habilitados por padrão na
pilha de transporte e fornecem um fluxo de dados de rede mais suave com melhor
desempenho em altas velocidades. O Windows Server 2022 e o Windows 11 têm essa
nova funcionalidade.

Aprimoramentos no comutador virtual do Hyper-V

Os comutadores virtuais no Hyper-V foram aprimorados com o RSC (Receive Segment

Coalescing) atualizado. O RSC permite que a rede do hipervisor una pacotes e processe-
os como um segmento maior. Os ciclos de CPU são reduzidos e os segmentos
permanecerão unidos por todo o caminho de dados até que sejam processados pelo
aplicativo pretendido. O RSC resulta em um desempenho aprimorado no tráfego de
rede de um host externo, recebido por um adaptador de rede virtual, bem como de um
adaptador de rede virtual para outro adaptador de rede virtual no mesmo host.

No vSwitch, o RSC também pode unir vários segmentos TCP em um segmento maior
antes que os dados atravessem o vSwitch. Essa alteração também melhora o
desempenho de rede para cargas de trabalho virtuais. O RSC é habilitado em
comutadores virtuais externos por padrão.

Detecção de anomalias de disco de insights do sistema

Os Insights do Sistema tem outra funcionalidade por meio de Windows Admin Center:
detecção de anomalias de disco.

A detecção de anomalias de disco é uma nova funcionalidade que destaca quando

discos estão se comportando de forma diferente da normal. Embora diferente não
necessariamente uma seja uma coisa ruim, ver esses momentos anormais pode ser útil
ao solucionar problemas em seus sistemas. Essa funcionalidade também está disponível
para servidores que executam o Windows Server 2019.

Aprimoramentos de reversão do Windows Update

Agora, os servidores podem se recuperar automaticamente de falhas de inicialização

removendo as atualizações se a falha de inicialização tiver sido introduzida após a
instalação de atualizações recentes do driver ou de qualidade do Windows. Quando um
dispositivo não puder ser iniciado corretamente após a instalação recente de
atualizações de driver ou de qualidade, o Windows desinstalará automaticamente as
atualizações para fazer com que o dispositivo volte a funcionar normalmente.

Essa funcionalidade requer que o servidor esteja usando a opção de instalação Server
Core com uma partição do Ambiente de Recuperação do Windows.
Armazenamento
O Windows Server 2022 inclui as seguintes atualizações de armazenamento. O
armazenamento também é afetado pelas atualizações da detecção de anomalias de
disco de insights do sistema e do Windows Admin Center.

Serviço de Migração de Armazenamento

Aprimoramentos no Serviço de Migração de Armazenamento no Windows Server 2022
facilitam a migração do armazenamento para o Windows Server ou para o Azure de
mais locais de origem. Estes são os recursos disponíveis ao executar o orquestrador do
Servidor de Migração de Armazenamento no Windows Server 2022:

Migrar usuários e grupos locais para o novo servidor.

Migrar o armazenamento de clusters de failover, migrar para clusters de failover e
migrar entre servidores autônomos e clusters de failover.
Migrar o armazenamento de um servidor Linux que usa o Samba.
Sincronizar mais facilmente compartilhamentos migrados ao Azure usando a
Sincronização de Arquivos do Azure.
Migrar para novas redes, como o Azure.
Migrar servidores do NetApp CIFS das matrizes do NetApp FAS para servidores e
clusters do Windows.

Velocidade de reparo de armazenamento ajustável

Velocidade de reparo de armazenamento ajustável pelo usuário é um novo recurso nos
Espaços de Armazenamento Diretos que oferece mais controle sobre o processo de
ressincronização de dados. A velocidade de reparo de armazenamento ajustável permite
alocar recursos para reparar cópias de dados (resiliência) ou executar cargas de trabalho
ativas (desempenho). O controle da velocidade de reparo ajuda a aprimorar a
disponibilidade e permite atender aos clusters de maneira mais flexível e eficiente.

Reparo e ressincronização mais rápidos

O reparo e a ressincronização do armazenamento após eventos como reinicializações
de nó e falhas de disco agora são duas vezes mais rápidos. Os reparos têm menos
variação no tempo de duração para que você possa ter mais certeza de quanto tempo
os reparos levarão. Esse recurso foi obtido por meio da adição de mais granularidade ao
acompanhamento de dados. Os reparos agora movem apenas os dados que precisam
ser movidos, reduzindo os recursos do sistema usados e o tempo de duração.
Cache do barramento de armazenamento com Espaços de
Armazenamento em servidores autônomos

O cache do barramento de armazenamento está disponível para servidores autônomos.

Ele pode aprimorar significativamente o desempenho de leitura e gravação, mantendo a
eficiência do armazenamento e mantendo os custos operacionais baixos. Semelhante à
sua implementação para os Espaços de Armazenamento Diretos, esse recurso une uma
mídia mais rápida (por exemplo, NVMe ou SSD) com uma mídia mais lenta (por
exemplo, HDD) para criar camadas. Uma parte da camada de mídia mais rápida é
reservada para o cache. Para saber mais, confira Habilitar um cache do barramento de
armazenamento usando Espaços de Armazenamento em servidores autônomos.

Instantâneos no nível de arquivo ReFS

O ReFS (Sistema de Arquivos Resiliente) da Microsoft agora inclui a capacidade de criar
instantâneos de arquivos usando uma operação rápida de metadados. Os instantâneos
são diferentes da clonagem de bloco ReFS, uma vez que os clones são graváveis,
enquanto os instantâneos são somente leitura. Essa funcionalidade é especialmente útil
em cenários de backup de máquina virtual com arquivos VHD/VHDX. Os instantâneos
do ReFS são exclusivos, pois eles levam um tempo constante independentemente do
tamanho do arquivo. O suporte para instantâneos está disponível em ReFSUtil ou como
uma API.

Compactação do SMB
O aprimoramento do SMB no Windows Server 2022 e no Windows 11 permite que um
usuário ou aplicativo compacte arquivos conforme eles são transferidos pela rede. Os
usuários não precisam mais compactar manualmente os arquivos para serem
transferidos muito mais rapidamente em redes mais lentas ou mais congestionadas.
Para obter detalhes, confira compactação SMB.

Contêineres
O Windows Server 2022 inclui as seguintes alterações nos contêineres do Windows.

Redução do tamanho da imagem do Server Core

Reduzimos o tamanho das imagens do Server Core. Esse tamanho de imagem menor
permite que você implante aplicativos conteinerizados mais rapidamente. No Windows
Server 2022, a camada de lançamento para fabricação (RTM) da imagem de contêiner
do Server Core no momento do GA atinge 2,76 GB descompactados no disco. Em
comparação com a camada RTM do Windows Server 2019 no momento da GA, que tem
uma entrada registrada de 3,47 GB descompactados no disco, isso representa uma
redução de 33% no volume em disco dessa camada. Embora você não deva esperar que
o tamanho total da imagem seja reduzido em 33%, um tamanho de camada RTM menor
geralmente significa que o tamanho total da imagem será menor ao todo.

７ Observação

As imagens base do contêiner do Windows são fornecidas em duas camadas: uma

camada RTM e uma camada de patch que contém as correções de segurança mais
recentes para bibliotecas e binários do sistema operacional sobrepostos na camada
RTM. O tamanho da camada de patch muda ao longo da vida útil do ciclo de
suporte da imagem do contêiner, dependendo de quantas alterações estão nos
binários. Quando você puxa uma imagem base de contêiner para um novo host,
precisa puxar ambas as camadas.

Ciclo de suporte mais longo para todas as imagens de contêiner do

Windows

As imagens do Windows Server 2022, incluindo Server Core, Nano Server e imagem do
servidor , têm cinco anos de suporte base e cinco anos de suporte estendido. Esse
ciclo de suporte mais longo garante que você tenha tempo de implementar, usar e
atualizar ou migrar quando for apropriado para sua organização. Para saber mais,
confira Ciclos de vida da imagem base dos contêineres do Windows e Ciclos de vida do
Windows Server 2022.

Fuso horário virtualizado

Com o Windows Server 2022, os contêineres do Windows agora podem manuter uma
configuração de fuso horário virtualizado separada do host. Todas as configurações que
o fuso horário do host normalmente usa agora são virtualizadas e instanciadas para
cada contêiner. Para configurar o fuso horário do contêiner, você pode usar o utilitário
de comando tzutil ou o cmdlet do PowerShell Set-TimeZone. Para saber mais, confira
Fuso horário virtualizado.

Aprimoramentos na escalabilidade para dar suporte à rede de

sobreposição
O Windows Server 2022 agrega várias melhorias de desempenho e escala que já
estavam presentes em quatro versões anteriores do Canal Semestral (SAC) do Windows
Server que não tinham sido portadas para o Windows Server 2019:

Corrigido o problema que causava esgotamento da porta ao usar centenas de

serviços e pods do Kubernetes no mesmo nó.
Desempenho aprimorado do encaminhamento de pacotes no comutador virtual
do Hyper-V (vSwitch).
Maior confiabilidade entre as reinicializações da CNI (Interface de Rede de
Contêiner) no Kubernetes.
Aprimoramentos no painel de controle do HNS (Serviço de Rede de Host) e no
plano de dados usado pelos contêineres do Windows Server e pela rede do
Kubernetes.

Para saber mais sobre os aprimoramentos de desempenho e escalabilidade para dar

suporte à rede de sobreposição, confira Rede de sobreposição do Kubernetes para
Windows .

Roteamento de Retorno de Servidor Direto para redes de

sobreposição e l2bridge

O DSR (Retorno de Servidor Direto) é uma distribuição assimétrica de carga de rede em

sistemas com balanceamento de carga que faz com que o tráfego de solicitação e
resposta use caminhos de rede diferentes. O uso de caminhos de rede diferentes ajuda
a evitar saltos extras e reduz a latência, acelerando o tempo de resposta entre o cliente
e o serviço e removendo carga extra do load balancer. O DSR atinge de maneira
transparente um melhor desempenho de rede para os aplicativos com pouca ou
nenhuma alteração na infraestrutura.

Para saber mais, confira DSR na introdução ao suporte do Windows no Kubernetes .

Aprimoramentos na gMSA

Você pode usar gMSAs (Contas de serviço gerenciado de grupo) com os contêineres do
Windows para facilitar a autenticação do AD (Active Directory). Quando foi introduzida
no Windows Server 2019, a gMSA exigia o ingresso do host do contêiner em um
domínio para recuperar as credenciais dela do Active Directory. No Windows Server
2022, o gMSA para contêineres com um host não associado ao domínio usa uma
identidade de usuário portátil, em vez de uma identidade de host, para recuperar
credenciais do gMSA. Portanto, a junção manual dos nós de trabalho do Windows a um
domínio não é mais necessária. Após a autenticação, o Kubernetes salva a identidade do
usuário como um segredo. A gMSA para contêineres com um host não ingressado no
domínio fornece a flexibilidade de criar contêineres com a gMSA sem ingressar o nó do
host no domínio.

Para saber mais sobre os aprimoramentos da gMSA, confira Criar gMSAs para
contêineres do Windows.

Suporte a IPv6

O Kubernetes no Windows agora oferece suporte à pilha dupla IPv6 em redes baseadas
em L2bridge no Windows Server. O IPv6 depende do CNI que o Kubernetes usa e
também requer o Kubernetes versão 1.20 ou posterior para habilitar o suporte IPv6 de
ponta a ponta. Para obter mais informações, confira IPv4/IPv6 na Introdução à
compatibilidade do Windows no Kubernetes .

Suporte a várias sub-redes para nós de trabalho do Windows com

o Calico para Windows

O HNS (Serviço de Rede de Host) agora permite o uso de sub-redes mais restritivas,
como sub-redes com um prefixo mais longo, além do uso de várias sub-redes para cada
nó de trabalho do Windows. Anteriormente, o HNS restringia as configurações do ponto
de extremidade do contêiner do Kubernetes para usar apenas o comprimento do
prefixo da sub-rede subjacente. A primeira CNI que usa essa funcionalidade é o Calico
para Windows . Para saber mais, confira Suporte a várias sub-redes no Serviço de Rede
Host.

Contêineres HostProcess para gerenciamento de nós

Os contêineres HostProcess são um novo tipo de contêiner que é executado
diretamente no host e estende o modelo de contêiner do Windows para permitir uma
gama mais ampla de cenários de gerenciamento de cluster do Kubernetes. Com os
contêineres HostProcess, os usuários podem empacotar e distribuir operações de
gerenciamento que exigem acesso ao host enquanto mantêm os métodos de controle
de versão e implantação fornecidos pelos contêineres. Você pode usar contêineres do
Windows para diversos cenários de gerenciamento de rede, armazenamento e plug-in
de dispositivos no Kubernetes.

Os contêineres HostProcess têm os seguintes benefícios:

Os usuários de cluster não precisam mais fazer logon e configurar individualmente

cada nó do Windows para tarefas administrativas e de gerenciamento de serviços
do Windows.
 Eles podem utilizar o modelo de contêiner para implantar a lógica de
gerenciamento nos clusters que forem necessários.
Os usuários podem criar contêineres HostProcess sobre imagens base existentes
do Windows Server 2019 ou posterior, gerenciá-los usando o tempo de execução
do contêiner do Windows e executá-los como qualquer usuário disponível no
domínio da máquina host.
Os contêineres HostProcess oferecem a melhor maneira de gerenciar nós do
Windows no Kubernetes.

Para saber mais, confira Contêineres HostProcess do Windows .

Aprimoramentos do Windows Admin Center

O Windows Server 2022 expande a extensão de Contêineres adicionada ao Windows

Admin Center para conteinerizar aplicativos Web existentes baseados em [Link] do
.NET Framework. Você pode usar pastas estáticas ou soluções do Visual Studio do seu
desenvolvedor.

O Windows Admin Center inclui os seguintes aprimoramentos:

A extensão de Contêineres agora oferece suporte a arquivos de Implantação da

Web, o que permite extrair o aplicativo e sua configuração de um servidor em
execução e, em seguida, conteinerizar o aplicativo.
Você pode validar a imagem localmente e efetuar push dela para o Registro de
Contêiner do Azure.
O Registro de Contêiner do Azure e a Instância de Contêiner do Azure agora têm
funcionalidade básica de gerenciamento. Agora você pode usar a interface de
usuário do Windows Admin Center para criar e excluir registros, gerenciar imagens
e iniciar e interromper novas instâncias de contêiner.

Ferramentas de Conteinerização de Aplicativo das Migrações para

Azure
A conteinerização de aplicativos do Migrações para Azure é uma solução ponta a ponta
que conteineriza e move aplicativos Web existentes para o Serviço de Kubernetes do
Azure. Você pode avaliar servidores Web existentes, criar uma imagem de contêiner,
enviar a imagem por push para o Registro de Contêiner do Azure, criar uma
implantação do Kubernetes e, finalmente, implantá-la no Serviço de Kubernetes do
Azure.

Para obter mais informações sobre a ferramenta de conteinerização de aplicativos do

Migrações para Azure, confira Conteinerização e migração de aplicativo [Link] para o
Serviço de Kubernetes do Azure e Conteinerização e migração de aplicativo Web Java
para o Serviço de Kubernetes do Azure.

Comentários
Esta página foi útil?  Yes  No
Requisitos do sistema para o Hyper-V
no Windows Server
Artigo • 16/08/2024

Aplica-se a: Windows Server 2022 (versão preliminar), Windows Server 2016,

Microsoft Hyper-V Server 2016, Windows Server 2019, Microsoft Hyper-V Server
2019

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

O Hyper-V tem requisitos de hardware específicos e alguns recursos do Hyper-V têm

requisitos adicionais. Use os detalhes neste artigo para decidir quais requisitos seu
sistema deve atender para que você possa usar o Hyper-V conforme planejado por
você. Em seguida, revise o catálogo do Windows Server . Lembre-se de que os
requisitos do Hyper-V excedem os requisitos mínimos gerais do Windows Server porque
um ambiente de virtualização requer mais recursos de computação.

Se você já estiver usando o Hyper-V, é provável que você possa usar o hardware
existente. Os requisitos gerais de hardware não sofreram alterações significativas desde
o Windows Server 2012 R2. No entanto, você precisará de um hardware mais novo para
usar máquinas virtuais blindadas ou atribuição de dispositivos discretos. Esses recursos
dependem de suporte de hardware específico, conforme descrito abaixo. Fora isso, a
principal diferença no hardware é que agora a SLAT (Conversão de Endereços de
Segundo Nível) é necessária e não apenas recomendada.

Para obter detalhes sobre as configurações máximas suportadas para o Hyper-V, como
o número de máquinas virtuais em execução, consulte Planeje a escalabilidade do
Hyper-V no Windows Server. A lista de sistemas operacionais que você pode executar
em suas máquinas virtuais é abordada em Sistemas operacionais convidados do
Windows com suporte do Hyper-V no Windows Server.

Requisitos gerais
Independentemente dos recursos do Hyper-V que você deseja usar, você precisará:

Processador de 64 bits com SLAT. Para instalar os componentes de virtualização do

Hyper-V, como o hipervisor do Windows, o processador deve ter a SLAT. No
entanto, não é necessário instalar ferramentas de gerenciamento do Hyper-V,
como a VMConnect (Virtual Machine Connection), o Gerenciador do Hyper-V e os
cmdlets do Hyper-V para o Windows PowerShell. Confira abaixo "Como verificar os
requisitos do Hyper-V", para descobrir se o processador tem SLAT.

Extensões de modo de monitor VM

Memória suficiente – planeje pelo menos 4 GB de RAM. Obter mais memória é

melhor. Você precisará de memória suficiente para o host e todas as máquinas
virtuais que deseja executar ao mesmo tempo.

Suporte à virtualização ativado no BIOS ou UEFI:

Virtualização assistida por hardware. Isso está disponível em processadores que

incluem uma opção de virtualização, especialmente aqueles com a tecnologia
Intel VT (Intel Virtualization) ou AMD-V (AMD Virtualization).

A DEP (Prevenção de Execução de Dados) imposta por hardware deve estar

disponível e habilitada. Para sistemas Intel, esse é o bit XD (execute desabilitar
bit). Para sistemas AMD, esse é o bit NX (sem bit de execução).

Como verificar se há requisitos do Hyper-V

Abra o PowerShell ou uma janela do prompt de comando:

Prompt de comando do Windows

[Link]

Role até a seção Requisitos do Hyper-V para examinar o relatório.

Requisitos para recursos específicos

Esta seção lista os requisitos para atribuição de dispositivos discretos e máquinas
virtuais blindadas.

Atribuição discreta de dispositivo

Os requisitos de host são semelhantes aos requisitos existentes para o recurso SR-IOV
no Hyper-V.

O processador deve ter a EPT (Tabela de página estendida) da Intel ou a NPT

(Tabela de página aninhada) da AMD.

O chipset deve ter:

Remapeamento de interrupção – VT-d da Intel com a funcionalidade de

Remapeamento de Interrupção (VT-d2) ou qualquer versão da Unidade de
Gerenciamento de Memória de E/S (MMU de E/S) da AMD.

Remapeamento de DMA – VT-d da Intel com invalidações enfileiradas ou

qualquer MMU de E/S da AMD.

ACS (serviços de controle de acesso) em portas raiz do PCI Express.

As tabelas de firmware devem expor o MMU de E/S ao hipervisor do Windows.

Observe que esse recurso pode ser desativado na UEFI ou BIOS. Para obter
instruções, consulte a documentação de hardware ou entre em contato com o
fabricante do hardware.

Os dispositivos precisam de GPU ou NVMe (expressão de memória não volátil). Na GPU,

apenas determinados dispositivos dão suporte à atribuição de dispositivo discreta. Para
verificar, consulte a documentação de hardware ou entre em contato com o fabricante
do hardware. Para obter detalhes sobre esse recurso, inclusive modo de usar e as
considerações sobre ele, consulte a postagem "Atribuição de dispositivo discreta --
Descrição e plano de fundo " no blog Virtualização.

Máquinas virtuais blindadas

Essas máquinas virtuais dependem da segurança baseada em virtualização e estão
disponíveis a partir do Windows Server 2016.

Os requisitos do host são:

UEFI 2.3.1c – dá suporte à inicialização segura e medida

Os dois requisitos a seguir são opcionais para segurança baseada em virtualização

em geral, mas necessários para o host se você desejar obter a proteção que esses
recursos fornecem:

TPM v2.0 – protege ativos de segurança da plataforma

 IOMMU (Intel VT-D) – portanto, o hipervisor pode fornecer proteção de DMA
(acesso direto à memória)

Os requisitos da máquina virtual são:

Geração 2
Windows Server 2012 ou mais recente como o sistema operacional convidado

Comentários
Esta página foi útil?  Yes  No
Sistemas operacionais convidados do
Windows com suporte para Hyper-V no
Windows Server e Azure Stack HCI
Artigo • 13/08/2024

O Hyper-V dá suporte a várias versões de distribuições do Windows Server, do Windows

e do Linux para execução em máquinas virtuais, como sistemas operacionais
convidados. Este artigo aborda os sistemas operacionais convidados Windows Server e
Windows compatíveis. Para distribuições do Linux e do FreeBSD, confira Máquinas
virtuais compatíveis do Linux e do FreeBSD para o Hyper-V no Windows.

Alguns sistemas operacionais têm os serviços de integração internos. Outros exigem

que você instale ou atualize os serviços de integração como uma etapa separada depois
de configurar o sistema operacional na máquina virtual. Para obter mais informações,
consulte as seções a seguir e os Serviços de integração.

Os componentes configuráveis dos sistemas operacionais convidados são confinados

com base no sistema operacional de hospedagem. Para saber mais sobre o máximo de
componentes configuráveis no Hyper-V, consulte Planejar a escalabilidade do Hyper-V
no Windows Server.

Sistemas operacionais convidados Windows

Server compatíveis
Veja a seguir as versões do Windows Server compatíveis como sistemas operacionais
convidados com o Hyper-V no Windows Server.

ﾉ Expandir a tabela

Sistema Número máximo de Integration Services Observações

operacional processadores
convidado virtuais
(servidor)

Windows Server 2,048 para a geração Interno Hospedado no

2025 (versão prévia) 2; Windows Server 2025 e
64 para a geração 1; posteriores
2,048 disponível para
o sistema
Sistema Número máximo de Integration Services Observações
operacional processadores
convidado virtuais
(servidor)

operacional host
(partição raiz)

Windows Server 1,024 para a geração Interno Hospedado no

2022 2; Windows Server 2019 e
64 para a geração 1; posterior, Azure Stack
1,024 disponível para HCI, versão 20H2 e
o sistema posterior.
operacional host
(partição raiz)

Windows Server 240 para a geração 2; Interno

2019 64 para a geração 1;
320 disponível para o
sistema operacional
host (partição raiz)

Windows Server 240 para a geração 2; Interno

2016 64 para a geração 1;
320 disponível para o
sistema operacional
host (partição raiz)

Windows Server 64 Interno

2012 R2

Windows Server 64 Interno

2012

Windows Server 64 Instale todas as Edições Standard,

2008 R2 com atualizações críticas do Enterprise, Datacenter
Service Pack 1 (SP1) Windows depois de e Web.
configurar o sistema
operacional convidado.

Windows Server 8 Instale todas as Edições Datacenter,

2008 com Service atualizações críticas do Enterprise, Standard e
Pack 2 (SP2) Windows depois de Web (32 bits e 64 bits).
configurar o sistema
operacional convidado.

Sistemas operacionais convidados do cliente

Windows compatíveis
Veja a seguir as versões do cliente Windows compatíveis como sistemas operacionais
convidados com o Hyper-V no Windows Server.

ﾉ Expandir a tabela

Sistema Número máximo Integration Services Observações

operacional de processadores
convidado virtuais
(cliente)

Windows 11 32 Interno Máquina virtual de

geração 2 hospedada no
Windows Server 2019 ou
superior
Azure Stack HCI, versão
20H2 e posterior.

Windows 10 32 Interno

Windows 8.1 32 Interno

Windows 7 com 4 Atualize os serviços de Edições Ultimate,

Service Pack 1 integração depois de Enterprise e Professional
(SP1) configurar o sistema (32 bits e 64 bits).
operacional convidado.

Suporte ao sistema operacional convidado em

outras versões do Windows
A tabela a seguir fornece links para informações sobre os sistemas operacionais
convidados compatíveis com o Hyper-V em outras versões do Windows.

ﾉ Expandir a tabela

Sistema operacional do Artigo

host

Windows 10, 11 Sistemas operacionais convidados compatíveis com o Hyper-V

Cliente no Windows 10

Windows Server 2012 R2 e - Sistemas operacionais convidados do Windows compatíveis

Windows 8.1 com o Hyper-V no Windows Server 2012 R2 e no Windows 8.1
- Máquinas Virtuais do Linux e do FreeBSD no Hyper-V

Windows Server 2012 e Sistemas operacionais convidados do Windows com suporte para
Windows 8 Hyper-V no Windows Server 2012 e Windows 8
 Sistema operacional do Artigo
host

Windows Server 2008 e Sobre máquinas virtuais e sistemas operacionais convidados

Windows Server 2008 R2

Como a Microsoft dá suporte aos sistemas

operacionais convidados
A Microsoft dá suporte aos sistemas operacionais convidados da seguinte forma:

Os problemas encontrados em sistemas operacionais da Microsoft e em serviços

de integração são tratados pelo suporte da Microsoft.

Para problemas encontrados em outros sistemas operacionais que tenham sido

certificados pelo fornecedor do sistema operacional para execução em Hyper-V, o
suporte é prestado pelo fornecedor.

Para problemas encontrados em outros sistemas operacionais, a Microsoft envia o

problema à comunidade de suporte de vários fornecedores, a TSANet .

Links relacionados
Máquinas Virtuais do Linux e FreeBSD no Hyper-V

Sistemas operacionais convidados compatíveis para o Hyper-V Cliente no

Windows

Comentários
Esta página foi útil?  Yes  No
Máquinas virtuais Linux e FreeBSD com
suporte para o Hyper-V no Windows
Server e no Windows
Artigo • 16/08/2024

Aplica-se a: Azure Stack HCI, Windows Server 2025 (visualização), Windows Server
2022, Windows Server 2019, Windows Server 2016, Hyper-V Server 2016, Windows
Server 2012 R2, Hyper-V Server 2012 R2, Windows Server 2012, Hyper-V Server
2012, Windows Server 2008 R2, Windows 10, Windows 8.1, Windows 8, Windows
7.1, Windows 7

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

O Hyper-V dá suporte a dispositivos emulados e específicos do Hyper-V para máquinas

virtuais Linux e FreeBSD. Ao executar com dispositivos emulados, nenhum software
adicional precisa ser instalado. No entanto, dispositivos emulados não fornecem alto
desempenho e não podem aproveitar a infraestrutura avançada de gerenciamento de
máquina virtual que a tecnologia Hyper-V oferece. Para fazer uso completo de todos os
benefícios fornecidos pelo Hyper-V, a melhor opção é usar dispositivos específicos do
Hyper-V para Linux e FreeBSD. A coleção de drivers necessários para executar
dispositivos específicos do Hyper-V é conhecida como LIS (Linux Integration Services)
ou BIS (FreeBSD Integration Services).

O LIS foi adicionado ao kernel Linux e é atualizado para novas versões. No entanto,
distribuições Linux baseadas em kernels mais antigos podem não ter os
aprimoramentos ou as correções mais recentes. A Microsoft fornece um download que
contém drivers LIS instaláveis para algumas instalações Linux com base nesses kernels
mais antigos. Como os fornecedores de distribuição incluem versões do Linux
Integration Services, é melhor instalar a versão para download mais recente do LIS, se
aplicável, para sua instalação.

Para outras distribuições Linux, as alterações do LIS são integradas regularmente ao

kernel e aos aplicativos do sistema operacional, de modo que nenhum download ou
instalação separado é necessário.

Para versões mais antigas do FreeBSD (antes da 10.0), a Microsoft fornece portas que
contêm os drivers BIS instaláveis e daemons correspondentes para máquinas virtuais
FreeBSD. Para versões mais recentes do FreeBSD, o BIS é integrado ao sistema
operacional FreeBSD e nenhum download ou instalação separado é necessário, exceto
pelo download de portas KVP necessário para o FreeBSD 10.0.

 Dica

Baixe o Windows Server no Centro de Avaliação.

A meta deste conteúdo é fornecer informações que ajudem a facilitar a implantação do

Linux ou do FreeBSD no Hyper-V. Detalhes específicos incluem:

Distribuições Linux ou versões do FreeBSD que exigem o download e a instalação

de drivers do LIS ou BIS.

Distribuições Linux ou versões do FreeBSD que contêm drivers LIS ou BIS internos.

Mapas de distribuição de recursos que indicam os recursos nas principais

distribuições do Linux ou versões do FreeBSD.

Problemas conhecidos e soluções alternativas para cada distribuição ou versão.

Descrição do recurso para cada recurso do LIS ou BIS.

Nesta seção
Máquinas virtuais CentOS e Red Hat Enterprise Linux com suporte no Hyper-V

Máquinas virtuais do Debian com suporte no Hyper-V

Máquinas virtuais Oracle Linux com suporte no Hyper-V

Máquinas virtuais SUSE com suporte no Hyper-V

Máquinas virtuais Ubuntu com suporte no Hyper-V

Máquinas virtuais do FreeBSD compatíveis com o Hyper-V

Descrições de recursos para máquinas virtuais do Linux e do FreeBSD no Hyper-V

Melhores práticas para executar o Linux no Hyper-V

 Melhores práticas para executar o FreeBSD no Hyper-V

Comentários
Esta página foi útil?  Yes  No
Máquinas virtuais CentOS e Red Hat Enterprise Linux com
suporte no Hyper-V
Artigo • 27/09/2023

Aplica-se a: Azure Stack HCI, Windows Server 2022, Windows Server Windows Server 2019, Hyper-V Server Windows Server 2019,
Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2, Hyper-V Server 2012 R2, Windows 11, Windows 10, Windows 8.1

Os mapas de distribuição de recursos a seguir indicam os recursos presentes em versões internas e para download dos Serviços de
Integração do Linux. Os problemas conhecidos e as soluções alternativas para cada distribuição são listados após as tabelas.

Os drivers internos dos Serviços de Integração do Red Hat Enterprise Linux para Hyper-V (disponíveis desde o Red Hat Enterprise Linux 6.4)
são suficientes para os convidados do Red Hat Enterprise Linux executarem usando os dispositivos sintéticos de alto desempenho em hosts
Hyper-V. Esses drivers internos são certificados pelo Red Hat para esse uso. As configurações certificadas podem ser exibidas nesta página
da Web do Red Hat: Catálogo de certificações do Red Hat . Não é necessário baixar e instalar pacotes dos Serviços de Integração do Linux
no Centro de Download da Microsoft, e fazer isso pode limitar o suporte ao Red Hat, conforme descrito no artigo 1067 da Base de Dados
de Conhecimento do Red Hat: Red Hat Knowledgebase 1067 .

Devido aos possíveis conflitos entre o suporte interno dos LIS e o suporte aos LIS para download ao atualizar o kernel, desabilite as
atualizações automáticas, desinstale os pacotes dos LIS para download, atualize o kernel, reinicialize, depois instale a versão mais recente
dos LIS e reinicie novamente.

７ Observação

As informações oficiais de certificação do Red Hat Enterprise Linux são disponibilizadas por meio do Portal do cliente do Red Hat .

Nesta seção:

RHEL/CentOS 9.x Series

RHEL/CentOS 8.x Series

RHEL/CentOS 7.x Series

RHEL/CentOS 6.x Series

RHEL/CentOS 5.x Series

Observações

Legenda da tabela
Interno – os LIS estão incluídos como parte dessa distribuição do Linux. Os números de versão do módulo de kernel para os LIS
internos (conforme mostrado pelo lsmod, por exemplo) são diferentes do número de versão no pacote de download dos LIS
fornecidos pela Microsoft. Uma incompatibilidade não indica que os LIS internos estão desatualizados.

✔ – Recurso disponível

(em branco) – Recurso não disponível

RHEL/CentOS 9.x Series

Recurso SO host 9.x

Disponibilidade dos LIS Interno

Básico Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔

Hora Precisa do Windows Server 2016 Windows Server 2022, 2019, 2016 ✔
Azure Stack HCI

>256 vCPUs ✔

Rede
Recurso SO host 9.x

Quadros jumbo Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Marcação e truncamento VLAN Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Migração dinâmica Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Injeção de IP estático Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 2

Azure Stack HCI

vRSS Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Descarregamentos de segmentação e soma de verificação TCP Windows Server 2022, 2019, 2016, 2012 R2 ✔
Azure Stack HCI

SR-IOV Windows Server 2022, 2019, 2016 ✔

Azure Stack HCI

Storage

Redimensionamento do VHDX Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Fibre Channel Virtual Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 3
Azure Stack HCI

Backup de máquina virtual ativa Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 5
Azure Stack HCI

Suporte ao TRIM Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

SCSI WWN Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Memória

Suporte ao kernel de PAE Windows Server 2022, 2019, 2016, 2012 R2

Azure Stack HCI

Configuração da lacuna de MMIO Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Memória Dinâmica – Adição Dinâmica Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 9, 10
Azure Stack HCI

Memória Dinâmica – Inchamento Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 9,10
Azure Stack HCI

Redimensionamento da memória de runtime Windows Server 2022, 2019, 2016 ✔

Azure Stack HCI

Vídeo

Dispositivo de vídeo específico do Hyper-V Windows Server 2022, 2019, 2016, 2012 R2 ✔
Azure Stack HCI

Diversos

Par chave-valor Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Interrupção Não Mascarável Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Cópia de arquivo do host para o convidado Windows Server 2022, 2019, 2016, 2012 R2 ✔
Azure Stack HCI

Comando lsvmbus Windows Server 2022, 2019, 2016, 2012 R2 ✔

Azure Stack HCI

Soquetes do Hyper-V Windows Server 2022, 2019, 2016 ✔

Azure Stack HCI
Recurso SO host 9.x

Passagem de PCI/DDA Windows Server 2022, 2019, 2016 ✔

Azure Stack HCI

Máquinas virtuais de 2ª geração

Inicialização por meio da UEFI Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 14, 17
Azure Stack HCI

Inicialização Segura Windows Server 2022, 2019, 2016 ✔

Azure Stack HCI

RHEL/CentOS 8.x Series

Recurso SO host 8.1-8.6+ 8.0

Disponibilidade dos LIS Interno Interno

Básico Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Hora Precisa do Windows Server 2016 Windows Server 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

>256 vCPUs ✔

Rede

Quadros jumbo Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Marcação e truncamento VLAN Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Migração dinâmica Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Injeção de IP estático Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 2 ✔ Observação 2
Azure Stack HCI

vRSS Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Descarregamentos de segmentação e soma de verificação TCP Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔
Azure Stack HCI

SR-IOV Windows Server 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Storage

Redimensionamento do VHDX Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Fibre Channel Virtual Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 3 ✔ Observação 3
Azure Stack HCI

Backup de máquina virtual ativa Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 5 ✔ Observação 5
Azure Stack HCI

Suporte ao TRIM Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

SCSI WWN Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Memória

Suporte ao kernel de PAE Windows Server 2022, 2019, 2016, 2012 R2 N/D N/D
Azure Stack HCI

Configuração da lacuna de MMIO Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Memória Dinâmica – Adição Dinâmica Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 9, 10 ✔ Observação 9, 10
Azure Stack HCI
 Recurso SO host 8.1-8.6+ 8.0

Memória Dinâmica – Inchamento Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 9, 10 ✔ Observação 9, 10
Azure Stack HCI

Redimensionamento da memória de runtime Windows Server 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Vídeo

Dispositivo de vídeo específico do Hyper-V Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔
Azure Stack HCI

Diversos

Par chave-valor Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Interrupção Não Mascarável Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Cópia de arquivo do host para o convidado Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔
Azure Stack HCI

Comando lsvmbus Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI

Soquetes do Hyper-V Windows Server 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Passagem de PCI/DDA Windows Server 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Máquinas virtuais de 2ª geração

Inicialização por meio da UEFI Windows Server 2022, 2019, 2016, 2012 R2 ✔ Observação 14, 17 ✔ Observação 14
Azure Stack HCI

Inicialização Segura Windows Server 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

RHEL/CentOS 7.x Series

Esta série tem apenas kernels de 64 bits.

Recurso SO host 7.5-7.7 7.3-7.4 7.0-7.2 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.

Disponibilidade dos LIS 4.3 LIS 4.3 LIS 4.3 Interno Interno Interno Interno Interno Interno In
LIS

Básico Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Hora Precisa do Windows ✔ ✔ ✔ ✔ ✔

Windows Server Server
2016 2022,
2019,
2016
Azure
Stack
HCI

>256 vCPUs ✔
Observação
16

Rede
Recurso SO host 7.5-7.7 7.3-7.4 7.0-7.2 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.

Quadros jumbo Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Marcação e Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
truncamento VLAN Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Migração dinâmica Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Injeção de IP Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
estático Server Observação Observação Observação Observação Observação Observação Observação Observação Observação O
2022, 2 2 2 2 2 2 2 2 2 2
2019,
2016,
2012 R2
Azure
Stack
HCI

vRSS Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Descarregamentos Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
de segmentação e Server
soma de verificação 2022,
TCP 2019,
2016,
2012 R2
Azure
Stack
HCI

SR-IOV Windows ✔ ✔ ✔ ✔ ✔
Server
2022,
2019,
2016
Azure
Stack
HCI

Storage

Redimensionamento Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
do VHDX Server
2022,
Recurso SO host 7.5-7.7 7.3-7.4 7.0-7.2 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.

2019,
2016,
2012 R2
Azure
Stack
HCI

Fibre Channel Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Virtual Server Observação Observação Observação Observação Observação Observação Observação Observação Observação O
2022, 3 3 3 3 3 3 3 3 3 3
2019,
2016,
2012 R2
Azure
Stack
HCI

Backup de máquina Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

virtual ativa Server Observação Observação Observação Observação Observação Observação Observação Observação Observação O
2022, 5 5 5 4,5 4,5 4, 5 4, 5 4, 5 4, 5 4,
2019,
2016,
2012 R2
Azure
Stack
HCI

Suporte ao TRIM Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

SCSI WWN Windows ✔ ✔ ✔ ✔

Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Memória

Suporte ao kernel Windows N/D N/D N/D N/D N/D N/D N/D N/D N/D N
de PAE Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Configuração da Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
lacuna de MMIO Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Memória Dinâmica Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

– Adição Dinâmica Server Observação Observação Observação Observação Observação Observação Observação Observação Observação O
2022, 8, 9, 10 8, 9, 10 8, 9, 10 8, 9, 10 9, 10 9, 10 9, 10 9, 10 9, 10 8,
2019,
2016,
Recurso SO host 7.5-7.7 7.3-7.4 7.0-7.2 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.

2012 R2
Azure
Stack
HCI

Memória Dinâmica Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

– Inchamento Server Observação Observação Observação Observação Observação Observação Observação Observação Observação O
2022, 9, 10 9, 10 9, 10 9, 10 9, 10 9, 10 9, 10 9, 10 9, 10 9,
2019,
2016,
2012 R2
Azure
Stack
HCI

Redimensionamento Windows ✔ ✔ ✔
da memória de Server
runtime 2022,
2019,
2016
Azure
Stack
HCI

Vídeo

Dispositivo de vídeo Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

específico do Server
Hyper-V 2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Diversos

Par chave-valor Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server Observação Observação Observação Observação Observação Observação O
2022, 4 4 4 4 4 4 4
2019,
2016,
2012 R2
Azure
Stack
HCI

Interrupção Não Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Mascarável Server
2022,
2019,
2016,
2012 R2
Azure
Stack
HCI

Cópia de arquivo do Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

host para o Server Observação Observação Observação Observação Observação Observação
convidado 2022, 4 4 4 4 4 4
2019,
2016,
2012 R2
Azure
Stack
HCI

Comando lsvmbus Windows ✔ ✔ ✔

Server
2022,
2019,
2016,
2012 R2
 Recurso SO host 7.5-7.7 7.3-7.4 7.0-7.2 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.

Azure
Stack
HCI

Soquetes do Hyper- Windows ✔ ✔ ✔

V Server
2022,
2019,
2016

Passagem de Windows ✔ ✔ ✔ ✔ ✔ ✔
PCI/DDA Server
2022,
2019,
2016
Azure
Stack
HCI

Máquinas virtuais
de 2ª geração

Inicialização por Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

meio da UEFI Server Observação Observação Observação Observação Observação Observação Observação Observação Observação O
2022, 14 14 14 14 14 14 14 14 14 14
2019,
2016,
2012 R2
Azure
Stack
HCI

Inicialização Segura Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server
2022,
2019,
2016
Azure
Stack
HCI

RHEL/CentOS 6.x Series

O kernel de 32 bits para esta série está habilitado para PAE. Não há suporte dos LIS internos para o RHEL/CentOS 6.0-6.3.

Recurso SO host 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.9, 6.8 6.6, 6.7 6.5 6.4

Disponibilidade dos LIS LIS 4.3 LIS 4.3 LIS 4.3 Interno Interno Interno Interno

Básico Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Hora Precisa do Windows Windows

Server 2016 Server 2022,
2019, 2016
Azure Stack
HCI

>256 vCPUs

Rede

Quadros jumbo Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Recurso SO host 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.9, 6.8 6.6, 6.7 6.5 6.4

Marcação e truncamento Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

VLAN Server 2022, Observação Observação Observação Observação Observação 1 Observação 1 Observação 1
2019, 2016, 1 1 1 1
2012 R2
Azure Stack
HCI

Migração dinâmica Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Injeção de IP estático Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022, Observação Observação Observação Observação Observação 2 Observação 2 Observação 2
2019, 2016, 2 2 2 2
2012 R2
Azure Stack
HCI

vRSS Windows ✔ ✔ ✔ ✔ ✔
Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Descarregamentos de Windows ✔ ✔ ✔ ✔ ✔
segmentação e soma de Server 2022,
verificação TCP 2019, 2016,
2012 R2
Azure Stack
HCI

SR-IOV Windows
Server 2022,
2019, 2016
Azure Stack
HCI

Storage

Redimensionamento do Windows ✔ ✔ ✔ ✔ ✔ ✔
VHDX Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Fibre Channel Virtual Windows ✔ ✔ ✔ ✔ ✔ ✔

Server 2022, Observação Observação Observação Observação Observação 3 Observação 3
2019, 2016, 3 3 3 3
2012 R2
Azure Stack
HCI

Backup de máquina virtual Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

ativa Server 2022, Observação Observação Observação Observação Observação Observação Observação
2019, 2016, 5 5 5 4, 5 4, 5 4, 5, 6 4, 5, 6
2012 R2
Azure Stack
HCI

Suporte ao TRIM Windows ✔ ✔ ✔ ✔

Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

SCSI WWN Windows ✔ ✔ ✔

Server 2022,
2019, 2016,
Recurso SO host 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.9, 6.8 6.6, 6.7 6.5 6.4

2012 R2
Azure Stack
HCI

Memória

Suporte ao kernel de PAE Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Configuração da lacuna de Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

MMIO Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Memória Dinâmica – Windows ✔ ✔ ✔ ✔ ✔ ✔

Adição Dinâmica Server 2022, Observação Observação Observação Observação Observação Observação
2019, 2016, 7, 9, 10 7, 9, 10 7, 9, 10 7, 9, 10 7, 8, 9, 10 7, 8, 9, 10
2012 R2
Azure Stack
HCI

Memória Dinâmica – Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

Inchamento Server 2022, Observação Observação Observação Observação Observação Observação Observação
2019, 2016, 7, 9, 10 7, 9, 10 7, 9, 10 7, 9, 10 7, 9, 10 7, 9, 10 7, 9, 10, 11
2012 R2
Azure Stack
HCI

Redimensionamento da Windows
memória de runtime Server 2022,
2019, 2016
Azure Stack
HCI

Vídeo

Dispositivo de vídeo Windows ✔ ✔ ✔ ✔ ✔ ✔

específico do Hyper-V Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Diversos

Par chave-valor Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022, Observação Observação Observação Observação
2019, 2016, 12 12 12, 13 12, 13
2012 R2
Azure Stack
HCI

Interrupção Não Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔

Mascarável Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI

Cópia de arquivo do host Windows ✔ ✔ ✔ ✔ ✔

para o convidado Server 2022, Observação Observação
2019, 2016, 12 12
2012 R2
Azure Stack
HCI

Comando lsvmbus Windows ✔ ✔ ✔

Server 2022,
2019, 2016,
 Recurso SO host 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.9, 6.8 6.6, 6.7 6.5 6.4

2012 R2
Azure Stack
HCI

Soquetes do Hyper-V Windows ✔ ✔ ✔

Server 2022,
2019, 2016
Azure Stack
HCI

Passagem de PCI/DDA Windows ✔

Server 2022,
2019, 2016
Azure Stack
HCI

Máquinas virtuais de 2ª
geração

Inicialização por meio da Windows ✔ ✔ ✔ ✔

UEFI Server 2022, Observação Observação Observação Observação
2019, 2016, 14 14 14 14
2012 R2
Azure Stack
HCI

Inicialização Segura Windows

Server 2022,
2019, 2016
Azure Stack
HCI

RHEL/CentOS 5.x Series

Esta série tem um kernel PAE de 32 bits com suporte disponível. Não há suporte dos LIS internos para o RHEL/CentOS anterior à 5.9.

Recurso SO host 5.2 -5.11 5.2-5.11 5.9 - 5.11

Disponibilidade dos LIS LIS 4.3 LIS 4.1 Interno

Básico Windows Server 2022, 2019, ✔ ✔ ✔

2016, 2012 R2
Azure Stack HCI

Hora Precisa do Windows Server 2016 Windows Server 2022, 2019,

2016
Azure Stack HCI

>256 vCPUs

Rede

Quadros jumbo Windows Server 2022, 2019, ✔ ✔ ✔

2016, 2012 R2
Azure Stack HCI

Marcação e truncamento VLAN Windows Server 2022, 2019, ✔ Observação 1 ✔ Observação 1 ✔ Observação 1
2016, 2012 R2
Azure Stack HCI

Migração dinâmica Windows Server 2022, 2019, ✔ ✔ ✔

2016, 2012 R2
Azure Stack HCI

Injeção de IP estático Windows Server 2022, 2019, ✔ Observação 2 ✔ Observação 2 ✔ Observação 2

2016, 2012 R2
Azure Stack HCI

vRSS Windows Server 2022, 2019,

2016, 2012 R2
Azure Stack HCI

Descarregamentos de segmentação e soma de Windows Server 2022, 2019, ✔ ✔

verificação TCP 2016, 2012 R2
Recurso Azure Stack HCI
SO host 5.2 -5.11 5.2-5.11 5.9 - 5.11

SR-IOV Windows Server 2022, 2019,

2016
Azure Stack HCI

Storage

Redimensionamento do VHDX Windows Server 2022, 2019, ✔ ✔

2016, 2012 R2
Azure Stack HCI

Fibre Channel Virtual Windows Server 2022, 2019, ✔ Observação 3 ✔ Observação 3

2016, 2012 R2
Azure Stack HCI

Backup de máquina virtual ativa Windows Server 2022, 2019, ✔ Observação 5, 15 ✔ Observação 5 ✔ Observação 4,
2016, 2012 R2 5, 6
Azure Stack HCI

Suporte ao TRIM Windows Server 2022, 2019,

2016, 2012 R2
Azure Stack HCI

SCSI WWN Windows Server 2022, 2019,

2016, 2012 R2
Azure Stack HCI

Memória

Suporte ao kernel de PAE Windows Server 2022, 2019, ✔ ✔ ✔

2016, 2012 R2
Azure Stack HCI

Configuração da lacuna de MMIO Windows Server 2022, 2019, ✔ ✔ ✔

2016, 2012 R2
Azure Stack HCI

Memória Dinâmica – Adição Dinâmica Windows Server 2022, 2019,

2016, 2012 R2
Azure Stack HCI

Memória Dinâmica – Inchamento Windows Server 2022, 2019, ✔ Observação 7, 9, ✔ Observação 7, 9,

2016, 2012 R2 10, 11 10, 11
Azure Stack HCI

Redimensionamento da memória de runtime Windows Server 2022, 2019,

2016
Azure Stack HCI

Vídeo

Dispositivo de vídeo específico do Hyper-V Windows Server 2022, 2019, ✔ ✔

2016, 2012 R2
Azure Stack HCI

Diversos

Par chave-valor Windows Server 2022, 2019, ✔ ✔

2016, 2012 R2
Azure Stack HCI

Interrupção Não Mascarável Windows Server 2022, 2019, ✔ ✔ ✔

2016, 2012 R2
Azure Stack HCI

Cópia de arquivo do host para o convidado Windows Server 2022, 2019, ✔ ✔

2016, 2012 R2
Azure Stack HCI

Comando lsvmbus Windows Server 2022, 2019,

2016, 2012 R2
Azure Stack HCI

Soquetes do Hyper-V Windows Server 2022, 2019,

2016
Azure Stack HCI
Recurso SO host 5.2 -5.11 5.2-5.11 5.9 - 5.11

Passagem de PCI/DDA Windows Server 2022, 2019,

2016
Azure Stack HCI

Máquinas virtuais de 2ª geração

Inicialização por meio da UEFI Windows Server 2022, 2019,

2016, 2012 R2
Azure Stack HCI

Inicialização Segura Windows Server 2022, 2019,

2016
Azure Stack HCI

Observações
1. Para esta versão do RHEL/CentOS, a marcação de VLAN funciona, mas o truncamento de VLAN não funciona.

2. A injeção de IP estático não funcionará se o Gerenciador de Rede for configurado para um determinado adaptador de rede sintético
na máquina virtual. Para um bom funcionamento da injeção de IP estático, verifique se o Gerenciador de Rede está completamente
desativado ou foi desativado para um adaptador de rede específico por meio de seu arquivo ifcfg-ethX.

3. No Windows Server 2012 R2, ao usar dispositivos de fibre channel virtuais, verifique se o LUN 0 (número de unidade lógica 0) foi
preenchido. Se o LUN 0 não tiver sido preenchido, uma máquina virtual Linux talvez não possa montar dispositivos de fibre channel
nativamente.

4. Para LIS interno, o pacote "hyperv-daemons" deve ser instalado para essa funcionalidade.

5. Caso haja identificadores de arquivos abertos durante uma operação de backup de máquina virtual dinâmica, em alguns casos
extremos, os VHDs de backup podem passar por uma fsck (verificação de consistência do sistema de arquivos) na restauração. As
operações de backup dinâmicas poderão falhar silenciosamente se a máquina virtual tiver um dispositivo iSCSI conectado ou um
armazenamento diretamente conectado (também conhecido como disco de passagem).

6. Embora o download dos Serviços de Integração do Linux seja preferencial, o suporte ao backup dinâmico para RHEL/CentOS 5.9 –
5.11/6.4/6.5 também está disponível por meio do Fundamentos de backup do Hyper-V para o Linux .

7. O suporte à memória dinâmica só está disponível em máquinas virtuais de 64 bits.

8. O suporte à inclusão automática não está habilitado por padrão nesta distribuição. Para habilitar o suporte à inclusão automática,
você precisa adicionar uma regra udev em /etc/udev/rules.d/ da seguinte maneira:

a. Crie um arquivo /etc/udev/rules.d/[Link]. Você pode usar qualquer outro nome desejado para o arquivo.

b. Adicione o seguinte conteúdo ao arquivo: SUBSYSTEM=="memory", ACTION=="add", ATTR{state}="online"

c. Reinicialize o sistema para habilitar o suporte à inclusão automática.

Embora o download dos Serviços de Integração do Linux crie essa regra na instalação, a regra também é removida quando o LIS é
desinstalado. Portanto, a regra deverá ser recriada se a memória dinâmica for necessária após a desinstalação.

9. As operações de memória dinâmica poderão falhar se o sistema operacional convidado estiver com pouca memória. Estas são
algumas práticas recomendadas:

A memória de inicialização e a memória mínima devem ser iguais ou maiores que a quantidade de memória recomendada pelo
fornecedor de distribuição.

Os aplicativos que tendem a consumir toda a memória disponível em um sistema estão limitados a consumir até 80% da RAM
disponível.

10. Se você estiver usando Memória Dinâmica em um sistema operacional Windows Server 2016 ou Windows Server 2012 R2, especifique
os parâmetros de Memória de inicialização, Memória mínima e Memória máxima em múltiplos de 128 megabytes (MB). Se isso não
for feito, haverá falhas da inclusão automática e você pode não perceber nenhum aumento de memória em um sistema operacional
convidado.

11. Determinadas distribuições, incluindo aquelas que usam os LIS 4.0 e 4.1, fornecem apenas suporte ao Inchamento e não fornecem
suporte à inclusão automática. Nesse cenário, o recurso de memória dinâmica pode ser usado definindo o parâmetro Memória de
inicialização como um valor igual ao parâmetro de Memória máxima. Isso faz com que toda a memória necessária seja incluída
 automaticamente à máquina virtual no momento da inicialização e, mais tarde, dependendo dos requisitos de memória do host, o
Hyper-V pode alocar ou desalocar livremente a memória do convidado usando o Inchamento. Configure a Memória de inicialização e
a Memória mínima no ou acima do valor recomendado para a distribuição.

12. Para habilitar a infraestrutura de KVP (par chave/valor), instale o pacote rpm hypervkvpd ou hyperv-daemons do RHEL ISO. Como
alternativa, o pacote pode ser instalado diretamente de repositórios do RHEL.

13. A infraestrutura de KVP pode não funcionar corretamente sem uma atualização de software do Linux. Entre em contato com seu
fornecedor de distribuição para obter a atualização de software caso você veja problemas com esse recurso.

14. Nas máquinas virtuais Windows Server 2012 R2 Geração 2, as máquinas virtuais têm uma inicialização segura habilitada por padrão e
algumas máquinas virtuais Linux não serão inicializadas a menos que essa opção seja desabilitada. Você pode desabilitar a
inicialização segura na seção Firmware das configurações da máquina virtual no Gerenciador do Hyper-V ou usando o PowerShell:

Powershell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

O download dos Serviços de Integração do Linux pode ser aplicado a VMs da Geração 2 existentes, mas não fornece a funcionalidade
da Geração 2.

15. No Red Hat Enterprise Linux ou CentOS 5.2, 5.3 e 5.4, a funcionalidade de congelamento do sistema de arquivos não está disponível,
portanto, o backup de máquina virtual dinâmico também não está disponível.

16. No RHEL 7.6, o suporte para >256 vcpus está disponível no kernel 3.10.0-957.38.1 ou posterior e o kernel 3.10.0-1062.4.1 ou posterior
é necessário para o RHEL 7.7.

17. O RHEL 8.5 exige o Windows Server 2019 ou mais recente ou o Azure Stack HCI 20H2 ou mais recente.

Consulte Também

Set-VMFirmware

Máquinas virtuais do Debian com suporte no Hyper-V

Máquinas virtuais Oracle Linux com suporte no Hyper-V

Máquinas virtuais SUSE com suporte no Hyper-V

Máquinas virtuais Ubuntu com suporte no Hyper-V

Máquinas virtuais do FreeBSD compatíveis com o Hyper-V

Descrições de recursos para máquinas virtuais do Linux e do FreeBSD no Hyper-V

Melhores práticas para executar o Linux no Hyper-V

Certificação de Hardware do Red Hat

Máquinas virtuais do Debian com
suporte no Hyper-V
Artigo • 26/09/2023

Aplica-se a: Azure Stack HCI, Windows Server 2022, Windows Server 2019, Hyper-V
Server 2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2,
Hyper-V Server 2012 R2, Windows 10, Windows 8.1

Este artigo descreve o suporte oferecido para VMs (máquinas virtuais) do Debian no
Hyper-V.

Legenda da tabela
O mapa de distribuição de recursos a seguir indica os recursos que estão presentes em
cada versão do Windows Server. Os problemas conhecidos e as soluções alternativas
para cada distribuição são listados após a tabela.

Interno – Os LIS (Serviços de Integração do Linux) estão incluídos como parte

dessa distribuição do Linux. O pacote de download do LIS fornecido pela Microsoft
não funciona para essa distribuição. Não instale o pacote da Microsoft. Os
números de versão do módulo de kernel para os LIS internos (conforme mostrado
pelo lsmod, por exemplo) são diferentes do número de versão no pacote de
download dos LIS fornecidos pela Microsoft. Uma incompatibilidade não indica
que o LIS interno está desatualizado.

✔ – Recurso disponível

(em branco) – Recurso não disponível

Recurso Versão do 11 (Bullseye) 10.0-10.3

Windows Server (Buster)

Disponibilidade Interno Interno

Básico 2019, 2016, 2012 ✔ ✔

R2

Hora Precisa do Windows Server 2016 2019, 2016 ✔ ✔ Observação

Observação 4 4

Rede
Recurso Versão do 11 (Bullseye) 10.0-10.3
Windows Server (Buster)

Quadros jumbo 2019, 2016, 2012 ✔ ✔

R2

Marcação e truncamento VLAN 2019, 2016, 2012 ✔ ✔

R2

Migração dinâmica 2019, 2016, 2012 ✔ ✔

R2

Injeção de IP estático 2019, 2016, 2012

R2

vRSS 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 4 4

Descarregamentos de segmentação e 2019, 2016, 2012 ✔ ✔ Observação

soma de verificação TCP R2 Observação 4 4

SR-IOV 2019, 2016 ✔ ✔ Observação

Observação 4 4

Storage

Redimensionamento do VHDX 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 1 1

Fibre Channel Virtual 2019, 2016, 2012

R2

Backup de máquina virtual ativa 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 2 2

Suporte ao TRIM 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 4 4

SCSI WWN 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 4 4

Memória

Suporte ao kernel de PAE 2019, 2016, 2012 ✔ ✔

R2

Configuração da lacuna de MMIO 2019, 2016, 2012 ✔ ✔

R2

Memória Dinâmica – Adição Dinâmica 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 4 4
Recurso Versão do 11 (Bullseye) 10.0-10.3
Windows Server (Buster)

Memória Dinâmica – Inchamento 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 4 4

Redimensionamento da memória de 2019, 2016 ✔ ✔ Observação

runtime Observação 4 4

Vídeo

Dispositivo de vídeo específico do Hyper- 2019, 2016, 2012 ✔ ✔

V R2

Diversos

Par chave-valor 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 2 2

Interrupção Não Mascarável 2019, 2016, 2012 ✔ ✔

R2

Cópia de arquivo do host para o 2019, 2016, 2012 ✔ ✔ Observação

convidado R2 Observação 2 2

Comando lsvmbus 2019, 2016, 2012

R2

Soquetes do Hyper-V 2019, 2016 ✔ ✔ Observação

Observação 4 4

Passagem de PCI/DDA 2019, 2016 ✔ ✔ Observação

Observação 4 4

Máquinas virtuais de 2ª geração

Inicialização por meio da UEFI 2019, 2016, 2012 ✔ ✔ Observação

R2 Observação 3 3

Inicialização Segura 2019, 2016 ✔ ✔

Observações
1. Não há suporte para a criação de sistemas de arquivos em VHDs maiores que 2 TB.

2. Do Debian 8.3 em diante, o pacote do Debian instalado manualmente "hyperv-

daemons" contém os daemons de VSS, par chave-valor e fcopy. No Debian 7.x e
8.0-8.2, o pacote hyperv-daemons deve vir de backports do Debian .
 3. Máquinas virtuais de 2ª geração do Windows Server 2012 R2 têm a inicialização
segura habilitada por padrão e algumas máquinas virtuais do Linux não são
inicializadas a menos que essa opção seja desabilitada. Você pode desabilitar a
inicialização segura na seção Firmware das configurações da máquina virtual no
Gerenciador do Hyper-V ou usando o PowerShell:

PowerShell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

4. As funcionalidades do kernel upstream mais recentes só estão disponíveis usando

os kernels disponíveis no repositório de backports do Debian .

5. Embora o Debian 7.x esteja sem suporte e use um kernel mais antigo, o kernel
incluído nos backports do Debian para Debian 7.x aprimorou os recursos do
Hyper-V.

Confira também
Máquinas virtuais CentOS e Red Hat Enterprise Linux com suporte no Hyper-V

Máquinas virtuais Oracle Linux com suporte no Hyper-V

Máquinas virtuais SLES (SUSE Linux Enterprise Server) com suporte no Hyper-V

Máquinas virtuais Debian com suporte no Hyper-V

Máquinas virtuais do FreeBSD compatíveis com o Hyper-V

Descrições de recursos para máquinas virtuais do Linux e do FreeBSD no Hyper-V

Melhores práticas para executar o Linux no Hyper-V

Máquinas virtuais Oracle Linux com suporte
no Hyper-V
Artigo • 27/09/2023

Aplica-se ao: Azure Stack HCI, Windows Server 2022, Windows Server 2019, Windows Server
2016, Hyper-V Server 2016, Windows Server 2012 R2, Hyper-V Server 2012 R2, Windows 10,
Windows 8.1

O mapa de distribuição de recursos a seguir indica os recursos que estão presentes em cada
versão. Os problemas conhecidos e as soluções alternativas para cada distribuição são listados
após a tabela.

Nesta seção:

Série Oracle Linux 9.x

Série Oracle Linux 8.x
Série Oracle Linux 7.x
Série Oracle Linux 6.x

Legenda da tabela
Interno – o LIS é incluído como parte dessa distribuição do Linux. Os números de versão do
módulo de kernel para o LIS interno (conforme mostrado pelo lsmod, por exemplo) são
diferentes do número de versão no pacote de download do LIS fornecido pela Microsoft.
Uma incompatibilidade não indica que o LIS interno está desatualizado.

✔ – Recurso disponível

(em branco) – Recurso não disponível

RHCK – Kernel compatível com Red Hat

UEK – UEK (Unbreakable Enterprise Kernel)

UEK4 – criado na versão 4.1.12 do Kernel do Linux de upstream
UEK5 – criado na versão 4.14 do Kernel do Linux de upstream
UEK6 – criado na versão 5.4 do Kernel do Linux de upstream

Série Oracle Linux 9.x

Recurso Versão do Windows 9.0 (RHCK)
Server

Disponibilidade

Básico 2019, 2016, 2012 R2 ✔

Recurso Versão do Windows 9.0 (RHCK)
Server

Hora Precisa do Windows Server 2016 2019, 2016 ✔

Rede

Quadros jumbo 2019, 2016, 2012 R2 ✔

Marcação e truncamento VLAN 2019, 2016, 2012 R2 ✔

Migração dinâmica 2019, 2016, 2012 R2 ✔

Injeção de IP estático 2019, 2016, 2012 R2 ✔ Observação 2

vRSS 2019, 2016, 2012 R2 ✔

Descarregamentos de segmentação e soma de verificação 2019, 2016, 2012 R2 ✔

TCP

SR-IOV 2019, 2016 ✔

Storage

Redimensionamento do VHDX 2019, 2016, 2012 R2 ✔

Fibre Channel Virtual 2019, 2016, 2012 R2 ✔ Observação 3

Backup de máquina virtual ativa 2019, 2016, 2012 R2 ✔ Observação 5

Suporte ao TRIM 2019, 2016, 2012 R2 ✔

SCSI WWN 2019, 2016, 2012 R2 ✔

Memória

Suporte ao kernel de PAE 2019, 2016, 2012 R2 N/D

Configuração da lacuna de MMIO 2019, 2016, 2012 R2 ✔

Memória Dinâmica – Adição Dinâmica 2019, 2016, 2012 R2 ✔ Observação 7, 8,

9

Memória Dinâmica – Inchamento 2019, 2016, 2012 R2 ✔ Observação 7, 8,

9

Redimensionamento da memória de runtime 2019, 2016 ✔

Vídeo

Dispositivo de vídeo específico do Hyper-V 2019, 2016, 2012 R2 ✔

Diversos

Par chave-valor 2019, 2016, 2012 R2 ✔

Interrupção Não Mascarável 2019, 2016, 2012 R2 ✔

Cópia de arquivo do host para o convidado 2019, 2016, 2012 R2 ✔

Recurso Versão do Windows 9.0 (RHCK)
Server

Comando lsvmbus 2019, 2016, 2012 R2 ✔

Soquetes do Hyper-V 2019, 2016 ✔

Passagem de PCI/DDA 2019, 2016 ✔

Máquinas virtuais de 2ª geração

Inicialização por meio da UEFI 2019, 2016, 2012 R2 ✔ Observação 12

Inicialização Segura 2019, 2016 ✔

Série Oracle Linux 8.x

Recurso Versão do Windows 8.0-8.5 (RHCK)
Server

Disponibilidade

Básico 2019, 2016, 2012 R2 ✔

Hora Precisa do Windows Server 2016 2019, 2016 ✔

Rede

Quadros jumbo 2019, 2016, 2012 R2 ✔

Marcação e truncamento VLAN 2019, 2016, 2012 R2 ✔

Migração dinâmica 2019, 2016, 2012 R2 ✔

Injeção de IP estático 2019, 2016, 2012 R2 ✔ Observação 2

vRSS 2019, 2016, 2012 R2 ✔

Descarregamentos de segmentação e soma de verificação 2019, 2016, 2012 R2 ✔

TCP

SR-IOV 2019, 2016 ✔

Storage

Redimensionamento do VHDX 2019, 2016, 2012 R2 ✔

Fibre Channel Virtual 2019, 2016, 2012 R2 ✔ Observação 3

Backup de máquina virtual ativa 2019, 2016, 2012 R2 ✔ Observação 5

Suporte ao TRIM 2019, 2016, 2012 R2 ✔

SCSI WWN 2019, 2016, 2012 R2 ✔

Memória
 Recurso Versão do Windows 8.0-8.5 (RHCK)
Server

Suporte ao kernel de PAE 2019, 2016, 2012 R2 N/D

Configuração da lacuna de MMIO 2019, 2016, 2012 R2 ✔

Memória Dinâmica – Adição Dinâmica 2019, 2016, 2012 R2 ✔ Observação 7, 8,

9

Memória Dinâmica – Inchamento 2019, 2016, 2012 R2 ✔ Observação 7, 8,

9

Redimensionamento da memória de runtime 2019, 2016 ✔

Vídeo

Dispositivo de vídeo específico do Hyper-V 2019, 2016, 2012 R2 ✔

Diversos

Par chave-valor 2019, 2016, 2012 R2 ✔

Interrupção Não Mascarável 2019, 2016, 2012 R2 ✔

Cópia de arquivo do host para o convidado 2019, 2016, 2012 R2 ✔

Comando lsvmbus 2019, 2016, 2012 R2 ✔

Soquetes do Hyper-V 2019, 2016 ✔

Passagem de PCI/DDA 2019, 2016 ✔

Máquinas virtuais de 2ª geração

Inicialização por meio da UEFI 2019, 2016, 2012 R2 ✔ Observação 12

Inicialização Segura 2019, 2016 ✔

Série Oracle Linux 7.x

Esta série tem apenas kernels de 64 bits.

Recurso Versão 7.5-7.8 7.3-7.4

do
Windows
RHCK UEK5 RHCK UEK4
Server

Disponibilidade LIS 4.3 Interno Interno LIS 4.3 Interno Interno

Básico 2019, ✔ ✔ ✔ ✔ ✔ ✔
2016,
2012 R2

Hora Precisa do 2019, ✔ ✔

Windows Server 2016
2016

Rede

Quadros jumbo 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2

Marcação e 2019, ✔ ✔ ✔ ✔ ✔ ✔
truncamento VLAN 2016,
2012 R2

Migração dinâmica 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2

Injeção de IP 2019, ✔ ✔ ✔ ✔ ✔ ✔
estático 2016, Observação Observação Observação Observação Observação Observação
2012 R2 2 2 2 2 2 2

vRSS 2019, ✔ ✔ ✔ ✔ ✔ ✔
2016,
2012 R2

Descarregamentos 2019, ✔ ✔ ✔ ✔ ✔ ✔
de segmentação e 2016,
soma de verificação 2012 R2
TCP

SR-IOV 2019, ✔ ✔ ✔ ✔ ✔ ✔
2016

Storage

Redimensionamento 2019, ✔ ✔ ✔ ✔ ✔ ✔
do VHDX 2016,
2012 R2

Fibre Channel 2019, ✔ ✔ ✔ ✔ ✔ ✔

Virtual 2016, Observação Observação Observação Observação Observação Observação
2012 R2 3 3 3 3 3 3

Backup de máquina 2019, ✔ ✔ ✔ ✔ ✔ ✔

virtual ativa 2016, Observação Observação Observação Observação Observação Observação
2012 R2 5 4,5 5 5 4,5 5

Suporte ao TRIM 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2

SCSI WWN 2019, ✔ ✔ ✔ ✔ ✔

2016,
2012 R2

Memória
Suporte ao kernel 2019, N/D N/D N/D N/D N/D N/D
de PAE 2016,
2012 R2

Configuração da 2019, ✔ ✔ ✔ ✔ ✔ ✔
lacuna de MMIO 2016,
2012 R2

Inclusão automática 2019, ✔ ✔ ✔ ✔ ✔ ✔

da Memória 2016, Observação Observação Observação Observação Observação Observação
Dinâmica 2012 R2 7,8,9 8,9 8,9 8,9 8,9 8,9

Inchamento da 2019, ✔ ✔ ✔ ✔ ✔ ✔
Memória Dinâmica 2016, Observação Observação Observação Observação Observação Observação
2012 R2 7,8,9 8,9 8,9 8,9 8,9 8,9

Redimensionamento 2019, ✔ ✔ ✔
da memória de 2016
runtime

Vídeo

Vídeo específico do 2019, ✔ ✔ ✔ ✔ ✔ ✔

Hyper-V 2016,
2012 R2

Diversos

Par chave-valor 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2

Interrupção Não 2019, ✔ ✔ ✔ ✔ ✔ ✔

Mascarável 2016,
2012 R2

Cópia de arquivo do 2019, ✔ ✔ ✔ ✔ ✔ ✔

host para o 2016,
convidado 2012 R2

Comando lsvmbus 2019, ✔ ✔ ✔ ✔

2016,
2012 R2

Soquetes do Hyper- 2019, ✔ ✔ ✔ ✔

V 2016

Passagem de 2019, ✔ ✔ ✔ ✔ ✔ ✔
PCI/DDA 2016

Máquinas virtuais
de 2ª geração

Inicialização por 2019, ✔ ✔ ✔ ✔ ✔ ✔

meio da UEFI 2016, Observação Observação Observação Observação Observação Observação
2012 R2 12 12 12 12 12 12
 Inicialização Segura 2019, ✔ ✔ ✔ ✔ ✔ ✔
2016,
2012 R2

Série Oracle Linux 6.x

Esta série tem apenas kernels de 64 bits.

Recurso Versão do Windows 6.8-6.10 (RHCK) 6.8-6.10 (UEK4)

Server

Disponibilidade LIS 4.3 Interno

Básico 2019, 2016, 2012 R2 ✔ ✔

Hora Precisa do Windows Server 2016 2019, 2016

Rede

Quadros jumbo 2019, 2016, 2012 R2 ✔ ✔

Marcação e truncamento VLAN 2019, 2016, 2012 R2 ✔ Observação 1 ✔ Observação 1

Migração dinâmica 2019, 2016, 2012 R2 ✔ ✔

Injeção de IP estático 2019, 2016, 2012 R2 ✔ Observação 2 ✔

vRSS 2019, 2016, 2012 R2 ✔ ✔

Descarregamentos de segmentação e soma de 2019, 2016, 2012 R2 ✔ ✔

verificação TCP

SR-IOV 2019, 2016

Storage

Redimensionamento do VHDX 2019, 2016, 2012 R2 ✔ ✔

Fibre Channel Virtual 2019, 2016, 2012 R2 ✔ Observação 3 ✔ Observação 3

Backup de máquina virtual ativa 2019, 2016, 2012 R2 ✔ Observação 5 ✔ Observação 5

Suporte ao TRIM 2019, 2016, 2012 R2 ✔ ✔

SCSI WWN 2019, 2016, 2012 R2 ✔ ✔

Memória

Suporte ao kernel de PAE 2019, 2016, 2012 R2 N/D N/D

Configuração da lacuna de MMIO 2019, 2016, 2012 R2 ✔ ✔

Memória Dinâmica – Adição Dinâmica 2019, 2016, 2012 R2 ✔ Observação 6, ✔ Observação 6,

8, 9 8, 9

Memória Dinâmica – Inchamento 2019, 2016, 2012 R2 ✔ Observação 6, ✔ Observação 6,

Recurso Versão do Windows 6.8-6.10 (RHCK) 6.8-6.10 (UEK4)
Server

8, 9 8, 9

Redimensionamento da memória de runtime 2019, 2016

Vídeo

Dispositivo de vídeo específico do Hyper-V 2019, 2016, 2012 R2 ✔ ✔

Diversos

Par chave-valor 2019, 2016, 2012 R2 ✔ Observação ✔ Observação

10,11 10,11

Interrupção Não Mascarável 2019, 2016, 2012 R2 ✔ ✔

Cópia de arquivo do host para o convidado 2019, 2016, 2012 R2 ✔ ✔

Comando lsvmbus 2019, 2016, 2012 R2 ✔ ✔

Soquetes do Hyper-V 2019, 2016 ✔ ✔

Passagem de PCI/DDA 2019, 2016 ✔ ✔

Máquinas virtuais de 2ª geração

Inicialização por meio da UEFI 2019, 2016, 2012 R2 ✔ Observação 12 ✔ Observação 12

Inicialização Segura 2019, 2016

Observações
1. Para esta versão do Oracle Linux, a marcação de VLAN funciona, mas o tronco de VLAN não
funciona.

2. A injeção de IP estático talvez não funcione se o Gerenciador de Rede foi configurado para
um determinado adaptador de rede sintético na máquina virtual. Para um bom
funcionamento da injeção de IP estático, verifique se o Gerenciador de Rede está
completamente desativado ou foi desativado para um adaptador de rede específico por meio
de seu arquivo ifcfg-ethX.

3. No Windows Server 2012 R2, ao usar dispositivos de fibre channel virtuais, verifique se o LUN
0 (número de unidade lógica 0) foi preenchido. Se o LUN 0 não tiver sido preenchido, uma
máquina virtual Linux talvez não possa montar dispositivos de fibre channel nativamente.

4. Para LIS interno, o pacote "hyperv-daemons" deve ser instalado para essa funcionalidade.

5. Caso haja identificadores de arquivos abertos durante uma operação de backup de máquina
virtual dinâmica, em alguns casos extremos, os VHDs de backup podem passar por uma fsck
(verificação de consistência do sistema de arquivos) na restauração. As operações de backup
em tempo real poderão falhar silenciosamente se a máquina virtual tiver um dispositivo iSCSI
 anexado ou armazenamento conectado diretamente (também conhecido como disco de
passagem).

6. O suporte à memória dinâmica só está disponível em máquinas virtuais de 64 bits.

7. O suporte à inclusão automática não está habilitado por padrão nesta distribuição. Para
habilitar o suporte à inclusão automática, você precisa adicionar uma regra udev em
/etc/udev/rules.d/ da seguinte maneira:

a. Crie um arquivo /etc/udev/rules.d/[Link]. Você pode usar qualquer outro

nome desejado para o arquivo.

b. Adicione o seguinte conteúdo ao arquivo: SUBSYSTEM=="memory", ACTION=="add",

ATTR{state}="online"

c. Reinicialize o sistema para habilitar o suporte à inclusão automática.

Embora o download dos Serviços de Integração do Linux crie essa regra na instalação, a regra
também é removida quando o LIS é desinstalado. Portanto, a regra deverá ser recriada se a
memória dinâmica for necessária após a desinstalação.

8. As operações de memória dinâmica poderão falhar se o sistema operacional convidado

estiver com pouca memória. Estas são algumas práticas recomendadas:

A memória de inicialização e a memória mínima devem ser iguais ou maiores que a

quantidade de memória recomendada pelo fornecedor de distribuição.

Os aplicativos que tendem a consumir toda a memória disponível em um sistema estão

limitados a consumir até 80% da RAM disponível.

9. Se você estiver usando Memória Dinâmica em um sistema operacional Windows Server 2016
ou Windows Server 2012 R2, especifique os parâmetros de Memória de inicialização,
Memória mínima e Memória máxima em múltiplos de 128 megabytes (MB). Se isso não for
feito, haverá falhas de adição automática e talvez você não veja nenhum aumento de
memória em um sistema operacional convidado.

10. Para habilitar a infraestrutura de KVP (par chave/valor), instale o pacote rpm hypervkvpd ou
hyperv-daemons do Oracle Linux ISO. Como alternativa, o pacote pode ser instalado
diretamente de repositórios Oracle Linux Yum.

11. A infraestrutura de KVP (par chave/valor) pode não funcionar corretamente sem uma
atualização de software do Linux. Entre em contato com seu fornecedor de distribuição para
obter a atualização de software caso você veja problemas com esse recurso.

12. Nas máquinas virtuais Windows Server 2012 R2 Geração 2, as máquinas virtuais têm uma
inicialização segura habilitada por padrão e algumas máquinas virtuais Linux não serão
inicializadas a menos que essa opção seja desabilitada. Você pode desabilitar a inicialização
segura na seção Firmware das configurações da máquina virtual no Gerenciador do Hyper-V
ou usando o PowerShell:
 Powershell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

O download dos Serviços de Integração do Linux pode ser aplicado a VMs da Geração 2
existentes, mas não fornece a funcionalidade da Geração 2.

Consulte Também

Set-VMFirmware

Máquinas virtuais CentOS e Red Hat Enterprise Linux com suporte no Hyper-V

Máquinas virtuais do Debian com suporte no Hyper-V

Máquinas virtuais SUSE com suporte no Hyper-V

Máquinas virtuais Ubuntu com suporte no Hyper-V

Máquinas virtuais do FreeBSD compatíveis com o Hyper-V

Descrições de recursos para máquinas virtuais do Linux e do FreeBSD no Hyper-V

Melhores práticas para executar o Linux no Hyper-V

Máquinas virtuais SLES (SUSE Linux Enterprise Server) com
suporte no Hyper-V
Artigo • 28/11/2023

Aplica-se a: Azure Stack HCI, Windows Server 2022, Windows Server 2019, Hyper-V Server 2019, Windows Server 2016, Hyper-V
Server 2016, Windows Server 2012 R2, Hyper-V Server 2012 R2, Windows 10, Windows 8.1

Veja a seguir um mapa de distribuição de recursos que indica os recursos de cada versão. Os problemas conhecidos e as soluções
alternativas para cada distribuição são listados após a tabela.

Os drivers internos do SUSE Linux Enterprise Service para Hyper-V são certificados pelo SUSE. Um exemplo de configuração pode ser
exibido neste boletim: Boletim de Certificação SUSE YES .

Legenda da tabela
Interno – O LIS está incluído como parte dessa distribuição do Linux. O pacote de download do LIS fornecido pela Microsoft
não funciona para essa distribuição. Portanto, não o instale. Os números de versão do módulo de kernel para o LIS interno
(conforme mostrado pelo lsmod, por exemplo) são diferentes do número de versão no pacote de download do LIS fornecido
pela Microsoft. Uma incompatibilidade não indica que o LIS interno está desatualizado.

✔ – Recurso disponível

(em branco) – Recurso não disponível

O SLES12+ tem apenas 64 bits.

Recurso Versão do sistema SLES 15 SP1- SLES 15 SLES 12 SP3- SLES 12 SP2 SLES 12 SP1 SLES 11 SP4 SLES 11 SP3
operacional SP4 SP5

Disponibilidade Interno Interno Interno Interno Interno Interno Interno

Básico WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
2022,2019,2016,2012
Azure Stack HCI

Hora Precisa do WS/Hyper-V ✔ ✔ ✔ ✔

Windows Server 2022,2019,2016
2016

Rede

Quadros jumbo WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI

Marcação e WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
truncamento VLAN 2022,2019,2016,2012
Azure Stack HCI

Migração ao vivo WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI

Injeção de IP WS/Hyper-V ✔Observação ✔Observação ✔Observação ✔Observação ✔Observação ✔Observação ✔Observação

estático 2022,2019,2016,2012 1 1 1 1 1 1 1
Azure Stack HCI

vRSS WS/Hyper-V ✔ ✔ ✔ ✔ ✔
2022,2019,2016,2012
Azure Stack HCI

Descarregamentos WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔
de segmentação e 2022,2019,2016,2012
soma de verificação Azure Stack HCI
TCP
Recurso Versão do sistema SLES 15 SP1- SLES 15 SLES 12 SP3- SLES 12 SP2 SLES 12 SP1 SLES 11 SP4 SLES 11 SP3
operacional SP4 SP5

SR-IOV WS/Hyper-V ✔ ✔ ✔ ✔
2022,2019,2016,2012
Azure Stack HCI

Storage

Redimensionamento WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
do VHDX 2022,2019,2016,2012
Azure Stack HCI

Fibre Channel WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

Virtual 2022,2019,2016,2012
Azure Stack HCI

Backup de máquina WS/Hyper-V ✔ ✔Observação ✔ ✔ ✔ ✔ ✔

virtual ativa 2022,2019,2016,2012 Observação 2,3,8 Observação Observação Observação Observação Observação
Azure Stack HCI 2,3,8 2,3,8 2,3,8 2,3,8 2,3,8 2,3,8

Suporte ao TRIM WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI

SCSI WWN WS/Hyper-V ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI

Memória

Suporte ao kernel WS/Hyper-V N/D N/D N/D N/D N/D ✔ ✔

de PAE 2022,2019,2016,2012
Azure Stack HCI

Configuração da WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
lacuna de MMIO 2022,2019,2016,2012
Azure Stack HCI

Memória Dinâmica WS/Hyper-V ✔ ✔Observação ✔ ✔ ✔ ✔ ✔

– Adição Dinâmica 2022,2019,2016,2012 Observação 6 Observação Observação Observação Observação Observação
Azure Stack HCI 6 6 6 6 4,5,6 4,5,6

Memória Dinâmica WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

– Inchamento 2022,2019,2016,2012 Observação Observação Observação Observação Observação Observação Observação
Azure Stack HCI 6 6 6 6 6 4,5,6 4,5,6

Redimensionamento WS/Hyper-V ✔ ✔ ✔ ✔
da memória de 2022,2019,2016 Observação Observação Observação Observação
runtime 6 6 6 6

Vídeo

Dispositivo de vídeo WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

específico do 2022,2019,2016,2012
Hyper-V Azure Stack HCI

Diversos

Pares chave/valor WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012 Observação Observação
Azure Stack HCI 7 7

Interrupção Não WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

Mascarável 2022,2019,2016,2012
Azure Stack HCI

Cópia de arquivo do WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

host para o 2022,2019,2016,2012
convidado Azure Stack HCI

Comando lsvmbus WS/Hyper-V ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI
Recurso Versão do sistema SLES 15 SP1- SLES 15 SLES 12 SP3- SLES 12 SP2 SLES 12 SP1 SLES 11 SP4 SLES 11 SP3
operacional SP4 SP5

Soquetes do Hyper- WS/Hyper-V ✔ ✔ ✔

V 2022,2019,2016

Passagem de WS/Hyper-V ✔ ✔ ✔ ✔ ✔
PCI/DDA 2022,2019,2016

Máquinas virtuais
de 2ª geração

Inicialização por WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

meio da UEFI 2022,2019,2016,2012 Observação Observação Observação Observação Observação Observação
Azure Stack HCI 9 9 9 9 9 9

Inicialização Segura WS/Hyper-V ✔ ✔ ✔ ✔ ✔

2022,2019,2016

Observações
1. A injeção de IP estático pode não funcionar se o Gerenciador de Rede tiver sido configurado para um determinado adaptador
de rede específico do Hyper-V na máquina virtual, pois pode substituir as configuração de IP estático que foram configuradas
manualmente. Para garantir o funcionamento tranquilo da injeção de IP estático, verifique se o Gerenciador de Rede está
completamente desativado ou foi desativado para um adaptador de rede específico por meio de seu arquivo ifcfg-ethX.

2. Se houver identificadores de arquivo abertos durante uma operação de backup de máquina virtual dinâmica, em alguns casos
extremos, os VHDs de backup podem passar por uma fsck (verificação de consistência do sistema de arquivos) na restauração.

3. As operações de backup dinâmicas poderão falhar silenciosamente se a máquina virtual tiver um dispositivo iSCSI conectado ou
um armazenamento diretamente conectado (também conhecido como disco de passagem).

4. As operações de memória dinâmica podem falhar se o sistema operacional convidado estiver funcionando com pouca
memória. Estas são algumas práticas recomendadas:

A memória de inicialização e a memória mínima devem ser iguais ou maiores que a quantidade de memória recomendada
pelo fornecedor de distribuição.

Os aplicativos que tendem a consumir toda a memória disponível em um sistema estão limitados a consumir até 80% da
RAM disponível.

5. O suporte à memória dinâmica só está disponível em máquinas virtuais de 64 bits.

6. Se você estiver usando Memória Dinâmica nos sistemas operacionais do Windows Server 2016 ou do Windows Server 2012,
especifique os parâmetros de Memória de inicialização, Memória mínima e Memória máxima em múltiplos de 128 megabytes
(MB). Se isso não for feito, haverá falhas da inclusão automática e você pode não perceber nenhum aumento de memória em
um sistema operacional convidado.

7. No Windows Server 2016 ou no Windows Server 2012 R2, a infraestrutura de par chave/valor pode não funcionar corretamente
sem uma atualização de software do Linux. Entre em contato com seu fornecedor de distribuição para obter a atualização de
software caso você encontre problemas com esse recurso.

8. O backup do VSS falhará, se uma única partição for montada várias vezes.

9. As máquinas virtuais de segunda geração do Windows Server 2012 R2 têm a inicialização segura habilitada por padrão e as
máquinas virtuais de segunda geração do Linux não serão inicializadas a menos que essa opção seja desabilitada. Você pode
desabilitar a inicialização segura na seção Firmware das configurações da máquina virtual no Gerenciador do Hyper-V ou
usando o PowerShell:

Powershell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

Consulte Também
Set-VMFirmware

Máquinas virtuais CentOS e Red Hat Enterprise Linux com suporte no Hyper-V

Máquinas virtuais do Debian com suporte no Hyper-V

Máquinas virtuais do Oracle Linux com suporte no Hyper-V

Máquinas virtuais do Ubuntu com suporte no Hyper-V

Máquinas virtuais do FreeBSD compatíveis com o Hyper-V

Descrições de recursos para máquinas virtuais do Linux e do FreeBSD no Hyper-V

Melhores práticas para executar o Linux no Hyper-V

Máquinas virtuais Debian com suporte
no Hyper-V
Artigo • 30/10/2023

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server
2019, Hyper-V Server 2019, Windows Server 2016, Hyper-V Server 2016, Windows
Server 2012 R2, Hyper-V Server 2012 R2, Windows 10, Windows 8.1

O mapa de distribuição de recursos a seguir indica os recursos de cada versão. Os

problemas conhecidos e as soluções alternativas para cada distribuição são listados
após a tabela.

Legenda da tabela
Interno – o LINS (Linux Integration Services) está incluído como parte dessa
distribuição do Linux. O pacote de download LIS fornecido pela Microsoft não
funciona para essa distribuição, portanto, não o instale. Os números de versão do
módulo de kernel para o LIS interno (conforme mostrado pelo lsmod, por
exemplo) são diferentes do número de versão no pacote de download LIS
fornecido pela Microsoft. Uma incompatibilidade não indica que o LIS interno está
desatualizado.

✔ – Recurso disponível

(em branco) – Recurso não disponível

Recurso Versão do 22.04 LTS 20.04 LTS 18.04 LTS 16.04 LTS
sistema
operacional
Windows
Server

Disponibilidade Interno Interno Interno Interno

Básico 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012
R2

Hora Precisa do 2022, 2019, ✔ ✔ ✔ ✔

Windows Server 2016 2016

Rede
Recurso Versão do 22.04 LTS 20.04 LTS 18.04 LTS 16.04 LTS
sistema
operacional
Windows
Server

Quadros jumbo 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012
R2

Marcação e 2022, 2019, ✔ ✔ ✔ ✔

truncamento VLAN 2016, 2012
R2

Migração ao vivo 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012
R2

Injeção de IP estático 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012 Observação Observação Observação Observação
R2 1 1 1 1

vRSS 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012
R2

Descarregamentos de 2022, 2019, ✔ ✔ ✔ ✔

segmentação e soma 2016, 2012
de verificação TCP R2

SR-IOV 2022, 2019, ✔ ✔ ✔ ✔

2016

Storage

Redimensionamento 2022, 2019, ✔ ✔ ✔ ✔

do VHDX 2016, 2012
R2

Fibre Channel Virtual 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012 Observação Observação Observação Observação
R2 2 2 2 2

Backup de máquina 2022, 2019, ✔ ✔ ✔ ✔

virtual ativa 2016, 2012 Observação Observação Observação Observação
R2 3, 4, 5 3, 4, 5 3, 4, 5 3, 4, 5

Suporte ao TRIM 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012
R2
Recurso Versão do 22.04 LTS 20.04 LTS 18.04 LTS 16.04 LTS
sistema
operacional
Windows
Server

SCSI WWN 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012
R2

Memória

Suporte ao kernel de 2022, 2019, ✔ ✔ ✔ ✔

PAE 2016, 2012
R2

Configuração da 2022, 2019, ✔ ✔ ✔ ✔

lacuna de MMIO 2016, 2012
R2

Memória Dinâmica – 2022, 2019, ✔ ✔ ✔ ✔

Adição Dinâmica 2016, 2012 Observação Observação Observação Observação
R2 6, 7, 8 6, 7, 8 6, 7, 8 6, 7, 8

Memória Dinâmica – 2022, 2019, ✔ ✔ ✔ ✔

Inchamento 2016, 2012 Observação Observação Observação Observação
R2 6, 7, 8 6, 7, 8 6, 7, 8 6, 7, 8

Redimensionamento 2022, 2019, ✔ ✔ ✔ ✔

da memória de 2016
runtime

Vídeo

Dispositivo de vídeo 2022, 2019, ✔ ✔ ✔ ✔

específico do Hyper-V 2016, 2012
R2

Diversos

Pares chave/valor 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012 Observação Observação Observação Observação
R2 5, 9 5, 9 5, 9 5, 9

Interrupção Não 2022, 2019, ✔ ✔ ✔ ✔

Mascarável 2016, 2012
R2

Cópia de arquivo do 2022, 2019, ✔ ✔ ✔ ✔

host para o convidado 2016, 2012
R2
Recurso Versão do 22.04 LTS 20.04 LTS 18.04 LTS 16.04 LTS
sistema
operacional
Windows
Server

Comando lsvmbus 2022, 2019, ✔ ✔ ✔ ✔

2016, 2012
R2

Soquetes do Hyper-V 2022, 2019, ✔ ✔ ✔ ✔

2016

Passagem de PCI/DDA 2022, 2019, ✔ ✔ ✔ ✔

2016

Máquinas virtuais de
2ª geração

Inicialização por meio 2022, 2019, ✔ ✔ ✔ ✔

da UEFI 2016, 2012 Observação Observação Observação
R2 10, 11 10, 11 10, 11

Inicialização Segura 2022, 2019, ✔ ✔ ✔ ✔

2016

Observações
1. A injeção de IP estático pode não funcionar se o Gerenciador de Rede tiver sido
configurado para um determinado adaptador de rede específico do Hyper-V na
máquina virtual, pois pode substituir as configuração de IP estático que foram
configuradas manualmente. Para garantir o funcionamento tranquilo da injeção de
IP estático, verifique se o Gerenciador de Rede está completamente desativado ou
foi desativado para um adaptador de rede específico por meio de seu arquivo
ifcfg-ethX.

2. Ao usar dispositivos de canal de fibra virtual, verifique se o número de unidade

lógica 0 (LUN 0) foi preenchido. Se o LUN 0 não tiver sido preenchido, uma
máquina virtual do Linux talvez não consiga montar os dispositivos de canal de
fibra nativamente.

3. Se houver identificadores de arquivo abertos durante uma operação de backup de

máquina virtual dinâmica, em alguns casos de canto, os VHDs de backup talvez
precisem passar por uma verificação de consistência do sistema de arquivos ( fsck )
na restauração.
 4. As operações de backup em tempo real poderão falhar silenciosamente se a
máquina virtual tiver um dispositivo iSCSI anexado ou armazenamento conectado
diretamente (também conhecido como disco de passagem).

5. Em versões de LTS (suporte a longo prazo), use o kernel HWE (Habilitação de

Hardware Virtual) mais recente para o Linux Integration Services atualizado.

Para instalar o kernel ajustado pelo Azure em 16.04, 18.04 e 20.04, execute os
seguintes comandos como raiz (ou sudo):

Bash

# apt-get update
# apt-get install linux-azure

6. O suporte à memória dinâmica só está disponível em máquinas virtuais de 64 bits.

7. As operações de Memória Dinâmica poderão falhar se o sistema operacional

convidado estiver com pouca memória. Estas são algumas práticas recomendadas:

A memória de inicialização e a memória mínima devem ser iguais ou maiores

que a quantidade de memória recomendada pelo fornecedor de distribuição.

Os aplicativos que tendem a consumir toda a memória disponível em um

sistema estão limitados a consumir até 80% da RAM disponível.

8. Se você estiver usando a Memória Dinâmica nos sistemas operacionais Windows

Server 2019, Windows Server 2016 ou Windows Server 2012/2012 R2, especifique
os parâmetros de Memória de inicialização, Memória mínima e Memória máxima
em múltiplos de 128 MB (megabytes). Não fazer isso pode levar a falhas de Hot-
Add e talvez você não veja nenhum aumento de memória em um sistema
operacional convidado.

9. No Windows Server 2019, no Windows Server 2016 ou no Windows Server 2012

R2, a infraestrutura de par chave/valor pode não funcionar corretamente sem uma
atualização de software do Linux. Entre em contato com o fornecedor de
distribuição para obter a atualização de software caso você veja problemas com
esse recurso.

10. As máquinas virtuais da 2ª Geração do Windows Server 2012 R2 têm a inicialização

segura habilitada por padrão, e algumas máquinas virtuais do Linux não serão
inicializadas, a menos que essa opção seja desabilitada. Você pode desabilitar a
inicialização segura na seção Firmware das configurações da máquina virtual no
Gerenciador do Hyper-V ou usando o PowerShell:
 Powershell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

11. Antes de tentar copiar o VHD de uma máquina virtual VHD de Geração 2 para criar
máquinas virtuais de Geração 2, siga estas etapas:

a. Faça logon na máquina virtual de Geração 2.

b. Mude para o diretório boot do EFI:

Bash

# cd /boot/efi/EFI

c. Copie o diretório ubuntu para um novo diretório chamado boot:

Bash

# sudo cp -r ubuntu/ boot

d. Mude para o diretório boot recém-criado:

Bash

# cd boot

e. Renomeie o arquivo [Link]:

Bash

# sudo mv [Link] [Link]

12. Para executar migrações ao vivo nas VMs configuradas na 2ª Geração, a opção
Migrar para um computador físico com uma versão de processador diferente
precisa estar habilitada em Processador>Compatibilidade nas configurações da VM.
Para saber mais, confira Modo de compatibilidade do processador no Hyper-V.

Confira também
Máquinas virtuais CentOS e Red Hat Enterprise Linux com suporte no Hyper-V

Máquinas virtuais do Debian com suporte no Hyper-V

Máquinas virtuais Oracle Linux com suporte no Hyper-V

Máquinas virtuais SUSE com suporte no Hyper-V

Descrições de recursos para máquinas virtuais do Linux e do FreeBSD no Hyper-V

Melhores práticas para executar o Linux no Hyper-V

Set-VMFirmware

Ubuntu 14.04 em uma VM de Geração 2 – Blog de Virtualização de Ben Armstrong

Máquinas virtuais do FreeBSD
compatíveis com o Hyper-V
Artigo • 27/09/2023

Aplica-se a: Azure Stack HCI, Windows Server 2022, Windows Server 2019, Hyper-V
Server 2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2,
Hyper-V Server 2012 R2, Windows 10, Windows 8.1

O mapa de distribuição de recursos a seguir indica os recursos de cada versão. Os

problemas conhecidos e as soluções alternativas para cada distribuição são listados
após a tabela.

Legenda da tabela
Interno – O BIS (FreeBSD Integration Service) está incluído como parte desta
versão do FreeBSD.

✔ – Recurso disponível

(em branco) – Recurso não disponível

Recurso Versão do 13.0-13.1 12.0-12.3 11.2-11.4 10.4

sistema
operacional
Windows
Server

Disponibilidade Interno Interno Interno Interno

Básico 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Hora Precisa do 2019, 2016 ✔ ✔ ✔

Windows Server 2016

Rede

Quadros jumbo 2019, 2016, ✔ ✔ ✔ ✔

2012 R2 Observação Observação Observação Observação
3 3 3 3

Marcação e 2019, 2016, ✔ ✔ ✔ ✔

truncamento VLAN 2012 R2
Recurso Versão do 13.0-13.1 12.0-12.3 11.2-11.4 10.4
sistema
operacional
Windows
Server

Migração ao vivo 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Injeção de IP estático 2019, 2016, ✔ ✔ ✔ ✔

2012 R2 Observação Observação Observação Observação
4 4 4 4

vRSS 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Descarregamentos de 2019, 2016, ✔ ✔ ✔ ✔

segmentação e soma 2012 R2
de verificação TCP

LRO 2019, 2016, ✔ ✔ ✔ ✔

(Descarregamento de 2012 R2
Recebimento Grande)

SR-IOV 2019, 2016 ✔ ✔ ✔ ✔

Storage Observação Observação1 Observação Observação

1 1 1

Redimensionamento 2019, 2016, ✔ ✔ ✔ ✔

do VHDX 2012 R2 Observação Observação Observação Observação
6 6 6 6

Fibre Channel Virtual 2019, 2016,

2012 R2

Backup de máquina 2019, 2016, ✔ ✔ ✔

virtual ativa 2012 R2

Suporte ao TRIM 2019, 2016, ✔ ✔ ✔

2012 R2

SCSI WWN 2019, 2016,

2012 R2

Memória

Suporte ao kernel de 2019, 2016,

PAE 2012 R2

Configuração da 2019, 2016, ✔ ✔ ✔ ✔

Recurso Versão do 13.0-13.1 12.0-12.3 11.2-11.4 10.4
sistema
operacional
Windows
Server

lacuna de MMIO 2012 R2

Memória Dinâmica – 2019, 2016,

Adição Dinâmica 2012 R2

Memória Dinâmica – 2019, 2016,

Inchamento 2012 R2

Redimensionamento 2019, 2016

da memória de
runtime

Vídeo

Dispositivo de vídeo 2019, 2016,

específico do Hyper-V 2012 R2

Diversos

Pares chave/valor 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Interrupção Não 2019, 2016, ✔ ✔ ✔ ✔

Mascarável 2012 R2

Cópia de arquivo do 2019, 2016,

host para o convidado 2012 R2

Comando lsvmbus 2019, 2016,

2012 R2

Soquetes do Hyper-V 2019, 2016

Passagem de PCI/DDA 2019, 2016 ✔ ✔ ✔

Máquinas virtuais de
2ª geração

Inicialização por meio 2019, 2016, ✔ ✔ ✔

da UEFI 2012 R2

Inicialização Segura 2019, 2016

Observações
 1. Sugira rotular dispositivos de disco para evitar o ROOT MOUNT ERROR durante
a inicialização.

2. Talvez a unidade de DVD virtual não seja reconhecida quando os drivers do BIS
forem carregados no FreeBSD 8.x e 9.x, a menos que você habilite o driver ATA
herdado por meio do comando a seguir.

sh

# echo ‘[Link].disk_enable=1' >> /boot/[Link]

# shutdown -r now

3. 9126 é o tamanho máximo de MTU com suporte.

4. Em um cenário de failover, não é possível definir um endereço IPv6 estático no

servidor de réplica. Em vez disso, use um endereço IPv4.

5. O KVP é fornecido pelas portas no FreeBSD 10.0. Confira as portas do FreeBSD

10.0 em [Link] para obter mais informações.

6. Para fazer com que o redimensionamento online do VHDX funcione corretamente

no FreeBSD 11.0, uma etapa manual especial é necessária para contornar um bug
GEOM que é corrigido na 11.0 e superior. Depois que o host redimensionar o disco
VHDX, abra o disco para gravação e execute “gpart recover”, conforme descrito a
seguir.

sh

# dd if=/dev/da1 of=/dev/da1 count=0

# gpart recover da1

Observações adicionais: a matriz de recursos da versões estáveis 10 e 11 é a mesma da

versão 11.1 do FreeBSD. Além disso, o FreeBSD 10.2 e as versões anteriores (10.1, 10.0,
9.x, 8.x) são o fim da vida útil. Veja aqui uma lista atualizada de versões compatíveis e
os avisos de segurança mais recentes.

Consulte Também
Descrições de recursos para máquinas virtuais do Linux e do FreeBSD no Hyper-V
Melhores práticas para executar o FreeBSD no Hyper-V
Descrições de recursos para máquinas
virtuais do Linux e do FreeBSD no
Hyper-V
Artigo • 27/09/2023

Aplica-se ao: Azure Stack HCI, Windows Server 2022, Windows Server 2019,
Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2, Hyper-V
Server 2012 R2, Windows Server 2012, Hyper-V Server 2012, Windows Server 2008
R2, Windows 10, Windows 8.1, Windows 8, Windows 7.1, Windows 7

Este artigo descreve os recursos disponíveis em componentes como núcleo, rede,

armazenamento e memória ao usar Linux e FreeBSD em uma máquina virtual.

Núcleo
Recurso Descrição

Desligamento integrado Com esse recurso, um administrador pode desligar máquinas

virtuais do Gerenciador do Hyper-V. Para obter mais informações,
consulte Desligamento do sistema operacional.

Sincronização da hora Esse recurso garante que o horário mantido dentro de uma
máquina virtual continue sincronizado com o horário mantido no
host. Para obter mais informações, consulte Sincronização de
horário.

Hora Precisa do Windows Esse recurso permite que o convidado use o recurso Tempo Preciso
Server 2016 do Windows Server 2016, melhorando a sincronização de horário
com o host para precisão de 1ms. Para obter mais informações,
consulte Tempo Preciso do Windows Server 2016

Suporte a Com esse recurso, uma máquina virtual pode usar vários
multiprocessamento processadores no host configurando várias CPUs virtuais.

Pulsação Com esse recurso, o host pode acompanhar o estado da máquina

virtual. Para saber mais, confira Pulsação.

Suporte integrado ao Com esse recurso, você pode usar um mouse na área de trabalho
mouse de uma máquina virtual e também usá-lo sem problemas entre a
área de trabalho do Windows Server e o console do Hyper-V para a
máquina virtual.
Recurso Descrição

Dispositivo de Esse recurso concede acesso de alto desempenho a dispositivos de

armazenamento específico armazenamento anexados a uma máquina virtual.
do Hyper-V

Dispositivo de rede Esse recurso concede acesso de alto desempenho a adaptadores

específico do Hyper-V de rede anexados a uma máquina virtual.

Rede
Recurso Descrição

Quadros jumbo Com esse recurso, um administrador pode aumentar o tamanho dos
quadros de rede além de 1500 bytes, o que leva a um aumento
significativo no desempenho da rede.

Marcação e truncamento Esse recurso permite configurar o tráfego de VLAN (LAN virtual)
VLAN para máquinas virtuais.

Migração dinâmica Com esse recurso, você pode migrar uma máquina virtual de um
host para outro. Para obter mais informações, consulte Visão geral
da Migração ao Vivo de máquina virtual.

Injeção de IP estático Com esse recurso, você pode replicar o endereço IP estático de uma
máquina virtual depois que ela tiver feito failover para sua réplica
em um host diferente. Essa replicação de IP garante que as cargas
de trabalho de rede continuem funcionando perfeitamente após um
evento de failover.

vRSS (RSS Virtual) Distribui a carga de um adaptador de rede virtual entre vários
processadores virtuais em uma máquina virtual. Para obter mais
informações, consulte RSS Virtual no Windows Server 2012 R2.

Descarregamentos de Transfere o trabalho de segmentação e soma de verificação da CPU

segmentação e soma de convidada para o comutador virtual do host ou adaptador de rede
verificação TCP durante transferências de dados de rede.

LRO (Descarregamento de Aumenta a taxa de transferência de entrada de conexões de largura

Recebimento Grande) de banda alta agregando vários pacotes em um buffer maior,
diminuindo a sobrecarga da CPU.

SR-IOV Os dispositivos de E/S de raiz única usam o DDA para permitir que
os convidados acessem partes de cartões NIC específicos,
permitindo latência reduzida e maior taxa de transferência. A SR-
IOV requer drivers de função física (PF) atualizados nos drivers de
host e função virtual (VF) no convidado.
Armazenamento
Recurso Descrição

Redimensionamento Com esse recurso, um administrador pode redimensionar um arquivo

do VHDX .vhdx de tamanho fixo anexado a uma máquina virtual. Para obter mais
informações, consulte Visão geral do Redimensionamento de disco
rígido virtual online.

Fibre Channel Virtual Com esse recurso, as máquinas virtuais podem reconhecer um
dispositivo de Fiber Channel e montá-lo nativamente. Para obter mais
informações, consulte Visão Geral do Fibre Channel Virtual do Hyper-V.

Backup de máquina Esse recurso facilita o backup sem tempo de inatividade de máquinas
virtual ativa virtuais dinâmicas.
Observe que a operação não será bem-sucedida se a máquina virtual
tiver discos rígidos virtuais (VHDs) hospedados no armazenamento
remoto, como um compartilhamento de protocolo SMB (SMB) ou um
volume iSCSI. Além disso, certifique-se de que o destino do backup não
resida no mesmo volume do volume do qual você está fazendo o
backup.

Suporte ao TRIM Os avisos TRIM indicam ao disco que alguns setores previamente
alocados não são mais necessários para o aplicativo e podem ser
excluídos. Normalmente, esse processo é utilizado para permitir que um
aplicativo faça grandes alocações de espaço por meio de um arquivo e,
posteriormente, gerencie automaticamente essas alocações, como por
exemplo, para arquivos de disco rígido virtual.

SCSI WWN O driver storvsc extrai informações do WWN da porta e do nó de

dispositivos anexados à máquina virtual e cria os arquivos sysfs
apropriados.

Memória
Recurso Descrição

Suporte ao kernel de A tecnologia PAE (Extensão de Endereço Físico) permite que um kernel
PAE de 32 bits acesse um espaço de endereço físico maior que 4 GB.
Distribuições mais antigas do Linux, como RHEL 5.x, usadas para enviar
um kernel separado que estava habilitado para PAE. As distribuições mais
recentes, como o RHEL 6.x, têm suporte predefinido para PAE.

Configuração da Com esse recurso, os fabricantes de dispositivos podem configurar o

lacuna de MMIO local da lacuna de MMIO (E/S Mapeada na Memória). A lacuna de MMIO
normalmente é usada para dividir a memória física disponível entre os
Recurso Descrição

JeOS (Sistemas Operacionais Just Enough) de um dispositivo e a

infraestrutura de software real que o alimenta.

Memória Dinâmica – O host pode aumentar ou diminuir dinamicamente a quantidade de

Adição Dinâmica memória disponível para uma máquina virtual enquanto ela estiver em
operação. Antes do provisionamento, o Administrador habilitará a
Memória Dinâmica no painel Configurações da Máquina Virtual e
especificará a memória de inicialização, a memória mínima e a memória
máxima para a máquina virtual. Quando a máquina virtual está em
operação, a Memória Dinâmica não pode ser desabilitada e somente as
configurações Mínima e Máxima podem ser alteradas. (É uma melhor
prática especificar esses tamanhos de memória como múltiplos de 128
MB.)
Quando a máquina virtual é iniciada pela primeira vez, a memória
disponível é igual à Memória de Inicialização. À medida que a demanda
de memória aumenta devido às cargas de trabalho do aplicativo, o
Hyper-V pode alocar dinamicamente mais memória para a máquina
virtual por meio do mecanismo Hot-Add, se houver suporte nessa versão
do kernel. A quantidade máxima de memória alocada é limitada pelo
valor do parâmetro Memória Máxima.

A guia Memória do gerenciador do Hyper-V exibirá a quantidade de

memória atribuída à máquina virtual, mas as estatísticas de memória na
máquina virtual mostrarão a maior quantidade de memória alocada.

Para saber mais, consulte Visão geral da Memória Dinâmica do Hyper-V.

Memória Dinâmica – O host pode aumentar ou diminuir dinamicamente a quantidade de

Inchamento memória disponível para uma máquina virtual enquanto ela estiver em
operação. Antes do provisionamento, o Administrador habilita a
Memória Dinâmica no painel Configurações da Máquina Virtual e
especifica a Memória de Inicialização, a Memória Mínima e a Memória
Máxima para a máquina virtual. Quando a máquina virtual está em
operação, a Memória Dinâmica não pode ser desabilitada e somente as
configurações Mínima e Máxima podem ser alteradas. (É uma prática
recomendada especificar esses tamanhos de memória como múltiplos de
128 MB.)
Quando a máquina virtual é iniciada pela primeira vez, a memória
disponível é igual à Memória de Inicialização. À medida que a demanda
de memória aumenta devido às cargas de trabalho do aplicativo, o
Hyper-V pode alocar dinamicamente mais memória para a máquina
virtual por meio do mecanismo Hot-Add (acima). À medida que a
demanda de memória diminui, o Hyper-V pode desprovisionar
automaticamente a memória da máquina virtual por meio do mecanismo
Balloon. O Hyper-V não desprovisionará a memória abaixo do parâmetro
Memória Mínima.
Recurso Descrição

A guia Memória do gerenciador do Hyper-V exibirá a quantidade de

memória atribuída à máquina virtual, mas as estatísticas de memória na
máquina virtual mostrarão a maior quantidade de memória alocada.

Para saber mais, consulte Visão geral da Memória Dinâmica do Hyper-V.

Redimensionamento Um administrador pode definir a quantidade de memória disponível para

da memória de uma máquina virtual enquanto ela estiver em operação, aumentando a
runtime memória ("Adição Frequente") ou diminuindo-a ("Remoção Frequente").
A memória é retornada ao Hyper-V por meio do driver de Balloon
(consulte "Memória dinâmica – Balloon"). O driver de balão mantém uma
quantidade mínima de memória livre após o balonismo, chamada de
"piso", de modo que a memória atribuída não pode ser reduzida abaixo
da demanda atual mais essa quantidade de piso. A guia Memória do
gerenciador do Hyper-V exibirá a quantidade de memória atribuída à
máquina virtual, mas as estatísticas de memória na máquina virtual
mostrarão a maior quantidade de memória alocada. (É uma melhor
prática especificar os valores de memória como múltiplos de 128 MB.)

Vídeo
Recurso Descrição

Dispositivo de vídeo Esse recurso fornece gráficos de alto desempenho e resolução superior
específico do Hyper- para máquinas virtuais. Esse dispositivo não fornece funcionalidades de
V Modo de Sessão Aprimorado ou RemoteFX.

Diversos
Recurso Descrição

Troca de KVP Esse recurso fornece um serviço de troca de par chave/valor (KVP) para
(par Chave- máquinas virtuais. Normalmente, os administradores usam o mecanismo de
Valor) KVP para executar operações de leitura e gravação de dados personalizados
em uma máquina virtual. Para obter mais informações, confira Troca de dados:
usando pares chave-valor para compartilhar informações entre o host e o
convidado no Hyper-V.

Interrupção Não Com esse recurso, um administrador pode emitir NMI (Interrupções Não
Mascarável Mascarável) para uma máquina virtual. As NMIs são úteis para obter despejos
de memória de sistemas operacionais que ficaram sem resposta devido a bugs
do aplicativo. Esses despejos de memória podem ser diagnosticados após a
reinicialização.
Recurso Descrição

Cópia de Esse recurso permite que os arquivos sejam copiados do computador físico
arquivo do host host para as máquinas virtuais convidadas sem usar o adaptador de rede. Para
para o obter mais informações, consulte Serviços de convidado.
convidado

Comando Esse comando obtém informações sobre dispositivos no VMBus (barramento

lsvmbus de máquina virtual) do Hyper-V semelhante a comandos de informações como
lspci.

Soquetes do Esse é um canal de comunicação adicional entre o host e o sistema

Hyper-V operacional convidado. Para carregar e usar o módulo de kernel dos Soquetes
do Hyper-V, confira Criar seus próprios serviços de integração.

Passagem de Com o Windows Server 2016, os administradores podem passar por

PCI/DDA dispositivos PCI Express por meio do mecanismo de Atribuição de Dispositivo
Discreto. Os dispositivos comuns são placas de rede, placas gráficas e
dispositivos de armazenamento especiais. A máquina virtual exigirá que o
driver apropriado use o hardware exposto. O hardware deve ser atribuído à
máquina virtual para que seja usado.
Para obter mais informações, consulte Atribuição de dispositivo discreto –
Descrição e plano de fundo .

O DDA é um pré-requisito para o sistema de rede SR-IOV. As portas virtuais

precisarão ser atribuídas à máquina virtual e a máquina virtual deve usar os
drivers de VF (Função Virtual) corretos para multiplexação de dispositivo.

Máquinas virtuais de 2ª geração

Recurso Descrição

Inicialização por Esse recurso permite que as máquinas virtuais inicializem usando a UEFI
meio da UEFI (Unified Extensible Firmware Interface).
Para obter mais informações, consulte Visão geral da máquina virtual de
geração 2 .

Inicialização Esse recurso permite que as máquinas virtuais usem o modo de inicialização
Segura segura baseado em UEFI. Quando uma máquina virtual é inicializada no modo
seguro, vários componentes do sistema operacional são verificados usando
assinaturas presentes no armazenamento de dados da UEFI.
Para saber mais, confira Inicialização Segura.

Consulte Também
Máquinas virtuais CentOS e Red Hat Enterprise Linux com suporte no Hyper-V
Máquinas virtuais do Debian com suporte no Hyper-V

Máquinas virtuais Oracle Linux com suporte no Hyper-V

Máquinas virtuais SUSE com suporte no Hyper-V

Máquinas virtuais Ubuntu com suporte no Hyper-V

Máquinas virtuais do FreeBSD compatíveis com o Hyper-V

Melhores práticas para executar o Linux no Hyper-V

Melhores práticas para executar o FreeBSD no Hyper-V

Melhores práticas para executar o Linux
no Hyper-V
Artigo • 09/03/2023

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server
2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2, Hyper-
V Server 2012 R2, Windows Server 2012, Hyper-V Server 2012, Windows Server 2008
R2, Windows 10, Windows 8.1, Windows 8, Windows 7.1, Windows 7

Este tópico contém uma lista de recomendações para executar a máquina virtual do
Linux no Hyper-V.

Ajustar sistemas de arquivos Linux em arquivos

VHDX dinâmicos
Alguns sistemas de arquivos do Linux podem consumir quantidades significativas de
espaço em disco real, mesmo quando o sistema de arquivos está praticamente vazio.
Para reduzir a quantidade de uso do espaço em disco real de arquivos VHDX dinâmicos,
considere as seguintes recomendações:

Ao criar o VHDX, use BlockSizeBytes de 1MB (do padrão de 32 MB) no PowerShell,

por exemplo:

Powershell

PS > New-VHD -Path C:\MyVHDs\[Link] -SizeBytes 127GB -Dynamic -

BlockSizeBytes 1MB

O formato ext4 é preferencial para ext3 porque ext4 é mais eficiente em termos de
espaço do que ext3 quando usado com arquivos VHDX dinâmicos.

Ao criar o sistema de arquivos, especifique o número de grupos para 4096, por

exemplo:

Bash

# mkfs.ext4 -G 4096 /dev/sdX1

Tempo limite do menu grub em Máquinas
Virtuais de 2ª geração
Devido a remoção do hardware herdado da emulação em máquinas virtuais de 2ª
geração, o temporizador de contagem regressiva do menu grub faz a contagem muito
rapidamente para que o menu grub seja exibido, carregando imediatamente a entrada
padrão. Até que o grub seja corrigido para usar o temporizador compatível com EFI,
modifique /boot/grub/[Link], /etc/default/grub ou equivalente para ter
"timeout=100000" em vez do padrão "timeout=5".

Inicialização PxE em Máquinas Virtuais de 2ª

geração
Como o temporizador PIT não está presente em Máquinas Virtuais de 2ª geração, as
conexões de rede com o servidor TFTP PxE podem ser encerradas prematuramente e
impedir que o carregador de inicialização leia a configuração do Grub e carregue um
kernel do servidor.

No RHEL 6.x, o carregador de inicialização EFI do grub v0.97 herdado pode ser usado
em vez do grub2, conforme descrito aqui:
[Link]
Guide/[Link]

Em distribuições do Linux diferentes do RHEL 6.x, etapas semelhantes podem ser

seguidas para configurar o grub v0.97 para carregar kernels do Linux de um servidor
PxE.

Além disso, a entrada de teclado e mouse no RHEL/CentOS 6.6 não funcionará com o
kernel de pré-instalação, o que impede a especificação de opções de instalação no
menu. Um console serial deve ser configurado para permitir a escolha de opções de
instalação.

No arquivo efidefault no servidor PxE, adicione o seguinte parâmetro kernel

"console=ttyS1"

Na VM no Hyper-V, configure uma porta COM usando este cmdlet do PowerShell:

Powershell

Set-VMComPort -VMName <Name> -Number 2 -Path \\.\pipe\dbg1

Especificar um arquivo de início rápido para o kernel de pré-instalação também evitaria
a necessidade de entrada de teclado e mouse durante a instalação.

Usar endereços MAC estáticos com clustering

de failover
As máquinas virtuais do Linux que serão implantadas usando o clustering de failover
devem ser configuradas com um endereço MAC (controle de acesso de mídia estático)
para cada adaptador de rede virtual. Em algumas versões do Linux, a configuração de
rede pode ser perdida após o failover porque um novo endereço MAC é atribuído ao
adaptador de rede virtual. Para evitar perder a configuração de rede, verifique se cada
adaptador de rede virtual tem um endereço MAC estático. Você pode configurar o
endereço MAC editando as configurações da máquina virtual no Gerenciador do Hyper-
V ou no Gerenciador de Cluster de Failover.

Usar adaptadores de rede específicos do

Hyper-V, não o adaptador de rede herdado
Configure e use o adaptador de Ethernet virtual, que é uma placa de rede específico do
Hyper-V com desempenho aprimorado. Se os adaptadores de rede herdados e
específicos do Hyper-V estiverem anexados a uma máquina virtual, os nomes de rede na
saída de ifconfig -a podem mostrar valores aleatórios, como _tmp12000801310. Para
evitar esse problema, remova todos os adaptadores de rede herdados ao usar
adaptadores de rede específicos do Hyper-V em uma máquina virtual do Linux.

Usar noop/none do agendador de E/S para

melhorar o desempenho de E/S do disco
O kernel do Linux oferece dois conjuntos de agendadores de E/S de disco para
reordenar solicitações. Um conjunto é para o subsistema ''blk'' mais antigo e um
conjunto é para o subsistema ''blk-mq'' mais recente. Em ambos os casos, com os discos
de estado sólido atuais, é recomendável usar um agendador que passa as decisões de
agendamento para o hipervisor do Hyper-V subjacente. Para kernels do Linux que usam
o subsistema ''blk'', esse é o agendador "noop". Para kernels do Linux que usam o
subsistema ''blk-mq'', esse é o agendador "none".

Para um disco específico, os agendadores disponíveis podem ser vistos neste local do
sistema de arquivos: /sys/class/block/ <diskname> /queue/scheduler, com o agendador
atualmente selecionado entre colchetes. Você pode alterar o agendador gravando neste
local do sistema de arquivos. A alteração deve ser adicionada a um script de
inicialização para que ela persista entre reinicializações. Consulte a documentação da
sua distribuição Linux para obter detalhes.

NUMA
As versões do kernel do Linux anteriores à 2.6.37 não são suporte para NUMA no
Hyper-V com tamanhos de VM maiores. Esse problema afeta principalmente
distribuições mais antigas usando o kernel do Red Hat 2.6.32, e foi corrigido no RHEL
(Red Hat Enterprise Linux) 6.6 (kernel-2.6.32-504). Sistemas que executam kernels
personalizados anteriores a 2.6.37 ou com base em RHEL anteriores a 2.6.32-504 devem
definir o parâmetro de inicialização numa=off na linha de comando do kernel em
[Link]. Para obter mais informações, consulte o KB 436883 do Red Hat.

Reservar mais memória para kdump

Caso o kernel de captura de despejo acabe com uma pane na inicialização, reserve mais
memória para o kernel. Por exemplo, altere o parâmetro crashkernel=384M-:128M para
crashkernel=384M-:256M no arquivo de configuração do grub do Ubuntu.

Reduzir o VHDX ou expandir arquivos VHD e

VHDX pode resultar em tabelas de partição
GPT errôneas
O Hyper-V permite a redução de arquivos VHDX (disco virtual) sem considerar nenhuma
estrutura de dados de partição, volume ou sistema de arquivos que possa existir no
disco. Se o VHDX for reduzido até o final do VHDX antes do final de uma partição, os
dados podem ser perdidos, essa partição pode ser corrompida ou dados inválidos
podem ser retornados quando a partição for lida.

Depois de redimensionar um VHD ou VHDX, os administradores devem usar um

utilitário como fdisk ou se separar para atualizar a partição, o volume e as estruturas do
sistema de arquivos para refletir a alteração no tamanho do disco. Reduzir ou expandir
o tamanho de um VHD ou VHDX que tenha uma GPT (tabela de partição de GUID)
causará um aviso quando uma ferramenta de gerenciamento de partição for usada para
verificar o layout da partição, e o administrador será avisado para corrigir os cabeçalhos
GPT primário e secundário. Essa etapa manual pode ser executada de forma segura sem
perda de dados.
Referências adicionais
Máquinas virtuais compatíveis do Linux e do FreeBSD para o Hyper-V no Windows

Melhores práticas para executar o FreeBSD no Hyper-V

Implantar um cluster do Hyper-V

Criar imagens do Linux para o Azure

Otimizar sua VM do Linux no Azure

Melhores práticas para executar o
FreeBSD no Hyper-V
Artigo • 10/04/2023

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server
2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2, Hyper-
V Server 2012 R2, Windows Server 2012, Hyper-V Server 2012, Windows Server 2008
R2, Windows 10, Windows 8.1, Windows 8, Windows 7.1, Windows 7

Este tópico contém uma lista de recomendações para executar o FreeBSD como um
sistema operacional convidado em uma máquina virtual Hyper-V.

Habilitar o CARP no FreeBSD 10.2 no Hyper-V

O protocolo CARP (Common Address Redundancy Protocol) permite que vários hosts
compartilhem o mesmo endereço IP e VHID (ID de host virtual) para ajudar a fornecer
alta disponibilidade para um ou mais serviços. Se um ou mais hosts falharem, os outros
hosts assumirão de modo transparente para que os usuários não percebam uma falha
de serviço. Para usar o CARP no FreeBSD 10.2, siga as instruções no Manual do
FreeBSD e faça o seguinte no Gerenciador do Hyper-V.

Verifique se a máquina virtual tem um Adaptador de Rede e recebeu um

comutador virtual. Selecione a máquina virtual e selecioneAções>Configurações.

Habilite a falsificação de endereço MAC. Para fazer isso,

 1. Selecione a máquina virtual e selecioneAções>Configurações.

2. Expanda Adaptador de Rede e selecione Recursos Avançados.

3. Selecione Habilitar a falsificação de endereço MAC.

Criar rótulos para dispositivos de disco

Durante a inicialização, nós de dispositivo são criados à medida que novos dispositivos
são descobertos. Isso pode significar que os nomes de dispositivo podem mudar
quando novos dispositivos são adicionados. Se você receber um ERRO DE MONTAGEM
RAIZ durante a inicialização, crie rótulos para cada partição do IDE para evitar conflitos e
alterações. Para saber como, consulte Rotulando dispositivos de disco . Veja exemplos
a seguir.

） Importante

Faça uma cópia de backup do fstab antes de fazer alterações.

1. Reinicie o sistema no modo de usuário único. Isso pode ser feito selecionando a
opção de menu de inicialização 2 para o FreeBSD 10.3+ (opção 4 para o FreeBSD
8.x) ou executando um 'boot-s' no prompt de inicialização.

2. No modo de usuário único, crie rótulos GEOM para cada uma das partições de
disco do IDE listadas em seu fstab (raiz e troca). Veja abaixo um exemplo do
FreeBSD 10.3.

Bash

# cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/da0p2 / ufs rw 1 1
/dev/da0p3 none swap sw 0 0

# glabel label rootfs /dev/da0p2

# glabel label swap /dev/da0p3
# exit

Informações adicionais sobre os rótulos GEOM podem ser encontradas em:

Rotulando dispositivos de disco .

3. O sistema continuará com a inicialização de vários usuários. Após a conclusão da

inicialização, edite /etc/fstab e substitua os nomes de dispositivo convencionais
pelos respectivos rótulos. O /etc/fstab final terá esta aparência:
 # Device Mountpoint FStype Options Dump
Pass#
/dev/label/rootfs / ufs rw 1
1
/dev/label/swap none swap sw 0
0

4. Agora, o sistema pode ser reinicializado. Se tudo correu bem, ele aparecerá
normalmente e a montagem mostrará:

# mount
/dev/label/rootfs on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, mutilabel)

Usar um adaptador de rede sem fio como o

comutador virtual
Se o comutador virtual no host for baseado no adaptador de rede sem fio, reduza o
tempo de validade do ARP para 60 segundos pelo comando a seguir. Caso contrário, a
rede da VM poderá parar de funcionar depois de um tempo.

# sysctl [Link].max_age=60

Confira também

Máquinas virtuais do FreeBSD compatíveis com o Hyper-V

Compatibilidade de recurso do Hyper-V
por geração e convidado
Artigo • 16/08/2024

Aplica-se a: Windows Server 2025 (prévia), Windows Server 2022, Windows Server
2019 e Windows Server 2016

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

As tabelas neste artigo mostram as gerações e os sistemas operacionais compatíveis

com alguns dos recursos do Hyper-V, agrupados por categorias. Em geral, você obterá a
melhor disponibilidade de recursos com uma máquina virtual de geração 2 que executa
o sistema operacional mais recente.

Tenha em mente que alguns recursos dependem de hardware ou outra infraestrutura.

Para obter detalhes de hardware, consulte Requisitos do sistema para o Hyper-V no
Windows Server. Em alguns casos, um recurso pode ser usado com qualquer sistema
operacional convidado com suporte. Para obter detalhes sobre quais sistemas
operacionais têm suporte, consulte:

Máquinas virtuais do Linux e FreeBSD com suporte

Sistemas operacionais convidados compatíveis com o Windows

Disponibilidade e backup
ﾉ Expandir a tabela

Recurso Generation Sistema operacional convidado

Pontos de 1e2 Qualquer convidado com suporte

verificação

Clustering de 1e2 Convidados que executam aplicativos com reconhecimento de

convidado cluster e têm software de destino iSCSI instalado
Recurso Generation Sistema operacional convidado

Replicação 1e2 Qualquer convidado com suporte

Controlador de 1e2 Qualquer convidado do Windows Server com suporte usando

domínio apenas pontos de verificação de produção. Consulte Sistemas
operacionais convidados do Windows Server com suporte

Computação
ﾉ Expandir a tabela

Recurso Generation Sistema operacional convidado

Memória dinâmica 1e2 Versões específicas de convidados com suporte. Confira

Visão geral da Memória Dinâmica do Hyper-V para
versões anteriores a Windows Server 2016 e Windows 10.

Adição/remoção 1e2 Windows Server 2016, Windows 10

frequente de memória

NUMA Virtual 1e2 Qualquer convidado com suporte

Desenvolvimento e teste
ﾉ Expandir a tabela

Recurso Generation Sistema

operacional
convidado

Portas 1e2 Qualquer

seriais/COM Nota: para a geração 2, use o PowerShell do Windows convidado com
para configurar. Para obter detalhes, consulte Adicionar suporte
uma porta COM para depuração de kernel.

Mobilidade
ﾉ Expandir a tabela

Recurso Generation Sistema operacional convidado

Migração ao vivo 1e2 Qualquer convidado com suporte

Recurso Generation Sistema operacional convidado

Importar/exportar 1e2 Qualquer convidado com suporte

Rede
ﾉ Expandir a tabela

Recurso Generation Sistema operacional convidado

Adição/remoção frequente de 2 Qualquer convidado com suporte

adaptadores de rede virtual

Para adaptador de rede virtual 1 Qualquer convidado com suporte

legado

SR-IOV (virtualização de E/S de 1e2 Convidados do Windows de 64 bits,

raiz única) começando com o Windows Server 2012 e o
Windows 8.

VMMQ (várias filas de máquina 1e2 Qualquer convidado com suporte

virtual)

Experiência de conexão remota

ﾉ Expandir a tabela

Recurso Generation Sistema operacional convidado

DDA (Atribuição de 1e2 Windows Server 2012 e posterior, Windows 10 e Windows

dispositivo discreta) 11

Modo de sessão 1e2 Windows Server 2012 R2 e posterior e Windows 8.1 e

avançado posterior, com os Serviços de Área de Trabalho Remota
habilitados
Observação: talvez você também precise configurar o host.
Para obter detalhes, consulte Usar recursos locais na
máquina virtual do Hyper-V com VMConnect.

RemoteFx 1e2 Geração 1 em versões do Windows de 32 bits e 64 bits

começando com Windows 8.
Geração 2 em versões de 64 bits do Windows 10 e do
Windows 11
Segurança
ﾉ Expandir a tabela

Recurso Generation Sistema operacional convidado

Inicialização 2 Linux: Ubuntu 14.04 e posterior, SUSE Linux Enterprise Server

Segura 12 e posterior, Red Hat Enterprise Linux 7.0 e posterior e
CentOS 7.0 e posterior
Windows: todas as versões com suporte que podem ser
executadas em uma máquina virtual de geração 2

Máquinas virtuais 2 Windows: todas as versões com suporte que podem ser
blindadas executadas em uma máquina virtual de geração 2

Armazenamento
ﾉ Expandir a tabela

Recurso Generation Sistema operacional

convidado

Discos rígidos virtuais compartilhados (somente 1e2 Windows Server 2012 e

VHDX) posterior

SMB3 1e2 Tudo o que dá suporte a

SMB3

Espaços de armazenamento diretos 2 Windows Server 2016 e

posterior

Fibre Channel Virtual 1e2 Windows Server 2012 e

posterior

Formato VHDX 1e2 Qualquer convidado com

suporte

Comentários
Esta página foi útil?  Yes  No
Instalar a função Hyper-V no servidor
Windows
Artigo • 16/08/2024

Aplica-se a: Windows Server 2025 (prévia), Windows Server 2022, Windows Server
2016 e Windows Server 2019

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

Para criar e executar máquinas virtuais, instale a função Hyper-V no Windows Server
usando o Gerenciador do Servidor ou o cmdlet Install-WindowsFeature no Windows
PowerShell. Para o Windows 10 e Windows 11, consulte Instalação do Hyper-V no
Windows.

Para saber mais sobre o Hyper-V, confira a Visão geral da tecnologia Hyper-V. Para
saber mais sobre o Hyper-V, consulte a Visão geral do Hyper-V. Para experimentar o
Windows Server 2025, você pode baixar e instalar uma cópia de avaliação. Confira o
Centro de Avaliação .

Antes de instalar o Windows Server ou adicionar a função Hyper-V, verifique se:

O hardware do computador é compatível. Para obter mais informações, confira

Requisitos do sistema para o Windows Server e Requisitos do sistema para o
Hyper-V no Windows Server.

Você não planeja usar aplicativos de virtualização de terceiros que dependem dos
mesmos recursos de processador que o Hyper-V requer. Exemplos incluem o
VMWare Workstation e o VirtualBox. Você pode instalar o Hyper-V sem desinstalar
esses outros aplicativos. No entanto, se você tentar usá-los para gerenciar
máquinas virtuais quando o hipervisor do Hyper-V estiver em execução, as
máquinas virtuais poderão não ser iniciadas ou poderão não ser executadas de
modo confiável. Para obter detalhes e instruções sobre como desativar o hipervisor
do Hyper-V caso você precise usar um desses aplicativos, confira Os aplicativos de
 virtualização não funcionam em conjunto com o Hyper-V, o Device Guard e o
Credential Guard .

Para instalar apenas as ferramentas de gerenciamento, como o Gerenciador do Hyper-V,

consulte Gerenciar remotamente hosts Hyper-V com o Gerenciador do Hyper-V.

Instalar o Hyper-V usando o Gerenciador do

Servidor
1. No Gerenciador do Servidor, no menu Gerenciar, selecione Adicionar Funções e
Recursos.

2. Na página Antes de começar, verifique se o servidor de destino e o ambiente de

rede estão preparados para a função e o recurso que você vai instalar. Selecione
Avançar.

3. Na página Selecionar tipo de instalação, escolha Instalação baseada em função

ou recurso e selecione Avançar.

4. Na página Selecionar servidor de destino, escolha um servidor no pool de

servidores e selecione Avançar.

5. Na página Selecionar funções do servidor, selecione Hyper-V. Na página

Assistente para Adicionar Funções e Recursos, selecione Adicionar Recursos e
Avançar.

6. Na página Selecionar recursos, escolha Avançar e selecione Avançar novamente.

7. Nas páginas Criar Comutadores Virtuais, Migração de Máquina Virtual e

Repositórios Padrão, selecione as opções apropriadas ao seu ambiente específico.

8. Na página Confirmar seleções de instalação, selecione Reiniciar o servidor de

destino automaticamente, se necessário e escolha Instalar.

9. Quando a instalação for concluída, verifique se o Hyper-V foi instalado

corretamente. Abra a página Todos os Servidores no Gerenciador do Servidor e
selecione um servidor no qual você instalou o Hyper-V. Verifique o bloco Funções
e Recursos na página do servidor selecionado.

Instalar o Hyper-V usando o cmdlet Install-

WindowsFeature
 1. Na área de trabalho do Windows, selecione o botão Iniciar e digite qualquer parte
do nome Windows PowerShell.

2. Clique com o botão direito do mouse no Windows PowerShell e selecione

Executar como Administrador.

3. Para instalar o Hyper-V em um servidor ao qual você está conectado

remotamente, execute o comando a seguir e substitua <computer_name> pelo nome
do servidor.

PowerShell

Install-WindowsFeature -Name Hyper-V -ComputerName <computer_name> -

IncludeManagementTools -Restart

Se estiver conectado localmente ao servidor, execute o comando sem -

ComputerName <computer_name> .

4. Após o servidor ser reiniciado, você poderá ver que a função Hyper-V está
instalada e quais outras funções e recursos estão instalados executando o seguinte
comando:

PowerShell

Get-WindowsFeature -ComputerName <computer_name>

Se estiver conectado localmente ao servidor, execute o comando sem -

ComputerName <computer_name> .

７ Observação

Se você instalar essa função em um servidor que executa a opção de instalação

Server Core do Windows Server 2016 e usar o parâmetro -IncludeManagementTools ,
somente o Módulo do Hyper-V para o Windows PowerShell será instalado. Você
pode usar a ferramenta de gerenciamento de GUI, o Gerenciador do Hyper-V, em
outro computador para gerenciar remotamente um host do Hyper-V executado em
uma instalação Server Core. Para obter instruções sobre como se conectar
remotamente, consulte Gerenciar remotamente hosts do Hyper-V com o
Gerenciador do Hyper-V.

Referências adicionais
 Install-WindowsFeature

Comentários
Esta página foi útil?  Yes  No
Instalar a função Hyper-V no servidor
Windows
Artigo • 16/08/2024

Aplica-se a: Windows Server 2025 (prévia), Windows Server 2022, Windows Server
2016 e Windows Server 2019

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

Para criar e executar máquinas virtuais, instale a função Hyper-V no Windows Server
usando o Gerenciador do Servidor ou o cmdlet Install-WindowsFeature no Windows
PowerShell. Para o Windows 10 e Windows 11, consulte Instalação do Hyper-V no
Windows.

Para saber mais sobre o Hyper-V, confira a Visão geral da tecnologia Hyper-V. Para
saber mais sobre o Hyper-V, consulte a Visão geral do Hyper-V. Para experimentar o
Windows Server 2025, você pode baixar e instalar uma cópia de avaliação. Confira o
Centro de Avaliação .

Antes de instalar o Windows Server ou adicionar a função Hyper-V, verifique se:

O hardware do computador é compatível. Para obter mais informações, confira

Requisitos do sistema para o Windows Server e Requisitos do sistema para o
Hyper-V no Windows Server.

Você não planeja usar aplicativos de virtualização de terceiros que dependem dos
mesmos recursos de processador que o Hyper-V requer. Exemplos incluem o
VMWare Workstation e o VirtualBox. Você pode instalar o Hyper-V sem desinstalar
esses outros aplicativos. No entanto, se você tentar usá-los para gerenciar
máquinas virtuais quando o hipervisor do Hyper-V estiver em execução, as
máquinas virtuais poderão não ser iniciadas ou poderão não ser executadas de
modo confiável. Para obter detalhes e instruções sobre como desativar o hipervisor
do Hyper-V caso você precise usar um desses aplicativos, confira Os aplicativos de
 virtualização não funcionam em conjunto com o Hyper-V, o Device Guard e o
Credential Guard .

Para instalar apenas as ferramentas de gerenciamento, como o Gerenciador do Hyper-V,

consulte Gerenciar remotamente hosts Hyper-V com o Gerenciador do Hyper-V.

Instalar o Hyper-V usando o Gerenciador do

Servidor
1. No Gerenciador do Servidor, no menu Gerenciar, selecione Adicionar Funções e
Recursos.

2. Na página Antes de começar, verifique se o servidor de destino e o ambiente de

rede estão preparados para a função e o recurso que você vai instalar. Selecione
Avançar.

3. Na página Selecionar tipo de instalação, escolha Instalação baseada em função

ou recurso e selecione Avançar.

4. Na página Selecionar servidor de destino, escolha um servidor no pool de

servidores e selecione Avançar.

5. Na página Selecionar funções do servidor, selecione Hyper-V. Na página

Assistente para Adicionar Funções e Recursos, selecione Adicionar Recursos e
Avançar.

6. Na página Selecionar recursos, escolha Avançar e selecione Avançar novamente.

7. Nas páginas Criar Comutadores Virtuais, Migração de Máquina Virtual e

Repositórios Padrão, selecione as opções apropriadas ao seu ambiente específico.

8. Na página Confirmar seleções de instalação, selecione Reiniciar o servidor de

destino automaticamente, se necessário e escolha Instalar.

9. Quando a instalação for concluída, verifique se o Hyper-V foi instalado

corretamente. Abra a página Todos os Servidores no Gerenciador do Servidor e
selecione um servidor no qual você instalou o Hyper-V. Verifique o bloco Funções
e Recursos na página do servidor selecionado.

Instalar o Hyper-V usando o cmdlet Install-

WindowsFeature
 1. Na área de trabalho do Windows, selecione o botão Iniciar e digite qualquer parte
do nome Windows PowerShell.

2. Clique com o botão direito do mouse no Windows PowerShell e selecione

Executar como Administrador.

3. Para instalar o Hyper-V em um servidor ao qual você está conectado

remotamente, execute o comando a seguir e substitua <computer_name> pelo nome
do servidor.

PowerShell

Install-WindowsFeature -Name Hyper-V -ComputerName <computer_name> -

IncludeManagementTools -Restart

Se estiver conectado localmente ao servidor, execute o comando sem -

ComputerName <computer_name> .

4. Após o servidor ser reiniciado, você poderá ver que a função Hyper-V está
instalada e quais outras funções e recursos estão instalados executando o seguinte
comando:

PowerShell

Get-WindowsFeature -ComputerName <computer_name>

Se estiver conectado localmente ao servidor, execute o comando sem -

ComputerName <computer_name> .

７ Observação

Se você instalar essa função em um servidor que executa a opção de instalação

Server Core do Windows Server 2016 e usar o parâmetro -IncludeManagementTools ,
somente o Módulo do Hyper-V para o Windows PowerShell será instalado. Você
pode usar a ferramenta de gerenciamento de GUI, o Gerenciador do Hyper-V, em
outro computador para gerenciar remotamente um host do Hyper-V executado em
uma instalação Server Core. Para obter instruções sobre como se conectar
remotamente, consulte Gerenciar remotamente hosts do Hyper-V com o
Gerenciador do Hyper-V.

Referências adicionais
 Install-WindowsFeature

Comentários
Esta página foi útil?  Yes  No
Criar e configurar um comutador virtual
com o Hyper-V
Artigo • 16/08/2024

Aplica-se a: Windows Server 2025 (versão preliminar), Windows Server 2022,

Windows 10, Windows Server 2016, Microsoft Hyper-V Server 2016, Windows Server
2019, Microsoft Hyper-V Server 2019

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

Este artigo mostra como criar e configurar seu comutador virtual usando o Gerenciador
do Hyper-V ou o PowerShell. Um comutador virtual permite que máquinas virtuais
criadas em hosts Hyper-V se comuniquem com outros computadores. Ao instalar pela
primeira vez a função Hyper-V no Windows Server, você pode, opcionalmente, criar um
comutador virtual ao mesmo tempo. Para saber mais sobre os comutadores virtuais,
consulte Comutador virtual do Hyper-V.

Para obter mais informações sobre como você pode configurar sua infraestrutura de
rede com o Windows Server, examine a Documentação de Rede.

Pré-requisitos
Antes de criar e configurar o virtual switch, seu computador precisa atender aos
seguintes pré-requisitos:

A função de servidor Hyper-V deve ser instalada.

Determine que tipo de comutador virtual você precisa criar.
Identifique a rede à qual você conectará seu computador. Examine o artigo
Planejamento de rede principal para obter mais informações.
Tenha direitos administrativos.

Criar um comutador virtual

Depois de concluir os pré-requisitos, você estará pronto para criar o comutador virtual.
Nesta seção, criaremos um comutador virtual básico seguindo estas etapas.

Gerenciador Hyper-V

Veja como criar um comutador virtual com o Gerenciador do Hyper-V.

1. Abra o Gerenciador do Hyper-V.

2. No painel Ações selecione Gerenciador de Comutador Virtual.

3. Escolha o tipo de comutador virtual e selecione Criar Comutador Virtual.

4. Insira um nome para o comutador virtual e execute uma das etapas a seguir.

a. Se selecionou externo, escolha o adaptador de rede (NIC) que deseja usar e

selecione OK.

Você receberá um aviso de que a alteração pode interromper a

conectividade de rede, selecione Sim se você estiver feliz em continuar.

b. Se selecionou interno ou privado, selecione OK.

Compartilhamento do sistema operacional de

gerenciamento
Um comutador virtual externo permite que suas máquinas virtuais se conectem a uma
rede externa. Você também pode permitir que o sistema operacional de gerenciamento
compartilhe o mesmo adaptador de rede selecionado. Para começar, siga estas etapas.

Gerenciador Hyper-V

Veja como permitir que o sistema operacional de gerenciamento compartilhe o

comutador de adaptador de rede selecionado usando o Gerenciador do Hyper-V.

1. Abra o Gerenciador do Hyper-V.

2. No painel Ações selecione Gerenciador de Comutador Virtual.

3. Selecione o comutador virtual que deseja configurar, marque Permitir que o

sistema operacional de gerenciamento compartilhe esse adaptador de rede
e selecione OK.
 Você receberá um aviso de que a alteração pode interromper a conectividade
de rede, selecione Sim se você estiver feliz em continuar.

Identificação de VLAN (LAN virtual)

Especifique a ID (identificação) de VLAN usada por adaptadores de rede e comutadores
virtuais de máquinas virtuais. Para comutadores virtuais conectados a uma rede externa
ou interna, especifique a ID (VLAN). O número da ID da VLAN é usado pelo sistema
operacional de gerenciamento e pelas máquinas virtuais que se comunicam por meio
desse comutador virtual.

Você também pode configurar o comutador virtual com outras opções de VLAN, como
o modo de porta e a ID de VLAN nativa. Para essas opções, você precisará usar o
PowerShell e garantir que a configuração seja compatível com a configuração de suas
redes.

Para configurar a identificação de VLAN para a opção, siga estas etapas.

Gerenciador Hyper-V

Veja como especificar a ID da VLAN usando o Gerenciador do Hyper-V.

1. Abra o Gerenciador do Hyper-V.

2. No painel Ações selecione Gerenciador de Comutador Virtual.

3. Selecione o comutador virtual que deseja configurar e marque a opção

Habilitar identificação de LAN virtual para o sistema operacional de
gerenciamento.

a. Insira qualquer número de ID de VLAN ou deixar o padrão e, em seguida,

selecionar OK.

Você será solicitado a avisá-lo de que a alteração pode interromper a

conectividade de rede, selecione Sim se você estiver feliz em continuar.

Os identificadores de VLAN devem ser consistentes com sua rede para garantir a
compatibilidade entre seu computador, máquinas virtuais e outros dispositivos de
rede.

Próxima etapa
Agora que criou e configurou seu comutador virtual, aqui estão outros artigos para
ajudá-lo a continuar com o Hyper-V.

Saiba sobre o SET (Agrupamento Incorporado de Comutador).

Saiba como criar uma máquina virtual com o Hyper-V.
Saiba mais sobre outras opções de configuração nos artigos de referência Set-
VMSwitch e Set-VMNetworkAdapterVlan do PowerShell.

Comentários
Esta página foi útil?  Yes  No
Criar uma máquina virtual com o Hyper-
V
Artigo • 16/08/2024

Aplica-se a: Windows Server 2025 (versão preliminar), Windows Server 2022,

Windows Server 2016, Microsoft Hyper-V Server 2016, Windows Server 2019,
Microsoft Hyper-V Server 2019, Windows 11, Windows 10

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

Saiba como criar uma máquina virtual com o Gerenciador do Hyper-V e o PowerShell do
Windows e quais opções você tem ao criar uma máquina virtual no Gerenciador do
Hyper-V.

Criar uma máquina virtual

Gerenciador Hyper-V

1. Abra o Gerenciador do Hyper-V.

2. No painel Ação, selecione Novo e Máquina Virtual.

3. No Assistente de Nova Máquina Virtual, selecione Avançar.

4. Faça as escolhas apropriadas para sua máquina virtual em cada uma das
páginas. Para obter mais informações, consulte Novas opções de máquina
virtual e padrões no Gerenciador do Hyper-V.

5. Depois de verificar suas escolhas na página Resumo, selecione Concluir.

6. No Gerenciador do Hyper-V, clique com o botão direito na máquina virtual e

selecione conectar.
 7. Na janela Conexão de Máquina Virtual, selecione Iniciar>Ação.

Opções no Assistente de Nova Máquina Virtual

do Gerenciador do Hyper-V
A tabela a seguir lista as opções que você pode escolher ao criar uma máquina virtual
no Gerenciador do Hyper-V e os padrões para cada uma delas.

ﾉ Expandir a tabela

? Padrão para Windows Server 2016, Windows Outras opções

10 e posterior

Especificar Nome: Nova Máquina Virtual. Você também pode inserir seu
o nome e o Localização: próprio nome e escolher outro
local C:\ProgramData\Microsoft\Windows\Hyper- local para a máquina virtual.
V\. É aqui que os arquivos de
configuração da máquina
virtual serão armazenados.

Especificar a Geração 1 Você também pode optar por

geração criar uma máquina virtual de
Geração 2. Para obter mais
informações, confira Devo criar
uma máquina virtual de
geração 1 ou 2 no Hyper-V?.

Atribuir Memória de inicialização: 1024 MB Defina a memória de

Memória Memória dinâmica: não selecionada inicialização de 32 MB para
5902 MB.
Você também pode optar por
usar a Memória Dinâmica. Para
saber mais, consulte Visão
geral da Memória Dinâmica do
Hyper-V.

Configurar Não conectado Selecione uma conexão de

a rede rede para a máquina virtual
usar em uma lista de
comutadores virtuais
existentes. Consulte Criar uma
opção virtual para máquinas
virtuais Hyper-V.

Conectar o Criar um disco rígido virtual Você também pode optar por
disco rígido Name: <vmname>.vhdx usar um disco rígido virtual
 ? Padrão para Windows Server 2016, Windows Outras opções
10 e posterior

virtual Localização: existente ou aguardar e anexar

C:\Users\Public\Documents\Hyper-V\Virtual um disco rígido virtual mais
Hard Disks\ tarde.

Tamanho: 127 GB

Opções de Instalar um sistema operacional posteriormente Essas opções alteram a ordem

instalação de inicialização da máquina
virtual para que você possa
instalar de um arquivo .iso,
disquete inicializável ou um
serviço de instalação de rede,
como o WDS (Serviços de
Implantação do Windows).

Resumo Exibe as opções escolhidas para que você possa Ponta: é possível copiar o
verificar se elas estão corretas. resumo da página e colá-lo em
– Nome email ou em outro lugar para
– Geração ajudá-lo a acompanhar suas
– Memory máquinas virtuais.
– Rede
– Disco rígido
– Sistema operacional

Referências adicionais
New-VM

Versões de configuração de máquina virtual com suporte

Devo criar uma máquina virtual de geração 1 ou 2 no Hyper-V?

Criar uma opção virtual para máquinas virtuais Hyper-V

Comentários
Esta página foi útil?  Yes  No
Planejar a escalabilidade do Hyper-V no
Windows Server
Artigo • 15/04/2024

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

Este artigo fornece detalhes sobre a configuração máxima para os componentes que
você pode adicionar e remover em um host do Hyper-V ou das máquinas virtuais, como
processadores virtuais ou pontos de verificação. Ao planejar sua implantação, considere
os máximos que se aplicam a cada máquina virtual e aqueles que se aplicam ao host
Hyper-V. Os limites máximos continuam a aumentar nas versões do Windows Server, em
resposta as solicitações para dar suporte a cenários mais recentes, como o aprendizado
de máquina e a análise de dados.

７ Observação

Para obter informações sobre o System Center Virtual Machine Manager (VMM),
consulte Virtual Machine Manager. O VMM é um produto da Microsoft para o
gerenciamento de um data center virtualizado que é vendido separadamente.

Máximos para máquinas virtuais

Esses máximos se aplicam a cada máquina virtual quando o host executa a versão do
produto selecionada. O sistema operacional convidado pode oferecer suporte a menos
do que o máximo da máquina virtual. Nem todos os componentes estão disponíveis em
ambas as gerações de máquinas virtuais. Para obter uma comparação entre as gerações,
confira Devo criar uma máquina virtual de geração 1 ou 2 no Hyper-V?

ﾉ Expandir a tabela
Componente Máximo Observações

Pontos de 50 O número real pode ser menor, dependendo do

verificação armazenamento disponível. Cada ponto de
verificação é armazenado como um arquivo .avhd
que usa armazenamento físico.

Memória 240 TB para a Analise os requisitos do sistema operacional

geração 2 específico para determinar os valores mínimos e
1 TB para a recomendados.
geração 1

Portas seriais (COM) 2 Nenhum.

Tamanho dos discos Varia O tamanho máximo é determinado pelo sistema

físicos conectados operacional convidado.
diretamente a uma
máquina virtual

Adaptadores do 4 Como melhor prática, recomendamos que você

Fibre Channel conecte cada adaptador do Fibre Channel virtual
Virtual a um SAN virtual diferente.

Dispositivos de 1 unidade de Nenhum.

disquete virtuais disquete

Capacidade do 64 TB para o Cada disco rígido virtual é armazenado em mídia

disco rígido virtual formato VHDX física como um arquivo .vhdx ou .vhd,
2040 GB para dependendo do formato usado pelo disco rígido
formato VHD virtual.

Discos IDE virtuais 4 O disco de inicialização deve ser conectado a um

dos dispositivos IDE. O disco de inicialização pode
ser um disco rígido virtual ou um disco físico
conectado diretamente a uma máquina virtual.

Processadores 2048 para a O número de processadores virtuais com suporte

virtuais geração 2 em um sistema operacional convidado pode ser
64 para a menor. Para obter detalhes, consulte as
geração 1 informações publicadas para o sistema
operacional específico.

Controladores SCSI 4 O uso de dispositivos SCSI virtuais necessita dos

virtuais serviços de integração, que estão disponíveis para
os sistemas operacionais convidados com
suporte. Para obter detalhes sobre quais sistemas
operacionais são compatíveis, consulte Máquinas
virtuais do Linux e FreeBSD com suporte e
 Componente Máximo Observações

Sistemas operacionais convidados do Windows

com suporte.

Discos SCSI virtuais 256 Cada controlador SCSI oferece suporte a até 64
discos, o que significa que cada máquina virtual
pode ser configurada com até 256 discos SCSI
virtuais (4 controladores x 64 discos por
controlador).

Adaptadores de 68 adaptadores no O adaptador de rede específico do Hyper-V

rede virtuais total: fornece melhor desempenho e necessita de um
64 adaptadores driver incluído nos serviços de integração. Para
de rede obter mais informações, consulte Planejar a rede
específicos do do Hyper-V no Windows Server.
Hyper-V
4 adaptadores
de rede
herdados;

Máximos para os hosts do Hyper-V

Esses máximos se aplicam a cada host Hyper-V que executa a versão do produto
selecionada.

ﾉ Expandir a tabela

Componente Máximo Observações

Processadores lógicos 2\.048 Ambos os recursos devem ser

habilitados no firmware:
Virtualização assistida por
hardware
Prevenção de Execução de Dados
(DEP) imposta por hardware

Memória 4 PB para hosts que Nenhum.

oferecem suporte à
paginação de 5 níveis
256 TB para hosts que
oferecem suporte à
paginação de 4 níveis

Equipes de adaptador Nenhum limite imposto pelo Nenhum.

de rede Hyper-V.
 Componente Máximo Observações

(Agrupamento NIC)

Adaptadores de rede Nenhum limite imposto pelo Nenhum.

físicos Hyper-V.

Máquinas virtuais em 1024 Nenhum.

execução por servidor

Armazenamento Limitado ao suporte Observação: a Microsoft oferece

oferecido pelo sistema suporte ao NAS (armazenamento
operacional host. Nenhum conectado à rede) ao usar o SMB 3.0.
limite imposto pelo Hyper-V. Não há suporte para armazenamento
baseado em NFS.

Portas de comutador Varia; nenhum limite imposto O limite prático depende dos recursos
de rede virtual por pelo Hyper-V. computacionais disponíveis.
servidor

Processadores virtuais 2\.048 O limite é aplicado ao sistema

disponíveis no host operacional do host (partição raiz)

Processadores virtuais Nenhuma razão imposta Nenhum.

por processador pelo Hyper-V.
lógico

Processadores virtuais 2.048 Nenhum.

por servidor

Redes SAN (redes de Nenhum limite imposto pelo Nenhum.

área de Hyper-V.
armazenamento)
virtuais

Comutadores virtuais Varia; nenhum limite imposto O limite prático depende dos recursos
pelo Hyper-V. computacionais disponíveis.

Clusters de Failover e Hyper-V

Esta tabela lista os máximos que se aplicam ao usar o Hyper-V e o Clustering de
Failover. É importante fazer o planejamento de capacidade para garantir que haja
recursos de hardware suficientes para executar todas as máquinas virtuais em um
ambiente clusterizado.

ﾉ Expandir a tabela
 Componente Máximo Observações

Nós por cluster 64 Considere o número de nós que deseja reservar para failover e
tarefas de manutenção como a aplicação de atualizações.
Recomendamos que você planeje recursos suficientes para
permitir que um nó seja reservado para failover. Ou seja, ele
permanece ocioso até que outro nó seja submetido a failover, às
vezes chamado de nó passivo. Você pode aumentar esse número
se quiser reservar mais nós. Não há proporção recomendada ou
multiplicador de nós reservados para nós ativos; o único requisito
é que o número total de nós em um cluster não exceda o máximo
de 64.

Máquinas 8.000 Vários fatores podem afetar o número real de máquinas virtuais
virtuais em por que você pode executar simultaneamente em um único nó, como:
execução por cluster – A quantidade de memória física usada por cada máquina virtual.
cluster e por nó – A largura de banda da rede e do armazenamento.
– O número de eixos de disco, que afeta o desempenho de E/S.

Comentários
Esta página foi útil?  Yes  No
Capacidade de suporte ao sistema
operacional convidado e ao aplicativo
no Hyper-V
Artigo • 13/03/2023

O Hyper-V é um hipervisor amplamente usado em muitos produtos para servidores da

Microsoft, incluindo a família Windows Server (edições Datacenter, Standard e
Essentials) e o Azure Stack HCI. O Hyper-V fornece uma plataforma com amplo suporte
ao ecossistema e compatibilidade. Este artigo esclarece quais versões do Windows
Server ou do Azure Stack HCI são equivalentes a quais números de build do Hyper-V.
Isso ajuda a entender os cenários com suporte em que um sistema operacional
convidado ou um aplicativo foi validado para o Hyper-V.

Embora os diferentes produtos que incluem o Hyper-V possam conter variações nos
recursos, a base de código comum fornece uma plataforma consistente para sistemas
operacionais convidados e aplicativos em execução em uma máquina virtual para serem
executados em produtos compatíveis que têm o mesmo número de build do Hyper-V.
Isso significa que qualquer declaração de compatibilidade ou de suporte para um
sistema operacional convidado ou para um aplicativo certificado para builds específicos
do Hyper-V é compatível com todos os produtos que têm o mesmo número de build do
Hyper-V.

A seguinte tabela mostra quais números de build do Hyper-V estão disponíveis em

quais produtos compatíveis:

Build do Hyper-V Produtos compatíveis

20348 Windows Server 2022 Datacenter

Windows Server 2022 Standard
Windows Server 2022 Essentials
Azure Stack HCI versão 21H2
Azure Stack HCI versão 22H2

17763 e 17784 Windows Server 2019 Datacenter

Windows Server 2019 Standard
Windows Server 2019 Essentials
Servidor Hyper-V 2019
Azure Stack HCI versão 20H2
 Build do Hyper-V Produtos compatíveis

14393 Windows Server 2016 Datacenter

Windows Server 2016 Standard
Windows Server 2016 Essentials
Hyper-V Server 2016

Para obter mais informações, consulte:

Informações sobre versões do Windows Server

Sistemas operacionais convidados Windows com suporte no Hyper-V
Sistemas operacionais convidados Linux e FreeBSD com suporte no Hyper-V
Devo criar uma máquina virtual de
geração 1 ou 2 no Hyper-V?
Artigo • 21/06/2024

Aplica-se a: Windows 10, Windows 11, Windows Server 2016, Microsoft Hyper-V
Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019, Windows Server
2022, Azure Stack HCI

A criação de uma máquina virtual de geração 1 ou 2 depende de qual sistema

operacional convidado você deseja instalar e do método de inicialização que deseja usar
para implantar a máquina virtual. Recomendamos que você crie máquinas virtuais de 2ª
geração para aproveitar recursos como a Inicialização Segura, a menos que uma das
seguintes instruções seja verdadeira:

Você está usando um disco rígido virtual existente e pré-criado (arquivos VHD ou
VHDX), que não é compatível com UEFI.
A 2ª geração não dá suporte ao sistema operacional que você deseja executar na
máquina virtual.
A 2ª geração não dá suporte ao método de inicialização que você deseja usar.

Para obter mais informações sobre quais recursos estão disponíveis com máquinas
virtuais de 2ª geração, consulte Compatibilidade de recursos do Hyper-V por geração e
convidado.

Não é possível alterar a geração de uma máquina virtual depois que ela é criada.
Recomendamos que você revise as considerações aqui e escolha o sistema operacional,
o método de inicialização e os recursos que deseja usar antes de escolher uma geração.

Quais são as vantagens de usar uma máquina

virtual da 2ª geração?
Aqui estão algumas das vantagens que você obtém ao usar uma máquina virtual de 2ª
geração:

Inicialização segura

Use a Inicialização Segura para ajudar a impedir que firmware, sistemas

operacionais ou drivers UEFI não autorizados sejam executados no momento da
inicialização. A Inicialização Segura verifica se o carregador de inicialização está
assinado por uma autoridade confiável no banco de dados UEFI. A Inicialização
 Segura é habilitada por padrão em máquinas virtuais da 2ª geração. Se você
precisar executar um sistema operacional convidado que a Inicialização Segura
não suporta, poderá desabilitá-lo depois de criar a máquina virtual. Para saber
mais, confira Inicialização Segura.

Para a Inicialização Segura das máquinas virtuais Linux da 2ª geração, você precisa
escolher o modelo de Inicialização Segura de uma Autoridade de Certificação UEFI
ao criar a máquina virtual.

Volume de inicialização maior O volume máximo de inicialização para máquinas

virtuais de 2ª geração é de 64 TB. Esse volume máximo de inicialização é o
tamanho máximo de disco suportado por um .VHDX Para máquinas virtuais de
geração 1, o volume máximo de inicialização é de 2 TB para um .VHDX e 2040 GB
para um .VHD Para obter mais informações, consulte Visão geral do formato de
disco rígido virtual do Hyper-V.

Você também pode ver uma pequena melhoria nos tempos de inicialização e
instalação da máquina virtual com máquinas virtuais de 2ª geração.

Há suporte para quais sistemas operacionais

convidados?
As máquinas virtuais de 1ª geração oferecem suporte para a maioria dos sistemas
operacionais convidados. As máquinas virtuais de 2ª geração dão suporte à maioria das
versões de 64 bits do Windows e versões mais atuais dos sistemas operacionais Linux e
FreeBSD. Use as seções a seguir para ver qual geração de máquina virtual dá suporte ao
sistema operacional convidado que você deseja instalar.

Suporte ao sistema operacional convidado do Windows

Suporte ao sistema operacional convidado CentOS e Red Hat Enterprise Linux

Suporte ao sistema operacional convidado do Debian

Suporte ao sistema operacional convidado do FreeBSD

Suporte ao sistema operacional convidado Oracle Linux

Suporte ao sistema operacional convidado do SUSE

Suporte ao sistema operacional convidado do Ubuntu

Suporte ao sistema operacional convidado do Windows

A tabela a seguir mostra quais versões de 64 bits do Windows você pode usar como um
sistema operacional convidado para máquinas virtuais de 1ª e 2ª geração.

ﾉ Expandir a tabela

Versões de 64 bits do Windows Geração 1 Geração 2

Windows Server 2025 ✔ ✔

Windows Server 2022 ✔ ✔

Windows Server 2019 ✔ ✔

Windows Server 2016 ✔ ✔

Windows Server 2012 R2 ✔ ✔

Windows Server 2012 ✔ ✔

Windows Server 2008 R2 ✔ ✖

Windows Server 2008 ✔ ✖

Windows 11 ✖ ✔

Windows 10 ✔ ✔

Windows 8.1 ✔ ✔

Windows 8 ✔ ✔

Windows 7 ✔ ✖

A tabela a seguir mostra quais versões de 32 bits do Windows você pode usar como um
sistema operacional convidado para máquinas virtuais de 1ª e 2ª geração.

ﾉ Expandir a tabela

Versões de 32 bits do Windows Geração 1 Geração 2

Windows 10 ✔ ✖

Windows 8.1 ✔ ✖

Windows 8 ✔ ✖

Windows 7 ✔ ✖
Suporte ao sistema operacional convidado CentOS e Red
Hat Enterprise Linux
A tabela a seguir mostra quais versões do RHEL (Red Hat Enterprise Linux) e CentOS
você pode usar como um sistema operacional convidado para máquinas virtuais de 1ª e
2ª geração.

ﾉ Expandir a tabela

Versões do sistema Geração Geração 2

operacional 1

Série RHEL/CentOS 8.x ✔ ✔

Série RHEL/CentOS 7.x ✔ ✔

Série RHEL/CentOS 6.x ✔ ✔

Observação: Há suporte apenas para Windows Server
2016 e superior.

Série RHEL/CentOS 5.x ✔ ✖

Para obter mais informações, consulte Máquinas virtuais CentOS e Red Hat Enterprise
Linux no Hyper-V.

Suporte ao sistema operacional convidado do Debian

A tabela a seguir mostra quais versões do Debian você pode usar como um sistema
operacional convidado para máquinas virtuais de 1ª e 2ª geração.

ﾉ Expandir a tabela

Versões do sistema operacional Geração 1 Geração 2

Série Debian 10.x (buster) ✔ ✔

Série Debian 9.x (stretch) ✔ ✔

Série Debian 8.x (jessie) ✔ ✔

Série Debian 7.x (wheezy) ✔ ✖

Para obter mais informações, consulte Máquinas virtuais Debian no Hyper-V.

Suporte ao sistema operacional convidado do FreeBSD

A tabela a seguir mostra quais versões do FreeBSD você pode usar como um sistema
operacional convidado para máquinas virtuais de 1ª e 2ª geração.

ﾉ Expandir a tabela

Versões do sistema operacional Geração 1 Geração 2

FreeBSD 12 a 12.1 ✔ ✔

FreeBSD 11.1 a 11.3 ✔ ✔

FreeBSD 11 ✔ ✖

FreeBSD 10 a 10.3 ✔ ✖

FreeBSD 9.1 e 9.3 ✔ ✖

FreeBSD 8.4 ✔ ✖

Para obter mais informações, consulte Máquinas virtuais FreeBSD no Hyper-V.

Suporte ao sistema operacional convidado Oracle Linux

A tabela a seguir mostra quais versões do Red Hat Compatible Kernel Series você pode
usar como um sistema operacional convidado para máquinas virtuais de 1ª e 2ª
geração.

ﾉ Expandir a tabela

Versões do Red Hat Compatible Kernel Series Geração 1 Geração 2

Série Oracle Linux 8.x ✔ ✔

Série Oracle Linux 7.x ✔ ✔

Série Oracle Linux 6.x ✔ ✖

A tabela a seguir mostra quais versões do Unbreakable Enterprise Kernel você pode usar
como um sistema operacional convidado para máquinas virtuais de 1ª e 2ª geração.

ﾉ Expandir a tabela

Versões do Unbreakable Enterprise Kernel (UEK) Geração 1 Geração 2

Oracle Linux UEK R3 QU3 ✔ ✖

Oracle Linux UEK R3 QU2 ✔ ✖

 Versões do Unbreakable Enterprise Kernel (UEK) Geração 1 Geração 2

Oracle Linux UEK R3 QU1 ✔ ✖

Para obter mais informações, consulte Máquinas virtuais Oracle Linux no Hyper-V.

Suporte ao sistema operacional convidado do SUSE

A tabela a seguir mostra quais versões do SUSE você pode usar como um sistema
operacional convidado para máquinas virtuais de 1ª e 2ª geração.

ﾉ Expandir a tabela

Versões do sistema operacional Geração 1 Geração 2

Série SUSE Linux Enterprise Server 15 ✔ ✔

Série SUSE Linux Enterprise Server 12 ✔ ✔

Série SUSE Linux Enterprise Server 11 ✔ ✖

Abrir o SUSE 12.3 ✔ ✖

Para obter mais informações, consulte Máquinas virtuais SUSE no Hyper-V.

Suporte ao sistema operacional convidado do Ubuntu

A tabela a seguir mostra quais versões do Ubuntu você pode usar como um sistema
operacional convidado para máquinas virtuais de 1ª e 2ª geração.

ﾉ Expandir a tabela

Versões do sistema operacional Geração 1 Geração 2

Ubuntu 20.04 ✔ ✔

Ubuntu 18.04 ✔ ✔

Ubuntu 16.04 ✔ ✔

Ubuntu 14.04 ✔ ✔

Ubuntu 12.04 ✔ ✖

Para obter mais informações, consulte Máquinas virtuais Ubuntu no Hyper-V.

Como posso inicializar a máquina virtual?
As VMs de geração 1 e geração 2 oferecem suporte a diferentes métodos de
inicialização, esses métodos são mostrados na tabela a seguir.

ﾉ Expandir a tabela

Método de inicialização Geração Geração

1 2

Inicialização PXE usando um adaptador de rede padrão ✖ ✔

Inicialização PXE usando um adaptador de rede herdado ✔ ✖

Inicialize a partir de um disco rígido virtual SCSI ( .VHDX) ou DVD virtual (. ✖ ✔

ISO)

Inicialize a partir do disco rígido virtual do controlador IDE ( .VHD) , DVD ✔ ✖

virtual ( .ISO) ou uma unidade de CD/DVD física

Inicializar a partir de disquete virtual ( .VFD) ✔ ✖

Qual é a diferença no suporte ao dispositivo?

A tabela a seguir compara os dispositivos disponíveis entre máquinas virtuais de 1ª e 2ª
geração.

ﾉ Expandir a tabela

Dispositivo da 1ª geração Substituto da 2ª Aprimoramentos da 2ª geração

geração

Controlador IDE Controlador Inicialize a partir de (tamanho máximo de

virtual SCSI 64 TB e capacidade de
.VHDX redimensionamento online)

CD-ROM IDE CD-ROM virtual Suporte para até 64 dispositivos de DVD

SCSI SCSI por controlador SCSI.

BIOS herdado Firmware UEFI Inicialização Segura

Adaptador de rede herdado Adaptador de Inicialização de rede com IPv4 e IPv6

rede sintético

Controlador DMA (acesso Sem suporte a N/D

direto à memória) e de controlador de
disquete disquete
 Dispositivo da 1ª geração Substituto da 2ª Aprimoramentos da 2ª geração
geração

UART (universal asynchronous UART opcional Mais rápido e mais confiável

receiver-transmitter) para para depuração
portas COM (Component
Object Model)

Controlador de teclado i8042 Entrada baseada Usa menos recursos porque não há
em software emulação. Também reduz a superfície de
ataque do sistema operacional convidado.

Teclado PS/2 Teclado baseado Usa menos recursos porque não há

em software emulação. Também reduz a superfície de
ataque do sistema operacional convidado.

Mouse PS/2 Mouse baseado Usa menos recursos porque não há

em software emulação. Também reduz a superfície de
ataque do sistema operacional convidado.

Vídeo S3 Vídeo baseado Usa menos recursos porque não há

em software emulação. Também reduz a superfície de
ataque do sistema operacional convidado.

Barramento PCI Não é mais N/D

necessário

PIC (controlador de interrupção Não é mais N/D

programável) necessário

PIT (temporizador de intervalo Não é mais N/D

programável) necessário

Superdispositivo de E/S Não é mais N/D

necessário

Considerações sobre o uso de máquinas

virtuais de geração 1 e geração 2
Aqui estão mais algumas dicas sobre como usar as diferentes gerações de máquinas
virtuais.

Criando VMs com mais de 64 CPUs lógicas

O gerenciador do Hyper-V pode falhar ao criar uma VM de nova geração 1 em um
sistema com mais de 64 CPUs lógicas. O Gerenciador do Hyper-V não permite
especificar o número de processadores virtuais no momento da criação da VM. Para
hosts com mais de 64 processadores lógicos, especifique o número de processadores
virtuais na criação da VM usando o Windows Admin Center, o PowerShell ou outra
ferramenta.

Carregando um disco rígido virtual no Azure

Os discos rígidos virtuais criados em VMs de geração 1 e geração 2 podem ser
carregados no Azure, desde que usem o formato de arquivo VHD. O disco rígido virtual
deve ter um disco de tamanho fixo (não em expansão dinâmica). Confira VMs de 2ª
geração no Azure para saber mais sobre os recursos da 2ª geração com suporte no
Azure. Para obter mais informações sobre como carregar um VHD ou VHDX do
Windows, consulte Preparar um VHD ou VHDX do Windows para carregar no Azure.

Anexar ou adicionar uma unidade de DVD

Não é possível conectar uma unidade física de CD ou DVD a uma máquina virtual
da 2ª geração. A unidade de DVD virtual de máquinas virtuais da 2ª geração tem
suporte apenas para arquivos de imagem ISO. Para criar um arquivo de imagem
ISO de um ambiente Windows, você pode usar a ferramenta de linha de comando
OScdimg. Para obter mais informações, veja Opções de linha de comando de
Oscdimg‎.
Ao criar uma nova máquina virtual com o cmdlet New-VM do Windows PowerShell,
a máquina virtual de 2ª geração não tem uma unidade de DVD. Você poderá
adicionar uma unidade de DVD enquanto a máquina virtual estiver em execução.

Use o firmware UEFI

A Inicialização Segura ou o firmware UEFI não são pedidos pelo host físico do
Hyper-V. Para VMs de 2ª geração, o Hyper-V fornece firmware virtual para
máquinas virtuais que é independente do que está no host Hyper-V.
O firmware UEFI em uma máquina virtual de 2ª geração não dá suporte ao modo
de configuração da Inicialização Segura.
Não há suporte à execução de um shell UEFI ou outros aplicativos UEFI em uma
máquina virtual de 2ª geração. O uso de um shell UEFI ou aplicativos UEFI não
Microsoft é tecnicamente possível se eles forem compilados diretamente das
fontes. Se esses aplicativos não estiverem assinados digitalmente corretamente,
você deverá desabilitar a Inicialização Segura para a máquina virtual.

Trabalhar com arquivos VHDX

 É possível redimensionar um arquivo VHDX contendo o volume de inicialização de
uma máquina virtual de 2ª geração enquanto ela estiver em execução.
Não há suporte ou recomendamos que você crie um único disco virtual (arquivo
VHD ou VHDX) que seja inicializável nas máquinas virtuais de geração 1 e 2. Em
vez disso, crie arquivos VHDX inicializáveis destinados apenas à geração 1 ou
máquinas virtuais de geração 2.
A geração da máquina virtual é uma propriedade da máquina, não do disco rígido
virtual. Não é possível saber se um arquivo VHDX foi criado como uma máquina
virtual de geração 1 ou 2.
Um arquivo VHDX criado com uma máquina virtual de 2ª geração pode ser
conectado ao controlador IDE ou ao controlador SCSI de uma máquina virtual da
1ª geração. No entanto, se o disco rígido virtual for um arquivo VHDX inicializável,
a máquina virtual de geração 1 falhará ao inicializar.

Usar IPv6 em vez de IPv4

Quando você inicializa da rede com PXE, as máquinas virtuais de geração 2 usam o IPv4
por padrão. Para usar o IPv6, execute o cmdlet do Windows PowerShell Set-
VMFirmware. No exemplo a seguir, o seguinte comando define o protocolo preferencial
para IPv6, para uma máquina virtual chamada TestVM:

PowerShell

Set-VMFirmware -VMName 'TestVM' -IPProtocolPreference IPv6

Adicionar uma porta COM para depuração de

kernel
As portas COM não estão disponíveis em máquinas virtuais de 2ª geração até que você
as adicione. Você pode adicionar portas COM com o Windows PowerShell ou o WMI
(Instrumentação de Gerenciamento do Windows). Estas etapas mostram como fazer isso
com o Windows PowerShell.

Para adicionar uma porta COM:

1. Desabilite a Inicialização Segura. A depuração de kernel não é compatível com a

Inicialização Segura. Verifique se a máquina virtual está em um estado Desativado
e use o cmdlet Set-VMFirmware. Por exemplo, o comando a seguir desabilita a
Inicialização Segura na máquina virtual TestVM:

PowerShell
 Set-VMFirmware -VMName 'TestVM' -EnableSecureBoot Off

2. Adicione uma porta COM. Use o cmdlet Set-VMComPort para adicionar uma porta
COM. Por exemplo, o comando a seguir configura a primeira porta COM da
máquina virtual TestVM, conectando-a ao pipe de nome TestPipe no computador
local:

PowerShell

Set-VMComPort -VMName 'TestVM' -Number 1 -Path '\\.\pipe\TestPipe'

７ Observação

As portas COM configuradas não estão listadas nas configurações de uma máquina
virtual no Gerenciador do Hyper-V.

Consulte Também
Máquinas Virtuais do Linux e FreeBSD no Hyper-V
Usar recursos locais na máquina virtual do Hyper-V com VMConnect
Planejar a escalabilidade do Hyper-V no Windows Server 2016
Planejar a rede do Hyper-V no Windows
Server
Artigo • 12/04/2023

Aplica-se a: Windows Server 2022, Microsoft Hyper-V Server 2016, Windows Server
2016, Microsoft Hyper-V Server 2019, Windows Server 2019

Uma compreensão básica da rede no Hyper-V ajuda você a planejar a rede para
máquinas virtuais. Este artigo também aborda algumas considerações de rede ao usar a
migração dinâmica e ao usar o Hyper-V com outros recursos e funções de servidor.

Noções básicas de rede do Hyper-V

A rede básica no Hyper-V é bastante simples. Ele usa duas partes: um comutador virtual
e um adaptador de rede virtual. Você precisará de pelo menos um de cada para
estabelecer a rede de uma máquina virtual. O comutador virtual se conecta a qualquer
rede baseada em Ethernet. O adaptador de rede virtual se conecta a uma porta no
comutador virtual, o que possibilita que uma máquina virtual use uma rede.

A maneira mais fácil de estabelecer a rede básica é criar um comutador virtual quando
você instala o Hyper-V. Em seguida, ao criar uma máquina virtual, você pode conectá-la
ao comutador. Conectar-se ao comutador adiciona automaticamente um adaptador de
rede virtual à máquina virtual. Para obter instruções, consulte Criar uma opção virtual
para máquinas virtuais Hyper-V.

Para lidar com vários tipos de rede, você pode adicionar comutadores virtuais e
adaptadores de rede virtual. Todos os comutadores fazem parte do host Hyper-V, mas
cada adaptador de rede virtual pertence a apenas uma máquina virtual.

O comutador virtual é um comutador de rede Ethernet de camada 2 baseado em

software. Ele fornece recursos internos para monitoramento, controle e segmentação de
tráfego, bem como segurança e diagnóstico. Você pode adicionar ao conjunto de
recursos internos instalando suplementos, também chamados de extensões. Eles estão
disponíveis de fornecedores de software independentes. Para obter mais informações
sobre a opção e as extensões, consulte Comutador Virtual do Hyper-V.

Opções de comutador e adaptador de rede

O Hyper-V oferece três tipos de comutadores virtuais e dois tipos de adaptadores de
rede virtual. Você escolhe qual deles quer durante a criação. Você pode usar o
Gerenciador do Hyper-V ou o módulo Hyper-V para Windows PowerShell para criar e
gerenciar comutadores virtuais e adaptadores de rede virtual. Alguns recursos de rede
avançados, como ACLs (listas de controle de acesso) de porta estendidas, só podem ser
gerenciados usando cmdlets no módulo Hyper-V.

Você pode fazer algumas alterações em um comutador virtual ou adaptador de rede

virtual depois de criá-lo. Por exemplo, é possível alterar um comutador existente para
um tipo diferente, mas fazer isso pode afetar os recursos de rede de todas as máquinas
virtuais conectadas ao comutador. Então, você provavelmente não fará isso a menos
que tenha cometido um erro ou precise testar algo. Como outro exemplo, você pode
conectar um adaptador de rede virtual a um comutador diferente, o que você poderá
fazer se quiser se conectar a uma rede diferente. Mas você não pode alterar um
adaptador de rede virtual de um tipo para outro. Em vez de alterar o tipo, você
adicionaria outro adaptador de rede virtual e escolheria o tipo apropriado.

Os tipos de comutador virtual são:

Comutador virtual externo: conecta-se a uma rede física com fio associando-se a
um adaptador de rede físico.

Comutador virtual interno: conecta-se a uma rede que só pode ser usada pelas
máquinas virtuais em execução no host que tem o comutador virtual e entre o
host e as máquinas virtuais.

Comutador virtual privado – conecta-se a uma rede que só pode ser usada pelas
máquinas virtuais em execução no host que tem o comutador virtual, mas não
fornece rede entre o host e as máquinas virtuais.

Opções de comutador virtual:

Nome da Descrição
configuração

Permitir que o Permitir que o host Hyper-V compartilhe o uso do comutador virtual e da
sistema de NIC ou combine a NIC com a máquina virtual. Com isso habilitado, o host
operacional de pode usar qualquer uma das configurações que você definir para o
gerenciamento comutador virtual, como configurações de QoS (Qualidade de Serviço),
compartilhe esse configurações de segurança ou outros recursos do comutador virtual do
adaptador de Hyper-V.
rede
 Nome da Descrição
configuração

Habilitar a SR- Permita que o tráfego de máquina virtual ignore o comutador de máquina
IOV (virtualização virtual e vá diretamente para a NIC física. A SR-IOV só está disponível para
de E/S de raiz máquinas virtuais que executam o Windows Server. Para obter mais
única) informações, consulte Virtualização de E/S de raiz única na Referência
Complementar de Pôster: Rede Hyper-V.

Os tipos de adaptador de rede virtual são:

Adaptador de rede específico do Hyper-V – disponível para máquinas virtuais de

geração 1 e 2. Ele foi projetado especificamente para o Hyper-V e requer um driver
incluído nos serviços de integração do Hyper-V. Esse tipo de adaptador de rede é
mais rápido e é a opção recomendada, a menos que você precise inicializar na
rede ou esteja executando um sistema operacional convidado sem suporte. O
driver necessário é fornecido apenas para sistemas operacionais convidados com
suporte. Observe que, no Gerenciador do Hyper-V e nos cmdlets de rede, esse tipo
é chamado apenas de adaptador de rede.

Adaptador de rede herdado – disponível apenas em máquinas virtuais da 1ª

geração. Emula um adaptador PCI Fast Ethernet baseado em Intel 21140 e pode
ser usado para inicializar em uma rede para que você possa instalar um sistema
operacional de um serviço como os Serviços de Implantação do Windows.

Rede Hyper-V e tecnologias relacionadas

Versões recentes do Windows Server introduziram melhorias que oferecem mais opções
para configurar a rede para o Hyper-V. Por exemplo, o Windows Server 2012 introduziu
suporte para a rede convergida. Isso permite rotear o tráfego de rede por meio de um
comutador virtual externo. O Windows Server 2016 se baseia nisso permitindo o RDMA
(Acesso Remoto Direto à Memória) em adaptadores de rede associados a um
comutador virtual Hyper-V. Você pode usar essa configuração com ou sem SET (Switch
Embedded Teaming). Para detalhes, confira Acesso Remoto Direto à Memória (RDMA) e
Agrupamento incorporado de comutador (SET)

Alguns recursos dependem de configurações de rede específicas ou são melhores em

determinadas configurações. Considere isso ao planejar ou atualizar sua infraestrutura
de rede.

Clustering de failover – é uma prática recomendada isolar o tráfego de cluster e usar a

QoS (Qualidade de Serviço) do Hyper-V no comutador virtual. Para conhecer os
detalhes, consulte Recomendações de rede para um Cluster Hyper-V
Migração ao vivo – use opções de desempenho para reduzir o uso da rede e da CPU e
o tempo necessário para concluir uma migração ao vivo. Para obter mais instruções,
consulte Configurar hosts para migração dinâmica sem clustering de failover.

Espaços de Armazenamento Diretos – esse recurso depende do protocolo de rede

SMB3.0 e do RDMA. Para conhecer os detalhes, confira Espaços de Armazenamento
Diretos no Windows Server 2016.
Planejar a escalabilidade do Hyper-V no
Windows Server
Artigo • 15/04/2024

） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

Este artigo fornece detalhes sobre a configuração máxima para os componentes que
você pode adicionar e remover em um host do Hyper-V ou das máquinas virtuais, como
processadores virtuais ou pontos de verificação. Ao planejar sua implantação, considere
os máximos que se aplicam a cada máquina virtual e aqueles que se aplicam ao host
Hyper-V. Os limites máximos continuam a aumentar nas versões do Windows Server, em
resposta as solicitações para dar suporte a cenários mais recentes, como o aprendizado
de máquina e a análise de dados.

７ Observação

Para obter informações sobre o System Center Virtual Machine Manager (VMM),
consulte Virtual Machine Manager. O VMM é um produto da Microsoft para o
gerenciamento de um data center virtualizado que é vendido separadamente.

Máximos para máquinas virtuais

Esses máximos se aplicam a cada máquina virtual quando o host executa a versão do
produto selecionada. O sistema operacional convidado pode oferecer suporte a menos
do que o máximo da máquina virtual. Nem todos os componentes estão disponíveis em
ambas as gerações de máquinas virtuais. Para obter uma comparação entre as gerações,
confira Devo criar uma máquina virtual de geração 1 ou 2 no Hyper-V?

ﾉ Expandir a tabela
Componente Máximo Observações

Pontos de 50 O número real pode ser menor, dependendo do

verificação armazenamento disponível. Cada ponto de
verificação é armazenado como um arquivo .avhd
que usa armazenamento físico.

Memória 240 TB para a Analise os requisitos do sistema operacional

geração 2 específico para determinar os valores mínimos e
1 TB para a recomendados.
geração 1

Portas seriais (COM) 2 Nenhum.

Tamanho dos discos Varia O tamanho máximo é determinado pelo sistema

físicos conectados operacional convidado.
diretamente a uma
máquina virtual

Adaptadores do 4 Como melhor prática, recomendamos que você

Fibre Channel conecte cada adaptador do Fibre Channel virtual
Virtual a um SAN virtual diferente.

Dispositivos de 1 unidade de Nenhum.

disquete virtuais disquete

Capacidade do 64 TB para o Cada disco rígido virtual é armazenado em mídia

disco rígido virtual formato VHDX física como um arquivo .vhdx ou .vhd,
2040 GB para dependendo do formato usado pelo disco rígido
formato VHD virtual.

Discos IDE virtuais 4 O disco de inicialização deve ser conectado a um

dos dispositivos IDE. O disco de inicialização pode
ser um disco rígido virtual ou um disco físico
conectado diretamente a uma máquina virtual.

Processadores 2048 para a O número de processadores virtuais com suporte

virtuais geração 2 em um sistema operacional convidado pode ser
64 para a menor. Para obter detalhes, consulte as
geração 1 informações publicadas para o sistema
operacional específico.

Controladores SCSI 4 O uso de dispositivos SCSI virtuais necessita dos

virtuais serviços de integração, que estão disponíveis para
os sistemas operacionais convidados com
suporte. Para obter detalhes sobre quais sistemas
operacionais são compatíveis, consulte Máquinas
virtuais do Linux e FreeBSD com suporte e
 Componente Máximo Observações

Sistemas operacionais convidados do Windows

com suporte.

Discos SCSI virtuais 256 Cada controlador SCSI oferece suporte a até 64
discos, o que significa que cada máquina virtual
pode ser configurada com até 256 discos SCSI
virtuais (4 controladores x 64 discos por
controlador).

Adaptadores de 68 adaptadores no O adaptador de rede específico do Hyper-V

rede virtuais total: fornece melhor desempenho e necessita de um
64 adaptadores driver incluído nos serviços de integração. Para
de rede obter mais informações, consulte Planejar a rede
específicos do do Hyper-V no Windows Server.
Hyper-V
4 adaptadores
de rede
herdados;

Máximos para os hosts do Hyper-V

Esses máximos se aplicam a cada host Hyper-V que executa a versão do produto
selecionada.

ﾉ Expandir a tabela

Componente Máximo Observações

Processadores lógicos 2\.048 Ambos os recursos devem ser

habilitados no firmware:
Virtualização assistida por
hardware
Prevenção de Execução de Dados
(DEP) imposta por hardware

Memória 4 PB para hosts que Nenhum.

oferecem suporte à
paginação de 5 níveis
256 TB para hosts que
oferecem suporte à
paginação de 4 níveis

Equipes de adaptador Nenhum limite imposto pelo Nenhum.

de rede Hyper-V.
 Componente Máximo Observações

(Agrupamento NIC)

Adaptadores de rede Nenhum limite imposto pelo Nenhum.

físicos Hyper-V.

Máquinas virtuais em 1024 Nenhum.

execução por servidor

Armazenamento Limitado ao suporte Observação: a Microsoft oferece

oferecido pelo sistema suporte ao NAS (armazenamento
operacional host. Nenhum conectado à rede) ao usar o SMB 3.0.
limite imposto pelo Hyper-V. Não há suporte para armazenamento
baseado em NFS.

Portas de comutador Varia; nenhum limite imposto O limite prático depende dos recursos
de rede virtual por pelo Hyper-V. computacionais disponíveis.
servidor

Processadores virtuais 2\.048 O limite é aplicado ao sistema

disponíveis no host operacional do host (partição raiz)

Processadores virtuais Nenhuma razão imposta Nenhum.

por processador pelo Hyper-V.
lógico

Processadores virtuais 2.048 Nenhum.

por servidor

Redes SAN (redes de Nenhum limite imposto pelo Nenhum.

área de Hyper-V.
armazenamento)
virtuais

Comutadores virtuais Varia; nenhum limite imposto O limite prático depende dos recursos
pelo Hyper-V. computacionais disponíveis.

Clusters de Failover e Hyper-V

Esta tabela lista os máximos que se aplicam ao usar o Hyper-V e o Clustering de
Failover. É importante fazer o planejamento de capacidade para garantir que haja
recursos de hardware suficientes para executar todas as máquinas virtuais em um
ambiente clusterizado.

ﾉ Expandir a tabela
 Componente Máximo Observações

Nós por cluster 64 Considere o número de nós que deseja reservar para failover e
tarefas de manutenção como a aplicação de atualizações.
Recomendamos que você planeje recursos suficientes para
permitir que um nó seja reservado para failover. Ou seja, ele
permanece ocioso até que outro nó seja submetido a failover, às
vezes chamado de nó passivo. Você pode aumentar esse número
se quiser reservar mais nós. Não há proporção recomendada ou
multiplicador de nós reservados para nós ativos; o único requisito
é que o número total de nós em um cluster não exceda o máximo
de 64.

Máquinas 8.000 Vários fatores podem afetar o número real de máquinas virtuais
virtuais em por que você pode executar simultaneamente em um único nó, como:
execução por cluster – A quantidade de memória física usada por cada máquina virtual.
cluster e por nó – A largura de banda da rede e do armazenamento.
– O número de eixos de disco, que afeta o desempenho de E/S.

Comentários
Esta página foi útil?  Yes  No
Planejar a segurança do Hyper-V no
Windows Server
Artigo • 06/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2016, Microsoft Hyper-V Server
2016, Windows Server 2019 e Microsoft Hyper-V Server 2019

Proteja o sistema operacional host, as máquinas virtuais, os arquivos de configuração e

os dados da máquina virtual do Hyper-V. Use a lista de melhores práticas a seguir como
uma lista de verificação para ajudar a proteger seu ambiente do Hyper-V.

Proteger o host do Hyper-V

Manter o sistema operacional host protegido.
Minimize a superfície de ataque usando a opção de instalação mínima do
Windows Server necessária para o sistema operacional de gerenciamento. Para
obter mais informações, consulte a seção Opções de Instalação da biblioteca de
conteúdo técnico do Windows Server. Não é recomendável que você execute
cargas de trabalho de produção do Hyper-V no Windows 10.
Mantenha o sistema operacional host, o firmware e os drivers de dispositivo do
Hyper-V com as atualizações de segurança mais recentes. Verifique as
recomendações do fornecedor para atualizar o firmware e os drivers.
Não use o host do Hyper-V como uma estação de trabalho ou instale nenhum
software desnecessário.
Gerenciar hosts do Hyper-V remotamente. Se você precisar gerenciar o host do
Hyper-V localmente, use o Credential Guard. Para obter mais informações,
consulte Proteger credenciais de domínio derivadas com o Credential Guard.
Habilitar políticas de integridade de código. Use serviços de integridade de
código protegidos por segurança baseada em virtualização. Para saber mais,
confira Guia de implantação do Device Guard.

Usar uma rede segura.

Use uma rede separada com um adaptador de rede dedicado para o
computador físico do Hyper-V.
Use uma rede privada ou segura para acessar configurações de VM e arquivos
de disco rígido virtual.
Use uma rede privada/dedicada para o tráfego de migração dinâmica.
Considere habilitar o IPSec nessa rede para usar a criptografia e proteger os
 dados da VM que passam pela rede durante a migração. Para obter mais
informações, consulte Configurar hosts para migração dinâmica sem clustering
de failover.

Proteger tráfego de migração de armazenamento.

Use o SMB 3.0 para criptografia de ponta a ponta de dados SMB contra
adulteração de proteção de dados ou espionagem em redes não confiáveis. Use
uma rede privada para acessar o conteúdo de compartilhamento SMB para evitar
ataques man-in-the-middle. Para obter mais informações, consulte
Aprimoramentos de segurança SMB.

Configurar hosts para fazer parte de uma malha protegida.

Para obter mais informações, confira Malha protegida.

Proteger dispositivos.

Proteja os dispositivos de armazenamento em que você mantém arquivos de

recurso de máquina virtual.

Proteger o disco rígido.

Use a Criptografia de Unidade de Disco BitLocker para proteger os recursos.

Proteja o sistema operacional host do Hyper-V.

Use as recomendações de configuração de segurança de linha de base descritas na

Linha de base de segurança do Windows Server.

Conceder permissões adequadas.

Adicione usuários que precisam gerenciar o host do Hyper-V ao grupo de
administradores do Hyper-V.
Não conceda permissões aos administradores de máquinas virtuais no sistema
operacional host do Hyper-V.

Configurar exclusões e opções antivírus para o Hyper-V.

O Windows Defender já tem exclusões automáticas configuradas. Para obter mais

informações sobre exclusões, confira Exclusões de antivírus recomendadas para
hosts do Hyper-V .

Não monte VHDs desconhecidos. Isso pode expor o host a ataques no nível do
sistema de arquivos.
 Não habilite o aninhamento em seu ambiente de produção, a menos que seja
necessário.

Se você habilitar o aninhamento, não execute hipervisores sem suporte em uma

máquina virtual.

Para ambientes mais seguros:

Usar hardware com um chip TPM (Trusted Platform Module) 2.0 para configurar
uma malha protegida.

Para obter mais informações, consulte Requisitos do sistema para o Hyper-V no

Windows Server 2016.

Proteger máquinas virtuais

Criar máquinas virtuais de geração 2 para sistemas operacionais convidados
com suporte.

Para obter mais informações, consulte Configurações de segurança de geração 2.

Habilitar inicialização segura.

Para obter mais informações, consulte Configurações de segurança de geração 2.

Manter o sistema operacional convidado protegido.

Instale as atualizações de segurança mais recentes antes de ativar uma máquina
virtual em um ambiente de produção.
Instale os serviços de integração nos sistemas operacionais convidados com
suporte que precisam deles e mantenha-os atualizados. As atualizações do
serviço de integração para convidados que executam versões com suporte do
Windows estão disponíveis por meio do Windows Update.
Intensifique a proteção do sistema operacional executado em cada máquina
virtual com base na função que ele executa. Use as recomendações de
configuração de segurança de linha de base descritas na Linha de base de
segurança do Windows.

Usar uma rede segura.

Verifique se os adaptadores de rede virtual se conectam ao comutador virtual

correto e têm a configuração e os limites de segurança adequados aplicados.

Armazenar discos rígidos virtuais e arquivos de instantâneo em um local seguro.

Proteger dispositivos.
 Configure apenas os dispositivos necessários para uma máquina virtual. Não
habilite a atribuição de dispositivo discreta em seu ambiente de produção, a
menos que você precise dela para um cenário específico. Se você habilitá-lo,
certifique-se de expor apenas dispositivos de fornecedores confiáveis.

Configurar o software de detecção de antivírus, firewall e intrusão em máquinas

virtuais conforme apropriado com base na função de máquina virtual.

Habilitar a segurança baseada em virtualização para convidados que executam o

Windows 10, Windows Server 2016 ou posterior.

Confira Guia de implantação do Device Guard para saber mais.

Habilitar somente a Atribuição de dispositivo discreta se necessário para uma

carga de trabalho específica.

Devido à natureza de passar por um dispositivo físico, trabalhe com o fabricante

do dispositivo para entender se ele deve ser usado em um ambiente seguro.

Para ambientes mais seguros:

Implantar máquinas virtuais com blindagem habilitada e implantá-las em uma

malha protegida.

Para obter mais informações, consulte Configurações de segurança de geração 2 e

Malha protegida.
Planejar a aceleração de GPU no
Windows Server
Artigo • 17/05/2024

Aplica-se a: Windows Server 2025 (visualização), Windows Server 2022, Windows

Server 2016, Microsoft Hyper-V Server 2016, Windows Server 2019, Microsoft
Hyper-V Server 2019

Este artigo apresenta os recursos de virtualização de gráficos disponíveis no Windows

Server.

Quando usar a aceleração de GPU

Dependendo da sua carga de trabalho, convém considerar a aceleração da GPU. Veja o
que você deve considerar antes de escolher a aceleração de GPU:

Cargas de trabalho de comunicação remota de aplicativos e áreas de trabalho

(VDI/DaaS): se você estiver criando um serviço de comunicação remota de
aplicativo ou área de trabalho com o Windows Server, considere o catálogo de
aplicativos que você espera que seus usuários executem. Alguns tipos de
aplicativos, como aplicativos CAD/CAM, aplicativos de simulação, jogos e
aplicativos de renderização/visualização, dependem muito da renderização 3D
para oferecer uma interatividade suave e responsiva. A maioria dos clientes
considera as GPUs uma necessidade para uma experiência razoável do usuário
com esses tipos de aplicativos.
Cargas de trabalho de renderização, codificação e visualização remotas: essas
cargas de trabalho orientadas a gráficos tendem a depender muito dos recursos
especializados de uma GPU, como renderização 3D eficiente e
codificação/decodificação de quadros, a fim de atingir metas de custo e taxa de
transferência. Para esse tipo de carga de trabalho, uma única máquina virtual (VM)
habilitada para GPU pode ser capaz de corresponder à taxa de transferência de
muitas VMs somente de CPU.
Cargas de trabalho de HPC e ML: para cargas de trabalho computacionais
altamente paralelas a dados, como treinamento ou inferência de modelo de
aprendizado de máquina e computação de alto desempenho, as GPUs podem
reduzir drasticamente o tempo de resultado, o tempo de inferência e o tempo de
treinamento. Como alternativa, eles podem oferecer melhor custo-benefício do
que uma arquitetura somente de CPU em um nível de desempenho comparável.
 Muitas estruturas de computação de alto desempenho (HPC) e aprendizado de
máquina podem usar aceleração de GPU; considere se a aceleração da GPU pode
beneficiar sua carga de trabalho específica.

Virtualização de GPU no Windows Server

As tecnologias de virtualização de GPU permitem a aceleração de GPU em um ambiente
virtualizado, normalmente em máquinas virtuais. Se sua carga de trabalho for
virtualizada com o Hyper-V, você precisará empregar a virtualização gráfica para
fornecer aceleração de GPU da GPU física para seus aplicativos ou serviços virtualizados.
No entanto, se a carga de trabalho for executada diretamente em hosts físicos do
Windows Server, você não precisará da virtualização gráfica; seus aplicativos e serviços
já têm acesso aos recursos de GPU e às APIs com suporte nativo no Windows Server.

As seguintes tecnologias de virtualização gráfica estão disponíveis para VMs do Hyper-V

no Windows Server:

DDA (Atribuição de dispositivo discreto)

GPU-P (particionamento de GPU)

Além das cargas de trabalho de VM, o Windows Server também dá suporte à aceleração
de GPU de cargas de trabalho conteinerizadas em contêineres do Windows. Para obter
mais informações, consulte Aceleração de GPU em contêineres do Windows.

DDA (Atribuição de dispositivo discreto)

A DDA (Atribuição de Dispositivo Discreto), também conhecida como passagem de GPU,
que permite dedicar uma ou mais GPUs físicas a uma máquina virtual. Em uma
implantação de DDA, cargas de trabalho virtualizadas são executadas no driver nativo e
normalmente têm acesso total à funcionalidade da GPU. O DDA oferece o nível mais
alto de compatibilidade do aplicativo e potencial de desempenho. O DDA também pode
fornecer aceleração de GPU para VMs Linux, sujeitas a suporte.

Uma implantação de DDA pode acelerar apenas um número limitado de máquinas

virtuais, pois cada GPU física pode fornecer aceleração para no máximo uma VM. Se
você estiver desenvolvendo um serviço cuja arquitetura dá suporte a máquinas virtuais
compartilhadas, considere hospedar várias cargas de trabalho aceleradas por VM. Por
exemplo, se você estiver criando uma solução de Serviços de Área de Trabalho Remota,
poderá melhorar a escala do usuário usando os recursos de várias sessões do Windows
Server para hospedar várias áreas de trabalho de usuário em cada VM. Esses usuários
compartilham os benefícios da aceleração da GPU.
Para obter mais informações, confira estes tópicos:

Planejar a implantação da Atribuição de Dispositivo Discreto

Implantar dispositivos gráficos usando a Atribuição de Dispositivo Discreto

GPU-P (particionamento de GPU)

） Importante

O particionamento de GPU no Windows Server 2025 está em VERSÃO PRELIMINAR.

Estas informações estão relacionadas a um produto de pré-lançamento, que pode
ser bastante modificado antes de ser lançado. A Microsoft não faz nenhuma
garantia, expressa ou implícita, com relação às informações fornecidas aqui.

A partir do Windows Server 2025, o particionamento de GPU permite que você

compartilhe um dispositivo de GPU físico com várias máquinas virtuais (VMs). Com o
particionamento de GPU ou a virtualização de GPU, cada VM obtém uma fração
dedicada da GPU em vez de toda a GPU.

O particionamento de GPU usa a interface SR-IOV (Virtualização de E/S de Raiz Única),

que oferece um limite de segurança com suporte de hardware com desempenho
previsível para cada VM. Cada VM pode acessar apenas os recursos de GPU dedicados a
elas e o particionamento de hardware seguro impede o acesso não autorizado por
outras VMs.

Para saber mais sobre particionamento de GPU, consulte estes artigos:

Particionamento de GPU
Particionar e atribuir GPUs a uma máquina virtual

Comparando o particionamento de DDA e GPU

Considere a seguinte funcionalidade e as diferenças de suporte entre as tecnologias de
virtualização gráfica ao planejar sua implantação:

ﾉ Expandir a tabela

Descrição Atribuição de dispositivo Particionamento de GPU

discreto

Modelo de recurso Somente dedicado Partitioned

da GPU
Descrição Atribuição de dispositivo Particionamento de GPU
discreto

Densidade da VM Baixa (uma ou mais GPUs para uma Alta (uma ou mais GPUs para muitas
VM) VMs)

Compatibilidade do Todas as funcionalidades de GPU Todas as funcionalidades de GPU

aplicativo oferecidas pelo fornecedor (DX 12, oferecidas pelo fornecedor (DX 12,
OpenGL, CUDA) OpenGL, CUDA)

AVC444 Disponível por meio da Política de Disponível por meio da Política de

Grupo Grupo

VRAM da GPU Até o limite de VRAM compatível Até VRAM suportada pela GPU por
com a GPU partição

Driver da GPU no Driver do fornecedor da GPU Driver do fornecedor da GPU

convidado (NVIDIA, AMD, Intel) (NVIDIA, AMD, Intel)
Planejar a implantação de dispositivos
usando Atribuição de Dispositivo
Distinto
Artigo • 14/06/2023

Aplica-se a: Windows Server 2022, Microsoft Hyper-V Server 2019, Windows Server
2019, Microsoft Hyper-V Server 2016, Windows Server 2016

A Atribuição de Dispositivo Distinto permite que o hardware físico PCIe (Peripheral

Component Interconnect Express) fique diretamente acessível a uma VM (máquina
virtual). Este artigo discute os tipos de dispositivos que podem ser usados, os requisitos
do sistema host, as limitações impostas às VMs e as implicações de segurança.

Para atribuição discreta de dispositivo, a Microsoft dá suporte a duas classes de

dispositivo: adaptadores gráficos e dispositivos de armazenamento NVMe. É provável
que outros dispositivos funcionem e os fornecedores de hardware possam oferecer
instruções de suporte para eles. Em caso de outros dispositivos, entre em contato com
os fornecedores de hardware específicos para obter suporte.

Para saber mais sobre outros métodos de virtualização de GPU, confira Planejar a
aceleração de GPU no Windows Server. Se você quiser experimentar a Atribuição de
Dispositivo Distinto, acesse Como implantar dispositivos gráficos usando a Atribuição de
Dispositivo Distinto ou Como implantar dispositivos de armazenamento usando a
Atribuição de Dispositivo Distinto.

VMs e sistemas operacionais convidados com

suporte
A Atribuição de Dispositivo Discreto tem suporte para VMs de Geração 1 ou 2. Os
convidados com suporte incluem:

Windows 10 ou versões mais recentes

Windows Server 2016 ou posterior
Windows Server 2012 R2 com a Atualização para adicionar suporte à Atribuição de
Dispositivo Distinto para Azure .

Para obter mais informações, confira Máquinas virtuais do Linux e do FreeBSD para
Hyper-V no Windows Server e no Windows.
Requisitos de sistema
O sistema precisa atender aos Requisitos de hardware para Windows Server e aos
Requisitos do sistema para Hyper-V no Windows Server. A Atribuição de Dispositivo
Distinto também exige um hardware de classe de servidor capaz de conceder ao
sistema operacional o controle sobre a configuração da malha da PCIe (Native PCI
Express Control). Além disso, o PCIe Root Complex precisa dar suporte ao ACS (Serviço
de Controle de Acesso), que permite que o Hyper-V force todo o tráfego da PCIe por
meio da unidade de gerenciamento de memória de entrada e saída.

Esses recursos geralmente não são expostos diretamente no BIOS do servidor e

geralmente ficam ocultos atrás de outras configurações. Se as mesmas funcionalidades
forem necessárias para dar suporte a SR-IOV e, no BIOS, defina "Habilitar SR-IOV". Entre
em contato com o fornecedor do sistema se você não conseguir identificar a
configuração correta no BIOS.

Para verificar se o hardware tem capacidade de Atribuição de Dispositivo Distinto,

execute o Script de perfil do computador em um host habilitado para Hyper-V. O script
testa se o servidor está configurado corretamente e quais dispositivos são capazes de
fazer a atribuição discreta de dispositivo.

Requisitos do dispositivo
Nem todos os dispositivos PCIe podem ser usados com Atribuição de Dispositivo
Discreto. Não há suporte para dispositivos mais antigos que usam Interrupções PCI
(INTx) herdadas. Para obter mais informações, confira Atribuição de Dispositivo Distinto
– Computadores e dispositivos . Você também pode executar o Script de perfil do
computador para exibir quais dispositivos são capazes de serem usados para atribuição
discreta de dispositivo.

Os fabricantes de dispositivos podem entrar em contato com o representante da

Microsoft para obter mais detalhes.

Driver de dispositivo
A Atribuição de Dispositivo Distinto passa o dispositivo PCIe inteiro para a VM
convidada. Não é necessário instalar um driver de host antes da montagem do
dispositivo na VM. O único requisito no host é que seja possível determinar o Caminho
de Localização PCIe do dispositivo. O driver de dispositivo pode ser instalado para
ajudar na identificação do dispositivo. Uma GPU sem o driver de dispositivo instalado
no host pode aparecer como um dispositivo de renderização básica da Microsoft. Se o
driver de dispositivo estiver instalado, o fabricante e o modelo provavelmente serão
exibidos.

Depois que o dispositivo é montado no convidado, o driver de dispositivo do fabricante

pode ser instalado na máquina virtual convidada como de costume.

Limitações da VM
Devido à natureza da implementação da Atribuição de Dispositivo Distinto, alguns
recursos da VM ficam restritos enquanto um dispositivo é anexado. Os seguintes
recursos não estão disponíveis:

Salvar/restaurar VM
Migração dinâmica de uma VM
O uso da memória dinâmica
Como adicionar a VM a um cluster de HA (alta disponibilidade)

Segurança
A Atribuição de Dispositivo Discreta passa todo o dispositivo para a VM. Isso significa
que todas as funcionalidades desse dispositivo podem ser acessadas pelo sistema
operacional convidado. Algumas funcionalidades, como a atualização de firmware,
podem prejudicar a estabilidade do sistema. Vários avisos são apresentados ao
administrador enquanto o dispositivo é desmontado do host. Você só deve usar a
Atribuição de Dispositivo Distinto quando os locatários das VMs são confiáveis.

Se o administrador quiser usar um dispositivo com um locatário não confiável, os

fabricantes de dispositivos poderão criar um driver de mitigação de dispositivo a ser
instalado no host. Entre em contato com o fabricante do dispositivo para saber se ele
fornece um driver de mitigação de dispositivo.

Se você quiser ignorar as verificações de segurança de um dispositivo que não tem um

driver de mitigação de dispositivo, passe o parâmetro -Force para o cmdlet Dismount-
VMHostAssignableDevice . Ao fazer essa passagem, você alterou o perfil de segurança
desse sistema. Você só deve fazer essa alteração durante a criação de protótipos ou em
ambientes confiáveis.

Caminho do local da PCIe

O caminho do local da PCIe é necessário para desmontar e montar o dispositivo do
host. Um caminho de local de exemplo é
PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000) . O script de perfil do

computador também retorna o caminho do local do dispositivo PCIe.

Obter o caminho do local usando o Gerenciador de

Dispositivos

1. Abra Gerenciador de Dispositivos e localize o dispositivo.

2. Clique com o botão direito do mouse no dispositivo e escolha Propriedades.
3. Navegue até a guia Detalhes, expanda o menu suspenso Propriedade e selecione
Caminhos de Local.
4. Clique com o botão direito do mouse na entrada que começa com PCIROOT e
selecione Copiar para obter o caminho de local desse dispositivo.

Espaço MMIO
Alguns dispositivos, principalmente GPUs, exigem espaço de MMIO adicional para
serem alocados à VM, deixando acessível a memória desse dispositivo. Por padrão, cada
VM começa com 128 MB de espaço de MMIO baixo e 512 MB de espaço de MMIO alto
alocados. No entanto, um dispositivo pode exigir mais espaço MMIO ou vários
dispositivos podem ser passados fazendo com que os requisitos combinados excedam
esses valores. A alteração do espaço MMIO é fácil e pode ser executada no PowerShell
usando os seguintes comandos:

PowerShell

Set-VM -LowMemoryMappedIoSpace 3Gb -VMName $vm

Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName $vm

A maneira mais fácil de determinar quanto espaço MMIO alocar é usar o Script de Perfil
de Computador. Para baixar e executar o script de perfil do computador, execute os
seguintes comandos em um console do PowerShell:

PowerShell

curl -o SurveyDDA.ps1
[Link]
Documentation/live/hyperv-tools/DiscreteDeviceAssignment/SurveyDDA.ps1
.\SurveyDDA.ps1

Para dispositivos que podem ser atribuídos, o script exibe os requisitos de MMIO de um
determinado dispositivo. A seguinte saída de script é um exemplo:

PowerShell

NVIDIA GRID K520

Express Endpoint -- more secure.
...
And it requires at least: 176 MB of MMIO gap space
...

O espaço MMIO baixo é usado apenas por sistemas operacionais de 32 bits e

dispositivos que usam endereços de 32 bits. Na maioria das circunstâncias, é suficiente
definir o espaço alto de MMIO de uma VM, pois as configurações de 32 bits não são
muito comuns.

） Importante

Ao atribuir um espaço MMIO a uma VM, especifique um tamanho suficiente. O

espaço MMIO deve ser a soma do espaço MMIO exigido por todos os dispositivos
atribuídos desejados além de um buffer para outros dispositivos virtuais que
exigem alguns MBs de espaço MMIO. Use os valores de MMIO padrão já descritos
como o buffer para MMIO baixo e alto (128 MB e 512 MB, respectivamente).
Considere o exemplo anterior. Se você atribuir uma só GPU K520, defina o espaço
MMIO da VM como o valor emitido pelo script do perfil de computador, mais um
buffer: 176 MB + 512 MB. Se você atribuir três GPUs K520, defina o espaço MMIO como
três vezes o volume base de 176 MB, mais um buffer, ou 528 MB + 512 MB.

Para obter uma visão mais detalhada do espaço MMIO, confira Atribuição de Dispositivo
Distinto – GPUs no blog Tech Community.

Script do perfil de computador

Para identificar se o servidor está configurado corretamente e quais dispositivos podem
ser passados usando a Atribuição de Dispositivo Distinto, execute o script
SurveyDDA.ps1. do PowerShell.

Antes de usar o script, verifique se a função Hyper-V está instalada e execute o script
em uma janela de comando do PowerShell com privilégios de administrador.

Se o sistema estiver configurado incorretamente para dar suporte à Atribuição de

Dispositivo Distinto, a ferramenta exibirá uma mensagem de erro com os detalhes do
problema. Se o sistema estiver configurado corretamente, a ferramenta vai enumerar
todos os dispositivos localizados no barramento PCIe.

Para cada dispositivo encontrado, a ferramenta exibirá se pode ser usada com a
atribuição discreta de dispositivo. Se um dispositivo for identificado como compatível
com a atribuição discreta de dispositivo, o script indicará um motivo. Quando um
dispositivo for identificado como compatível, o caminho de localização do dispositivo
será exibido. Além disso, se esse dispositivo exigir espaço de MMIO, isso também será
exibido.
O que é Virtualização Aninhada?
Artigo • 31/07/2024

A virtualização aninhada é um recurso que permite executar o Hyper-V em uma VM

(máquina virtual) do Hyper-V. Ao longo dos anos, o hardware melhorou e os casos de
uso da Virtualização Aninhada se expandiram. Por exemplo, a Virtualização Aninhada
pode ser útil para:

Executar aplicativos ou emuladores em uma VM aninhada

Testar versões de software em VMs
Reduzir os tempos de implantação para ambientes de treinamento
Usar o isolamento do Hyper-V para contêineres

Os processadores modernos incluem recursos de hardware que tornam a virtualização

mais rápida e mais segura. O Hyper-V conta com essas extensões de processador para
executar máquinas virtuais (por exemplo, Intel VT-x e AMD-V). A virtualização aninhada
torna esse suporte a hardware disponível para máquinas virtuais convidadas.

O diagrama a seguir mostra o Hyper-V sem aninhamento. O hipervisor do Hyper-V

assume o controle total dos recursos de virtualização de hardware (seta laranja) e não
os expõe ao sistema operacional convidado.

Em contrapartida, o diagrama a seguir mostra o Hyper-V com a virtualização aninhada

habilitada. Nesse caso, o Hyper-V expõe as extensões de virtualização de hardware para
suas máquinas virtuais. Com o aninhamento habilitado, uma máquina virtual convidada
pode instalar seu próprio hipervisor e executar suas próprias VMs convidadas.
Redimensionamento de Memória de Runtime e
Memória Dinâmica
Quando o Hyper-V está em execução em uma máquina virtual, a máquina virtual deve
ser desativada para ajustar sua memória. Isso significa que mesmo se a memória
dinâmica estiver habilitada, a quantidade de memória não varia. Habilitar a virtualização
aninhada não tem efeito na memória dinâmica ou redimensionamento de memória de
runtime.

Para máquinas virtuais sem memória dinâmica habilitada, a tentativa de ajustar a

quantidade de memória enquanto ela estiver em execução falhará. A incompatibilidade
ocorre somente enquanto o Hyper-V está em execução na VM.

Aplicativos de virtualização de terceiros

Aplicativos de virtualização diferentes do Hyper-V não tem suporte em máquinas
virtuais do Hyper-V e provavelmente falharão. Os aplicativos de virtualização incluem
qualquer software que exija extensões de virtualização de hardware.

Cenários com suporte

O uso de uma VM do Hyper-V aninhada em produção é compatível com o Azure e o
local nos cenários a seguir. Também recomendamos que você verifique se seus serviços
e aplicativos também têm suporte.
A Virtualização Aninhada não é adequada para Clustering de Failover do Windows
Server e aplicativos sensíveis ao desempenho. Recomendamos que você avalie
totalmente os serviços e aplicativos.

VMs do Hyper-V em VMs do Hyper-V

Executar VMs do Hyper-V aninhadas em VMs do Hyper-V é ótimo para laboratórios de
teste e ambientes de avaliação. Especialmente quando as configurações podem ser
facilmente modificadas e os estados salvos podem ser usados na reversão para
configurações específicas. Os laboratórios de teste normalmente não exigem o mesmo
SLA (contrato de nível de serviço) que os ambientes de produção.

Há suporte para ambientes de produção que executam VMs do Hyper-V em execução

em VMs do Hyper-V. No entanto, é recomendável garantir que seus serviços e
aplicativos também sejam compatíveis. Se você usar uma VM aninhada do Hyper-V em
produção, é recomendável avaliar totalmente se os serviços ou aplicativos fornecem o
comportamento esperado.

Para saber mais sobre como configurar a Virtualização Aninhada no Azure, consulte
nosso blog da Tech Community Como configurar a virtualização aninhada para VM/VHD
do Azure .

Virtualização de terceiros na virtualização do Hyper-V

Embora possa ser possível que a virtualização de terceiros seja executada no Hyper-V, a
Microsoft não testa esse cenário. Não há suporte para virtualização de terceiros na
virtualização do Hyper-V. Verifique se o fornecedor do hipervisor dá suporte a esse
cenário.

Virtualização do Hyper-V na virtualização de terceiros

Embora possa ser possível que a virtualização do Hyper-V seja executada na
virtualização de terceiros, a Microsoft não testa esse cenário. Não há suporte para a
virtualização do Hyper-V na virtualização de terceiros, verifique se o fornecedor do
hipervisor dá suporte a esse cenário.

Azure Stack HCI aninhado em VMs do Hyper-V

O Azure Stack HCI foi projetado e testado para ser executado em hardware físico
validado. O Azure Stack HCI pode ser executado aninhado em uma máquina virtual para
avaliação, mas não há suporte para ambientes de produção em uma configuração
aninhada.

Para saber mais sobre o Azure Stack HCI aninhado em VMs do Hyper-V, consulte
Virtualização aninhada no Azure Stack HCI.

Contêineres isolados do Hyper-V em execução aninhados

no Hyper-V
A Microsoft oferece isolamento do Hyper-V para contêineres. Esse modo de isolamento
oferece segurança aprimorada e maior compatibilidade entre as versões do host e do
contêiner. Com o isolamento do Hyper-V, várias instâncias de contêiner são executadas
simultaneamente em um host. Cada contêiner é executado dentro de uma máquina
virtual altamente otimizada e obtém efetivamente seu próprio kernel. Como um
contêiner isolado do Hyper-C oferece isolamento por meio de uma camada do
hipervisor entre si e o host do contêiner, quando o host do contêiner é uma máquina
virtual baseada no Hyper-V, há uma sobrecarga de desempenho. A sobrecarga de
desempenho associada ocorre em termos de tempo de inicialização do contêiner,
armazenamento, rede e operações de CPU.

Quando um contêiner isolado do Hyper-V é executado em uma VM do Hyper-V, ele

está em execução aninhado. O uso de uma VM do Hyper-V abre muitos cenários úteis,
mas também aumenta a latência, pois há dois níveis de hipervisores em execução acima
do host físico.

Há suporte para a execução de contêineres isolados do Hyper-V aninhados no Hyper-V.

Há suporte para um nível de virtualização aninhada na produção, o que permite
implantações isoladas de contêineres.

Para saber mais sobre contêineres aninhados do Hyper-V, consulte Ajuste de

desempenho em contêineres do Windows Server.

Executando o WSL2 em uma VM do Hyper-V em

execução aninhada no Hyper-V
O Subsistema do Windows para Linux (WSL) é um recurso do sistema operacional do
Windows que permite executar um sistema de arquivos Linux, juntamente com
ferramentas de linha de comando do Linux e aplicativos GUI, diretamente no Windows.

Há suporte para a execução do WSL2 em uma VM Hyper-V aninhada no Hyper-V.

Para saber mais sobre como habilitar o WSL 2 para execução em uma VM, consulte
Perguntas frequentes sobre o Subsistema do Windows para Linux.

Próxima etapa
Executar o Hyper-V em uma Máquina Virtual com a Virtualização Aninhada

Comentários
Esta página foi útil?  Yes  No
Configurar redes de área local virtual
para o Hyper-V
Artigo • 16/08/2024

VLANs (redes de área local virtual) oferecem uma maneira de isolar o tráfego de rede.
As VLANs são configuradas em comutadores e roteadores que dão suporte a 802.1q.
Caso você configure várias VLANs e queira que a comunicação ocorra entre elas, será
preciso configurar os dispositivos de rede que permitem isso.

É necessário o seguinte para configurar as VLANs:

Um adaptador de rede físico e um driver que dá suporte à marcação VLAN de

802.1q.
Um comutador de rede física que dá suporte à marcação de VLAN 802.1q.

No host, configure o comutador virtual para permitir o tráfego de rede na porta do

comutador físico. Isso é para as IDs de VLAN que você deseja usar internamente com
máquinas virtuais. Em seguida, configure a máquina virtual para especificar a VLAN que
a máquina virtual usa para todas as comunicações de rede.

Para permitir que um comutador virtual use

uma VLAN
1. No Gerenciador do Hyper-V, selecione Gerenciador de Comutador Virtual no
painel Ações à direita.

2. No Gerenciador de Comutador Virtual, em Comutadores Virtuais à esquerda,

selecione um comutador virtual conectado a um adaptador de rede física que dê
suporte a VLANs.

3. Em ID de VLAN no painel à direita, selecione Habilitar identificação de LAN

virtual para o sistema operacional de gerenciamento e digite um número para a
ID da VLAN.

4. Selecione OK.

Todo o tráfego que passa pelo adaptador de rede física conectado ao comutador virtual
é marcado com a ID de VLAN que você definiu.
Para permitir que uma máquina virtual use
uma VLAN
1. No Gerenciador do Hyper-V, em Máquinas Virtuais, clique com o botão direito na
máquina virtual apropriada e selecione Configurações. Ou selecione o computador
e, em seguida, selecione Configurações, sob o nome do computador no painel à
direita.

2. Na tela Configurações, em Hardware no painel à esquerda, selecione um

Adaptador de Rede que tenha um comutador virtual configurado com uma VLAN.

3. Em ID de VLAN no painel à direita, selecione Habilitar identificação de LAN

virtual e digite a mesma ID de VLAN especificada para o comutador virtual.

4. Selecione OK.

Se a máquina virtual precisar usar mais VLANs, siga um destes procedimentos:

Conecte mais adaptadores de rede virtual a comutadores virtuais apropriados e

atribua as IDs de VLAN. Certifique-se de configurar os endereços IP corretamente
e se o tráfego que pretende rotear por meio da VLAN também usa o endereço IP
correto.

Configure o adaptador de rede virtual no modo tronco usando o cmdlet Set-

VMNetworkAdapterVlan.

Confira também
Comutador Virtual do Hyper-V

Comentários
Esta página foi útil?  Yes  No
Exportar e Importar máquinas virtuais
Artigo • 09/03/2023

Aplica-se a: Windows Server 2022, Windows 10, Windows Server 2016, Microsoft
Hyper-V Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019

Este artigo mostra como exportar e importar uma máquina virtual, que é uma forma
rápida de movê-la ou copiá-la. Este artigo também discute algumas das escolhas a
serem feitas ao fazer uma exportação ou uma importação.

Exportar uma Máquina Virtual

Uma exportação reúne todos os arquivos necessários em uma unidade: arquivos de
disco rígido virtual, arquivos de configuração de máquina virtual e arquivos de ponto de
verificação. Faça isso em uma máquina virtual no estado iniciado ou parado.

Usando o Gerenciador do Hyper-V

Para criar uma exportação de máquina virtual:

1. No Gerenciador do Hyper-V, clique com o botão direito na máquina virtual e

selecione Exportar.

2. Escolha o local de armazenamento dos arquivos exportados e clique em Exportar.

Quando a exportação for concluída, você poderá ver todos os arquivos exportados no
local de exportação.

Usando o PowerShell
Abra uma sessão como Administrador e execute um comando como o seguinte, depois
de substituir o <nome da VM> e o <caminho>:

PowerShell

Export-VM -Name \<vm name\> -Path \<path\>

Para obter detalhes, confira Export-VM.

Importar uma Máquina Virtual
Importar uma máquina virtual a registra com o host do Hyper-V. Você pode importá-la
de novo para o host ou para um novo host. Se a estiver importando para o mesmo host,
não precisará exportar a máquina virtual primeiro, pois o Hyper-V tenta recriar a
máquina virtual com base nos arquivos disponíveis. A importação de uma máquina
virtual a registra, de modo que ela possa ser usada no host do Hyper-V.

） Importante

As configurações de máquina virtual do Hyper-V têm um número de versão

específico. Você só poderá importar uma máquina virtual se o host do Hyper-V der
suporte a essa versão de configuração. Normalmente, isso significa que você pode
importar uma máquina virtual para um host do Hyper-V que executa uma versão
mais recente do Hyper-V, mas não é possível importar uma máquina virtual criada
em uma versão mais recente do Hyper-V para uma versão mais antiga do Hyper-V.
Confira Versões compatíveis de configuração de máquina virtual para obter mais
informações.

O assistente para Importar Máquina Virtual também ajuda a corrigir incompatibilidades

que possam existir na movimentação de um host para outro. Essas são diferenças
comuns no hardware físico, como memória, comutadores virtuais e processadores
virtuais.

Importação usando o Gerenciador do Hyper-V

Para importar uma máquina virtual:

1. No menu Ações do Gerenciador do Hyper-V, clique em Importar Máquina Virtual.

2. Clique em Próximo.

3. Selecione a pasta que contém os arquivos exportados e clique em Avançar.

4. Escolha a máquina virtual a ser importada.

5. Escolha o tipo de importação e clique em Avançar. (Para ver as descrições, confira

Tipos de importação abaixo.)

6. Clique em Concluir.

Importar usando o PowerShell

Use o cmdlet Import-VM seguindo o exemplo do tipo de importação desejado. Para ver
as descrições dos tipos, confira Tipos de importação abaixo.

Registro no local

Esse tipo de importação usa os arquivos no local em que estão armazenados no

momento da importação e retém a ID das máquinas virtuais. O comando a seguir
mostra um exemplo de um arquivo de importação. Execute um comando semelhante
com valores próprios.

PowerShell

Import-VM -Path 'C:\<vm export path>\2B91FEB3-F1E0-4FFF-B8BE-

[Link]'

Restaurar
Para importar a máquina virtual que especifica um caminho próprio para os arquivos de
máquina virtual, execute um comando como este, substituindo os exemplos pelos seus
valores:

PowerShell

Import-VM -Path 'C:\<vm export path>\2B91FEB3-F1E0-4FFF-B8BE-

[Link]' -Copy -VhdDestinationPath 'D:\Virtual Machines\WIN10DOC'
-VirtualMachinePath 'D:\Virtual Machines\WIN10DOC'

Importação como uma cópia

Para concluir uma importação de cópia e mover os arquivos da máquina virtual para o
local padrão do Hyper-V, execute um comando como este, substituindo os exemplos
pelos seus valores:

PowerShell

Import-VM -Path 'C:\<vm export path>\2B91FEB3-F1E0-4FFF-B8BE-

[Link]' -Copy -GenerateNewId

Para obter detalhes, confira Import-VM.

Tipos de importação
O Hyper-V inclui três tipos de importação:

Registrar-se no local – Esse tipo pressupõe que os arquivos de exportação estejam

no local em que você armazenará e executará a máquina virtual. A máquina virtual
importada tem a mesma ID que no momento da exportação. Por isso, se a
máquina virtual já estiver registrada no Hyper-V, ela precisa ser excluída para que a
importação funcione. Quando a importação for concluída, os arquivos de
exportação passam a ser os arquivos de estado em execução e não podem ser
removidos.

Restaurar a máquina virtual – Restaure a máquina virtual para um local escolhido

ou use o padrão para o Hyper-V. Esse tipo de importação cria uma cópia do
arquivo exportado e os move para o local selecionado. Quando importado, a
máquina virtual tem a mesma ID que no momento da exportação. Por isso, se a
máquina virtual já estiver em execução no Hyper-V, ela precisará ser excluída para
que a importação seja concluída. Quando a importação for concluída, os arquivos
exportados permanecerão intactos, podendo ser removidos ou importados
novamente.

Copiar a máquina virtual – Isso é semelhante ao tipo Restaurar, pois você

seleciona um local para os arquivos. A diferença é que a máquina virtual importada
tem uma nova ID exclusiva, o que significa que você pode importar a máquina
virtual para o mesmo host várias vezes.
Configurar hosts para migração
dinâmica sem cluster de failover
Artigo • 19/06/2024

Aplica-se a: Windows Server 2022, Windows Server 2016, Microsoft Hyper-V Server
2016, Windows Server 2019 e Microsoft Hyper-V Server 2019

Este artigo mostra como configurar hosts que não estão clusterizados para que você
possa fazer migrações dinâmicas entre eles. Use estas instruções se você não configurou
a migração dinâmica quando instalou o Hyper-V ou se quiser alterar as configurações.
Para configurar hosts clusterizados, use as ferramentas para cluster de failover.

Requisitos para configurar a migração dinâmica

Para configurar hosts não clusterizados para a migração dinâmica, você precisará de:

Uma conta de usuário com permissão para executar as várias etapas. A associação
no grupo de Administradores do Hyper-V local ou no grupo Administradores nos
computadores de origem e de destino atende a esse requisito, a menos que você
esteja configurando a delegação restrita. A associação no grupo Administradores
de Domínio é necessária para configurar a delegação restrita.

A função Hyper-V no Windows Server 2016 ou Windows Server 2012 R2 instalada

nos servidores de origem e de destino. Você pode fazer uma migração dinâmica
entre hosts que executam o Windows Server 2016 e o Windows Server 2012 R2 se
a máquina virtual tiver pelo menos a versão 5.
Para obter instruções de atualização de versão, consulte Atualizar a versão da
máquina virtual no Hyper-V no Windows 10 ou no Windows Server 2016. Para
obter instruções de instalação, consulte Instalar a função Hyper-V no Windows
Server.

Computadores de origem e de destino que pertencem ao mesmo domínio Active

Directory ou a domínios que confiam uns nos outros.

As ferramentas de gerenciamento do Hyper-V instaladas em um computador que

execute o Windows Server 2016 ou o Windows 10, a menos que as ferramentas
sejam instaladas no servidor de origem ou de destino e você execute as
ferramentas do servidor.
Considere as opções de autenticação e rede
Considere como você quer configurar o seguinte:

Autenticação: qual protocolo será usado para autenticar o tráfego de migração

dinâmica entre os servidores de origem e de destino? A escolha determina se você
precisará entrar no servidor de origem antes de iniciar uma migração dinâmica:

O Kerberos possibilita evitar a necessidade de entrar no servidor, mas exige que

a delegação restrita seja configurada. Veja abaixo para obter instruções.

O CredSSP possibilita que você evite configurar a delegação restrita, mas exige
que você entre no servidor de origem. Você pode fazer isso por meio de uma
sessão do console local, uma sessão da Área de Trabalho Remota ou uma
sessão do Windows PowerShell remota.

O CredSPP exige login para situações que podem não ser óbvias. Por exemplo,
se você entrar no TestServer01 para mover uma máquina virtual para
TestServer02 e depois quiser retornar a máquina virtual para TestServer01, você
precisará entrar no TestServer02 antes de tentar retornar a máquina virtual para
TesterServer01. Se você não fizer isso, a tentativa de autenticação falhará,
ocorrerá um erro e a seguinte mensagem será exibida:

"A operação de migração de máquina virtual falhou na origem da migração.

Falha ao estabelecer uma conexão com o host nome do computador: credenciais
não disponíveis no pacote de segurança 0x8009030E."

Desempenho: faz sentido configurar opções de desempenho? Essas opções

podem reduzir o uso de rede e CPU, bem como fazer com que as migrações
dinâmicas sejam mais rápidas. Considere seus requisitos e sua infraestrutura e
teste diferentes configurações para ajudá-lo a decidir. As opções estão descritas
no final da etapa 2.

Preferência de rede: Você permitirá o tráfego da migração dinâmica através de

qualquer rede disponível ou isolará o tráfego em redes específicas? Como prática
recomendada de segurança, convém isolar o tráfego em redes confiáveis privadas
porque o tráfego da migração ao vivo não é criptografado quando enviado pela
rede. O isolamento de rede pode ser obtido por uma rede fisicamente isolada ou
por outra tecnologia de rede confiável, como as VLANs.

Atualizando para o Windows Server 2025 (visualização)

 ） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

A partir do Windows Server 2025 (visualização), o Credential Guard é habilitado por

padrão em todos os servidores ingressados no domínio que não são Controladores de
Domínio. Como resultado, talvez você não consiga mais usar o Live Migration com o
Hyper-V após a atualização para o Windows Server 2025. A delegação baseada em
CredSSP é o padrão para o Windows Server 2022 e versões anteriores para migração ao
vivo. Para obter mais informações, consulte Configurar o Credential Guard.

Etapa 1: Configurar a delegação restrita

(opcional)
Se você decidiu usar o Kerberos para autenticar o tráfego da migração dinâmica,
configure a delegação restrita usando uma conta que seja membro do grupo
Administradores de Domínio.

Usar o snap-in Usuários e Computadores para configurar

a delegação restrita
1. Abra o snap-in Usuários e Computadores do Active Directory. (Em Gerenciador do
Servidor, selecione o servidor se ele não estiver selecionado, clique em
Ferramentas>>Usuários e Computadores do Active Directory).

2. No painel de navegação em Usuários e Computadores do Active Directory,

selecione o domínio e clique duas vezes na pasta Computadores.

3. Na pasta Computadores, clique com o botão direito do mouse na conta do

computador do servidor de origem e clique em Propriedades.

4. Em Propriedades, clique na guia Delegação.

5. Na guia Delegação, selecione Confiar neste computador para delegação somente

em serviços especificados e, em seguida, selecione Usar qualquer protocolo de
autenticação.

6. Clique em Adicionar.
 7. Em Adicionar Serviços, clique em Usuários ou Computadores.

8. Em Selecionar Usuários ou Computadores, digite o nome do servidor de destino.

Clique em Verificar Nomes para verificá-lo e, em seguida, clique OK.

9. Em Adicionar Serviços, nas lista de serviços disponíveis, execute as etapas a seguir

e depois clique em OK:

Para mover o armazenamento de máquina virtual, selecione cifs. Isso é

necessário se você quiser mover o armazenamento com a máquina virtual,
bem como se quiser mover apenas o armazenamento de uma máquina
virtual. Se o servidor estiver configurado para usar o armazenamento SMB
para Hyper-V, isso já deve estar selecionado.

Para mover máquinas virtuais, selecione Serviço de Migração de Sistema

Virtual da Microsoft.

10. Na guia Delegação da caixa de diálogo Propriedades, verifique se os serviços

selecionados na etapa anterior estão listados como os serviços aos quais o
computador de destino poderá apresentar credenciais delegadas. Clique em OK.

11. Na pasta Computers, selecione a conta de computador do servidor de destino e

repita o processo. Na caixa de diálogo Selecionar Usuários ou Computadores,
especifique o nome do servidor de destino.

As alterações de configuração entrarão em vigor depois que ocorrerem os dois

seguintes eventos:

As alterações são replicadas nos controladores de domínio aos quais os servidores

que executam o Hyper-V estão conectados.
O controlador de domínio emite um novo tíquete Kerberos.

Etapa 2: configurar os computadores de origem

e de destino para migração dinâmica
Esta etapa inclui a escolha de opções para autenticação e rede. Como prática
recomendada de segurança, convém selecionar redes específicas para o tráfego da
migração dinâmica, conforme discutido acima. Esta etapa também mostra como
escolher a opção de desempenho.

Usar o Gerenciador do Hyper-V para configurar os

computadores de origem e de destino para migração
dinâmica
1. Abra o Gerenciador do Hyper-V. (No Gerenciador do Servidor, clique em
Ferramentas>>Gerenciador do Hyper-V.)

2. No painel de navegação, selecione um dos servidores. (Se ele não estiver listado,
clique com o botão direito do mouse em Gerenciador do Hyper-V, clique em
Conectar ao Servidor, digite o nome do servidor e clique em OK. Repita para
adicionar mais servidores.)

3. No painel de Ações, clique em Configurações do Hyper-V>>Migrações

dinâmicas.

4. No painel Migrações ao Vivo, marque Habilitar migrações ao vivo de entrada e

saída.

5. Em Migrações dinâmicas simultâneas, especifique um número diferente se não

quiser usar o padrão de 2.

6. Em Migrações ao vivo de entrada, se desejar usar conexões de redes específicas

para aceitar o tráfego da migração ao vivo, clique em Adicionar para digitar as
informações de endereços IP. Caso contrário, clique em Usar qualquer rede
disponível para migração ao vivo. Clique em OK.

7. Para escolher o Kerberos e as opções de desempenho, expanda Migrações

dinâmicas e selecione Recursos Avançados.

Se você tiver configurado a delegação restrita, em Protocolo de

autenticação, selecione Kerberos.
Em Opções de desempenho, examine os detalhes e escolha uma opção
diferente se for apropriado para seu ambiente.

8. Clique em OK.

9. Selecione o outro servidor no Gerenciador Hyper-V e repita as etapas.

Usar o Windows PowerShell para configurar os

computadores de origem e de destino para migração
dinâmica
Três cmdlets estão disponíveis para configurar a migração dinâmica em hosts não
clusterizados: Enable-VMMigration, Set-VMMigrationNetwork e Set-VMHost. Este
exemplo usa os três e faz o seguinte:
 Configura a migração dinâmica no host local
Permite o tráfego de migração de entrada somente em uma rede específica
Escolhe o Kerberos como o protocolo de autenticação

Cada linha representa um comando separado.

PowerShell

PS C:\> Enable-VMMigration

PS C:\> Set-VMMigrationNetwork [Link]

PS C:\> Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

O cmdlet Set-VMHost também permite escolher uma opção de desempenho (e muitas

outras configurações de host). Por exemplo, para escolher o SMB, mas deixar o
protocolo de autenticação definido como o padrão de CredSSP, digite:

PowerShell

PS C:\> Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

Esta tabela descreve como funcionam as opções de desempenho.

ﾉ Expandir a tabela

Opção Descrição

TCP/IP Copia a memória da máquina virtual para o servidor de destino por uma conexão
TCP/IP.

Compactação Compacta o conteúdo da memória da máquina virtual antes de copiá-lo para o

servidor de destino em uma conexão TCP/IP. Observação: Essa é a configuração
padrão.

SMB Copia a memória da máquina virtual para o servidor de destino através de uma
conexão SMB 3.0.
– O SMB Direct é usado quando os adaptadores de rede nos servidores de
origem e destino têm recursos RDMA (Acesso Remoto Direto à Memória)
habilitados.
– O SMB Multichannel detecta e usa automaticamente várias conexões quando
uma configuração adequada de SMB Multichannel é identificada.

Para obter mais informações, consulte Melhorar o desempenho de um servidor

de arquivos com o SMB Direct.
Próximas etapas
Depois de configurar os hosts, você estará pronto para fazer uma migração dinâmica.
Para obter instruções, confira Usar a migração dinâmica sem Cluster de Failover para
mover uma máquina virtual.
Atualizar a versão da máquina virtual no
Hyper-V no Windows ou no Windows
Server
Artigo • 11/04/2023

Aplica-se a: Windows Server 2022, Windows 10, Windows Server 2019, Windows
Server 2016

Disponibilize os recursos mais recentes do Hyper-V em suas máquinas virtuais fazendo

upgrade da versão de configuração. Não faça isso até:

Ter atualizado seus hosts Hyper-V para a versão mais recente do Windows ou do
Windows Server.
Atualizar o nível funcional do cluster.
Ter certeza de que não precisará mover a máquina virtual de volta para um host
Hyper-V que executa uma versão anterior do Windows ou do Windows Server.

Para obter mais informações, consulte Upgrade sem interrupção do sistema operacional
de cluster e Executar um upgrade sem interrupção de um cluster de host Hyper-V no
VMM.

Etapa 1: Verificar as versões de configuração da

máquina virtual
1. Na área de trabalho do Windows, clique no botão Iniciar e digite qualquer parte
do nome Windows PowerShell.
2. Clique com o botão direito do mouse no Windows PowerShell e selecione
Executar como Administrador.
3. Use o cmdlet Get-VM. Execute o comando a seguir para obter as versões de suas
máquinas virtuais.

PowerShell

Get-VM * | Format-Table Name, Version

Você também pode ver a versão de configuração no Gerenciador do Hyper-V

selecionando a máquina virtual e examinando a guia Resumo.
Etapa 2: Atualizar a versão de configuração da
máquina virtual
1. Desligue a máquina virtual no Gerenciador do Hyper-V.
2. Selecione Ação > Fazer Upgrade da Versão de Configuração. Se essa opção não
está disponível para a máquina virtual, ela já está na maior versão de configuração
com suporte pelo host Hyper-V.

Para atualizar a versão de configuração da máquina virtual usando o Windows

PowerShell, use o cmdlet Update-VMVersion. Execute o comando a seguir, em que
vmname é o nome da máquina virtual.

PowerShell

Update-VMVersion <vmname>

Versões de configuração de máquina virtual

com suporte
Usando o cmdlet do PowerShell Get-VMHostSupportedVersion, você pode ver a quais
versões de configuração de máquina virtual o Host do Hyper-V dá suporte. Quando
você cria uma máquina virtual, ela é criada com a versão de configuração padrão. Para
ver as versões de configuração de máquina virtual compatíveis com o Host do Hyper-V
e qual é o padrão, execute o comando a seguir.

PowerShell

Get-VMHostSupportedVersion

Se você precisar criar uma máquina virtual que possa mover para um Host do Hyper-V
que executa uma versão mais antiga do Windows, use o cmdlet New-VM com o
parâmetro -Version . Por exemplo, para criar uma máquina virtual chamada
"WindowsCV5" com a versão de configuração 5.0, execute o seguinte comando:

PowerShell

New-VM -Name "WindowsCV5" -Version 5.0

７ Observação
 Você só poderá importar uma máquina virtual se o host do Hyper-V der suporte a
essa versão de configuração. Normalmente, isso significa que você pode importar
uma máquina virtual para um host do Hyper-V que executa uma versão mais
recente do Hyper-V, mas não é possível importar uma máquina virtual criada em
uma versão mais recente do Hyper-V para uma versão mais antiga do Hyper-V.

Se a versão de configuração da VM não estiver listada como compatível com o

sistema operacional host Hyper-V na tabela abaixo, você precisará atualizar a
versão de configuração da VM para uma versão mais recente ou criar uma VM da
mesma geração usando os discos rígidos virtuais existentes antes de iniciar a VM.

Versões de configuração de VM com suporte a hosts de

manutenção de longo prazo
A tabela a seguir lista as versões de configuração da VM para hosts que executam uma
versão de serviço de longo prazo do Windows.

Versão do Windows 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
do host Hyper-V

Windows Server ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
2022

Windows 10 ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
Enterprise LTSC 2021

Windows Server ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
2019

Windows 10 ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Enterprise LTSC 2019

Windows Server ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔
2016

Windows 10 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔
Enterprise 2016 LTSB

Windows 10 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔
Enterprise 2015 LTSB

Windows Server ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔
2012 R2

Windows 8.1 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔
Versões de configuração de VM com suporte a hosts do
Canal Semestral
A tabela a seguir lista as versões de configuração da VM para hosts que executam uma
versão de Canal Semestral do Windows. Para obter mais informações sobre versões de
Canal Semestral do Windows, visite as páginas a seguir para Windows Server e
Windows.

Versão do Windows 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
do host Hyper-V

Windows 11 (versão ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
21H2)

Atualização de ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
novembro de 2021
do Windows 10
(versão 21H2)

Atualização de maio ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
de 2021 do
Windows 10 (versão
21H1)

Windows Server, ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
versão 20H2

Atualização de ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
outubro de 2020 do
Windows 10 (versão
20H2)

Windows Server, ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
versão 2004

Atualização de maio ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
de 2020 do
Windows 10 (versão
2004)

Windows Server, ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
versão 1909

Atualização de ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
novembro de 2019
para Windows 10
(versão 1909)
 Versão do Windows 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
do host Hyper-V

Windows Server, ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
versão 1903

Atualização de maio ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
de 2019 do
Windows 10 (versão
1903)

Windows Server, ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
versão 1809

Atualização de ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
outubro de 2018
para Windows 10
(Versão 1809)

Windows Server, ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
versão 1803

Atualização de abril ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
de 2018 para o
Windows 10 (versão
1803)

Windows 10 Fall ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Creators Update
(versão 1709)

No Windows 10 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔
Creators Update
(versão 1703)

Na Atualização de ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔
Aniversário do
Windows 10 (versão
1607)

Por que devo fazer upgrade da versão de

configuração da máquina virtual?
Quando você move ou importa uma máquina virtual para um computador que executa
o Hyper-V no Windows Server 2019, no Windows Server 2016 ou no Windows 10, a
configuração da máquina virtual não é atualizada automaticamente. Isso significa que
você pode mover a máquina virtual de volta para um host Hyper-V que executa uma
versão anterior do Windows ou do Windows Server. Mas isso também significa que você
não pode usar alguns dos novos recursos de máquina virtual até atualizar manualmente
a versão de configuração.

） Importante

Você não pode fazer downgrade de uma versão de configuração de máquina

virtual depois de fazer upgrade.

A versão de configuração da máquina virtual representa a compatibilidade da

configuração da máquina virtual, do estado salvo e dos arquivos de instantâneo com a
versão do Hyper-V. Ao atualizar a versão de configuração, você alterará a estrutura de
arquivos usada para armazenar a configuração das máquinas virtuais e os arquivos de
ponto de verificação. Você também atualiza a versão de configuração para a versão mais
recente compatível com esse host Hyper-V. Máquinas virtuais atualizadas agora usam
um novo formato de arquivo de configuração, que foi projetado para aumentar a
eficiência de leitura e gravação de dados de configuração de máquina virtual. A
atualização também reduz a possibilidade de obter dados corrompidos em caso de
falha de armazenamento.

A tabela a seguir lista descrições, extensões de nome de arquivo e locais padrão para
cada tipo de arquivo usado em máquinas virtuais novas ou atualizadas.

Tipos de Descrição
arquivo de
máquina
virtual

Configuração Informações de configuração de máquina virtual armazenadas no formato de

arquivo binário.
Extensão de nome de arquivo: .vmcx
Local padrão: C:\ProgramData\Microsoft\Windows\Hyper-V\Máquinas Virtuais

Estado do Informações de estado de runtime de máquina virtual armazenadas no formato

runtime de arquivo binário.
Extensão de nome de arquivo: .vmrs e .vmgs
Local padrão: C:\ProgramData\Microsoft\Windows\Hyper-V\Máquinas Virtuais

Disco rígido Armazena discos rígidos virtuais para a máquina virtual.

virtual Extensão de nome de arquivo: .vhd ou .vhdx
Local padrão: C:\ProgramData\Microsoft\Windows\Hyper-V\Discos Rígidos
Virtuais
 Tipos de Descrição
arquivo de
máquina
virtual

Disco rígido Diferenciando arquivos de disco usados para pontos de verificação de máquina
virtual virtual.
automático Extensão de nome de arquivo: .avhdx
Local padrão: C:\ProgramData\Microsoft\Windows\Hyper-V\Discos Rígidos
Virtuais

Ponto de Pontos de verificação são armazenados em vários arquivos de ponto de

verificação verificação. Cada ponto de verificação cria um arquivo de configuração e o
arquivo de estado de runtime.
Extensões de nome de arquivo: .vmrs e .vmcx
Local padrão: C:\ProgramData\Microsoft\Windows\Instantâneos

O que acontece que seu não fizer upgrade da

versão de configuração de máquina virtual?
Se você tem máquinas virtuais criadas com uma versão anterior do Hyper-V, alguns
recursos que estão disponíveis no sistema operacional do host mais recente podem não
funcionar com essas máquinas virtuais enquanto não atualizar a versão de configuração.

Como diretriz geral, recomendamos a atualização da versão de configuração depois de

você ter feito upgrade dos hosts de virtualização com êxito para uma versão mais
recente do Windows e tiver certeza de que não precisará reverter. Quando você está
usando o recurso upgrade sem interrupção do SO do cluster, ele normalmente seria
feito após a atualização do nível funcional do cluster. Dessa forma, você também se
beneficiará de novos recursos e alterações internas e otimizações.

７ Observação

Depois que a versão de configuração da VM for atualizada, a VM não poderá iniciar

em hosts que não dão suporte à versão de configuração atualizada.

A tabela a seguir mostra a versão de configuração mínima da máquina virtual necessária

para usar alguns recursos do Hyper-V.

Recurso Versão de
configuração da VM
mínima
 Recurso Versão de
configuração da VM
mínima

Permite recursos de processador adicionais para Perfmon 9.0

Expor automaticamente a configuração multithreading simultâneo para 9.0

VMs em execução em hosts usando o Agendador Principal

Suporte à hibernação 9.0

Aumentar o número máximo padrão de dispositivos virtuais para 64 por 8.3

dispositivo (por exemplo, rede e dispositivos atribuídos)

Suporte a VBS (segurança baseada em virtualização) de convidado 8.0

Unidade de armazenamento de chaves 8.0

VMs com memória grande 8.0

Virtualização aninhada 8.0

Número de processadores virtuais 8.0

Suporte a XSAVE 8.0

VMMQ (várias filas de máquina virtual) 7.1

vTPM (Virtual Trusted Platform Module) 7.0

Adição/remoção ativa de memória 6.2

PowerShell Direct 6.2

Pontos de Verificação de Produção 6.2

Inicialização segura para VMs do Linux 6.2

Agrupamento de máquina virtual 6.2

Para obter mais informações sobre esses recursos, consulte Novidades no Hyper-V no
Windows Server.
Implantar dispositivos gráficos usando
Atribuição Discreta de Dispositivo
Artigo • 17/05/2024

Saiba como usar a Atribuição de Dispositivo Discreto (DDA) para passar um dispositivo
PCIe inteiro para uma máquina virtual (VM) com o PowerShell. Isso permite acesso de
alto desempenho a dispositivos como armazenamento NVMe ou placas gráficas de
dentro de uma VM, ao mesmo tempo em que pode aplicar os drivers nativos do
dispositivo. Para obter mais informações sobre dispositivos que funcionam e possíveis
implicações de segurança, confira Planejar a implantação de dispositivos usando a
Atribuição de Dispositivo Discreta.

Este artigo orienta você pelas etapas para usar um dispositivo com DDA:

1. Configurar a VM para DDA

2. Desmontar o dispositivo da partição do host
3. Atribuir o dispositivo à VM convidada

Pré-requisitos
Antes de usar o DDA para implantar dispositivos gráficos, você precisa ter o seguinte.

Um host Hyper-V executando o Windows Server 2016 ou posterior.

Uma VM executando um dos seguintes sistemas operacionais:

Windows Server 2016 ou posterior.

Windows 10 ou posterior.

Revise o Plano de implantação de dispositivos usando atribuição de dispositivo

discreto para garantir que seu hardware seja compatível com DDA.
Execute o Script do PowerShell SurveyDDA.ps1. para identificar se o servidor
está configurado corretamente. O script também exibe quais dispositivos
podem ser passados usando a Atribuição de Dispositivo Discreto.

Direitos administrativos para o host Hyper-V.

(Opcional) Embora não seja necessário, se a Virtualização de E/S de raiz única (SR-
IOV) não estiver habilitada ou suportada, você poderá encontrar problemas ao
usar o DDA para implantar dispositivos gráficos.
Configurar a VM para DDA
A primeira etapa na solução é resolver as restrições de DDA para as VMs.

1. Entre no site do host Hyper-V como administrador.

2. Abra um prompt do PowerShell elevado.

3. Configure a Automatic Stop Action de uma VM para habilitar o TurnOff com o

seguinte cmdlet do PowerShell:

PowerShell

Set-VM -Name VMName -AutomaticStopAction TurnOff

Preparação da VM para dispositivos gráficos

Alguns elementos de hardware têm um desempenho melhor se a VM estiver
configurada de uma determinada maneira. Para obter detalhes sobre se você precisa
das configurações a seguir para seu hardware, entre em contato com o fornecedor de
hardware. Para obter mais informações, confira Planejar a implantação de dispositivos
usando a Atribuição de Dispositivo Discreta e esta postagem no blob .

1. Habilite a combinação de gravação na CPU usando o seguinte cmdlet:

PowerShell

Set-VM -GuestControlledCacheTypes $true -VMName VMName

2. Configure o espaço de E/S mapeada de memória de 32 bits (MMIO) usando o

seguinte cmdlet:

PowerShell

Set-VM -LowMemoryMappedIoSpace 3Gb -VMName VMName

3. Configure um espaço MMIO maior que 32 bits usando o seguinte cmdlet:

PowerShell

Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName VMName

  Dica

Os valores de espaço MMIO mostrados são valores razoáveis a serem

definidos para experimentar uma única GPU. Se depois de iniciar a VM, o
dispositivo estiver relatando um erro relacionado a recursos insuficientes,
você provavelmente precisará modificar esses valores. Para obter mais
informações sobre como calcular com precisão os requisitos do MMIO,
confira Planejar a implantação de dispositivos usando a Atribuição de
Dispositivo Discreta.

Desmontar o dispositivo da partição do host

Siga as instruções nesta seção para desmontar o dispositivo da partição do host.

Instalar o driver de particionamento (opcional)

O DDA oferece aos fornecedores de hardware a capacidade de fornecer um driver de
mitigação de segurança com seus dispositivos. Esse driver não é o mesmo que o driver
de dispositivo instalado na VM convidada. Cabe ao fornecedor de hardware fornecer
esse driver. Mas se eles fornecerem um driver, instale-o antes de desmontar o
dispositivo da partição host. Entre em contato com o fornecedor de hardware para ver
se ele tem um driver de mitigação.

Se nenhum driver de particionamento for fornecido, durante a desmontagem, você

deverá usar a opção -Force para ignorar o aviso de segurança. Para obter mais
informações sobre as implicações de segurança, confira Planejar a implantação de
dispositivos usando a Atribuição de Dispositivo Discreta.

Localizar o caminho de localização do dispositivo

O caminho de localização do PCI é necessário para desmontar e montar o dispositivo do
host. Um exemplo de caminho de localização se parece com o seguinte:
PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000) . Para obter mais informações

sobre como localizar o caminho de localização, confira Planejar a implantação de

dispositivos usando a Atribuição de Dispositivo Discreta.

Desabilitar o dispositivo
Use o Gerenciador de Dispositivos ou o PowerShell para garantir que o dispositivo
esteja desabilitado.

Desmontar o dispositivo
Dependendo se o fornecedor forneceu um driver de mitigação, você deve usar a opção
-Force ou não, conforme mostrado aqui:

Se um driver de mitigação tiver sido instalado, use o seguinte cmdlet:

PowerShell

Dismount-VMHostAssignableDevice -LocationPath $locationPath

Se um driver de mitigação não tiver sido instalado, use o seguinte cmdlet:

PowerShell

Dismount-VMHostAssignableDevice -Force -LocationPath $locationPath

Atribuir o dispositivo à VM convidada

A etapa final é informar ao Hyper-V que uma VM deve ter acesso ao dispositivo.
Especifique o caminho de localização e o nome da VM.

PowerShell

Add-VMAssignableDevice -LocationPath $locationPath -VMName VMName

Concluir tarefas na VM
Depois que um dispositivo for montado com êxito em uma VM, agora você poderá
iniciar essa VM e interagir com o dispositivo como se estivesse em execução em um
sistema bare-metal. Agora você pode instalar os drivers do fornecedor de hardware na
VM e os aplicativos podem ver o hardware. Você pode verificar isso abrindo o
Gerenciador de Dispositivos na VM convidada e vendo que o hardware está disponível.

Remover um dispositivo e devolvê-lo ao host

Se você quiser retornar o dispositivo de volta ao estado original, deverá interromper a
VM e emitir este comando:

PowerShell

# Remove the device from the VM

Remove-VMAssignableDevice -LocationPath $locationPath -VMName VMName

# Mount the device back in the host

Mount-VMHostAssignableDevice -LocationPath $locationPath

Em seguida, você pode reabilitar o dispositivo no Gerenciador de Dispositivos e o

sistema operacional do host poderá interagir com o dispositivo novamente.

Exemplo - Montar uma GPU em uma VM

Este exemplo usa o PowerShell para configurar uma VM chamada ddatest1 para usar a
primeira GPU disponível pelo fabricante NVIDIA e atribuí-la à VM.

PowerShell

# Configure the VM for a Discrete Device Assignment

$vm = "ddatest1"
# Set automatic stop action to TurnOff
Set-VM -Name $vm -AutomaticStopAction TurnOff
# Enable Write-Combining on the CPU
Set-VM -GuestControlledCacheTypes $true -VMName $vm
# Configure 32 bit MMIO space
Set-VM -LowMemoryMappedIoSpace 3Gb -VMName $vm
# Configure Greater than 32 bit MMIO space
Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName $vm

# Find the Location Path and disable the Device

# Enumerate all PNP Devices on the system
$pnpdevs = Get-PnpDevice -presentOnly
# Select only those devices that are Display devices manufactured by NVIDIA
$gpudevs = $pnpdevs | Where-Object {$_.Class -like "Display" -and
$_.Manufacturer -like "NVIDIA"}
# Select the location path of the first device that's available to be
dismounted by the host.
$locationPath = ($gpudevs | Get-PnpDeviceProperty
DEVPKEY_Device_LocationPaths).data[0]
# Disable the PNP Device
Disable-PnpDevice -InstanceId $gpudevs[0].InstanceId

# Dismount the Device from the Host

Dismount-VMHostAssignableDevice -Force -LocationPath $locationPath
 # Assign the device to the guest VM.
Add-VMAssignableDevice -LocationPath $locationPath -VMName $vm

Solucionar problemas com a montagem de uma GPU

Se você passar uma GPU para uma VM, mas os Serviços de Área de Trabalho Remota ou
um aplicativo não estiver reconhecendo a GPU, verifique os seguintes problemas
comuns.

Certifique-se de instalar a versão mais recente do controlador suportado pelo

fornecedor da GPU e de que o controlador não está comunicando erros. Você
pode fazer isso verificando o estado do dispositivo no Gerenciador de Dispositivos.

Verifique se o dispositivo tem espaço MMIO suficiente alocado na VM. Para obter
mais informações, confira Espaço MMIO.

Certifique-se de usar uma GPU cujo uso tenha suporte do fornecedor nesta
configuração. Por exemplo, alguns fornecedores impedem que seus cartões de
consumidor funcionem quando passados para uma VM.

Verifique se o aplicativo dá suporte à execução dentro de uma VM e se o aplicativo

dá suporte à GPU e aos drivers associados. Alguns aplicativos têm listas de
permissões de GPUs e ambientes.

Se você usar a função Host da Sessão da Área de Trabalho Remota ou os Serviços

Multipontos do Windows no convidado, verifique se uma entrada de Política de
Grupo específica está definida para permitir o uso da GPU padrão. Use um Objeto
de Política de Grupo aplicado ao convidado (ou o Editor de Política de Grupo Local
no convidado). Navegue até o seguinte item de Política de Grupo:

Configuração do Computador\Modelos de Administrador\Componentes do

Windows\Serviços de Área de Trabalho Remota\Host de Sessão da Área de
Trabalho Remota\Ambiente de Sessão Remota\Usar adaptadores de elementos
gráficos de hardware para todas as sessões dos Serviços de Área de Trabalho
Remota.

Defina o valor da Política de Grupo como Habilitado e reinicialize a VM depois de

aplicar a política.
Implantar dispositivos de
armazenamento NVMe usando a
Atribuição Discreta de Dispositivo
Artigo • 05/10/2023

Aplica-se a: Windows Server 2022, Windows Server 2019, Microsoft Hyper-V Server
2016, Windows Server 2016

A partir do Windows Server 2016, você pode usar a Atribuição Discreta de Dispositivo,
ou DDA, para passar um dispositivo PCIe inteiro para uma VM. Isso permitirá acesso de
alto desempenho a dispositivos como o armazenamento NVMe ou Placas Gráficas de
dentro de uma VM, ao mesmo tempo em que poderá aproveitar os drivers nativos de
dispositivos. Visite o Plano de Implantação de Dispositivos usando a Atribuição Discreta
de Dispositivo para obter mais detalhes sobre quais dispositivos funcionam, quais são as
possíveis implicações de segurança etc. Há três etapas para usar um dispositivo com a
DDA:

Configurar a VM para DDA

Desmontar o dispositivo da partição de host
Atribuindo o dispositivo à VM convidada

Todo comando pode ser executado no Host em um console do Windows PowerShell

como administrador.

Configurar a VM para DDA

A Atribuição Discreta de Dispositivo impõe algumas restrições às VMs e a etapa a seguir
precisa ser executada.

1. Configure a "Ação de Parada Automática" de uma VM como TurnOff executando o

seguinte

Set-VM -Name VMName -AutomaticStopAction TurnOff

Desmontar o dispositivo da partição de host

Localizando o caminho de local do dispositivo
O caminho de Local da PCI é necessário para desmontar e montar o dispositivo do Host.
Um caminho de local de exemplo é semelhante ao seguinte:
"PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000)" . Mais detalhes sobre como

localizar o Caminho de Local podem ser encontrados aqui: Plano de Implantação de

Dispositivos usando a Atribuição Discreta de Dispositivo.

Desabilitar o dispositivo
Usando o Gerenciador de Dispositivos ou o PowerShell, verifique se o dispositivo está
"desabilitado".

Desmontar o dispositivo

Dismount-VMHostAssignableDevice -LocationPath $locationPath

Atribuindo o dispositivo à VM convidada

A etapa final é informar ao Hyper-V que uma VM deve ter acesso ao dispositivo. Além
do caminho de local encontrado acima, você precisará saber o nome da VM.

Add-VMAssignableDevice -LocationPath $locationPath -VMName VMName

O que vem a seguir

Depois que um dispositivo for montado com êxito em uma VM, agora você pode iniciar
essa VM e interagir com o dispositivo como normalmente faria se estivesse em
execução em um sistema bare-metal. Você pode verificar isso abrindo o gerenciador de
dispositivos na VM convidada e vendo se o hardware aparece agora.

Removendo um dispositivo e retornando-o ao

host
Se você quiser retornar o dispositivo ao estado original, precisará interromper a VM e
emitir o seguinte:

#Remove the device from the VM

Remove-VMAssignableDevice -LocationPath $locationPath -VMName VMName
#Mount the device back in the host
Mount-VMHostAssignableDevice -LocationPath $locationPath

Em seguida, você poderá reabilitar o dispositivo no gerenciador de dispositivos e o

sistema operacional host poderá interagir com o dispositivo novamente.
Executar o Hyper-V em uma Máquina
Virtual com a Virtualização Aninhada
Artigo • 29/07/2023

A Virtualização Aninhada é um recurso que permite executar o Hyper-V dentro de uma

máquina virtual (VM) do Hyper-V. A Virtualização Aninhada é útil para executar um
emulador de telefone do Visual Studio em uma máquina virtual ou testar configurações
que normalmente exigem vários hosts.

Para saber mais sobre a Virtualização Aninhada e os cenários com suporte, confira O
que é Virtualização Aninhada para Hyper-V?.

Pré-requisitos

Processador Intel com a tecnologia VT-x e EPT

O host do Hyper-V deve ser Windows Server 2016 ou posterior ou Windows 10 ou
posterior.
Configuração de VM versão 8.0 ou superior.

Processador AMD EPYC / Ryzen ou posterior

O host do Hyper-V deve ser Windows Server 2016 ou posterior ou Windows 10 ou
posterior.
Configuração da VM versão 10.0 ou superior.

７ Observação

O convidado pode ser qualquer sistema operacional convidado compatível com o

Windows. Sistemas operacionais Windows mais novos podem dar suporte a
esclarecimentos que aprimoram o desempenho.

Configurar a Virtualização Aninhada

1. Crie uma máquina virtual. Confira os pré-requisitos para as versões de SO e VM
necessárias.
 2. Enquanto a máquina virtual estiver no estado OFF, execute o comando a seguir no
host físico do Hyper-V para habilitar a virtualização aninhada para a máquina
virtual.

PowerShell

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

3. Iniciar a máquina virtual.

4. Instale o Hyper-V na máquina virtual, exatamente como você faria para um

servidor físico. Para obter mais informações sobre como instalar o Hyper-V, confira
Instalar o Hyper-V.

７ Observação

Ao usar o Windows Server 2019 como a VM de primeiro nível, o número de vCPUs

deve ser 225 ou menos.

Desabilitar Virtualização Aninhada

Você pode desabilitar a virtualização aninhada para uma máquina virtual interrompida
usando o seguinte comando do PowerShell:

PowerShell

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $false

Opções de rede
Há duas opções para redes com máquinas virtuais aninhadas:

1. Falsificação de endereço MAC

2. Rede NAT

Falsificação de endereço MAC

Para que os pacotes de rede sejam encaminhados por meio de dois comutadores
virtuais, a falsificação de endereço MAC deverá ser habilitada no primeiro nível (L1) do
comutador virtual. Para habilitar a falsificação de endereço MAC, execute o comando do
PowerShell a seguir.

PowerShell

Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -

MacAddressSpoofing On

NAT (conversão de endereços de rede)

A segunda opção depende do NAT (conversão de endereços de rede). Essa abordagem
é mais adequada para casos em que a falsificação de endereço MAC não é possível,
como em um ambiente de nuvem pública.

Primeiro, é preciso criar um comutador NAT virtual na máquina virtual host (VM
“intermediária”). O exemplo a seguir cria um novo switch interno nomeado VmNAT e cria
um objeto NAT para todos os endereços IP na sub-rede [Link]/24 .

PowerShell

New-VMSwitch -Name VmNAT -SwitchType Internal

New-NetNat –Name LocalNAT –InternalIPInterfaceAddressPrefix
“[Link]/24”

Em seguida, atribua um endereço IP ao adaptador de rede:

PowerShell

Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress

[Link] -AddressFamily IPv4 -PrefixLength 24

Cada máquina virtual aninhada deve ter um endereço IP e um gateway atribuído a ela.
O IP do gateway deve apontar para o adaptador NAT da etapa anterior. Talvez você
queira atribuir um servidor DNS:

PowerShell

Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress

[Link] -DefaultGateway [Link] -AddressFamily IPv4 -
PrefixLength 24
Netsh interface ip add dnsserver “vEthernet (VmNat)” address=<my DNS server>

Próximas etapas
Gerenciar hosts do Hyper-V remotamente com o Gerenciador do Hyper-V
Cmdlets para configurar dispositivos de
memória persistente para VMs do
Hyper-V
Artigo • 10/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019

Este artigo fornece a administradores do sistema e profissionais de TI informações sobre

como configurar VMs do Hyper-V com memória persistente (também conhecida como
memória de classe de armazenamento ou NVDIMM). Dispositivos de memória
persistente NVDIMM-N compatíveis com JDEC têm suporte no Windows Server 2016 e
no Windows 10 e fornecem acesso no nível dos bytes a dispositivos não voláteis de
latência muito baixa. Há suporte para dispositivos de memória persistente de VM no
Windows Server 2019.

Criar um dispositivo de memória persistente

para uma VM
Use o cmdlet New-VHD para criar um dispositivo de memória persistente para uma VM.
O dispositivo precisa ser criado em um volume DAX NTFS existente. A nova extensão de
nome de arquivo (.vhdpmem) é usada para especificar que se trata de um dispositivo de
memória persistente. Há suporte apenas para o formato de arquivo VHD fixo.

Exemplo: New-VHD d:\[Link] -Fixed -SizeBytes 4GB

Criar uma VM com um controlador de memória

persistente
Use o cmdlet New-VM para criar uma VM de Geração 2 com o tamanho de memória
especificado e o caminho para uma imagem VHDX. Em seguida, use Add-
VMPmemController para adicionar um controlador de memória persistente a uma VM.

Exemplo:

PowerShell

New-VM -Name "ProductionVM1" -MemoryStartupBytes 1GB -VHDPath

c:\vhd\[Link]
 Add-VMPmemController ProductionVM1x

Anexar um dispositivo de memória persistente

a uma VM
Usar Add-VMHardDiskDrive para anexar um dispositivo de memória persistente a uma
VM

Exemplo: Add-VMHardDiskDrive ProductionVM1 PMEM -ControllerLocation 1 -Path

D:\[Link]

Dispositivos de memória persistente dentro de uma VM do Hyper-V aparecem como

um dispositivo de memória persistente a ser consumido e gerenciado pelo sistema
operacional convidado. Os sistemas operacionais convidados podem usar o dispositivo
como um bloco ou volume DAX. Quando os dispositivos de memória persistente dentro
de uma VM são usados como um volume DAX, eles se beneficiam da capacidade de
endereçamento no nível do byte de baixa latência do dispositivo host (sem virtualização
de E/S no caminho do código).

７ Observação

A memória persistente só tem suporte para VMs do Hyper-V Gen2. Não há suporte
para Migração ao Vivo e Migração de Armazenamento para VMs com memória
persistente. Os pontos de verificação de produção das VMs não incluem o estado
de memória persistente.

Comentários
Esta página foi útil?  Yes  No
Cmdlets para configurar dispositivos de
memória persistente para VMs do
Hyper-V
Artigo • 10/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019

Este artigo fornece a administradores do sistema e profissionais de TI informações sobre

como configurar VMs do Hyper-V com memória persistente (também conhecida como
memória de classe de armazenamento ou NVDIMM). Dispositivos de memória
persistente NVDIMM-N compatíveis com JDEC têm suporte no Windows Server 2016 e
no Windows 10 e fornecem acesso no nível dos bytes a dispositivos não voláteis de
latência muito baixa. Há suporte para dispositivos de memória persistente de VM no
Windows Server 2019.

Criar um dispositivo de memória persistente

para uma VM
Use o cmdlet New-VHD para criar um dispositivo de memória persistente para uma VM.
O dispositivo precisa ser criado em um volume DAX NTFS existente. A nova extensão de
nome de arquivo (.vhdpmem) é usada para especificar que se trata de um dispositivo de
memória persistente. Há suporte apenas para o formato de arquivo VHD fixo.

Exemplo: New-VHD d:\[Link] -Fixed -SizeBytes 4GB

Criar uma VM com um controlador de memória

persistente
Use o cmdlet New-VM para criar uma VM de Geração 2 com o tamanho de memória
especificado e o caminho para uma imagem VHDX. Em seguida, use Add-
VMPmemController para adicionar um controlador de memória persistente a uma VM.

Exemplo:

PowerShell

New-VM -Name "ProductionVM1" -MemoryStartupBytes 1GB -VHDPath

c:\vhd\[Link]
 Add-VMPmemController ProductionVM1x

Anexar um dispositivo de memória persistente

a uma VM
Usar Add-VMHardDiskDrive para anexar um dispositivo de memória persistente a uma
VM

Exemplo: Add-VMHardDiskDrive ProductionVM1 PMEM -ControllerLocation 1 -Path

D:\[Link]

Dispositivos de memória persistente dentro de uma VM do Hyper-V aparecem como

um dispositivo de memória persistente a ser consumido e gerenciado pelo sistema
operacional convidado. Os sistemas operacionais convidados podem usar o dispositivo
como um bloco ou volume DAX. Quando os dispositivos de memória persistente dentro
de uma VM são usados como um volume DAX, eles se beneficiam da capacidade de
endereçamento no nível do byte de baixa latência do dispositivo host (sem virtualização
de E/S no caminho do código).

７ Observação

A memória persistente só tem suporte para VMs do Hyper-V Gen2. Não há suporte
para Migração ao Vivo e Migração de Armazenamento para VMs com memória
persistente. Os pontos de verificação de produção das VMs não incluem o estado
de memória persistente.

Comentários
Esta página foi útil?  Yes  No
Escolher entre pontos de verificação
padrão ou de produção no Hyper-V
Artigo • 10/04/2023

Aplica-se a: Windows Server 2022, Windows 10, Windows Server 2016, Microsoft
Hyper-V Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019

Começando no Windows Server 2016 e no Windows 10, você pode escolher entre
pontos de verificação padrão e de produção para cada máquina virtual. Os pontos de
verificação de produção são o padrão para novas máquinas virtuais.

Pontos de verificação de produção são imagens "pontuais” de uma máquina virtual

que podem ser restauradas posteriormente de maneira que tenha suporte
completo em todas as cargas de trabalho de produção. Isso é obtido usando a
tecnologia de backup no convidado para criar o ponto de verificação, em vez de
usar a tecnologia de estado salvo.

Os pontos de verificação padrão capturam o estado, os dados e a configuração de

hardware de uma máquina virtual em execução e são voltados para cenários de
desenvolvimento e teste. Os pontos de verificação padrão podem ser úteis quando
você precisa recriar um estado ou uma condição específica de uma máquina virtual
em execução para que possa solucionar um problema.

Alterar pontos de verificação para padrão ou

de produção
1. No Gerenciador Hyper-V, clique com o botão direito do mouse na máquina virtual
e clique em Configurações.

2. Na seção Gerenciamento, selecione Pontos de Verificação.

3. Selecione pontos de verificação de produção ou padrão.

Se você escolher pontos de verificação de produção, também poderá especificar

se o host deverá obter um ponto de verificação padrão se não for possível obter
um de produção. Se você desmarcar essa caixa de seleção e um ponto de
verificação de produção não puder ser obtido, nenhum ponto de verificação será
obtido.
 4. Se você quiser armazenar os arquivos de configuração do ponto de verificação em
um local diferente, altere isso na seção Local do Arquivo de Ponto de Verificação.

5. Clique em Aplicar para salvar as alterações. Se tiver terminado, clique em OK para

fechar a caixa de diálogo.

７ Observação

Somente Pontos de verificação de produção têm suporte em convidados que

executam a função Active Directory Domain Services (Controlador de Domínio) ou
a função Active Directory Lightweight Directory Services.

Referências adicionais
Pontos de verificação de produção

Habilitar ou desabilitar pontos de verificação

Criar arquivos de conjunto de VHD do
Hyper-V
Artigo • 06/04/2023

Os arquivos do conjunto de VHDs são um novo modelo de disco virtual compartilhado

para clusters convidados no Windows Server 2016. Os arquivos do conjunto de VHDs
dão suporte ao redimensionamento online de discos virtuais compartilhados, à Réplica
do Hyper-V e podem ser incluídos em pontos de verificação consistentes com o
aplicativo.

Os arquivos do conjunto de VHDs usam um novo tipo de arquivo VHD, . VHDS. Os

arquivos do conjunto de VHDs armazenam informações de ponto de verificação sobre o
disco virtual de grupo usado em clusters convidados, na forma de metadados.

O Hyper-V trata todos os aspectos do gerenciamento das cadeias de ponto de

verificação e da mesclagem do conjunto de VHDs compartilhado. O software de
gerenciamento pode executar operações de disco como o redimensionamento online
em arquivos do conjunto de VHDs da mesma maneira que faz para o arquivos .VHDX.
Isso significa que o software de gerenciamento não precisa saber o formato de arquivo
do conjunto de VHDs.

７ Observação

É importante avaliar o impacto dos arquivos do conjunto de VHDs antes da

implantação na produção. Verifique se não há degradação funcional ou de
desempenho em seu ambiente, como latência de disco.

Criar um arquivo do conjunto de VHDs a partir

do Gerenciador do Hyper-V
1. Abra o Gerenciador do Hyper-V. Clique em Iniciar, vá em Ferramentas
Administrativas e clique em Gerenciador do Hyper-V.
2. No painel Ação, clique em Novo e em Disco Rígido.
3. Na página Escolher formato de disco, selecione Conjunto de VHDs como o
formato do disco rígido virtual.
4. Continue pelas outras páginas do assistente para personalizar o disco rígido
virtual. Você pode clicar em Próximo para ir para as outras páginas do assistente
 ou pode clicar no nome de uma página no painel do lado esquerdo para ir
diretamente para essa página.
5. Após terminar de configurar o disco rígido virtual, clique em Concluir.

Criar um arquivo do conjunto de VHDs a partir

do Windows PowerShell
Use o cmdlet New-VHD, com o tipo de arquivo . VHDS no caminho do arquivo. Este
exemplo cria um arquivo do conjunto de VHDs chamado [Link] com 10 GB de
tamanho.

PowerShell

PS c:\>New-VHD -Path c:\[Link] -SizeBytes 10GB

Migrar um arquivo VHDX compartilhado para

um arquivo do conjunto de VHDs
É necessário colocar a VM offline para migrar um VHDX compartilhado existente para
um VHDS. Esse é o processo recomendado usando o Windows PowerShell:

1. Remover o VHDX da VM. Por exemplo, execute:

PowerShell

PS c:\>Remove-VMHardDiskDrive [Link]

2. Converter o VHDX em um VHDS. Por exemplo, execute:

PowerShell

PS c:\>Convert-VHD [Link] [Link]

3. Adicionar o VHDS à VM. Por exemplo, execute:

PowerShell

PS c:\>Add-VMHardDiskDrive [Link]
Habilitar ou desabilitar pontos de
verificação no Hyper-V
Artigo • 11/04/2023

Aplica-se a: Windows Server 2022, Windows 10, Windows Server 2016, Microsoft
Hyper-V Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019

Você pode optar por habilitar ou desabilitar os pontos de verificação para cada máquina
virtual.

1. No Gerenciador Hyper-V, clique com o botão direito na máquina virtual e clique

em Configurações.

2. Na seção Gerenciamento, selecione Pontos de Verificação.

3. Para permitir que os pontos de verificação sejam tirados dessa máquina virtual,
verifique se a opção Habilitar Pontos de Verificação está selecionada. Para
desativar os pontos de verificação, desmarque a caixa de seleção Habilitar Pontos
de Verificação.

4. Clique em Aplicar para aplicar as alterações. Se tiver terminado, clique em OK para

fechar a caixa de diálogo.

Referências adicionais
Escolher entre pontos de verificação padrão ou de produção no Hyper-V
Gerenciar hosts do Hyper-V
remotamente com o Gerenciador do
Hyper-V
Artigo • 06/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows 10, Windows 8.1

Este artigo lista as combinações com suporte de hosts Hyper-V e versões do

Gerenciador do Hyper-V e descreve como se conectar a hosts Hyper-V remotos e locais
para que você possa gerenciá-los.

O Gerenciador do Hyper-V permite gerenciar um pequeno número de hosts Hyper-V,

remotos e locais. Ele é instalado quando você instala as Ferramentas de Gerenciamento
do Hyper-V, que podem ser executadas por meio de uma instalação completa do
Hyper-V ou de uma instalação somente de ferramentas. Fazer uma instalação somente
de ferramentas significa que você pode usar as ferramentas em computadores que não
atendem aos requisitos de hardware para hospedar o Hyper-V. Para obter detalhes
sobre o hardware para hosts Hyper-V, consulte Requisitos do sistema.

Se o Gerenciador do Hyper-V não estiver instalado, consulte as instruções abaixo.

Há suporte para combinações de versões de

host do Hyper-V e gerenciador do Hyper-V
Em alguns casos, você pode usar uma versão diferente do gerenciador do Hyper-V do
que a versão do Hyper-V no host, conforme mostrado na tabela. Quando você faz isso,
o gerenciador do Hyper-V fornece os recursos disponíveis para a versão do Hyper-V no
host que você está gerenciando. Por exemplo, se você usar a versão do gerenciador do
Hyper-V no Windows Server 2012 R2 para gerenciar remotamente um host que executa
o Hyper-V no Windows Server 2012, não poderá usar recursos disponíveis no Windows
Server 2012 R2 nesse host do Hyper-V.

A tabela a seguir mostra quais versões de um host Hyper-V você pode gerenciar a partir
de uma versão específica do gerenciador do Hyper-V. Somente as versões do sistema
operacional com suporte são listadas. Para obter detalhes sobre o status de suporte de
uma versão específica do sistema operacional, use o botão Pesquisar ciclo de vida do
produto na página Política de Ciclo de Vida da Microsoft . Em geral, versões mais
antigas do gerenciador do Hyper-V só podem gerenciar um host do Hyper-V
executando a mesma versão ou a versão comparável do Windows Server.

Versão do gerenciador do Versão do host do Hyper-V

Hyper-V

Windows Server 2016, – Windows Server 2016: todas as edições e opções de instalação,
Windows 10 incluindo o Nano Server e a versão correspondente do Hyper-V
Server
– Windows Server 2012 R2: todas as edições e opções de
instalação, e a versão correspondente do Hyper-V Server
– Windows Server 2012: todas as edições e opções de instalação,
e a versão correspondente do Hyper-V Server
– Windows 10
– Windows 8.1

Windows Server 2012 R2, – Windows Server 2012 R2: todas as edições e opções de
Windows 8.1 instalação, e a versão correspondente do Hyper-V Server
– Windows Server 2012: todas as edições e opções de instalação,
e a versão correspondente do Hyper-V Server
– Windows 8.1

Windows Server 2012 – Windows Server 2012: todas as edições e opções de instalação,
e a versão correspondente do Hyper-V Server

Windows Server 2008 R2 – Windows Server 2008 R2: todas as edições e opções de
Service Pack 1, Windows 7 instalação, e a versão correspondente do Hyper-V Server
Service Pack 1

Windows Server 2008, – Windows Server 2008: todas as edições e opções de instalação,
Windows Vista Service Pack 2 e a versão correspondente do Hyper-V Server

７ Observação

O suporte ao Service Pack terminou para o Windows 8 em 12 de janeiro de 2016.

Para obter mais informações, consulte as perguntas frequentes sobre o Windows
8.1 .

Conectar-se a um host Hyper-V

Para se conectar a um host do Hyper-V do gerenciador do Hyper-V, clique com o botão
direito do mouse em gerenciador do Hyper-V no painel esquerdo e clique em
Conectar-se ao servidor.
Gerenciar Hyper-V em um computador local
O gerenciador do Hyper-V não lista os computadores que hospedam o Hyper-V até que
você adicione o computador, incluindo um computador local. Para fazer isso:

1. No painel esquerdo, clique com o botão direito do mouse em Gerenciador do

Hyper-V.
2. Clique em Conectar-se com o Servidor.
3. Em Selecionar Computador, clique em Computador local e em OK.

Se você não conseguir se conectar:

É possível que apenas as ferramentas do Hyper-V estejam instaladas. Para verificar

se a plataforma Hyper-V está instalada, procure o serviço de Gerenciamento de
Máquinas Virtuais. /(Abra o aplicativo da área de trabalho Serviços: clique em
Iniciar, clique na caixa Iniciar pesquisa, digite [Link] e pressione Enter. Se o
serviço de Gerenciamento de Máquinas Virtuais não estiver listado, instale a
plataforma Hyper-V seguindo as instruções em Instalar o Hyper-V.
Verifique se seu hardware atende aos requisitos. Consulte Requisitos do sistema.
Verifique se sua conta de usuário pertence ao grupo Administradores ou ao grupo
Administradores do Hyper-V.

Gerencie hosts do Hyper-V remotamente

Para gerenciar hosts remotos do Hyper-V, habilite o gerenciamento remoto no
computador local e no host remoto.

No Windows Server, abra o Gerenciador do Servidor no >Servidor local>do

Gerenciamento remoto e clique em Permitir conexões remotas com este computador.

Ou, a partir de qualquer sistema operacional, abra o Windows PowerShell como

Administrador e execute:

PowerShell

Enable-PSRemoting

Conectar-se a hosts no mesmo domínio

No Windows 8.1 e em anteriores, o gerenciamento remoto funciona somente quando o
host está no mesmo domínio e sua conta de usuário local também está no host remoto.
Para adicionar um host remoto do Hyper-V ao gerenciador do Hyper-V, selecione Outro
computador na caixa de diálogo Selecionar Computador e digite o nome de host do
host remoto, o nome do NetBIOS ou o FQDN (nome de domínio totalmente
qualificado).

O gerenciador do Hyper-V no Windows Server 2016 e Windows 10 oferece mais tipos

de conexão remota do que as versões anteriores, descritas nas seções a seguir.

Conectar-se a um host remoto no Windows Server 2016

ou Windows 10 como um usuário diferente
Isso permite que você se conecte ao host do Hyper-V quando não estiver em execução
no computador local como um usuário que seja membro do grupo Administradores do
Hyper-V ou do grupo Administradores no host do Hyper-V. Para fazer isso:

1. No painel esquerdo, clique com o botão direito do mouse em Gerenciador do

Hyper-V.
2. Clique em Conectar-se com o Servidor.
3. Selecione Conectar-se como outro usuário na caixa de diálogo Selecionar
Computador.
4. Selecione Definir usuário.

７ Observação

Isso só funcionará em hosts remotos do Windows Server 2016 ou Windows 10.

Conectar-se a um host remoto no Windows Server 2016

ou Windows 10 usando um endereço IP
Para fazer isso:

1. No painel esquerdo, clique com o botão direito do mouse em Gerenciador do

Hyper-V.
2. Clique em Conectar-se com o Servidor.
3. Digite o endereço IP no campo de texto Outro computador.

７ Observação

Isso só funcionará em hosts remotos do Windows Server 2016 ou Windows 10.

Conectar-se a um host remoto do Windows Server 2016
ou Windows 10 fora do seu domínio ou sem domínio
Para fazer isso:

1. No host do Hyper-V a ser gerenciado, abra uma sessão do Windows PowerShell

como Administrador.

2. Crie as regras de firewall necessárias para zonas de rede privadas:

PowerShell

Enable-PSRemoting

3. Para permitir o acesso remoto em zonas públicas, habilite as regras de firewall para
CredSSP e WinRM:

PowerShell

Enable-WSManCredSSP -Role server

Para obter detalhes, consulte Enable-PSRemoting e Enable-WSManCredSSP.

Em seguida, configure o computador que você usará para gerenciar o host do Hyper-V.

1. Abra uma sessão do Windows PowerShell como administrador.

2. Execute estes comandos:

PowerShell

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "fqdn-of-hyper-v-

host"

PowerShell

Enable-WSManCredSSP -Role client -DelegateComputer "fqdn-of-hyper-v-

host"

3. É aconselhável configurar a seguinte política de grupo:

Configuração do computador >Modelos

Administrativos>Sistema>Delegação de credenciais>Permitir a delegação
de novas credenciais com autenticação de servidor somente NTLM
 Clique em Habilitar e adicione wsman/fqdn-de-hyper-v-host.

4. Abra o Gerenciador do Hyper-V.

5. No painel esquerdo, clique com o botão direito do mouse em Gerenciador do

Hyper-V.

6. Clique em Conectar-se com o Servidor.

７ Observação

Isso só funcionará em hosts remotos do Windows Server 2016 ou Windows 10.

Para obter detalhes do cmdlet, consulte Set-Item e Enable-WSManCredSSP.

Instalar o gerenciador do Hyper-V

Para usar uma ferramenta de interface do usuário, escolha a adequada para o sistema
operacional no computador em que você executará o gerenciador do Hyper-V:

No Windows Server, abra o Gerenciador do Servidor >Gerenciar>Adicionar funções e

recursos. Acesse a página Recursos e expanda Ferramentas de administração de
servidor remoto>Ferramentas de administração de função>Ferramentas de
gerenciamento do Hyper-V.

No Windows, o gerenciador do Hyper-V está disponível em qualquer sistema

operacional do Windows que inclua o Hyper-V.

1. Na área de trabalho do Windows, clique no botão Iniciar e comece a digitar

Programas e recursos.
2. Nos resultados da pesquisa, clique em Programas e Recursos.
3. No painel esquerdo, clique em Ativar ou desativar os recursos do Windows.
4. Expanda a pasta Hyper-V e clique em Ferramentas de gerenciamento do Hyper-
V.
5. Para instalar o Gerenciador do Hyper-V, clique em Ferramentas de gerenciamento
do Hyper-V. Se você também deseja instalar o módulo do Hyper-V, clique nessa
opção.

Para usar o Windows PowerShell, execute o seguinte comando como Administrador:

PowerShell

add-windowsfeature rsat-hyper-v-tools
Referências adicionais
Instalar o Hyper-V
Gerenciamento de recursos de CPU do
host do Hyper-V
Artigo • 06/04/2023

Os controles de recursos de CPU do host do Hyper-V apresentados no Windows Server

2016 ou posterior permitem que os administradores do Hyper-V gerenciem e aloquem
melhor os recursos de CPU do servidor host entre a partição de gerenciamento ou "raiz"
e as VMs convidadas. Usando esses controles, os administradores podem dedicar um
subconjunto dos processadores de um sistema host à partição raiz. Isso pode separar o
trabalho feito em um host do Hyper-V das cargas de trabalho em execução em
máquinas virtuais convidadas executando-as em subconjuntos separados dos
processadores do sistema.

Para obter detalhes sobre o hardware para hosts do Hyper-V, consulte Requisitos do
sistema Hyper-V do Windows 10.

Tela de fundo
Antes de definir os controles para recursos de CPU do host do Hyper-V, é útil examinar
os conceitos básicos da arquitetura do Hyper-V. Você pode encontrar um resumo geral
na seção Arquitetura do Hyper-V. Confira os conceitos importantes para este artigo:

O Hyper-V cria e gerencia partições de máquina virtual, nas quais os recursos de

computação são alocados e compartilhados, sob controle do hipervisor. As
partições fornecem limites de isolamento fortes entre todas as máquinas virtuais
convidadas e entre as VMs convidadas e a partição raiz.

A partição raiz é em si uma partição de máquina virtual, embora tenha

propriedades exclusivas e privilégios muito maiores do que as máquinas virtuais
convidadas. A partição raiz fornece os serviços de gerenciamento que controlam
todas as máquinas virtuais convidadas, fornece suporte a dispositivos virtuais para
convidados e gerencia toda a E/S do dispositivo para máquinas virtuais
convidadas. A Microsoft recomenda fortemente não executar nenhuma carga de
trabalho de aplicativo em uma partição de host.

Cada VP (processador virtual) da partição raiz é mapeado 1:1 para um LP

(processador lógico) subjacente. Um VP de host sempre será executado no mesmo
LP subjacente – não há migração dos VPs da partição raiz.
 Por padrão, os LPs nos quais os VPs host são executados também podem executar
VPs convidados.

Um VP convidado pode ser agendado pelo hipervisor para ser executado em

qualquer processador lógico disponível. Embora o agendador de hipervisor tenha
o cuidado de considerar a localidade do cache temporal, a topologia NUMA e
muitos outros fatores ao agendar um VP convidado, o VP pode ser agendado em
qualquer LP de host.

A configuração de raiz mínima ou "minroot"

As versões iniciais do Hyper-V tinham um limite máximo de arquitetura de 64 VPs por
partição. Isso se aplica às partições raiz e de convidado. À medida que sistemas com
mais de 64 processadores lógicos apareciam em servidores high-end, o Hyper-V
também evoluiu seus limites de escala de host para dar suporte a esses sistemas
maiores, em um ponto que dá suporte a um host com até 320 LPs. No entanto, quebrar
o limite de 64 VP por partição na época apresentou vários desafios e gerou
complexidades que tornaram proibitivo o suporte a mais de 64 VPs por partição. Para
resolver isso, o Hyper-V limitou o número de VPs dados à partição raiz para 64, mesmo
que o computador subjacente tivesse muito mais processadores lógicos disponíveis. O
hipervisor continuaria a utilizar todos os LPs disponíveis para executar VPs convidados,
mas limitou artificialmente a partição raiz em 64. Essa configuração ficou conhecida
como a configuração de "raiz mínima" ou "minroot". Testes de desempenho
confirmaram que, mesmo em sistemas de grande escala com mais de 64 LPs, a raiz não
precisava de mais de 64 VPs de raiz para fornecer suporte suficiente a um grande
número de VMs e VPs convidados. Na verdade, geralmente eram adequados muito
menos de 64 VPs de raiz, dependendo, é claro, do número e do tamanho das VMs
convidadas, das cargas de trabalho específicas que estão sendo executadas etc.

Esse conceito de "minroot" continua sendo utilizado atualmente. Na verdade, mesmo

que o Hyper-V do Windows Server 2016 tenha aumentado seu limite máximo de
suporte arquitetônico de LPs de host para 512 LPs, a partição raiz ainda será limitada a
um máximo de 320 LPs.

Usando a Minroot para restringir e isolar

recursos de computação do host
Com o limite padrão alto de 320 LPs no Hyper-V do Windows Server 2016, a
configuração da minroot só será utilizada nos maiores sistemas de servidor. No entanto,
essa funcionalidade pode ser configurada para um limite muito menor pelo
administrador de host do Hyper-V e, portanto, aproveitada para restringir
consideravelmente a quantidade de recursos da CPU do host disponíveis para a partição
raiz. O número específico de LPs raiz a serem utilizados deve, naturalmente, ser
escolhido com cuidado para dar suporte às demandas máximas das VMs e cargas de
trabalho alocadas ao host. No entanto, valores razoáveis para o número de LPs do host
podem ser determinados por meio de avaliação cuidadosa e monitoramento de cargas
de trabalho de produção e validados em ambientes de não produção antes da
implantação ampla.

Habilitar e configurar minroot

A configuração da minroot é controlada por meio de entradas BCD do hipervisor. Para
habilitar a minroot, em um prompt de comandos com privilégios de administrador:

bcdedit /set hypervisorrootproc n

Em que n é o número de VPs raiz.

O sistema deve ser reinicializado e o novo número de processadores raiz persistirá

durante o tempo de vida da inicialização do sistema operacional. A configuração da
minroot não pode ser alterada dinamicamente no runtime.

Se houver vários nós NUMA, cada nó obterá processadores n/NumaNodeCount .

Observe que, com vários nós NUMA, você deve garantir que a topologia da VM seja tal
que haja LPs livres suficientes (ou seja, LPs sem VPs raiz) em cada nó NUMA para
executar os VPs de nó NUMA da VM correspondente.

Verificar a configuração da minroot

Você pode verificar a configuração da minroot de host usando o Gerenciador de Tarefas,
conforme mostrado abaixo.
Quando a minroot estiver ativa, o Gerenciador de Tarefas exibirá o número de
processadores lógicos alocados para o host no momento, além do número total de
processadores lógicos no sistema.
Controles de Recursos de Máquina
Virtual
Artigo • 28/08/2023

Aplica-se a: Windows Server 2022, Windows Server 2016, Microsoft Hyper-V Server
2016, Windows Server 2019 e Microsoft Hyper-V Server 2019

Este artigo descreve os controles de isolamento e de recursos do Hyper-V para

máquinas virtuais. Esses recursos, aos quais nos referiremos como Grupos de CPU de
Máquina Virtual ou apenas "grupos de CPU", foram introduzidos no Windows Server
2016. Grupos de CPU permitem que os administradores do Hyper-V gerenciem e
aloquem melhor os recursos de CPU do host em máquinas virtuais convidadas. Usando
grupos de CPU, os administradores do Hyper-V podem:

Criar grupos de máquinas virtuais, com cada grupo tendo alocações diferentes do
total de recursos de CPU do host de virtualização, compartilhados em todo o
grupo. Isso permite que o administrador do host implemente classes de serviço
para diferentes tipos de VMs.

Definir limites de recursos de CPU para grupos específicos. Esse "limite de grupo"
define o limite superior para recursos de CPU do host que todo o grupo pode
consumir, impondo efetivamente a classe de serviço desejada para esse grupo.

Restringir um grupo de CPU para ser executado somente em um conjunto

específico de processadores do sistema host. Isso pode ser usado para isolar VMs
que pertencem a diferentes grupos de CPU entre si.

Gerenciar grupos de CPU

Os grupos de CPU são gerenciados por meio do Serviço de Computação de Host do
Hyper-V ou HCS. Uma ótima descrição do HCS, sua gênese, links para as APIs do HCS e
muito mais está disponível no blog da equipe de Virtualização da Microsoft na
postagem Introdução ao HCS (Serviço de Computação de Host).

７ Observação

Somente o HCS pode ser usado para criar e gerenciar grupos de CPU. As interfaces
de gerenciamento do Gerenciador do Hyper-V, WMI e PowerShell não dão suporte
a grupos de CPU.
A Microsoft fornece um utilitário de linha de comando, [Link], no Centro de
Download da Microsoft que usa a interface HCS para gerenciar grupos de CPU. Esse
utilitário também pode exibir a topologia da CPU de um host.

Como funcionam os grupos de CPU

A alocação de recursos de computação de host entre grupos de CPU é imposta pelo
hipervisor do Hyper-V, usando um limite de grupo de CPU computado. O limite do
grupo de CPU é uma fração da capacidade total da CPU para um grupo de CPU. O valor
do limite de grupo depende da classe do grupo ou do nível de prioridade atribuído. O
limite de grupo calculado pode ser considerado como "um número de LP de tempo de
CPU". Esse orçamento de grupo é compartilhado. Assim, se apenas uma única VM
estivesse ativa, ela poderia usar a alocação de CPU de todo o grupo para si mesma.

O limite do grupo de CPU é calculado como G = n x C, onde:

G é a quantidade de LP do host que gostaríamos de atribuir ao grupo

n é o número total de LPs (processadores lógicos) no grupo
C é a alocação máxima de CPU, ou seja, a classe de serviço desejada para o grupo,
expressa como uma porcentagem da capacidade total de computação do sistema

Por exemplo, considere um grupo de CPU configurado com quatro LPs (processadores
lógicos) e um limite de 50%.

G=n*C
G = 4 * 50%
G = 2 LP de tempo de CPU para todo o grupo

Neste exemplo, o grupo de CPU G recebe 2 LP de tempo de CPU.

Observe que o limite de grupo se aplica independentemente do número de máquinas

virtuais ou processadores virtuais associados ao grupo e independentemente do estado
(por exemplo, desligamento ou início) das máquinas virtuais atribuídas ao grupo de
CPU. Portanto, cada VM associada ao mesmo grupo de CPU receberá uma fração da
alocação total de CPU do grupo e isso mudará com o número de VMs associadas ao
grupo de CPU. Portanto, como as VMs são VMs associadas ou não associadas de um
grupo de CPU, o limite total do grupo de CPU deve ser reajustado e definido para
manter o limite por VM desejado. O administrador do host da VM ou a camada de
software de gerenciamento de virtualização é responsável por gerenciar os limites de
grupo conforme necessário para obter a alocação de recursos de CPU por VM desejada.

Classes de serviço de exemplo

Vamos examinar alguns exemplos simples. Para começar, suponha que o administrador
do host do Hyper-V gostaria de dar suporte a duas camadas de serviço para VMs
convidadas:

1. Uma camada "C" de baixo nível. Forneceremos a essa camada 10% dos recursos de
computação de todo o host.

2. Uma camada "B" de nível intermediário. Forneceremos a essa camada 50% dos
recursos de computação de todo o host.

Neste ponto em nosso exemplo, afirmaremos que nenhum outro controle de recurso de
CPU está em uso, como limites de VM individuais, pesos e reservas. No entanto, os
limites de VM individuais são importantes, como veremos um pouco mais tarde.

Para simplificar, vamos supor que cada VM tenha 1 VP e que nosso host tenha 8 LPs.
Começaremos com um host vazio.

Para criar a camada "B", o administrador do host define o limite de grupo como 50%:

G=n*C
G = 8 * 50%
G = 4 LP de tempo de CPU para todo o grupo

O administrador do host adiciona uma única VM da camada "B". Neste ponto, nossa VM
da camada "B" pode usar no máximo 50% da CPU do host, ou o equivalente a 4 LPs, em
nosso sistema de exemplo.

Agora, o administrador adiciona uma segunda VM de "Camada B". A alocação do grupo

de CPU é dividida uniformemente entre todas as VMs. Temos um total de 2 VMs no
Grupo B, portanto, cada VM agora obtém metade do total do Grupo B de 50%, 25%
cada, ou o equivalente a 2 LPs de tempo de computação.

Definir limites de CPU em VMs individuais

Além do limite de grupo, cada VM também pode ter um "limite de VM" individual. Os
controles de recursos de CPU por VM, incluindo um limite de CPU, peso e reserva,
fazem parte do Hyper-V desde sua introdução. Quando combinado com um limite de
grupo, um limite de VM especifica a quantidade máxima de CPU que cada VP pode
obter, mesmo que o grupo tenha recursos de CPU disponíveis.

Por exemplo, o administrador do host pode querer colocar um limite de 10% de VM em

VMs "C". Dessa forma, mesmo que a maioria dos VPs "C" esteja ociosa, cada VP nunca
poderá obter mais de 10%. Sem um limite de VM, as VMs "C" poderiam alcançar de
forma oportunista o desempenho além dos níveis permitidos por sua camada.
Isolar grupos de VMs para processadores de
host específicos
Os administradores de host do Hyper-V também podem querer a capacidade de
dedicar recursos de computação para uma VM. Por exemplo, imagine que o
administrador queira oferecer uma VM "A" premium que tenha um limite de classe de
100%. Essas VMs premium também exigem a menor latência de agendamento e
tremulação possível, ou seja, elas podem não ser desagendadas por nenhuma outra VM.
Para obter essa separação, um grupo de CPU também pode ser configurado com um
mapeamento de afinidade de LP específico.

Por exemplo, para ajustar uma VM "A" no host em nosso exemplo, o administrador
criaria um novo grupo de CPU e definiria a afinidade do processador do grupo como
um subconjunto dos LPs do host. Os grupos B e C teriam afinidades com os LPs
restantes. O administrador poderia criar uma única VM no Grupo A, que teria acesso
exclusivo a todos os LPs no Grupo A, enquanto os grupos de camadas presumivelmente
inferiores B e C compartilhariam os LPs restantes.

Separar VPs raiz de VPs convidados

Por padrão, o Hyper-V criará um VP raiz em cada LP físico subjacente. Esses VPs raiz são
estritamente mapeados 1:1 com os LPs do sistema e não são migrados, ou seja, cada VP
raiz sempre será executado no mesmo LP físico. Os VPs convidados podem ser
executados em qualquer LP disponível e compartilharão a execução com os VPs raiz.

No entanto, pode ser desejável separar completamente a atividade do VP raiz dos VPs
convidados. Considere nosso exemplo acima em que implementamos uma VM de
camada "A" premium. Para garantir que os VPs da VM "A" tenham a menor latência e
"tremulação" ou variação de agendamento possíveis, gostaríamos de executá-los em
um conjunto dedicado de LPs e garantir que o raiz não seja executado nesses LPs.

Isso pode ser feito usando uma combinação da configuração "minroot", que limita a
partição do sistema operacional do host a ser executado em um subconjunto do total
de processadores lógicos do sistema, juntamente com um ou mais grupos de CPU com
afinidade.

O host de virtualização pode ser configurado para restringir a partição de host a LPs
específicos, com um ou mais grupos de CPU com afinidade com os LPs restantes. Dessa
forma, as partições de raiz e de convidado podem ser executadas em recursos de CPU
dedicados e completamente isoladas, sem compartilhamento de CPU.
Para saber mais sobre a configuração "minroot", confira Gerenciamento de recursos de
CPU do host do Hyper-V.

Usar a ferramenta CpuGroups

Vamos examinar alguns exemplos de como usar a ferramenta CpuGroups.

７ Observação

Os parâmetros de linha de comando para a ferramenta CpuGroups são passados

usando apenas espaços como delimitadores. Nenhum caractere '/' ou '-' deve
proceder a opção de linha de comando desejada.

Descobrir a topologia da CPU

Executar a CpuGroups com GetCpuTopology retorna informações sobre o sistema atual,
conforme mostrado abaixo, incluindo o índice de LP, o nó NUMA ao qual o LP pertence,
as IDs de Pacote e Núcleo e o índice de VP ROOT.

O exemplo a seguir mostra um sistema com dois soquetes de CPU e nós NUMA, um
total de 32 LPs e vários threads habilitados e configurado para habilitar Minroot com 8
VPs raiz, 4 de cada nó NUMA. Os LPs que têm VPs raiz têm um RootVpIndex >= 0; Os
LPs com um RootVpIndex de -1 não estão disponíveis para a partição raiz, mas ainda
são gerenciados pelo hipervisor e executarão VPs convidados conforme permitido por
outras definições de configuração.

Console

C:\vm\tools>[Link] GetCpuTopology

LpIndex NodeNumber PackageId CoreId RootVpIndex

------- ---------- --------- ------ -----------
0 0 0 0 0
1 0 0 0 1
2 0 0 1 2
3 0 0 1 3
4 0 0 2 -1
5 0 0 2 -1
6 0 0 3 -1
7 0 0 3 -1
8 0 0 4 -1
9 0 0 4 -1
10 0 0 5 -1
11 0 0 5 -1
12 0 0 6 -1
 13 0 0 6 -1
14 0 0 7 -1
15 0 0 7 -1
16 1 1 16 4
17 1 1 16 5
18 1 1 17 6
19 1 1 17 7
20 1 1 18 -1
21 1 1 18 -1
22 1 1 19 -1
23 1 1 19 -1
24 1 1 20 -1
25 1 1 20 -1
26 1 1 21 -1
27 1 1 21 -1
28 1 1 22 -1
29 1 1 22 -1
30 1 1 23 -1
31 1 1 23 -1

Exemplo 2 – Imprimir todos os grupos de CPU no host

Aqui, listaremos todos os grupos de CPU no host atual, sua GroupId, o limite de CPU do
grupo e os índices de LPs atribuídos a esse grupo.

Observe que os valores de limite de CPU válidos estão no intervalo [0, 65536] e esses
valores expressam o limite de grupo em porcentagem (por exemplo, 32768 = 50%).

Console

C:\vm\tools>[Link] GetGroups

CpuGroupId CpuCap LpIndexes

------------------------------------ ------ --------
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31

Exemplo 3 – Imprimir um único grupo de CPU

Neste exemplo, consultaremos um único grupo de CPU usando GroupId como um filtro.

Console

C:\vm\tools>[Link] GetGroups /GroupId:36AB08CB-3A76-4B38-992E-

000000000003
CpuGroupId CpuCap LpIndexes
 ------------------------------------ ------ ----------
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15

Exemplo 4 – Criar um novo grupo de CPU

Aqui, criaremos um novo grupo de CPU, especificando a ID do Grupo e o conjunto de
LPs a serem atribuídos ao grupo.

Console

C:\vm\tools>[Link] CreateGroup /GroupId:36AB08CB-3A76-4B38-992E-

000000000001 /GroupAffinity:0,1,16,17

Agora, exiba nosso grupo recém-adicionado.

Console

C:\vm\tools>[Link] GetGroups
CpuGroupId CpuCap LpIndexes
------------------------------------ ------ ---------
36AB08CB-3A76-4B38-992E-000000000001 65536 0,1,16,17
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31

Exemplo 5 – Definir o limite do grupo de CPU como 50%

Aqui, definiremos o limite do grupo de CPU como 50%.

Console

C:\vm\tools>[Link] SetGroupProperty /GroupId:36AB08CB-3A76-4B38-992E-

000000000001 /CpuCap:32768

Agora vamos confirmar nossa configuração exibindo o grupo que acabamos de

atualizar.

Console

C:\vm\tools>[Link] GetGroups /GroupId:36AB08CB-3A76-4B38-992E-

000000000001

CpuGroupId CpuCap LpIndexes

 ------------------------------------ ------ ---------
36AB08CB-3A76-4B38-992E-000000000001 32768 0,1,16,17

Exemplo 6 – Imprimir IDs de grupo de CPU para todas as

VMs no host
Console

C:\vm\tools>[Link] GetVmGroup

VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G2 4ABCFC2F-6C22-498C-BB38-7151CE678758 36ab08cb-3a76-4b38-992e-
000000000002
P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC 36ab08cb-3a76-4b38-992e-
000000000003
P2 A593D93A-3A5F-48AB-8862-A4350E3459E8 36ab08cb-3a76-4b38-992e-
000000000004
G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200 36ab08cb-3a76-4b38-992e-
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 36ab08cb-3a76-4b38-992e-
000000000002

Exemplo 7 – Desassociar uma VM do grupo de CPU

Para remover uma VM de um grupo de CPU, defina para CpuGroupId da VM como o
GUID NULL. Isso desassocia a VM do grupo de CPU.

Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:00000000-0000-0000-

0000-000000000000

C:\vm\tools>[Link] GetVmGroup
VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G2 4ABCFC2F-6C22-498C-BB38-7151CE678758 36ab08cb-3a76-4b38-992e-
000000000002
P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC 36ab08cb-3a76-4b38-992e-
000000000003
P2 A593D93A-3A5F-48AB-8862-A4350E3459E8 36ab08cb-3a76-4b38-992e-
000000000004
G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200 36ab08cb-3a76-4b38-992e-
000000000002
 G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 00000000-0000-0000-0000-
000000000000

Exemplo 8 – Associar uma VM a um grupo de CPU

existente
Aqui, adicionaremos uma VM a um grupo de CPU existente. Observe que a VM não
deve estar associada a nenhum grupo de CPU existente ou a configuração da ID do
grupo de CPU falhará.

Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:36AB08CB-3A76-4B38-

992E-000000000001

Agora, confirme se a VM G1 está no grupo de CPU desejado.

Console

C:\vm\tools>[Link] GetVmGroup
VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G2 4ABCFC2F-6C22-498C-BB38-7151CE678758 36ab08cb-3a76-4b38-992e-
000000000002
P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC 36ab08cb-3a76-4b38-992e-
000000000003
P2 A593D93A-3A5F-48AB-8862-A4350E3459E8 36ab08cb-3a76-4b38-992e-
000000000004
G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200 36ab08cb-3a76-4b38-992e-
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 36AB08CB-3A76-4B38-992E-
000000000001

Exemplo 9 – Imprimir todas as VMs agrupadas pela ID do

grupo de CPU
Console

C:\vm\tools>[Link] GetGroupVms
CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36AB08CB-3A76-4B38-992E-000000000001 G1 F699B50F-86F2-4E48-8BA5-
 EB06883C1FDC
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-
7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-
DE4102787200
36ab08cb-3a76-4b38-992e-000000000003 P1 973B9426-0711-4742-AD3B-
D8C39D6A0DEC
36ab08cb-3a76-4b38-992e-000000000004 P2 A593D93A-3A5F-48AB-8862-
A4350E3459E8

Exemplo 10 – Imprimir todas as VMs para um único grupo

de CPU
Console

C:\vm\tools>[Link] GetGroupVms /GroupId:36ab08cb-3a76-4b38-992e-

000000000002

CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-
7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-
DE4102787200

Exemplo 11 – Tentar excluir um grupo de CPU não vazio

Somente grupos de CPU vazios, ou seja, grupos de CPU sem VMs associadas, podem ser
excluídos. A tentativa de excluir um grupo de CPU não vazio falhará.

Console

C:\vm\tools>[Link] DeleteGroup /GroupId:36ab08cb-3a76-4b38-992e-

000000000001
(null)
Failed with error 0xc0350070

Exemplo 12 – Desassociar a única VM de um grupo de

CPU e excluir o grupo
Neste exemplo, usaremos vários comandos para examinar um grupo de CPU, remover a
única VM pertencente a esse grupo e, em seguida, excluir o grupo.
Primeiro, vamos enumerar as VMs em nosso grupo.

Console

C:\vm\tools>[Link] GetGroupVms /GroupId:36AB08CB-3A76-4B38-992E-

000000000001
CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36AB08CB-3A76-4B38-992E-000000000001 G1 F699B50F-86F2-4E48-8BA5-
EB06883C1FDC

Vemos que apenas uma única VM, chamada G1, pertence a esse grupo. Vamos remover
a VM G1 do nosso grupo definindo a ID de grupo da VM como NULL.

Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:00000000-0000-0000-

0000-000000000000

E verificar nossa alteração...

Console

C:\vm\tools>[Link] GetVmGroup /VmName:g1

VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 00000000-0000-0000-0000-
000000000000

Agora que o grupo está vazio, podemos excluí-lo com segurança.

Console

C:\vm\tools>[Link] DeleteGroup /GroupId:36ab08cb-3a76-4b38-992e-

000000000001

E confirmar se nosso grupo se foi.

Console

C:\vm\tools>[Link] GetGroups
CpuGroupId CpuCap LpIndexes
------------------------------------ ------ -----------------------------
 36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31

Exemplo 13 – Associar uma VM de volta ao grupo de CPU

original
Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:36AB08CB-3A76-4B38-

992E-000000000002

C:\vm\tools>[Link] GetGroupVms
CpuGroupId VmName VmId
------------------------------------ -------------------------------- ------
------------------------------
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200
36AB08CB-3A76-4B38-992E-000000000002 G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC
36ab08cb-3a76-4b38-992e-000000000003 P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC
36ab08cb-3a76-4b38-992e-000000000004 P2 A593D93A-3A5F-48AB-8862-A4350E3459E8
Gerenciar tipos de agendador de
hipervisor Hyper-V
Artigo • 02/08/2023

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server versão 1803, Windows Server versão 1709, Windows 10

Este artigo descreve novos modos de lógica de agendamento de processador virtual

introduzidos no Windows Server 2016. Esses modos ou tipos de agendador determinam
como o hipervisor do Hyper-V aloca e gerencia o trabalho entre processadores virtuais
convidados. Um administrador de host do Hyper-V pode:

Selecione os tipos de agendador de hipervisor mais adequados para as máquinas

virtuais (VMs) convidadas.
Configure as VMs para aproveitar a lógica de agendamento.

７ Observação

Atualizações são necessárias para usar os recursos do agendador do hipervisor

descritos neste documento. Para obter mais informações, confira as Atualizações
necessárias.

Tela de fundo
Antes de discutir a lógica e os controles por trás do agendamento de processador
virtual do Hyper-V, é útil examinar os conceitos básicos abordados neste artigo.

Entender o SMT
O multithreading simultâneo (SMT) é uma técnica em designs de processador modernos
que permite que threads de execução independentes e separados compartilhem os
recursos do processador. O SMT geralmente oferece um aumento de desempenho
modesto para a maioria das cargas de trabalho. Ele paraleliza os cálculos quando
possível, aumentando a taxa de transferência de instrução. Nenhum ganho de
desempenho ou mesmo uma pequena perda de desempenho pode ocorrer quando
ocorre a contenção entre threads para recursos de processador compartilhados.
Os processadores que dão suporte ao SMT são disponibilizados pela Intel e AMD. A
Intel refere-se às ofertas de SMT como Tecnologia Intel Hyper Threading ou Intel HT.

Para fins deste artigo, as descrições do SMT e como ele é usado pelo Hyper-V se
aplicam igualmente aos sistemas Intel e AMD.

Para obter mais informações sobre a tecnologia Intel HT, confira Tecnologia Hyper-
Threading Intel .

Para obter mais informações sobre o AMD SMT, confira Arquitetura de núcleo
"Zen" .

Entender como o Hyper-V virtualiza

processadores
Antes de considerar os tipos de agendador do hipervisor, também é útil entender a
arquitetura Hyper-V. Você pode encontrar um resumo geral na visão geral da tecnologia
Hyper-V. Os seguintes conceitos são importantes para este artigo:

O Hyper-V cria e gerencia partições de VM, em que os recursos de computação

são alocados e compartilhados, sob controle do hipervisor. As partições fornecem
limites de isolamento fortes entre todas as VMs convidadas e entre as VMs
convidadas e a partição raiz.

A partição raiz é em si uma partição de VM, embora tenha propriedades exclusivas

e privilégios maiores do que as VMs convidadas. A partição raiz:
Fornece os serviços de gerenciamento que controlam todas as VMs convidadas.
Fornece suporte a dispositivos virtuais para convidados.
Gerencia toda a E/S do dispositivo para VMs convidadas.

É recomendável não executar nenhuma carga de trabalho de aplicativo na partição

raiz.

Cada VP (processador virtual) da partição raiz é mapeado 1:1 para um LP

(processador lógico) subjacente. Um VP de host sempre é executado no mesmo LP
subjacente. Não há migração dos VPs da partição raiz.

Por padrão, os LPs nos quais os VPs host são executados também podem executar
VPs convidados.

O hipervisor pode agendar o VP convidado para ser executado em qualquer

processador lógico disponível. Embora o agendador do hipervisor tente considerar
a localidade do cache temporal, a topologia de acesso à memória não uniforme
 (NUMA) e muitos outros fatores ao agendar um VP convidado, em última análise,
o VP pode ser agendado em qualquer LP de host.

Tipos de agendador do hipervisor

No Windows Server 2016, o hipervisor hyper-V dá suporte a vários modos de lógica do
agendador, que determinam como o hipervisor agenda processadores virtuais nos
processadores lógicos subjacentes. Esses tipos de agendador são:

O agendador clássico.
O agendador principal.
O agendador raiz.

O agendador clássico
O agendador clássico tem sido o padrão para todas as versões do hipervisor do Hyper-
V do Windows desde sua criação, incluindo o Hyper-V do Windows Server 2016. O
agendador clássico fornece um modelo de agendamento de compartilhamento justo,
preemptivo e round robin para processadores virtuais convidados.

O tipo de agendador clássico é o mais apropriado para a maioria dos usos tradicionais
do Hyper-V, como nuvens privadas, provedores de hospedagem e assim por diante. As
características de desempenho são bem compreendidas e melhor otimizadas para dar
suporte a uma ampla gama de cenários de virtualização, como:

Subscrição excessiva de VPs para LPs.

Execução de muitas VMs e cargas de trabalho heterogêneas simultaneamente.
Executando VMs de alto desempenho de maior escala.
Suporte ao conjunto de recursos completo do Hyper-V sem restrições e outros
cenários.

O agendador principal
O agendador principal do hipervisor é uma alternativa à lógica do agendador clássico e
foi introduzido no Windows Server 2016 e no Windows 10 versão 1607. O agendador
principal oferece um forte limite de segurança para isolamento de carga de trabalho
convidado e redução da variabilidade de desempenho para cargas de trabalho dentro
de VMs que estão em execução em um host de virtualização habilitado para SMT. O
agendador principal dá suporte à execução de VMs SMT e não SMT simultaneamente
no mesmo host de virtualização habilitado para SMT.
O agendador principal:

Usa a topologia SMT do host de virtualização.

Opcionalmente, expõe pares SMT a VMs convidadas.
Agenda grupos de processadores virtuais convidados da mesma VM para grupos
de processadores lógicos SMT.

Esse trabalho ocorre simetricamente. Se os LPs estiverem em grupos de dois, os VPs

serão agendados em grupos de dois e um núcleo nunca será compartilhado entre VMs.
Quando você agenda o VP para uma VM sem SMT habilitado, esse VP consome todo o
núcleo quando ele é executado. O resultado geral do agendador principal é que:

Os VPs convidados são restritos a serem executados em pares de núcleos físicos

subjacentes, isolando uma VM para os limites do núcleo do processador e
reduzindo a vulnerabilidade a ataques de espionagem de canal lateral de VMs
mal-intencionadas.
A variabilidade na taxa de transferência é reduzida.
O desempenho é potencialmente reduzido. Se apenas um em um grupo de VPs
puder ser executado, apenas um dos fluxos de instrução no núcleo será iniciado
enquanto o outro ficar ocioso.
O sistema operacional e os aplicativos em execução na VM convidada podem usar
o comportamento SMT e as APIs (interfaces de programação) para controlar e
distribuir o trabalho entre threads SMT, da mesma forma que fariam quando não
eram virtuais.
Existe um limite de segurança forte para o isolamento da carga de trabalho de
convidado. Os VPs convidados são restritos a serem executados em pares de
núcleos físicos subjacentes, reduzindo a vulnerabilidade a ataques de espionagem
de canal lateral.

O agendador principal é usado por padrão a partir do Windows Server 2019. No

Windows Server 2016, o agendador principal é opcional. O administrador do host
Hyper-V deve habilitá-lo explicitamente. O agendador clássico é o padrão.

Comportamento do agendador principal com SMT do host

desabilitado

Em alguns casos, você pode configurar o hipervisor para usar o tipo de agendador
principal, mas a funcionalidade SMT está desabilitada ou não está presente no host de
virtualização. Nesses casos, o comportamento do agendador clássico é usado
independentemente da configuração do tipo de agendador do hipervisor.

O agendador raiz
O agendador raiz foi introduzido com o Windows 10 versão 1803. Quando o tipo de
agendador raiz está habilitado, o hipervisor cede o controle do agendamento de
trabalho para a partição raiz. O agendador NT na instância do sistema operacional da
partição raiz gerencia todos os aspectos do trabalho de agendamento para LPs do
sistema.

O agendador raiz atende aos requisitos exclusivos inerentes ao suporte a uma partição
de utilitário para fornecer isolamento de carga de trabalho forte, conforme usado com o
WDAG (Windows Defender Application Guard). Neste cenário, deixar as
responsabilidades de agendamento para o sistema operacional raiz oferece várias
vantagens.

Você pode usar controles de recursos de CPU aplicáveis a cenários de contêiner

com a partição do utilitário, simplificando o gerenciamento e a implantação.
O agendador raiz do sistema operacional pode coletar prontamente métricas
sobre o uso da CPU da carga de trabalho dentro do contêiner. Ele pode usar esses
dados como entrada para a mesma política de agendamento aplicável a todas as
outras cargas de trabalho no sistema.
Essas mesmas métricas também ajudam a atribuir o trabalho realizado em um
contêiner de aplicativo para o sistema de host. O acompanhamento dessas
métricas é mais difícil com cargas de trabalho de VM tradicionais, em que alguns
funcionam em nome de todas as VMs em execução na partição raiz.

Uso do agendador raiz em sistemas cliente

No Windows 10 versão 1803, o agendador raiz é usado por padrão somente em
sistemas cliente, em que:

O hipervisor pode ser habilitado para dar suporte à segurança baseada em

virtualização e ao isolamento da carga de trabalho WDAG.
A operação adequada de sistemas futuros com arquiteturas principais
heterogêneas é útil.

É a única configuração de agendador de hipervisor com suporte para sistemas cliente.

Os administradores não devem tentar substituir o tipo de agendador de hipervisor
padrão em sistemas clientes do Windows 10.

Controles de recursos de CPU da máquina virtual e o agendador

raiz

Os controles de recursos do processador de VM fornecidos pelo Hyper-V não têm

suporte quando o agendador raiz do hipervisor está habilitado. A lógica do agendador
do sistema operacional raiz está gerenciando recursos de host globalmente e não tem
conhecimento das configurações específicas de uma VM. Os controles de recursos de
processador do Hyper-V por VM, como limites, pesos e reservas, somente são aplicáveis
quando o hipervisor controla diretamente o agendamento de VP, como com os tipos de
agendador clássico e principal.

Uso do agendador raiz em sistemas de servidor

No momento, não recomendamos usar o agendador raiz com o Hyper-V em servidores.
Suas características de desempenho ainda não foram totalmente caracterizadas e
ajustadas para acomodar a ampla gama de cargas de trabalho típicas de muitas
implantações de virtualização de servidor.

Habilitar o SMT em VMs convidadas

Depois que o hipervisor do host de virtualização for configurado para usar o tipo de
agendador principal, você poderá configurar VMs convidadas para usar o SMT. Expor o
fato de que os VPs são hiperthreaded para uma VM convidada permite que o
agendador no sistema operacional convidado e cargas de trabalho em execução na VM
detectem e usem a topologia SMT em seu próprio agendamento de trabalho.

No Windows Server 2016, o SMT convidado não está configurado por padrão. Um
administrador de host do Hyper-V deve habilitá-lo explicitamente.
No Windows Server 2019, novas VMs criadas no host herdam a topologia SMT do
host por padrão. Ou seja, uma VM versão 9.0 que você cria em um host com dois
threads SMT por núcleo também veria dois threads SMT por núcleo.

Você deve usar o PowerShell para habilitar o SMT em uma VM convidada. Não há
nenhuma interface do usuário fornecida no Gerenciador do Hyper-V. Para habilitar o
SMT em uma VM convidada, abra uma janela do PowerShell com permissões suficientes
e insira Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <n> , onde \<n> é o
número de threads SMT por núcleo que a VM convidada vê. \<n> = 0 define o valor
HwThreadCountPerCore para corresponder à contagem de threads SMT do host por valor

principal.

７ Observação

Há suporte para a configuração HwThreadCountPerCore = 0 a partir do Windows

Server 2019.
O exemplo a seguir mostra as informações do sistema obtidas do sistema operacional
convidado em execução em uma VM. Há dois processadores virtuais e SMT habilitados.
O sistema operacional convidado está detectando dois processadores lógicos que
pertencem ao mesmo núcleo.

Configurar o tipo de agendador de hipervisor

no Hyper-V do Windows Server 2016
O Hyper-V do Windows Server 2016 usa o modelo de agendador do hipervisor clássico
por padrão. Opcionalmente, você pode configurar o hipervisor para usar o agendador
principal. O agendador principal aumenta a segurança restringindo os VPs convidados a
serem executados em pares SMT físicos correspondentes. Essa configuração dá suporte
ao uso de VMs com agendamento SMT para seus VPs convidados.

７ Observação

Recomendamos que todos os clientes que executam o Hyper-V do Windows Server

2016 selecionem o agendador principal para garantir que seus hosts de
virtualização estejam protegidos de forma ideal contra VMs convidadas
potencialmente mal-intencionadas.

O Hyper-V do Windows Server 2019 usa como

padrão o agendador principal
Para garantir que os hosts Hyper-V sejam implantados na configuração de segurança
ideal, o Hyper-V do Windows Server 2019 agora usa o modelo de agendador de
hipervisor principal por padrão. Opcionalmente, o administrador do host pode
configurar o host para usar o agendador clássico herdado. Antes de substituir as
configurações padrão, os administradores devem ler, entender e considerar
cuidadosamente os impactos que cada tipo de agendador tem sobre a segurança e o
desempenho dos hosts de virtualização. Para obter mais informações, confira Sobre a
seleção de tipo de agendador de hipervisor Hyper-V.

Atualizações necessárias
Atualizações a seguir são necessárias para usar os recursos do agendador do hipervisor
descritos neste documento. Essas atualizações incluem alterações para dar suporte à
nova opção BCD hypervisorschedulertype , que é necessária para a configuração do
host.

Versão Liberação Atualização necessária Artigo do KB

Windows Server 2016 1607 2018.07 C KB4338822

Windows Server 2016 1703 2018.07 C KB4338827

Windows Server 2016 1709 2018.07 C KB4338817

Windows Server 2019 1804 Não Não

Selecione o tipo de agendador de hipervisor no

Windows Server
A configuração do agendador do hipervisor é controlada por meio da entrada BCD
hypervisorschedulertype .

Para selecionar um tipo de agendador, abra um prompt de comando com privilégios de

administrador e insira bcdedit /set hypervisorschedulertype type , onde type é uma
destas opções:

Clássico
Core
Raiz

Você deve reinicializar o sistema para que as alterações no tipo de agendador do

hipervisor entrem em vigor.

７ Observação
 O agendador raiz do hipervisor não tem suporte no Hyper-V do Windows Server
no momento. Os administradores do Hyper-V não devem tentar configurar o
agendador raiz para uso com cenários de virtualização de servidor.

Determinar o tipo de agendador atual

Você pode determinar o tipo de agendador de hipervisor atual em uso examinando o
log do sistema do Visualizador de Eventos. Você pode ver a ID de evento de
inicialização do hipervisor 2 mais recente, que relata o tipo de agendador de hipervisor
configurado na inicialização do hipervisor. Você pode obter os eventos de inicialização
do hipervisor no Visualizador de Eventos do Windows ou no PowerShell.

A ID 2 de evento de inicialização do hipervisor 2 indica o tipo de agendador do

hipervisor, em que:

1 = Agendador clássico, SMT desabilitado

2 = Agendador clássico
3 = Agendador principal
4 = Agendador raiz
Consultar o evento de inicialização do tipo do agendador
do hipervisor Hyper-V usando o PowerShell
Para consultar o ID 2 do evento do processo de trabalho do Hyper-V usando o
PowerShell, insira os comandos a seguir em um prompt do PowerShell.

PowerShell

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-

Hypervisor"; ID=2} -MaxEvents 1
Sobre a escolha do tipo de agendador
do Hipervisor Hyper-V
Artigo • 11/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server, versão 1709, Windows Server, versão 1803

Este documento descreve alterações importantes no uso padrão do Hyper-V e o uso

recomendado de tipos de agendador de hipervisor. Essas alterações afetam a segurança
do sistema e o desempenho da virtualização. Os administradores de host de
virtualização devem examinar e entender as alterações e implicações descritas neste
documento e avaliar cuidadosamente os impactos, as diretrizes de implantação
sugeridas e os fatores de risco envolvidos para entender melhor como implantar e
gerenciar hosts Hyper-V diante do cenário de segurança em rápida mudança.

） Importante

Atualmente, vulnerabilidades de segurança do lado do canal conhecidas vistas em

várias arquiteturas de processador podem ser exploradas por uma VM convidada
mal-intencionada com o comportamento de agendamento do tipo de agendador
clássico do hipervisor herdado quando executado em hosts com SMT
(Multithreading Simultâneo) habilitado. Se explorada com êxito, uma carga de
trabalho mal-intencionada poderá observar dados fora de seu limite de partição.
Essa classe de ataques pode ser atenuada com a configuração do hipervisor Hyper-
V para utilizar o tipo de agendador principal do hipervisor e a reconfiguração de
VMs convidadas. Com o agendador principal, o hipervisor restringe os VPs de uma
VM convidada a serem executados no mesmo núcleo de processador físico,
isolando fortemente a capacidade da VM de acessar dados até os limites do núcleo
físico no qual ela é executada. Essa é uma mitigação altamente eficaz contra esses
ataques do lado do canal, o que impede que a VM observe artefatos de outras
partições, seja a raiz, seja outra partição de convidado. Portanto, a Microsoft está
alterando as configurações padrão e as recomendadas para hosts de virtualização e
VMs convidadas.

Tela de fundo
Desde o Windows Server 2016, o Hyper-V dá suporte a vários métodos de
agendamento e gerenciamento de processadores virtuais, chamados de tipos de
agendador de hipervisor. Uma descrição detalhada de todos os tipos de agendador de
hipervisor pode ser encontrada em Noções básicas e uso de tipos de agendador de
hipervisor do Hyper-V.

７ Observação

Novos tipos de agendador de hipervisor foram apresentados pela primeira vez no

Windows Server 2016 e não estão disponíveis em versões anteriores. Todas as
versões do Hyper-V antes do Windows Server 2016 dão suporte apenas ao
agendador clássico. O suporte ao agendador principal só foi publicado
recentemente.

Sobre os tipos de agendador do hipervisor

Este artigo se concentra especificamente no uso do novo tipo de agendador principal
do hipervisor em comparação com o agendador "clássico" herdado e como esses tipos
de agendador se cruzam com o uso de Multi-Threading Simétrico, ou SMT. É
importante entender as diferenças entre os agendadores principais e clássicos e como
cada local funciona de VMs convidadas nos processadores do sistema subjacentes.

O agendador clássico
O agendador clássico refere-se ao método round robin de compartilhamento justo de
agendamento de trabalho em VPs (processadores virtuais) em todo o sistema, incluindo
VPs raiz, bem como VPs pertencentes a VMs convidadas. O agendador clássico tem sido
o tipo de agendador padrão usado em todas as versões do Hyper-V (até o Windows
Server 2019, conforme descrito aqui). As características de desempenho do agendador
clássico são bem compreendidas e o agendador clássico é demonstrado como capaz de
dar suporte ao excesso de assinaturas de cargas de trabalho, ou seja, excesso de
assinaturas da proporção VP:LP do host por uma margem razoável (dependendo dos
tipos de cargas de trabalho que estão sendo virtualizadas, utilização geral de recursos,
etc.).

Quando executado em um host de virtualização com SMT habilitado, o agendador

clássico agendará VPs convidados de qualquer VM em cada thread SMT pertencente a
um núcleo independentemente. Portanto, diferentes VMs podem ser executadas no
mesmo núcleo ao mesmo tempo (uma VM em execução em um thread de um núcleo
enquanto outra VM está em execução no outro thread).
O agendador principal
O agendador principal aproveita as propriedades do SMT para fornecer isolamento de
cargas de trabalho de convidado, o que afeta a segurança e o desempenho do sistema.
O agendador principal garante que os VPs de uma VM sejam agendados em threads
SMT irmãos. Isso é feito simetricamente para que, se os LPs estiverem em grupos de
dois, os VPs sejam agendados em grupos de dois e um núcleo de CPU do sistema nunca
seja compartilhado entre VMs.

Ao agendar VPs convidados em pares SMT subjacentes, o agendador principal oferecerá

um forte limite de segurança para isolamento de carga de trabalho e também poderá
ser usado para reduzir a variabilidade do desempenho em cargas de trabalho
dependentes de latência.

Observe que quando o VP é agendado para uma máquina virtual sem SMT habilitado,
esse VP consumirá todo o núcleo quando for executado e o thread SMT irmão do
núcleo ficará ocioso. Isso é necessário para fornecer o isolamento correto da carga de
trabalho, mas afeta o desempenho geral do sistema, especialmente à medida que os LPs
do sistema se tornam excessivamente assinados, ou seja, quando a proporção total de
VP:LP excede 1:1. Portanto, a execução de VMs convidadas configuradas sem vários
threads por núcleo é uma configuração abaixo do ideal.

Benefícios do uso do agendador principal

O agendador principal oferece os seguintes benefícios:

Um forte limite de segurança para isolamento de carga de trabalho de convidado:

os VPs convidados são restritos a serem executados em pares de núcleos físicos
subjacentes, reduzindo a vulnerabilidade a ataques de espionagem do lado do
canal.

Variabilidade reduzida da carga de trabalho: a variabilidade da taxa de

transferência da carga de trabalho convidada é bastante reduzida, o que oferece
maior consistência de carga de trabalho.

Uso do SMT em VMs convidadas – o sistema operacional e os aplicativos em

execução na máquina virtual convidada podem utilizar o comportamento SMT e as
APIs (interfaces de programação) para controlar e distribuir o trabalho entre
threads SMT, assim como fariam quando executados sem virtualização.

O agendador principal é usado atualmente em hosts de virtualização do Azure,

especificamente para aproveitar o limite de segurança forte e a baixa variabilidade da
carga de trabalho. A Microsoft acredita que o tipo de agendador principal deve ser e
continuará sendo o tipo de agendamento de hipervisor padrão para a maioria dos
cenários de virtualização. Portanto, para garantir que nossos clientes fiquem protegidos
por padrão, a Microsoft está fazendo essa alteração para o Windows Server 2019 agora.

Principais impactos no desempenho do agendador nas

cargas de trabalho de convidado
Embora seja necessário atenuar efetivamente determinadas classes de vulnerabilidades,
o agendador principal também pode reduzir potencialmente o desempenho. Os clientes
podem ver uma diferença nas características de desempenho com suas VMs e impacto
na capacidade geral da carga de trabalho de seus hosts de virtualização. Nos casos em
que o agendador principal precisar executar um VP não SMT, apenas um dos fluxos de
instrução no núcleo lógico subjacente será executado enquanto o outro deverá ficar
ocioso. Isso limitará a capacidade total do host em cargas de trabalho de convidado.

Esses impactos no desempenho podem ser minimizados com o cumprimento das

diretrizes de implantação neste documento. Os administradores de host precisam
considerar cuidadosamente seus cenários específicos de implantação de virtualização e
equilibrar sua tolerância ao risco de segurança com a necessidade de densidade máxima
de carga de trabalho, o excesso de consolidação de hosts de virtualização, etc.

Alterações nas configurações padrão e

recomendadas para Windows Server 2016 e
Windows Server 2019
A implantação de hosts Hyper-V com a postura de segurança máxima requer o uso do
tipo de agendador principal do hipervisor. Para garantir que nossos clientes fiquem
protegidos por padrão, a Microsoft está alterando as configurações padrão e
recomendadas a seguir.

７ Observação

Embora o suporte interno do hipervisor para os tipos de agendador tenha sido

incluído na versão inicial do Windows Server 2016, do Windows Server 1709 e do
Windows Server 1803, atualizações são exigidas para acessar o controle de
configuração que permite selecionar o tipo de agendador do hipervisor. Consulte
Noções básicas e uso de tipos de agendador de hipervisor do Hyper-V para obter
detalhes sobre essas atualizações.
Alterações no host de virtualização
O hipervisor usará o agendador principal por padrão a partir do Windows Server
2019.

A Microsoft confirma a configuração do agendador principal no Windows Server

2016. Há suporte ao tipo de agendador principal do hipervisor no Windows Server
2016; no entanto, o padrão é o agendador clássico. O agendador principal é
opcional e precisa ser habilitado explicitamente pelo administrador de host do
Hyper-V.

Alterações na configuração da máquina virtual

No Windows Server 2019, novas máquinas virtuais criadas com a VM padrão
versão 9.0 herdarão automaticamente as propriedades SMT (habilitadas ou
desabilitadas) do host de virtualização. Ou seja, se o SMT estiver habilitado no host
físico, as VMs recém-criadas também terão o SMT habilitado e herdarão a
topologia SMT do host por padrão, com a VM tendo o mesmo número de threads
de hardware por núcleo que o sistema subjacente. Isso será refletido na
configuração da VM com HwThreadCountPerCore = 0, em que 0 indica que a VM
deve herdar as configurações de SMT do host.

As máquinas virtuais existentes com uma versão de VM 8.2 ou anterior manterão a

configuração original do processador de VM para HwThreadCountPerCore, e o
padrão para convidados da versão da VM 8.2 é HwThreadCountPerCore = 1.
Quando esses convidados forem executados em um host do Windows Server
2019, eles serão tratados da seguinte maneira:

1. Se a VM tiver uma contagem de VP menor ou igual à contagem de núcleos

LP, a VM será tratada como uma VM não SMT pelo agendador principal.
Quando o VP convidado for executado em um único thread SMT, o thread
SMT irmão do núcleo ficará ocioso. Isso não é ideal e resultará em perda
geral de desempenho.

2. Se a VM tiver mais VPs do que núcleos LP, a VM será tratada como uma VM
SMT pelo agendador principal. No entanto, a VM não observará outras
indicações de que é uma VM SMT. Por exemplo, o uso da instrução CPUID ou
das APIs do Windows para consultar a topologia da CPU pelo sistema
operacional ou pelos aplicativos não indicará que o SMT está habilitado.

Quando uma VM existente é explicitamente atualizada de versões da VM

anteriores para a versão 9.0 por meio da operação Update-VM, ela manterá seu
 valor atual de HwThreadCountPerCore. A VM não terá o SMT habilitado à força.

No Windows Server 2016, a Microsoft recomenda habilitar o SMT para VMs

convidadas. Por padrão, as VMs criadas no Windows Server 2016 teriam o SMT
desabilitado, ou seja, HwThreadCountPerCore é definido como 1, a menos que seja
explicitamente alterado.

７ Observação

O Windows Server 2016 não dá suporte à configuração HwThreadCountPerCore

como 0.

Gerenciando a configuração de SMT da máquina virtual

A configuração de SMT da máquina virtual convidada é definida conforme a VM. O
administrador do host pode inspecionar e definir a configuração de SMT de uma VM e
escolher dentre as seguintes opções:

1. Configurar VMs para serem executadas como habilitadas para SMT, herdando
opcionalmente a topologia SMT do host automaticamente

2. Configurar VMs para serem executadas como não SMT

A configuração de SMT para uma VM é exibida nos painéis Resumo no console do

Gerenciador do Hyper-V. A definição das configurações de SMT de uma VM pode ser
feita usando as Configurações da VM ou o PowerShell.

Definindo as configurações de SMT da VM usando o PowerShell

Para definir as configurações de SMT para uma máquina virtual convidada, abra uma
janela do PowerShell com permissões suficientes e digite:

PowerShell

Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>

Em que:

0 = Não há suporte à herança d a topologia SMT do host (não há suporte a essa

configuração de HwThreadCountPerCore=0 no Windows Server 2016)

1 = Não SMT
 Valores > 1 = o número desejado de threads SMT por núcleo. Não pode exceder o
número de threads SMT físicos por núcleo.

Para ler as configurações de SMT para uma máquina virtual convidada, abra uma janela
do PowerShell com permissões suficientes e digite:

PowerShell

(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore

Observe que as VMs convidadas configuradas com HwThreadCountPerCore = 0 indicam

que o SMT será habilitado para o convidado e exporá o mesmo número de threads SMT
ao convidado que estão no host de virtualização subjacente, normalmente 2.

As VMs convidadas podem observar alterações na

topologia da CPU em cenários de mobilidade de VM
O sistema operacional e os aplicativos em uma VM podem ver alterações nas
configurações de host e VM antes e depois de eventos do ciclo de vida da VM, como
migração ao vivo ou operações de salvamento e restauração. Durante uma operação na
qual o estado da VM é salvo e restaurado, a configuração HwThreadCountPerCore da
VM e o valor realizado (ou seja, a combinação computada da configuração da VM e da
configuração do host de origem) são migrados. A VM continuará em execução com
essas configurações no host de destino. No ponto em que a VM foi desligada e
reiniciou, é possível que o valor percebido observado pela VM seja alterado. Isso deve
ser benigno, pois o software da camada de aplicativo e sistema operacional devem
procurar informações de topologia da CPU como parte de seus fluxos normais de
código de inicialização. No entanto, como essas sequências de inicialização de tempo
de inicialização são ignoradas durante as operações de migração dinâmica ou de
salvamento/restauração, as VMs que passam por essas transições de estado poderiam
seguir o valor calculado originalmente até serem desligadas e reiniciadas.

Alertas sobre configurações de VM não ideais

Máquinas virtuais configuradas com mais VPs do que núcleos físicos no host resultam
em uma configuração não ideal. O agendador de hipervisor tratará essas VMs como se
tivessem reconhecimento de SMT. No entanto, o software do sistema operacional e do
aplicativo na VM verá uma topologia de CPU mostrando que a SMT está desabilitada.
Quando essa condição for detectada, o Processo de Trabalho do Hyper-V registrará em
log um evento no host de virtualização avisando o administrador do host de que a
configuração da VM não é ideal e recomendando que a SMT seja habilitada para a VM.
Como identificar VMs configuradas de forma não ideal
Você pode identificar VMs não SMT procurando no log do sistema no Visualizador de
Eventos o ID de evento 3498 do Processo de Trabalho do Hyper-V, que será disparado
para uma VM sempre que o número de VPs na VM for maior que a contagem de
núcleos físicos. Os eventos do processo de trabalho podem ser obtidos do Visualizador
de Eventos ou por meio do PowerShell.

Consultando o evento de VM do processo de trabalho do Hyper-V

usando o PowerShell
Para consultar o ID de evento do processo de trabalho do Hyper-V 3498 usando o
PowerShell, insira os comandos a seguir em um prompt do PowerShell.

PowerShell

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-

Worker"; ID=3498}

Impactos da configuração de SMT convidada no uso de

esclarecimentos de hipervisor para sistemas operacionais
convidados
O hipervisor da Microsoft oferece vários esclarecimentos, ou dicas, que o sistema
operacional em execução em uma VM convidada pode consultar e usar para disparar
otimizações, como aquelas que podem beneficiar o desempenho ou melhorar o
tratamento de várias condições na execução virtualizada. Um esclarecimento
introduzido recentemente diz respeito ao tratamento do agendamento do processador
virtual e ao uso de mitigações do sistema operacional para ataques do lado do canal
que exploram a SMT.

７ Observação

A Microsoft recomenda que os administradores de host habilitem a SMT para VMs

convidadas a fim de otimizar o desempenho da carga de trabalho.

Os detalhes desse esclarecimento de convidado são fornecidos abaixo; no entanto, a

principal conclusão para os administradores de host de virtualização é que as máquinas
virtuais devem ter HwThreadCountPerCore configurado para corresponder à
configuração de SMT física do host. Isso permite que o hipervisor relate que não há
compartilhamento de núcleo não arquitetônico. Portanto, qualquer sistema operacional
convidado que dê suporte a otimizações que exijam o esclarecimento pode estar
habilitado. No Windows Server 2019, crie outras VMs e deixe o valor padrão de
HwThreadCountPerCore (0). VMs mais antigas migradas de hosts do Windows Server
2016 podem ser atualizadas para a versão de configuração do Windows Server 2019.
Depois de fazer isso, a Microsoft recomenda definir HwThreadCountPerCore = 0. No
Windows Server 2016, a Microsoft recomenda definir HwThreadCountPerCore para
corresponder à configuração do host (normalmente 2).

Detalhes de esclarecimento de
NoNonArchitecturalCoreSharing
Desde o Windows Server 2016, o hipervisor define um novo esclarecimento para
descrever sua manipulação de agendamento e posicionamento de VP para o sistema
operacional convidado. Esse esclarecimento é definido na Especificação Funcional de
Nível Geral do Hipervisor v5.0c.

Hypervisor synthetic CPUID leaf

[Link][NoNonArchitecturalCoreSharing = 1] indica que um
processador virtual nunca compartilhará um núcleo físico com outro processador virtual,
exceto em caso de processadores virtuais relatados como threads SMT irmãos. Por
exemplo, um VP convidado nunca será executado em um thread SMT junto com um VP
raiz em execução simultaneamente em um thread SMT irmão no mesmo núcleo do
processador. Essa condição só é possível na execução virtualizada e, portanto,
representa um comportamento de SMT não arquitetônica que também tem sérias
implicações de segurança. O sistema operacional convidado pode usar
NoNonArchitecturalCoreSharing = 1 como uma indicação de que é seguro habilitar
otimizações, o que pode ajudá-lo a evitar a sobrecarga de desempenho da configuração
de STIBP.

Em determinadas configurações, o hipervisor não indicará que

NoNonArchitecturalCoreSharing = 1. Por exemplo, se um host tiver a SMT habilitada e
estiver configurado para usar o agendador clássico do hipervisor,
NoNonArchitecturalCoreSharing será 0. Isso pode impedir que convidados habilitados
habilitem determinadas otimizações. Portanto, a Microsoft recomenda que os
administradores de host que usam SMT dependam do agendador principal do
hipervisor e verifiquem se as máquinas virtuais estão configuradas para herdar sua
configuração de SMT do host a fim de garantir o desempenho ideal da carga de
trabalho.
Resumo
O cenário de ameaças à segurança continua evoluindo. Para garantir que nossos clientes
estejam protegidos por padrão, a Microsoft está alterando a configuração padrão para
o hipervisor e as máquinas virtuais a partir do Windows Server 2019 Hyper-V e
fornecendo diretrizes e recomendações atualizadas para clientes que executam o
Hyper-V do Windows Server 2016. Os administradores de host de virtualização devem:

Ler e entender as diretrizes fornecidas neste documento

Avaliar e ajustar cuidadosamente suas implantações de virtualização para garantir

que elas atendam às metas de segurança, desempenho, densidade de virtualização
e capacidade de resposta da carga de trabalho para seus requisitos exclusivos

Considerar configurar novamente os hosts Hyper-V do Windows Server 2016

existentes para aproveitar os benefícios de segurança sólidos oferecidos pelo
agendador principal do hipervisor

Atualizar as VMs não SMT existentes para reduzir os impactos no desempenho das
restrições de agendamento impostas pelo isolamento de VP que resolve
vulnerabilidades de segurança de hardware
Gerenciar os Serviços de Integração do
Hyper-V
Artigo • 12/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e
Windows 11. Windows 10

Os Serviços de Integração do Hyper-V aprimoram o desempenho da máquina virtual e

fornecem recursos de conveniência aproveitando a comunicação bidirecional com o
host Hyper-V. Muitos desses serviços são conveniências, como cópia de arquivo
convidado, enquanto outros são importantes para a funcionalidade da máquina virtual,
como drivers de dispositivo sintético. Esse conjunto de serviços e drivers às vezes são
chamados de componentes de integração. Você pode controlar se os serviços de
conveniência individuais operam ou não para uma determinada máquina virtual. Os
componentes do driver não devem ser reparados manualmente.

Para obter detalhes sobre cada serviço de integração, consulte Serviços de integração
do Hyper-V.

） Importante

Cada serviço que você deseja usar deve ser habilitado no host e no convidado para
funcionar. Todos os serviços de integração, exceto a Interface do Serviço convidado
do Hyper-V, estão ativados por padrão em sistemas operacionais convidados do
Windows. Os serviços podem ser ativados e desativados individualmente. As
próximas seções mostram como.

Ativar ou desativar um serviço de integração

usando o Gerenciador do Hyper-V
1. No painel central, clique com o botão direito na máquina virtual e selecione
Configurações.

2. No painel esquerdo da janela Configurações, em Gerenciamento, selecione

Serviços de Integração.

O painel Serviços de Integração lista todos os serviços de integração disponíveis no host

Hyper-V e se o host habilitou a máquina virtual para usá-los.
Ativar ou desativar um serviço de integração usando o
PowerShell
Para fazer isso no PowerShell, use Enable-VMIntegrationService e Disable-
VMIntegrationService.

Os exemplos a seguir demonstram a ativação e desativação do serviço de integração de

cópia de arquivo convidado para uma máquina virtual chamada DemoVM.

1. Obtenha uma lista de serviços de integração em execução:

PowerShell

Get-VMIntegrationService -VMName "DemoVM"

2. O resultado deve ser assim:

PowerShell

VMName Name Enabled PrimaryStatusDescription

SecondaryStatusDescription
------ ---- ------- ------------------------ --
------------------------
DemoVM Guest Service Interface False OK
DemoVM Heartbeat True OK OK
DemoVM Key-Value Pair Exchange True OK
DemoVM Shutdown True OK
DemoVM Time Synchronization True OK
DemoVM VSS True OK

3. Ligar a Interface de Serviço de Convidado:

PowerShell

Enable-VMIntegrationService -VMName "DemoVM" -Name "Guest Service

Interface"

4. Verifique se a Interface do Serviço convidado está habilitada:

PowerShell

Get-VMIntegrationService -VMName "DemoVM"

5. Desligar a Interface de Serviço de Convidado:

PowerShell
 Disable-VMIntegrationService -VMName "DemoVM" -Name "Guest Service
Interface"

Verificar a versão dos serviços de integração do

convidado
Alguns recursos podem não funcionar corretamente ou não funcionar se os serviços de
integração do convidado não estiverem atualizados. Para obter as informações de
versão do Windows, entre no sistema operacional convidado, abra um prompt de
comando e execute este comando:

REG QUERY "HKLM\Software\Microsoft\Virtual Machine\Auto" /v

IntegrationServicesVersion

Os sistemas operacionais convidados anteriores não terão todos os serviços disponíveis.

Por exemplo, os convidados do Windows Server 2008 R2 podem não ter a Interface de
Serviço convidado do Hyper-V.

Iniciar e interromper um serviço de integração

de um convidado do Windows
Para que um serviço de integração seja totalmente funcional, seu serviço
correspondente deve estar em execução dentro do convidado, além de ser habilitado
no host. Nos convidados do Windows, cada serviço de integração é listado como um
serviço padrão do Windows. Você pode usar o miniaplicativo Serviços no Painel de
Controle ou no PowerShell para interromper e iniciar esses serviços.

） Importante

Interromper um serviço de integração pode afetar gravemente a capacidade dos

hosts de gerenciar sua máquina virtual. Para funcionar corretamente, cada serviço
de integração que você deseja usar deve estar habilitado no host e no convidado.
Como prática recomendada, você só deve controlar os serviços de integração do
Hyper-V usando as instruções acima. O serviço correspondente no sistema
operacional convidado será interrompido ou iniciado automaticamente quando
você alterar seu status no Hyper-V. Se você iniciar um serviço no sistema
operacional convidado, mas ele estiver desabilitado no Hyper-V, o serviço será
 interrompido. Se você interromper um serviço no sistema operacional convidado
habilitado no Hyper-V, o Hyper-V acabará por iniciá-lo novamente. Se você
desabilitar o serviço no convidado, o Hyper-V não poderá iniciá-lo.

Usar os Serviços do Windows para iniciar ou interromper

um serviço de integração dentro de um convidado do
Windows
1. Abra o Gerenciador de Serviços executando [Link] como Administrador ou
clicando duas vezes no ícone Serviços no Painel de Controle.

2. Localize os serviços que se iniciam com o Hyper-V.

3. Clique com o botão direito do mouse no serviço que você deseja iniciar ou
interromper. Selecione a ação desejada.

Usar o PowerShell para iniciar ou interromper um serviço

de integração dentro de um convidado do Windows
1. Para obter uma lista de serviços de integração, execute:

PowerShell

Get-Service -Name vmic* | FT -AutoSize

2. A saída deverá ser semelhante ao seguinte:

 PowerShell

Status Name DisplayName

------ ---- -----------
Running vmicguestinterface Hyper-V Guest Service Interface
Running vmicheartbeat Hyper-V Heartbeat Service
Running vmickvpexchange Hyper-V Data Exchange Service
Running vmicrdv Hyper-V Remote Desktop Virtualization
Service
Running vmicshutdown Hyper-V Guest Shutdown Service
Running vmictimesync Hyper-V Time Synchronization Service
Stopped vmicvmsession Hyper-V PowerShell Direct Service
Running vmicvss Hyper-V Volume Shadow Copy Requestor

3. Execute Start-Service ou Stop-Service. Por exemplo, para desativar o Windows

PowerShell Direct, execute:

PowerShell

Stop-Service -Name vmicvmsession

Iniciar e interromper um serviço de integração

de um convidado do Linux
Os serviços de integração do Linux geralmente são fornecidos por meio do kernel do
Linux. O driver dos serviços de integração do Linux é chamado de hv_utils.

1. Para descobrir se hv_utils está carregado, use este comando:

Bash

lsmod | grep hv_utils

2. A saída deverá ser semelhante ao seguinte:

Bash

Module Size Used by

hv_utils 20480 0
hv_vmbus 61440 8
hv_balloon,hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_s
torvsc

3. Para descobrir se os daemons necessários estão em execução, use este comando.

 Bash

ps -ef | grep hv

4. A saída deverá ser semelhante ao seguinte:

Bash

root 236 2 0 Jul11 ? [Link] [hv_vmbus_con]

root 237 2 0 Jul11 ? [Link] [hv_vmbus_ctl]
...
root 252 2 0 Jul11 ? [Link] [hv_vmbus_ctl]
root 1286 1 0 Jul11 ? [Link] /usr/lib/linux-
tools/3.13.0-32-generic/hv_kvp_daemon
root 9333 1 0 Oct12 ? [Link] /usr/lib/linux-
tools/3.13.0-32-generic/hv_kvp_daemon
root 9365 1 0 Oct12 ? [Link] /usr/lib/linux-
tools/3.13.0-32-generic/hv_vss_daemon
user 43774 43755 0 21:20 pts/0 [Link] grep --color=auto hv

5. Para ver quais daemons estão disponíveis, execute:

Bash

compgen -c hv_

6. A saída deverá ser semelhante ao seguinte:

Bash

hv_vss_daemon
hv_get_dhcp_info
hv_get_dns_info
hv_set_ifconfig
hv_kvp_daemon
hv_fcopy_daemon

Os daemons do serviço de integração que podem ser listados incluem o seguinte.

Se houver algum ausente, talvez eles não sejam compatíveis com seu sistema ou
talvez não estejam instalados. Para saber detalhes, confira Máquinas virtuais
compatíveis do Linux e do FreeBSD para o Hyper-V no Windows.

hv_vss_daemon: esse daemon é necessário para criar backups de máquina

virtual Linux em tempo real.
hv_kvp_daemon: esse daemon permite definir e consultar os pares chave-
valor intrínsecos e extrínsecos.
 hv_fcopy_daemon: esse daemon implementa um serviço de cópia de
arquivos entre o host e o convidado.

Exemplos
Esses exemplos demonstram como interromper e iniciar o daemon KVP, chamado
hv_kvp_daemon .

1. Use a ID do processo (PID) para interromper o processo do daemon. Para localizar

o PID, examine a segunda coluna da saída ou use pidof . Daemons do Hyper-V são
executados como raiz, portanto, é necessário possuir permissões de raiz.

Bash

sudo kill -15 `pidof hv_kvp_daemon`

2. Para verificar se todos os processos hv_kvp_daemon foram interrompidos, execute:

Bash

ps -ef | hv

3. Para iniciar o daemon novamente, execute-o como raiz:

Bash

sudo hv_kvp_daemon

4. Para verificar se o processo hv_kvp_daemon está listado com uma nova ID de

processo, execute:

Bash

ps -ef | hv

Manter os serviços de integração atualizados

Recomendamos que você mantenha os serviços de integração atualizados para obter o
melhor desempenho e os recursos mais recentes para suas máquinas virtuais. Isso
acontece para convidados do Windows por padrão se eles estiverem configurados para
obter atualizações importantes do Windows Update. Os convidados do Linux que usam
kernels atuais contêm serviços de integração internos, mas pode haver atualizações
opcionais disponíveis. Você receberá os componentes de integração mais recentes ao
atualizar o kernel. Para obter mais informações sobre convidados do Linux, consulte
Máquinas virtuais compatíveis com Linux e FreeBSD para Hyper-V no Windows.

７ Observação

O arquivo de imagem Disco dos Serviços de Integração ([Link]) não está

incluído no Hyper-V a partir do Windows Server 2016 e Windows 10 porque ele
não é mais necessário. Windows Server 2012 e mais antigos exigem o serviço de
integração do Data Exchange. Se o serviço de integração do Data Exchange não
puder ser habilitado, os serviços de integração para esses convidados estarão
disponíveis no Centro de Download como um arquivo de gabinete (cab). As
instruções para aplicar um cab estão disponíveis nesta postagem no blog do
Microsoft TechCommunity . Se o host Hyper-V estiver executando o Windows
Server 2012 R2 ou mais antigo, consulte a próxima seção para saber como instalar
ou atualizar os serviços de integração.

Instalar ou atualizar serviços de integração

para hosts Hyper-V anteriores a Windows
Server 2016 e Windows 10

７ Observação

Isso não é necessário para o Windows Server 2016 e Windows 10 ou mais recentes.

Para hosts Hyper-V anteriores a Windows Server 2016 e Windows 10, você precisará
instalar ou atualizar manualmente os serviços de integração nos sistemas operacionais
convidados.

Para instalar ou atualizar manualmente os serviços de integração:

1. Abra o Gerenciador do Hyper-V.

2. Conectar-se à máquina virtual. Clique com o botão direito na máquina virtual e

selecione Conectar.

3. No menu Ação de Conexão de Máquina Virtual, selecione Inserir Disco de

Instalação dos Serviços de Integração. Essa ação carrega o disco de instalação na
 unidade de DVD virtual. Dependendo do sistema operacional convidado, talvez
seja necessário iniciar a instalação manualmente do Explorador de Arquivos.

4. Após a conclusão da instalação, os serviços de integração estarão disponíveis para

uso.
Gerenciar máquinas virtuais do
Windows com o PowerShell Direct
Artigo • 12/04/2023

Aplica-se a: Windows Server 2022, Windows 10, Windows Server 2016, Windows
Server 2019

Você pode usar o PowerShell Direct para gerenciar remotamente uma máquina virtual
com Windows 10, Windows Server 2016 ou Windows Server 2019 em um host do
Hyper-V com Windows 10, Windows Server 2016 ou Windows Server 2019. O
PowerShell Direct permite o gerenciar o Windows PowerShell dentro de uma máquina
virtual independentemente da configuração de rede, das configurações de
gerenciamento remoto no host do Hyper-V ou da máquina virtual. Isso facilita a tarefa
dos Administradores do Hyper-V de automatizar e executar scripts de configuração e
gerenciamento de máquinas virtuais.

Há duas maneiras de executar o PowerShell Direct:

Criar e sair de uma sessão do PowerShell Direct usando cmdlets PSSession

Executar script ou comando com o cmdlet Invoke-Command

Se você estiver gerenciando máquinas virtuais mais antigas, use o VMConnect (Conexão
com Máquina Virtual) ou configure uma rede virtual para a máquina virtual.

Criar e sair de uma sessão do PowerShell Direct

usando cmdlets PSSession
1. No servidor do Hyper-V, abra o Windows PowerShell como Administrador.

2. Use o cmdlet Enter-PSSession para se conectar à máquina virtual. Execute um dos

seguintes comandos para criar uma sessão usando o nome da máquina virtual ou
o GUID:

Enter-PSSession -VMName <VMName>

 Enter-PSSession -VMGUID <VMGUID>

3. Digite suas credenciais para a máquina virtual.

4. Execute os comandos necessários. Esses comandos são executados na máquina

virtual com a qual você criou a sessão.

5. Quando terminar, use Exit-PSSession para fechar a sessão.

Exit-PSSession

Executar script ou comando com o cmdlet

Invoke-Command
Você pode usar o cmdlet Invoke-Command para executar um conjunto predeterminado
de comandos na máquina virtual. Aqui está um exemplo de como você pode usar o
cmdlet Invoke-Command, onde PSTest é o nome da máquina virtual e o script a ser
executado (foo.ps1) está na pasta de script na unidade “C:/”:

Invoke-Command -VMName PSTest -FilePath C:\script\foo.ps1

Para executar um único comando, use o parâmetro -ScriptBlock:

Invoke-Command -VMName PSTest -ScriptBlock { cmdlet }

O que é necessário para usar o PowerShell

Direct?
Para criar uma sessão do PowerShell Direct em uma máquina virtual,

A máquina virtual deve ser executada localmente no host e inicializada.

Você deve estar conectado ao computador host como um administrador do

Hyper-V.
 É necessário fornecer credenciais de usuário válidas para a máquina virtual.

O sistema operacional host deve executar pelo menos o Windows 10 ou o

Windows Server 2016.

A máquina virtual deve executar pelo menos o Windows 10 ou o Windows Server

2016.

Você pode usar o cmdlet Get-VM para verificar se as credenciais usadas têm a função de
administrador do Hyper-V e para obter uma lista das máquinas virtuais executadas
localmente no host e inicializadas.

Consulte Também
Enter-PSSessionExit-PSSessionInvoke-Command
Configurar a Réplica do Hyper-V
Artigo • 10/06/2024

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016;
Azure Stack HCI, versões 23H2 e 22H2

A Réplica do Hyper-V é uma parte integrante da função do Hyper-V. Ele contribui para
sua estratégia de recuperação de desastre replicando máquinas virtuais de um servidor
host Hyper-V para outro para manter suas cargas de trabalho disponíveis. A Réplica do
Hyper-V cria uma cópia de uma máquina virtual dinâmica para uma máquina virtual
offline de réplica. Observe o seguinte:

Hosts Hyper-V: os servidores host primários e secundários podem estar

fisicamente colocalizados ou em locais geográficos separados com replicação por
meio de um link de WAN. Os hosts Hyper-V podem ser autônomos, clusterizados
ou uma mistura de ambos. Não há nenhuma dependência do Active Directory
entre os servidores e eles não precisam ser membros do domínio.

Replicação e controle de alterações: quando você habilita a Réplica do Hyper-V

para uma máquina virtual específica, a replicação inicial cria uma máquina virtual
de réplica idêntica em um servidor host secundário. Depois que isso acontece, o
controle de alterações da Réplica do Hyper-V cria e mantém um arquivo de log
que captura alterações em um VHD de máquina virtual. O arquivo de log é
reproduzido em ordem inversa para o VHD de réplica com base nas configurações
de frequência de replicação. Isso significa que as alterações mais recentes são
armazenadas e replicadas de maneira assíncrona. A replicação pode ser via HTTP
ou HTTPS.

Replicação estendida (encadeada): permite replicar uma máquina virtual de um

host primário para um host secundário e replicar o host secundário para um
terceiro host. Observe que você não pode replicar do host primário diretamente
para o segundo e o terceiro.

Esse recurso torna a Réplica do Hyper-V mais robusta para recuperação de

desastre porque, se ocorrer uma interrupção, você poderá se recuperar da réplica
primária e estendida. Você poderá fazer failover para a réplica estendida se os
locais primário e secundário ficarem inativos. Observe que a réplica estendida não
dá suporte à replicação consistente com aplicativos e deve usar os mesmos VHDs
que a réplica secundária está usando.
Failover: se ocorrer uma interrupção em seu local principal (ou secundário, se
estendido), você poderá iniciar manualmente um failover de teste, planejado ou
não planejado.

ﾉ Expandir a tabela

Pergunta Teste Planejado Não planejado

Quando devo Verifique se uma máquina Durante o tempo de Durante eventos

executar isso? virtual pode fazer failover e inatividade e inesperados
iniciar no site secundário interrupções
Útil para teste e treinamento planejados

Uma máquina Sim Não No

virtual
duplicada é
criada?

Onde é Na máquina virtual de réplica Iniciada na primária e Na máquina

iniciada? concluída na virtual de
secundária réplica

Com que Recomendamos uma vez por Uma vez a cada seis Somente em
frequência mês para teste meses ou de acordo caso de
devo com os requisitos de desastre
executar? conformidade quando a
máquina virtual
primária não
estiver
disponível

A máquina Sim Sim. Quando a No

virtual interrupção é
primária resolvida, a replicação
continua a inversa replica as
replicação? alterações de volta
para o site primário
para que as primárias
e secundárias sejam
sincronizadas.

Há alguma Nenhum Nenhum. Após o Depende dos

perda de failover, a Réplica do pontos de
dados? Hyper-V replica o recuperação e
último conjunto de evento
alterações controladas
de volta para o
primário para garantir
zero perda de dados.
 Pergunta Teste Planejado Não planejado

Há algum Nenhum. Isso não afeta seu A duração da A duração da

tempo de ambiente de produção. Ele cria interrupção planejada interrupção não
inatividade? uma máquina virtual de teste planejada
duplicada durante o failover.
Quando o failover está
concluído, você seleciona
Failover na máquina virtual de
réplica e ele é limpo e excluído
automaticamente.

Pontos de recuperação: ao configurar a replicação para uma máquina virtual, você

especifica os pontos de recuperação que deseja armazenar dele. Pontos de
recuperação representam um instantâneo no tempo do qual você pode recuperar
uma máquina virtual. Obviamente, menos dados serão perdidos se você se
recuperar de um ponto de recuperação muito recente. Você podia acessar pontos
de recuperação até 24 horas atrás.

Pré-requisitos de implantação
Veja o que você deve verificar antes de começar:

Descubra quais VHDs precisam ser replicados. Em particular, VHDs que

contiverem dados que mudam rapidamente e não são usados pelo servidor de
Réplica após o failover, tais como discos de arquivo de paginação, deverão ser
excluídos da replicação para poupar largura de banda da rede. Anote os VHDs que
podem ser excluídos.

Decida com que frequência você precisa sincronizar dados: os dados no servidor
de réplica são sincronizados atualizados de acordo com a frequência de replicação
configurada (30 segundos, 5 minutos ou 15 minutos). A frequência escolhida deve
considerar o seguinte: as máquinas virtuais estão executando dados críticos com
um RPO baixo? Quais são suas considerações de largura de banda? Suas máquinas
virtuais altamente críticas obviamente precisarão de replicação mais frequente.

Decidir como recuperar dados: por padrão, a Réplica do Hyper-V armazena

apenas um ponto de recuperação que será a replicação mais recente enviada do
primário para o secundário. No entanto, se você quiser a opção de recuperar
dados para um ponto anterior no tempo, poderá especificar que pontos de
recuperação adicionais devem ser armazenados (até um máximo de 24 pontos por
hora). Se você precisar de pontos de recuperação adicionais, deverá observar que
isso requer mais sobrecarga nos recursos de processamento e armazenamento.
 Descubra quais cargas de trabalho você replicará: a replicação padrão da Réplica
do Hyper-V mantém a consistência no estado do sistema operacional da máquina
virtual após um failover, mas não o estado dos aplicativos em execução na
máquina virtual. Se você quiser recuperar o estado da carga de trabalho, poderá
criar pontos de recuperação consistentes com aplicativos. Observe que a
recuperação consistente com aplicativos não estará disponível no site de réplica
estendida se você estiver usando a replicação estendida (encadeada).

Decida como fazer a replicação inicial dos dados da máquina virtual: a replicação
começa transferindo as necessidades para transferir o estado atual das máquinas
virtuais. Esse estado inicial pode ser transmitido diretamente através da rede
existente, imediatamente ou em um momento posterior configurado por você.
Você também pode usar uma máquina virtual pré-existente restaurada (por
exemplo, se tiver restaurado um backup anterior da máquina virtual no servidor de
Réplica) como cópia inicial. Ou então, você pode poupar largura de banda da rede
copiando a cópia inicial para mídia externa e depois entregando fisicamente a
mídia ao site de Réplica. Se você quiser usar uma máquina virtual pré-existente,
exclua todos os instantâneos anteriores associados a ela.

Etapas de implantação.

Etapa 1: Configurar os hosts do Hyper-V

Você precisará de pelo menos dois hosts Hyper-V com uma ou mais máquinas virtuais
em cada servidor. Introdução ao Hyper-V. O servidor host para o qual você replicará as
máquinas virtuais precisará ser configurado como o servidor de réplica.

1. Nas configurações do Hyper-V para o servidor para o qual você replicará as

máquinas virtuais, em Configuração de Replicação, selecione Habilitar este
computador como um servidor de réplica.

2. Você pode replicar por HTTP ou HTTPS criptografado. Selecione Usar Kerberos
(HTTP) ou Usar autenticação baseada em certificado (HTTPS). Por padrão, HTTP
80 e HTTPS 443 são habilitados como exceções de firewall no servidor Hyper-V de
réplica. Se você alterar as configurações de porta padrão, também precisará alterar
a exceção de firewall. Se você estiver replicando por HTTPS, precisará selecionar
um certificado e deve ter a autenticação de certificado configurada.

3. Para autorização, selecione Permitir replicação de qualquer servidor autenticado

para permitir que o servidor de réplica aceite o tráfego de replicação de máquina
virtual de qualquer servidor primário que se autentique com êxito. Selecione
 Permitir replicação dos servidores especificados para aceitar o tráfego apenas
dos servidores primários especificamente selecionados.

Para ambas as opções, você pode especificar em que local os VHDs replicados
devem ser armazenados no servidor Hyper-V de réplica.

4. Clique em OK ou em Aplicar.

Etapa 2: Configurar o firewall

Para permitir a replicação entre os servidores primário e secundário, o tráfego deve
passar pelo Firewall do Windows (ou por quaisquer outros firewalls de terceiros).
Quando você instalou a função Hyper-V nos servidores por padrão, exceções para HTTP
(80) e HTTPS (443) são criadas. Se você estiver usando essas portas padrão, precisará
apenas habilitar as regras:

Para habilitar as regras em um servidor host autônomo:

1. Abra o Firewall do Windows com Segurança Avançada e clique em Regras de

Entrada.

2. Para habilitar a autenticação HTTP (Kerberos), clique com o botão direito do

mouse em Ouvinte HTTP da Réplica do Hyper-V (Entrada TCP)>Habilitar
Regra. Para habilitar a autenticação baseada em certificado HTTPS, clique
com o botão direito do mouse em Ouvinte HTTPS da Réplica do Hyper-V
(Entrada TCP)>Habilitar Regra.

Para habilitar regras em um cluster Hyper-V, abra uma sessão Windows PowerShell
usando Executar como Administrador e execute um destes comandos:

Para HTTP:

get-clusternode | ForEach-Object {Invoke-command -computername $_.name -

scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP

Listener (TCP-In)"}}

Para HTTPS:

get-clusternode | ForEach-Object {Invoke-command -computername $_.name -

scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS

Listener (TCP-In)"}}

Habilitar replicação de máquina virtual

Faça o seguinte em cada máquina virtual que você deseja replicar:

1. No painel Detalhes do Gerenciador do Hyper-V, selecione uma máquina virtual

clicando sobre ela. Clique com o botão direito do mouse na máquina virtual
selecionada e clique em Habilitar Replicação para abrir o assistente Habilitar
Replicação.

2. Na página Antes de Começar, clique em Avançar.

3. Na página Especificar Servidor de Réplica, na caixa Servidor de Réplica, insira

NetBIOS ou o FQIDN do Servidor de Réplica. Se o servidor de Réplica for parte de
um cluster de failover, insira o nome do Agente de Réplica do Hyper-V. Clique em
Próximo.

4. Na página Especificar Parâmetros de Conexão, a Réplica do Hyper-V recupera

automaticamente as configurações de autenticação e porta que você definiu para
o servidor de réplica. Se os valores não estiverem sendo recuperados, verifique se
o servidor está configurado como um servidor de réplica e se ele está registrado
no DNS. Se necessário, digite na configuração manualmente.

5. Na página Escolher VHDs de Replicação, verifique se os VHDs que você deseja

replicar estão selecionados e desmarque as caixas de seleção para todos os VHDs
que você deseja excluir da replicação. Em seguida, clique em Próximo.

6. Na página Configurar Frequência de Replicação, especifique com que frequência

as alterações devem ser sincronizadas do primário para o secundário. Em seguida,
clique em Próximo.

7. Na página Configurar Pontos de Recuperação Adicionais, selecione se deseja

manter apenas o ponto de recuperação mais recente ou criar pontos adicionais. Se
você quiser recuperar consistentemente aplicativos e cargas de trabalho que têm
os próprios gravadores VSS, recomendamos selecionar a frequência do VSS
(Serviço de Cópias de Sombra de Volume) e especificar com que frequência criar
instantâneos consistentes com aplicativos. Observe que o Serviço solicitante do
VMM do Hyper-V deve estar em execução nos servidores Hyper-V primários e
secundários. Em seguida, clique em Próximo.

8. Na página Escolher Replicação Inicial, selecione o método de replicação inicial a

ser usado. A configuração padrão para enviar a cópia inicial pela rede copiará o
arquivo de configuração de máquina virtual primária (VMCX) e os arquivos de
disco rígido virtual (VHDX e VHD) selecionados pela conexão de rede. Verifique a
disponibilidade da largura de banda da rede se você pretende usar essa opção. Se
a máquina virtual primária já estiver configurada no site secundário como uma
máquina virtual de replicação, poderá ser útil selecionar Usar uma máquina virtual
 existente no servidor de replicação como a cópia inicial. Você pode usar a
exportação do Hyper-V para exportar a máquina virtual primária e importá-la
como uma máquina virtual de réplica no servidor secundário. Para máquinas
virtuais maiores ou largura de banda limitada, você pode optar por que a
replicação inicial pela rede ocorra posteriormente e configurar fora do horário de
pico ou enviar as informações de replicação inicial como mídia offline.

Se você fizer a replicação offline, transportará a cópia inicial para o servidor

secundário usando um meio de armazenamento externo, como um disco rígido ou
uma unidade USB. Para fazer isso, você precisa conectar o armazenamento externo
ao servidor primário (ou nó proprietário em um cluster) e, em seguida, ao
selecionar Enviar cópia inicial usando mídia externa, você pode especificar um local
localmente ou na mídia externa onde a cópia inicial pode ser armazenada. Uma
máquina virtual de espaço reservado é criada no site de réplica. Depois que a
replicação inicial for concluída, o armazenamento externo poderá ser enviado para
o site de réplica. Lá, você conectará a mídia externa ao servidor secundário ou ao
nó proprietário do cluster secundário. Em seguida, você importará a réplica inicial
para um local especificado e a mesclará na máquina virtual de espaço reservado.

9. Na página Concluindo a Habilitação de Replicação, revise as informações no

Resumo e clique em Concluir.. Os dados da máquina virtual serão transferidos de
acordo com as configurações escolhidas. Uma caixa de diálogo é exibida para
indicar que a replicação foi habilitada com êxito.

10. Se você quiser configurar a replicação estendida (encadeada), abra o servidor de

réplica e clique com o botão direito do mouse na máquina virtual que deseja
replicar. Clique em Replicação>Estender Replicação e especifique as
configurações de replicação.

Executar um failover
Depois de concluir essas etapas de implantação, seu ambiente replicado está em
execução. Agora você pode executar failovers conforme necessário.

Failover de teste: se você quiser executar um failover de teste, clique com o botão
direito do mouse na máquina virtual de réplica e selecione Replicação>Failover de
Teste. Escolha o ponto de recuperação mais recente ou outro, se configurado. Uma
máquina virtual de teste será criada e iniciada no site secundário. Depois de concluir o
teste, selecione Parar Failover de Teste na máquina virtual de réplica para limpá-lo.
Observe que, para uma máquina virtual, você só pode executar um failover de teste por
vez. Para mais informações, confira Failover de teste na Réplica do Hyper-V .
Failover planejado: para executar um failover planejado, clique com o botão direito do
mouse na máquina virtual primária e selecioneReplicação>Failover Planejado. O
failover planejado executa verificações de pré-requisitos para garantir zero perda de
dados. Ele verifica se a máquina virtual primária está desligada antes de iniciar o failover.
Após o failover da máquina virtual, ela começa a replicar as alterações de volta para o
site primário quando ele está disponível. Observe que, para que isso funcione, o
servidor primário deve ser configurado para receber a replicação do servidor secundário
ou do Agente de Réplica do Hyper-V no caso de um cluster primário. O failover
planejado envia o último conjunto de alterações controladas. Para mais informações,
confira Failover planejado na Réplica do Hyper-V .

Failover não planejado: para executar um failover não planejado, clique com o botão
direito do mouse na máquina virtual de réplica e selecione Replicação>Failover não
planejado do Gerenciador do Hyper-V ou do Gerenciador de Clustering de Failover.
Você poderá se recuperar do ponto de recuperação mais recente ou dos pontos de
recuperação anteriores se essa opção estiver habilitada. Após o failover, verifique se
tudo está funcionando conforme o esperado na máquina virtual com failover e clique
em Concluir na máquina virtual de réplica. Leia mais .
Habilitar o hardware de monitoramento
de desempenho da Intel uma máquina
virtual do Hyper-V
Artigo • 09/03/2023

Os processadores Intel contêm recursos chamados coletivamente de hardware de

monitoramento de desempenho (por exemplo, PMU, PEBS, LBR). Esses recursos são
usados pelo software de ajuste de desempenho, como o Amplificador Intel VTune, para
analisar o desempenho do software. Antes do Windows Server 2019 e do Windows 10
versão 1809, nem o sistema operacional host nem as máquinas virtuais convidadas do
Hyper-V podiam usar o hardware de monitoramento de desempenho quando o Hyper-
V estava habilitado. A partir do Windows Server 2019 e Windows 10 versão 1809, o
sistema operacional do host tem acesso ao hardware de monitoramento de
desempenho por padrão. As máquinas virtuais convidadas do Hyper-V não têm acesso
por padrão, mas os administradores do Hyper-V podem optar por conceder acesso a
uma ou mais máquinas virtuais convidadas. Este documento descreve as etapas
necessárias para expor o hardware de monitoramento de desempenho a máquinas
virtuais convidadas.

Requisitos
Para habilitar o hardware de monitoramento de desempenho em uma máquina virtual,
você precisará de:

Um processador Intel com hardware de monitoramento de desempenho (ou seja,

PMU, PEBS, LBR). Consulte este documento da Intel para determinar qual
hardware de monitoramento de desempenho seu sistema dá suporte.
Windows Server 2019 ou Windows 10 versão 1809 (atualização de outubro de
2018) ou posterior
Uma máquina virtual do Hyper-V semvirtualização aninhada que também está no
estado parado

Para habilitar o próximo hardware de monitoramento de desempenho do IPT

(Rastreamento do Processador Intel) em uma máquina virtual, você precisará de:

Um processador Intel que dá suporte a IPT e ao recurso PT2GPA. [^1] Consulte

este documento da Intel para determinar qual hardware de monitoramento de
desempenho seu sistema dá suporte.
 Windows Server versão 1903 (SAC) ou Windows 10 versão 1903 (Atualização de
maio de 2019) ou posterior
Uma máquina virtual do Hyper-V semvirtualização aninhada que também está no
estado parado
A PMU precisa ser habilitada por meio da linha de comando usando o comando
visto abaixo.

[^1]: PT2GPA refere-se ao bit "Intel PT usa endereços físicos convidados". Isso é descrito
na versão [Link] do Intel SDM.

Habilitar componentes de monitoramento de

desempenho em uma máquina virtual
Para habilitar diferentes componentes de monitoramento de desempenho para uma
máquina virtual convidada específica, use o cmdlet Set-VMProcessor do PowerShell
durante a execução como Administrador:

７ Observação

A geração de máquina virtual deve ser 9.1 ou superior. Se a virtualização aninhada

também for oferecida ao convidado, isso precisará de 9.3 ou mais.

Powershell

# Enable IPT
Set-VMProcessor MyVMName -Perfmon @("ipt", "pmu")

Powershell

# Enable all components

Set-VMProcessor MyVMName -Perfmon @("ipt", "pmu", "lbr", "pebs")

Powershell

# Disable all components

Set-VMProcessor MyVMName -Perfmon @()

７ Observação
 Ao habilitar os componentes de monitoramento de desempenho, se "pebs" for
especificado, então "pmu" também deverá ser especificado.
O PEBS só tem suporte no hardware que tem uma versão de PMU >= 4.
Além disso, qualquer comando que tente habilitar "ipt" também deve especificar
"pmu" .

Habilitar um componente que não tem suporte pelos processadores físicos do host
resultará em uma falha de início de máquina virtual.

Efeitos da habilitação do hardware de

monitoramento de desempenho ao
salvar/restaurar, exportar e migrar ao vivo
A Microsoft não recomenda migrar ou salvar/restaurar máquinas virtuais ao vivo com
hardware de monitoramento de desempenho entre sistemas com hardware Intel
diferente. O comportamento específico do hardware de monitoramento de
desempenho geralmente não é arquitetônico e é alterado entre sistemas de hardware
Intel. Mover uma máquina virtual em execução entre diferentes sistemas pode resultar
em um comportamento imprevisível dos contadores não arquitetônicos.
Modo de compatibilidade dinâmica do
processador
Artigo • 10/07/2024

Aplica-se a: Windows Server 2025

O modo de compatibilidade dinâmica do processador é atualizado para aproveitar os

novos recursos do processador em um ambiente em cluster. A compatibilidade do
processador funciona determinando os recursos do processador com suporte para cada
nó individual no cluster e calculando o denominador comum em todos os
processadores. As VMs (máquinas virtuais) são configuradas para usar o número
máximo de recursos disponíveis em todos os servidores no cluster. Isso melhora o
desempenho em comparação com a versão anterior de compatibilidade do processador
que usava como padrão um conjunto mínimo e fixo de recursos do processador.

Quando usar o modo de compatibilidade do

processador
O modo de compatibilidade do processador permite mover uma VM ativa (migração
dinâmica) ou mover uma VM salva entre nós com diferentes conjuntos de recursos de
processo. No entanto, mesmo quando a compatibilidade do processador está
habilitada, você não pode mover VMs entre hosts com diferentes fabricantes de
processador. Por exemplo, você não pode mover VMs em execução ou VMs de estado
salvas de um host com processadores Intel para um host com processadores AMD. Se
você precisar mover uma VM dessa maneira, desligue-a primeiro e reinicie-a no novo
host.

） Importante

Somente as VMs do Hyper-V com a versão de configuração mais recente (10.0) se

beneficiam da configuração dinâmica. As VMs com versões mais antigas não se
beneficiam da configuração dinâmica e não continuarão a usar recursos de
processador fixo da versão anterior.

７ Observação
 Você não precisa usar o modo de compatibilidade do processador se planeja parar
e reiniciar as VMs. Sempre que uma VM é reiniciada, o sistema operacional
convidado enumera as compatibilidades do processador disponíveis no novo
computador host.

Por que o modo de compatibilidade do

processador é necessário
Os fabricantes de processadores geralmente introduzem otimizações e recursos em
seus processadores. Esses recursos geralmente melhoram o desempenho ou a
segurança usando hardware especializado para uma tarefa específica. Por exemplo,
muitos aplicativos de mídia usam recursos de processador para acelerar os cálculos
vetoriais. Esses recursos raramente são necessários para que os aplicativos sejam
executados; eles aumentam o desempenho.

O conjunto de recursos disponível em um processador varia de acordo com sua marca,

modelo e idade. Os sistemas operacionais e o software de aplicativo normalmente
enumeram o conjunto de recursos do processador do sistema quando são iniciados
pela primeira vez. O software não espera que os recursos disponíveis do processador
mudem durante sua vida útil, o que nunca acontece ao ser executado em um
computador físico, porque os recursos do processador são estáticos, a menos que o
processador seja atualizado.

No entanto, os recursos de mobilidade da VM permitem que uma VM em execução seja

migrada para um novo host de virtualização. Se o software na VM detectar e começar a
usar um recurso de processador específico e, em seguida, a VM for movida para um
novo host de virtualização sem esse recurso, o software provavelmente falhará. Isso
pode resultar na falha do aplicativo ou da VM.

Para evitar falhas, o Hyper-V executa verificações de "simulação" sempre que uma
operação de migração ao vivo ou salvamento/restauração da VM é iniciada. Essas
verificações comparam o conjunto de recursos do processador que estão disponíveis
para a VM no host de origem com o conjunto de recursos que estão disponíveis no host
de destino. Se esses conjuntos de recursos não corresponderem, a operação de
migração ou restauração será cancelada.

O que há de novo no modo de compatibilidade

do processador
No passado, todos os novos conjuntos de instruções do processador estavam ocultos, o
que significa que o sistema operacional convidado e o software do aplicativo não
podiam usar os aprimoramentos do conjunto de instruções do processador para ajudar
os aplicativos e as VMs a permanecerem com o desempenho.

Para superar essa limitação, o modo de compatibilidade do processador agora fornece

recursos dinâmicos aprimorados em processadores capazes de SLAT (conversão de
endereços de segundo nível). Essa nova funcionalidade calcula o denominador comum
dos recursos de CPU compatíveis com os nós no cluster e atualiza o modo de
compatibilidade do processador existente em uma VM para usar esse conjunto de
recursos calculado dinamicamente em vez do antigo conjunto de recursos codificados.

O novo modo de compatibilidade do processador garante que o conjunto de recursos

do processador disponíveis para VMs em hosts de virtualização corresponda
apresentando um conjunto de recursos comum em todos os servidores no cluster. Cada
VM recebe o número máximo de conjuntos de instruções do processador presentes em
todos os servidores no cluster. Esse processo ocorre automaticamente e é sempre
habilitado e replicado no cluster, portanto, não há nenhum comando para habilitar ou
desabilitar o processo.

Usando o modo de compatibilidade do

processador
Há conceitos importantes a serem entendidos no uso do modo de compatibilidade do
processador no Hyper-V:

A execução de VMs só pode ser migrada entre hosts de virtualização que usam
processadores do mesmo fabricante.

Você precisa desligar a VM antes de habilitar ou desabilitar o modo de

compatibilidade do processador.

O modo de compatibilidade do processador não é exigido para movimentações de

VM que envolvem uma parada e uma reinicialização da VM.

Sempre que uma VM é reiniciada, o sistema operacional convidado enumera os

recursos do processador disponíveis no novo computador host.

７ Observação

No Windows Server, a Microsoft recomenda ativar o modo de compatibilidade do

processador somente antes dos cenários de migração de VM e desativá-lo quando
 a migração for concluída.

Migrando VMs em execução entre clusters

Supondo que todos os servidores em cada cluster estejam executando o mesmo
hardware, é possível migrar ao vivo VMs em execução entre clusters. Existem três
cenários comuns.

Migração em tempo real de uma VM de um cluster com novos processadores

para um cluster com os mesmos processadores. Os recursos da VM são
transferidos para o cluster de destino. Esse cenário não requer que o modo de
compatibilidade do processador esteja habilitado; no entanto, deixá-lo ativado não
causará problemas.

Migração em tempo real de uma VM de um cluster com processadores mais

antigos para um cluster com processadores mais recentes. Os recursos da VM
são transferidos para o cluster de destino. Nesse cenário, se a VM for reiniciada,
ela receberá a funcionalidade calculada mais recente do cluster de destino.

Migração dinâmica de uma VM de um cluster com processadores mais recentes

para um cluster com processadores mais antigos. Você precisará definir o
processador de VM para usar o MinimumFeatureSet parâmetro para o
CompatibilityForMigrationMode PowerShell ou selecionar Compatível com outros

hosts com o mesmo fabricante de CPU no Windows Admin Center em

Processadores de Configurações > de Máquinas > Virtuais. Essa configuração
atribui a VM aos recursos mínimos de processador oferecidos no servidor. Depois
que a compatibilidade é movida para Compatível no cluster (recomendado) e a
VM é reiniciada, ela recebe a funcionalidade calculada mais recente do cluster de
destino.

Consequências do uso do modo de

compatibilidade do processador
É difícil quantificar os efeitos gerais do modo de compatibilidade do processador. A
perda de desempenho depende principalmente da carga de trabalho em execução na
VM. Algumas cargas de trabalho podem não ser afetadas, enquanto outras mostram
uma diferença perceptível. O software que depende muito de otimizações de hardware
(como criptografia, compactação ou cálculos intensivos de ponto flutuante) é o mais
afetado.
Os aplicativos que criptografam ou descriptografam uma grande quantidade de dados
se beneficiam desse recurso do processador, portanto, desativá-lo ativando o modo de
compatibilidade do processador afeta o desempenho dessas operações específicas.

Se você estiver preocupado com o impacto no desempenho do modo de

compatibilidade do processador, é melhor comparar o desempenho da carga de
trabalho da VM com o modo de compatibilidade do processador habilitado e com ele
desabilitado.

Configurar uma VM para usar o modo de

compatibilidade do processador
Esta seção explica como configurar uma VM para usar o modo de compatibilidade do
processador usando o gerenciador do Hyper-V ou o PowerShell. É possível executar
VMs com e sem modo de compatibilidade no mesmo cluster.

） Importante

Você precisa desligar a VM antes de habilitar ou desabilitar o modo de

compatibilidade do processador.

Habilitar o modo de compatibilidade do processador

usando o Gerenciador do Hyper-V
Para habilitar o modo de compatibilidade do processador para uma VM usando o
Gerenciador do Hyper-V:

1. Desligue a VM.

2. Selecione Iniciar, aponte para Ferramentas Administrativas e selecione

Gerenciador do Hyper-V.

3. Selecione o servidor que executa o Hyper-V e a VM desejada.

4. Se a VM estiver em execução, você precisará desligar a VM para habilitar a

configuração do modo de compatibilidade do processador.

5. No painel de Ação, selecione Configurações e, em seguida, selecione Processador.

6. Expanda Processador e selecione Compatibilidade.

 7. Selecione Migrar para um computador físico com um processador diferente e,
em seguida, selecione OK.

8. Reinicie a VM.

Desabilitar o modo de compatibilidade do processador

usando o Gerenciador do Hyper-V
Para desabilitar o modo de compatibilidade do processador para uma VM usando o
Gerenciador do Hyper-V:

1. Desligue a VM.

2. Selecione Iniciar, aponte para Ferramentas Administrativas e selecione

Gerenciador do Hyper-V.

3. Selecione o servidor que executa o Hyper-V e a VM desejada.

4. Se a VM estiver em execução, você precisará desligar a VM para desabilitar a

configuração do modo de compatibilidade do processador.

5. No painel de Ação, selecione Configurações e, em seguida, selecione Processador.

6. Expanda Processador e selecione Compatibilidade.

7. Desmarque a caixa de seleção Migrar para um computador físico com um

processador diferente e selecione OK.

8. Reinicie a VM.

Habilitar o modo de compatibilidade do processador

usando o PowerShell
Para habilitar o modo de compatibilidade do processador, execute o seguinte cmdlet:

PowerShell

get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $true

É recomendável definir os recursos de CPU da VM para o nível máximo compatível com

todos os servidores no cluster. Isso maximiza o desempenho da VM, preservando a
capacidade de mover a VM em execução para outros servidores no cluster.
Para permitir que a VM use os recursos comuns do nó de cluster, execute o seguinte
cmdlet:

PowerShell

get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $true -
CompatibilityForMigrationMode CommonClusterFeatureSet

Como alternativa, você pode definir os recursos de CPU da VM como mínimos,

garantindo que você possa mover a VM em execução para outros hosts Hyper-V fora do
cluster se eles tiverem o mesmo fabricante de CPU.

Para permitir que a VM use os recursos mínimos padrão para migrar entre clusters,
execute o seguinte cmdlet:

PowerShell

get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $true -
CompatibilityForMigrationMode MinimumFeatureSet

Desabilitar o modo de compatibilidade do processador

usando o PowerShell
Para desabilitar o modo de compatibilidade do processador para uma VM usando o
PowerShell, desligue a VM e execute o cmdlet Set-VMProcessor , definindo
CompatibilityForMigrationEnabled como $false:

PowerShell

get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $false

Em seguida, reinicie a VM.

Comentários
Esta página foi útil?  Yes  No
Visão geral de migração ao vivo
Artigo • 10/04/2023

A migração dinâmica é um recurso do Hyper-V no Windows Server. Ele permite mover

de forma transparente Máquinas Virtuais em execução de um host Hyper-V para outro
sem tempo de inatividade percebido. O principal benefício da migração dinâmica é a
flexibilidade. As Máquinas Virtuais em execução não estão vinculados a um único
computador host. Isso permite ações como esvaziar um host específico de Máquinas
Virtuais antes de descomissioná-lo ou atualizá-lo. Quando emparelhada com o Cluster
de Failover do Windows, a migração dinâmica permite a criação de sistemas altamente
disponíveis e tolerantes a falhas.

Tecnologias e documentação relacionadas

A migração dinâmica geralmente é usada em conjunto com algumas tecnologias
relacionadas, como Cluster de Failover e System Center Virtual Machine Manager. Caso
esteja usando a Migração Dinâmica por meio dessas tecnologias, aqui estão os
ponteiros para a documentação mais recente:

Cluster de Failover (Windows Server 2016)

System Center Virtual Machine Manager (System Center 2016)

Ao usar versões mais antigas do Windows Server ou precisar de detalhes sobre os

recursos introduzidos em versões mais antigas do Windows Server, aqui estão os
ponteiros para a documentação histórica:

Migração dinâmica (Windows Server 2008 R2)

Migração dinâmica (Windows Server 2012 R2)
Cluster de Failover (Windows Server 2012 R2)
Cluster de Failover (Windows Server 2008 R2)
System Center Virtual Machine Manager (System Center 2012 R2)
System Center Virtual Machine Manager (System Center 2008 R2)

Migração dinâmica no Windows Server 2016

Em Windows Server 2016, há menos restrições na implantação da migração dinâmica.
Agora ele funciona sem Cluster de Failover. Outras funcionalidades permanecem
inalteradas em relação às versões anteriores da Migração Dinâmica. Para obter mais
detalhes sobre como configurar e usar a migração dinâmica sem Cluster de Failover:
Configurar hosts para migração dinâmica sem cluster de failover
Usar a migração dinâmica sem Cluster de Failover para mover uma máquina virtual
Visão geral de migração ao vivo
Artigo • 10/04/2023

A migração dinâmica é um recurso do Hyper-V no Windows Server. Ele permite mover

de forma transparente Máquinas Virtuais em execução de um host Hyper-V para outro
sem tempo de inatividade percebido. O principal benefício da migração dinâmica é a
flexibilidade. As Máquinas Virtuais em execução não estão vinculados a um único
computador host. Isso permite ações como esvaziar um host específico de Máquinas
Virtuais antes de descomissioná-lo ou atualizá-lo. Quando emparelhada com o Cluster
de Failover do Windows, a migração dinâmica permite a criação de sistemas altamente
disponíveis e tolerantes a falhas.

Tecnologias e documentação relacionadas

A migração dinâmica geralmente é usada em conjunto com algumas tecnologias
relacionadas, como Cluster de Failover e System Center Virtual Machine Manager. Caso
esteja usando a Migração Dinâmica por meio dessas tecnologias, aqui estão os
ponteiros para a documentação mais recente:

Cluster de Failover (Windows Server 2016)

System Center Virtual Machine Manager (System Center 2016)

Ao usar versões mais antigas do Windows Server ou precisar de detalhes sobre os

recursos introduzidos em versões mais antigas do Windows Server, aqui estão os
ponteiros para a documentação histórica:

Migração dinâmica (Windows Server 2008 R2)

Migração dinâmica (Windows Server 2012 R2)
Cluster de Failover (Windows Server 2012 R2)
Cluster de Failover (Windows Server 2008 R2)
System Center Virtual Machine Manager (System Center 2012 R2)
System Center Virtual Machine Manager (System Center 2008 R2)

Migração dinâmica no Windows Server 2016

Em Windows Server 2016, há menos restrições na implantação da migração dinâmica.
Agora ele funciona sem Cluster de Failover. Outras funcionalidades permanecem
inalteradas em relação às versões anteriores da Migração Dinâmica. Para obter mais
detalhes sobre como configurar e usar a migração dinâmica sem Cluster de Failover:
Configurar hosts para migração dinâmica sem cluster de failover
Usar a migração dinâmica sem Cluster de Failover para mover uma máquina virtual
Configurar hosts para migração
dinâmica sem cluster de failover
Artigo • 19/06/2024

Aplica-se a: Windows Server 2022, Windows Server 2016, Microsoft Hyper-V Server
2016, Windows Server 2019 e Microsoft Hyper-V Server 2019

Este artigo mostra como configurar hosts que não estão clusterizados para que você
possa fazer migrações dinâmicas entre eles. Use estas instruções se você não configurou
a migração dinâmica quando instalou o Hyper-V ou se quiser alterar as configurações.
Para configurar hosts clusterizados, use as ferramentas para cluster de failover.

Requisitos para configurar a migração dinâmica

Para configurar hosts não clusterizados para a migração dinâmica, você precisará de:

Uma conta de usuário com permissão para executar as várias etapas. A associação
no grupo de Administradores do Hyper-V local ou no grupo Administradores nos
computadores de origem e de destino atende a esse requisito, a menos que você
esteja configurando a delegação restrita. A associação no grupo Administradores
de Domínio é necessária para configurar a delegação restrita.

A função Hyper-V no Windows Server 2016 ou Windows Server 2012 R2 instalada

nos servidores de origem e de destino. Você pode fazer uma migração dinâmica
entre hosts que executam o Windows Server 2016 e o Windows Server 2012 R2 se
a máquina virtual tiver pelo menos a versão 5.
Para obter instruções de atualização de versão, consulte Atualizar a versão da
máquina virtual no Hyper-V no Windows 10 ou no Windows Server 2016. Para
obter instruções de instalação, consulte Instalar a função Hyper-V no Windows
Server.

Computadores de origem e de destino que pertencem ao mesmo domínio Active

Directory ou a domínios que confiam uns nos outros.

As ferramentas de gerenciamento do Hyper-V instaladas em um computador que

execute o Windows Server 2016 ou o Windows 10, a menos que as ferramentas
sejam instaladas no servidor de origem ou de destino e você execute as
ferramentas do servidor.
Considere as opções de autenticação e rede
Considere como você quer configurar o seguinte:

Autenticação: qual protocolo será usado para autenticar o tráfego de migração

dinâmica entre os servidores de origem e de destino? A escolha determina se você
precisará entrar no servidor de origem antes de iniciar uma migração dinâmica:

O Kerberos possibilita evitar a necessidade de entrar no servidor, mas exige que

a delegação restrita seja configurada. Veja abaixo para obter instruções.

O CredSSP possibilita que você evite configurar a delegação restrita, mas exige
que você entre no servidor de origem. Você pode fazer isso por meio de uma
sessão do console local, uma sessão da Área de Trabalho Remota ou uma
sessão do Windows PowerShell remota.

O CredSPP exige login para situações que podem não ser óbvias. Por exemplo,
se você entrar no TestServer01 para mover uma máquina virtual para
TestServer02 e depois quiser retornar a máquina virtual para TestServer01, você
precisará entrar no TestServer02 antes de tentar retornar a máquina virtual para
TesterServer01. Se você não fizer isso, a tentativa de autenticação falhará,
ocorrerá um erro e a seguinte mensagem será exibida:

"A operação de migração de máquina virtual falhou na origem da migração.

Falha ao estabelecer uma conexão com o host nome do computador: credenciais
não disponíveis no pacote de segurança 0x8009030E."

Desempenho: faz sentido configurar opções de desempenho? Essas opções

podem reduzir o uso de rede e CPU, bem como fazer com que as migrações
dinâmicas sejam mais rápidas. Considere seus requisitos e sua infraestrutura e
teste diferentes configurações para ajudá-lo a decidir. As opções estão descritas
no final da etapa 2.

Preferência de rede: Você permitirá o tráfego da migração dinâmica através de

qualquer rede disponível ou isolará o tráfego em redes específicas? Como prática
recomendada de segurança, convém isolar o tráfego em redes confiáveis privadas
porque o tráfego da migração ao vivo não é criptografado quando enviado pela
rede. O isolamento de rede pode ser obtido por uma rede fisicamente isolada ou
por outra tecnologia de rede confiável, como as VLANs.

Atualizando para o Windows Server 2025 (visualização)

 ） Importante

O Windows Server 2025 está em VERSÃO PRELIMINAR. Estas informações estão

relacionadas a um produto de pré-lançamento, que pode ser bastante modificado
antes de ser lançado. A Microsoft não faz nenhuma garantia, expressa ou implícita,
com relação às informações fornecidas aqui.

A partir do Windows Server 2025 (visualização), o Credential Guard é habilitado por

padrão em todos os servidores ingressados no domínio que não são Controladores de
Domínio. Como resultado, talvez você não consiga mais usar o Live Migration com o
Hyper-V após a atualização para o Windows Server 2025. A delegação baseada em
CredSSP é o padrão para o Windows Server 2022 e versões anteriores para migração ao
vivo. Para obter mais informações, consulte Configurar o Credential Guard.

Etapa 1: Configurar a delegação restrita

(opcional)
Se você decidiu usar o Kerberos para autenticar o tráfego da migração dinâmica,
configure a delegação restrita usando uma conta que seja membro do grupo
Administradores de Domínio.

Usar o snap-in Usuários e Computadores para configurar

a delegação restrita
1. Abra o snap-in Usuários e Computadores do Active Directory. (Em Gerenciador do
Servidor, selecione o servidor se ele não estiver selecionado, clique em
Ferramentas>>Usuários e Computadores do Active Directory).

2. No painel de navegação em Usuários e Computadores do Active Directory,

selecione o domínio e clique duas vezes na pasta Computadores.

3. Na pasta Computadores, clique com o botão direito do mouse na conta do

computador do servidor de origem e clique em Propriedades.

4. Em Propriedades, clique na guia Delegação.

5. Na guia Delegação, selecione Confiar neste computador para delegação somente

em serviços especificados e, em seguida, selecione Usar qualquer protocolo de
autenticação.

6. Clique em Adicionar.
 7. Em Adicionar Serviços, clique em Usuários ou Computadores.

8. Em Selecionar Usuários ou Computadores, digite o nome do servidor de destino.

Clique em Verificar Nomes para verificá-lo e, em seguida, clique OK.

9. Em Adicionar Serviços, nas lista de serviços disponíveis, execute as etapas a seguir

e depois clique em OK:

Para mover o armazenamento de máquina virtual, selecione cifs. Isso é

necessário se você quiser mover o armazenamento com a máquina virtual,
bem como se quiser mover apenas o armazenamento de uma máquina
virtual. Se o servidor estiver configurado para usar o armazenamento SMB
para Hyper-V, isso já deve estar selecionado.

Para mover máquinas virtuais, selecione Serviço de Migração de Sistema

Virtual da Microsoft.

10. Na guia Delegação da caixa de diálogo Propriedades, verifique se os serviços

selecionados na etapa anterior estão listados como os serviços aos quais o
computador de destino poderá apresentar credenciais delegadas. Clique em OK.

11. Na pasta Computers, selecione a conta de computador do servidor de destino e

repita o processo. Na caixa de diálogo Selecionar Usuários ou Computadores,
especifique o nome do servidor de destino.

As alterações de configuração entrarão em vigor depois que ocorrerem os dois

seguintes eventos:

As alterações são replicadas nos controladores de domínio aos quais os servidores

que executam o Hyper-V estão conectados.
O controlador de domínio emite um novo tíquete Kerberos.

Etapa 2: configurar os computadores de origem

e de destino para migração dinâmica
Esta etapa inclui a escolha de opções para autenticação e rede. Como prática
recomendada de segurança, convém selecionar redes específicas para o tráfego da
migração dinâmica, conforme discutido acima. Esta etapa também mostra como
escolher a opção de desempenho.

Usar o Gerenciador do Hyper-V para configurar os

computadores de origem e de destino para migração
dinâmica
1. Abra o Gerenciador do Hyper-V. (No Gerenciador do Servidor, clique em
Ferramentas>>Gerenciador do Hyper-V.)

2. No painel de navegação, selecione um dos servidores. (Se ele não estiver listado,
clique com o botão direito do mouse em Gerenciador do Hyper-V, clique em
Conectar ao Servidor, digite o nome do servidor e clique em OK. Repita para
adicionar mais servidores.)

3. No painel de Ações, clique em Configurações do Hyper-V>>Migrações

dinâmicas.

4. No painel Migrações ao Vivo, marque Habilitar migrações ao vivo de entrada e

saída.

5. Em Migrações dinâmicas simultâneas, especifique um número diferente se não

quiser usar o padrão de 2.

6. Em Migrações ao vivo de entrada, se desejar usar conexões de redes específicas

para aceitar o tráfego da migração ao vivo, clique em Adicionar para digitar as
informações de endereços IP. Caso contrário, clique em Usar qualquer rede
disponível para migração ao vivo. Clique em OK.

7. Para escolher o Kerberos e as opções de desempenho, expanda Migrações

dinâmicas e selecione Recursos Avançados.

Se você tiver configurado a delegação restrita, em Protocolo de

autenticação, selecione Kerberos.
Em Opções de desempenho, examine os detalhes e escolha uma opção
diferente se for apropriado para seu ambiente.

8. Clique em OK.

9. Selecione o outro servidor no Gerenciador Hyper-V e repita as etapas.

Usar o Windows PowerShell para configurar os

computadores de origem e de destino para migração
dinâmica
Três cmdlets estão disponíveis para configurar a migração dinâmica em hosts não
clusterizados: Enable-VMMigration, Set-VMMigrationNetwork e Set-VMHost. Este
exemplo usa os três e faz o seguinte:
 Configura a migração dinâmica no host local
Permite o tráfego de migração de entrada somente em uma rede específica
Escolhe o Kerberos como o protocolo de autenticação

Cada linha representa um comando separado.

PowerShell

PS C:\> Enable-VMMigration

PS C:\> Set-VMMigrationNetwork [Link]

PS C:\> Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

O cmdlet Set-VMHost também permite escolher uma opção de desempenho (e muitas

outras configurações de host). Por exemplo, para escolher o SMB, mas deixar o
protocolo de autenticação definido como o padrão de CredSSP, digite:

PowerShell

PS C:\> Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

Esta tabela descreve como funcionam as opções de desempenho.

ﾉ Expandir a tabela

Opção Descrição

TCP/IP Copia a memória da máquina virtual para o servidor de destino por uma conexão
TCP/IP.

Compactação Compacta o conteúdo da memória da máquina virtual antes de copiá-lo para o

servidor de destino em uma conexão TCP/IP. Observação: Essa é a configuração
padrão.

SMB Copia a memória da máquina virtual para o servidor de destino através de uma
conexão SMB 3.0.
– O SMB Direct é usado quando os adaptadores de rede nos servidores de
origem e destino têm recursos RDMA (Acesso Remoto Direto à Memória)
habilitados.
– O SMB Multichannel detecta e usa automaticamente várias conexões quando
uma configuração adequada de SMB Multichannel é identificada.

Para obter mais informações, consulte Melhorar o desempenho de um servidor

de arquivos com o SMB Direct.
Próximas etapas
Depois de configurar os hosts, você estará pronto para fazer uma migração dinâmica.
Para obter instruções, confira Usar a migração dinâmica sem Cluster de Failover para
mover uma máquina virtual.
Usar a migração dinâmica sem Cluster
de Failover para mover uma máquina
virtual
Artigo • 12/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este artigo mostra como mover uma máquina virtual fazendo uma migração dinâmica
sem usar o Clustering de Failover. Uma migração ao vivo move máquinas virtuais em
execução entre hosts Hyper-V sem um tempo de inatividade perceptível.

Para fazer isso, você precisará de:

Uma conta de usuário associada ao grupo Administradores locais do Hyper-V ou

ao grupo Administradores nos computadores de origem e de destino.

A função Hyper-V no Windows Server 2016 ou Windows Server 2012 R2 instalada

nos servidores de origem e de destino e configurada para migração dinâmica.
Você pode fazer uma migração dinâmica entre hosts que executam o Windows
Server 2016 e o Windows Server 2012 R2 se a máquina virtual tiver pelo menos a
versão 5.

Para obter instruções de atualização de versão, consulte Atualizar a versão da

máquina virtual no Hyper-V no Windows 10 ou no Windows Server 2016. Para
obter instruções de instalação, confira Configurar hosts para migração dinâmica.

As ferramentas de gerenciamento do Hyper-V instaladas em um computador que

execute o Windows Server 2016 ou o Windows 10, a menos que as ferramentas
sejam instaladas no servidor de origem ou de destino e que você as execute de lá.

Usar o Gerenciador do Hyper-V para mover

uma máquina virtual em execução
1. Abra o Gerenciador do Hyper-V. (No Gerenciador do Servidor, clique em
Ferramentas>>Gerenciador do Hyper-V.)

2. No painel de navegação, selecione um dos servidores. (Se ele não estiver listado,
clique com o botão direito do mouse em Gerenciador do Hyper-V, clique em
 Conectar ao Servidor, digite o nome do servidor e clique em OK. Repita para
adicionar mais servidores.)

3. No painel Máquinas Virtuais, clique com o botão direito do mouse na máquina

virtual e clique em Mover. Essa ação abrirá o Assistente para Mover.

4. Use as páginas do assistente para escolher o tipo de movimentação, servidor de

destino e opções.

5. Na página Resumo, reveja suas escolhas e clique em Concluir.

Usar o Windows PowerShell para mover a

máquina virtual em execução
O exemplo a seguir usa o cmdlet Move-VM para mover uma máquina virtual chamada
LMTest para um servidor de destino chamado TestServer02 e move os discos rígidos
virtuais e outros arquivos, como pontos de verificação e arquivos de Paginação
Inteligente, para o diretório D:\LMTest no servidor de destino.

PS C:\> Move-VM LMTest TestServer02 -IncludeStorage -DestinationStoragePath

D:\LMTest

Solução de problemas

Falha ao estabelecer uma conexão

Se você ainda não configurou a delegação restrita, deve entrar no servidor de origem
antes de mover uma máquina virtual. Se você não fizer isso, a tentativa de autenticação
falhará, ocorrerá um erro e esta mensagem será exibida:

"A operação de migração de máquina virtual falhou na origem da migração. Falha ao

estabelecer uma conexão com o host nome do computador: credenciais não disponíveis
no pacote de segurança 0x8009030E."

Para corrigir esse problema, entre no servidor de origem e tente mover novamente. Para
evitar a necessidade de entrar em um servidor de origem antes de fazer uma migração
dinâmica, configure a delegação restrita. Você precisará das credenciais de
administrador de domínio para configurar a delegação restrita. Para obter instruções,
confira Configurar hosts para migração dinâmica.
Falhou porque o hardware do host não é compatível
Se uma máquina virtual não tiver a compatibilidade do processador ativada e tiver um
ou mais instantâneos, a movimentação falhará se os hosts tiverem versões de
processador diferentes. Ocorreu um erro e esta mensagem será exibida:

A máquina virtual não pode ser movida para o computador de destino. O hardware
no computador de destino não é compatível com os requisitos de hardware dessa
máquina virtual.

Para corrigir esse problema, desligue a máquina virtual e ative a configuração de

compatibilidade do processador.

1. No Gerenciador Hyper-V, no painel Máquinas Virtuais, clique com o botão direito

do mouse na máquina virtual e clique em Configurações.

2. No painel de navegação, abra Processadores e clique em Compatibilidade.

3. Verifique Migrar para um computador com uma versão de processador

diferente.

4. Clique em OK.

Para usar o Windows PowerShell, use o cmdlet Set-VMProcessor:

PS C:\> Set-VMProcessor TestVM -CompatibilityForMigrationEnabled $true

Ajuste de desempenho de servidores
Hyper-V
Artigo • 08/03/2024

O Hyper-V é a função de servidor de virtualização no Windows Server e no Azure Stack

HCI. Os servidores de virtualização podem hospedar várias máquinas virtuais isoladas,
mas que compartilham os recursos de hardware subjacentes por meio da virtualização
dos processadores, memória e dispositivos de E/S. Ao consolidar servidores em um
único computador, a virtualização pode melhorar a eficiência de energia e o uso de
recursos, além de reduzir os custos operacionais e de manutenção de servidores. Além
disso, as máquinas virtuais e as APIs de gerenciamento oferecem mais flexibilidade para
gerenciar recursos, balancear cargas e provisionar sistemas.

Referências adicionais
Terminologia do Hyper-V

Arquitetura Hyper-V

Configuração do servidor do Hyper-V

Desempenho do processador do Hyper-V

Desempenho de memória do Hyper-V

Desempenho de E/S de armazenamento do Hyper-V

Desempenho de E/S de rede do Hyper-V

Detectar gargalos em um ambiente virtualizado

Máquinas virtuais do Linux

Comutador Virtual Hyper-V
Artigo • 12/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico fornece uma visão geral do Comutador Virtual Hyper-V, que oferece a
capacidade de conectar VMs (máquinas virtuais) a redes externas ao host Hyper-V,
incluindo a intranet da sua organização e a Internet.

Você também pode se conectar a redes virtuais no servidor que está executando o
Hyper-V ao implantar a SDN (Rede Definida pelo Software).

７ Observação

Além deste tópico, a documentação a seguir sobre o Comutador Virtual Hyper-V

está disponível.

Gerenciar o comutador virtual do Hyper-V

Acesso Remoto Direto à Memória (RDMA) e Agrupamento incorporado de
comutador (SET)
Cmdlets de equipe do comutador de rede no Windows PowerShell
Novidades no VMM 2016
Configurar a malha de rede do VMM
Fórum do Hyper-V
Hyper-V: a extensão do comutador virtual WFP deve ser habilitada se for
exigida pelas extensões de terceiros

Para mais informações sobre outras tecnologias de rede, confira Rede no Windows
Server 2016.

O Comutador Virtual Hyper-V é um comutador de rede de Ethernet de camada 2

baseado em software que está disponível no Gerenciador Hyper-V quando a função de
servidor Hyper-V é instalada.

O Comutador Virtual Hyper-V inclui funcionalidades programaticamente gerenciadas e

extensíveis para conectar VMs a redes físicas e a redes virtuais. Além disso, o Comutador
Virtual Hyper-V fornece imposição de política para níveis de segurança, de isolamento e
de serviço.
 ７ Observação

O Comutador Virtual Hyper-V dá suporte apenas a Ethernet e não dá suporte a

quaisquer outras tecnologias de LAN (rede local) com fio, como Infiniband e Fibre
Channel.

O Comutador Virtual Hyper-V inclui recursos de isolamento de locatário, modelagem de

tráfego, proteção contra máquinas virtuais mal-intencionadas e solução de problemas
simplificada.

Com o suporte interno a drivers de filtro NDIS (Especificação de Interface de Dispositivo

de Rede) e a drivers de plug-in WFP (Plataforma para Filtros do Windows), o Comutador
Virtual Hyper-V permite que ISVs (fornecedores independentes de software) criem plug-
ins extensíveis chamados de Extensões de Comutador Virtual, que podem fornecer
funcionalidades avançadas de rede e de segurança. As Extensões de Comutador Virtual
que podem ser adicionadas ao Comutador Virtual Hyper-V são listadas no recurso
Gerenciador de Comutador Virtual do Gerenciador Hyper-V.

Na ilustração a seguir, uma VM tem uma NIC virtual conectada ao Comutador Virtual
Hyper-V por uma porta do comutador.

As funcionalidades do Comutador Virtual Hyper-V oferecem mais opções para impor o

isolamento de locatários, modelar e controlar o tráfego de rede e aplicar medidas de
proteção contra VMs mal-intencionadas.

７ Observação

No Windows Server 2016, uma VM com uma NIC virtual exibe com precisão a taxa
de transferência máxima da NIC virtual. Para exibir a velocidade da NIC virtual em
Conexões de Rede, clique com o botão direito do mouse no ícone da NIC virtual
desejada e clique em Status. A caixa de diálogo Status da NIC virtual será aberta.
 Em Conexão, o valor de Velocidade corresponde à velocidade da NIC física
instalada no servidor.

Usos do Comutador Virtual Hyper-V

Veja a seguir alguns cenários de caso de uso do Comutador Virtual Hyper-V.

Exibição de estatísticas: um desenvolvedor em um fornecedor de nuvem hospedado

implementa um pacote de gerenciamento que exibe o estado atual do comutador
virtual Hyper-V. O pacote de gerenciamento pode consultar as funcionalidades atuais
em todo o comutador, as definições de configuração e estatísticas de redes de portas
individuais usando a WMI. Em seguida, o status do comutador é apresentado para dar
aos administradores uma visualização rápida do estado do comutador.

Rastreamento de recursos: uma empresa de hospedagem está vendendo serviços com

preços estipulados de acordo com o nível de associação. Vários níveis de associação
incluem diferentes níveis de desempenho de rede. O administrador aloca recursos para
atender aos contratos de nível de serviço de maneira que equilibre a disponibilidade da
rede. O administrador acompanha as informações de forma programática, como o uso
atual da largura de banda atribuída e o número de VMs (máquinas virtuais): VMQ (fila
de máquina virtual) ou canais IOV atribuídos. O mesmo programa também registra
periodicamente os recursos em uso, além dos recursos atribuídos por VM para
rastreamento ou recursos de dupla entrada.

Gerenciando a ordem das extensões do comutador: uma empresa instalou extensões

no host Hyper-V para monitorar o tráfego e relatar detecção de intrusões. Durante a
manutenção, algumas extensões podem ser atualizadas causando a alteração da ordem
das extensões. Um programa de script simples é executado para reordenar as extensões
após as atualizações.

A extensão de encaminhamento gerencia a ID de VLAN: uma importante empresa de

comutadores está construindo uma extensão de encaminhamento que se aplica a todas
as políticas de rede. Um elemento que é gerenciado são as IDs de VLAN (rede local
virtual). O comutador virtual cede o controle da VLAN para uma extensão de
encaminhamento. A instalação da empresa de comutadores chama programaticamente
uma API (Interface de programação de aplicativo) de WMI (Instrumentação de
Gerenciamento do Windows) que habilita a transparência, informando ao Comutador
Virtual Hyper-V para passar e não executar nenhuma ação nas marcas de VLAN.

Funcionalidade do Comutador Virtual Hyper-V

Estes são alguns dos principais recursos incluídos no Comutador Virtual Hyper-V:

Proteção contra Envenenamento ARP/ND (falsificação): fornece proteção contra

uma VM mal-intencionada que usa falsificação de protocolo ARP para roubar
endereços IP de outras VMs. Fornece proteção contra ataques que podem ser
iniciados para IPv6 usando falsificação ND (Descoberta de Vizinhos).

Proteção DHCP: protege contra uma VM mal-intencionada que representa a si

mesma como servidor DHCP para ataques man-in-the-middle.

ACLs de porta: fornecem filtragem baseada em MAC (Controle de Acesso a Mídia)

ou em endereços/intervalos IP, o que permite configurar o isolamento de redes
virtuais.

Modo de tronco para uma VM: permite aos administradores configurar uma VM
específica como dispositivo virtual e direcionar o tráfego de várias VLANs para
essa VM.

Monitoramento de tráfego de rede: permite aos administradores examinar o

tráfego que está atravessando o comutador de rede.

VLAN isolada (privada): permite aos administradores segregar o tráfego de várias

VLANs para estabelecer mais facilmente comunidades de locatários isoladas.

A seguir está uma lista de funcionalidades que melhoram a capacidade de uso do

Comutador Virtual Hyper-V:

Suporte a limite e intermitência de largura de banda: o mínimo de largura de

banda garante a quantidade de largura de banda reservada. O máximo de largura
de banda limita a quantidade de largura de banda que uma VM pode consumir.

Suporte à marcação ECN (Notificação de Congestionamento Explícita): a

marcação ECN, também conhecida como DCTCP (Data Center TCP), permite que o
comutador físico e o sistema operacional regulem o fluxo de tráfego de modo que
os recursos de buffer do comutador não sejam inundados, o que resulta em maior
taxa de transferência de tráfego.

Diagnóstico: o diagnóstico permite o fácil rastreamento e monitoramento de

eventos e pacotes através do comutador virtual.
Requisitos de rede de host para o Azure
Stack HCI
Artigo • 25/06/2024

Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2

Este tópico discute as considerações e os requisitos de rede do host para o Azure Stack
HCI. Para obter informações sobre arquiteturas de datacenter e as conexões físicas entre
servidores, consulte Requisitos de rede física.

Para obter informações sobre como simplificar a rede de host usando o ATC de rede,
consulte Simplificar a rede de host com o ATC de rede.

Tipos de tráfego de rede

O tráfego de rede HCI do Azure Stack pode ser classificado de acordo com a finalidade
pretendida:

Tráfego de gerenciamento: tráfego de ou para fora do cluster local. Por exemplo,

tráfego de réplica de armazenamento ou tráfego usado pelo administrador para
gerenciamento do cluster, como Área de Trabalho Remota, Windows Admin Center,
Active Directory, etc.
Tráfego de computação: tráfego originado ou destinado a uma máquina virtual (VM).
Tráfego de armazenamento: tráfego usando SMB (Server Message Block), por
exemplo, migração ao vivo baseada em SMB ou Storage Spaces Direct. Esse tráfego é
tráfego de camada 2 e não é roteável.

） Importante

A réplica de armazenamento usa tráfego SMB não baseado em RDMA. Isso e a

natureza direcional do tráfego (Norte-Sul) o torna intimamente alinhado ao tráfego de
"gerenciamento" listado acima, semelhante ao de um compartilhamento de arquivos
tradicional.

Selecione um adaptador de rede

Os adaptadores de rede são qualificados pelos tipos de tráfego de rede (veja acima) com
os quais são suportados para uso. Ao examinar o Catálogo do Windows Server, a
certificação do Windows Server 2022 agora indica uma ou mais das seguintes funções.
Antes de comprar um servidor para o Azure Stack HCI, você deve ter minimamente pelo
menos um adaptador qualificado para gerenciamento, computação e armazenamento, pois
todos os três tipos de tráfego são necessários no Azure Stack HCI. Em seguida, você pode
usar o ATC de rede para configurar os adaptadores para os tipos de tráfego apropriados.

Para obter mais informações sobre essa qualificação de NIC baseada em função, consulte
este link .

） Importante

Não há suporte para o uso de um adaptador fora de seu tipo de tráfego qualificado.

ﾉ Expandir a tabela

Nível Função de Função de Função de

gerenciamento computação armazenamento

Distinção baseada em Gerenciamento Padrão de Padrão de

papéis computação armazenamento

Prêmio Máximo Não Aplicável Computação Armazenamento

premium Premium

７ Observação

A qualificação mais alta para qualquer adaptador em nosso ecossistema conterá as

qualificações Management, Compute Premium e Storage Premium .

Exigências do driver
Não há suporte para drivers de caixa de entrada para uso com o Azure Stack HCI. Para
identificar se o adaptador está usando um driver de caixa de entrada, execute o cmdlet a
seguir. Um adaptador está usando um driver de caixa de entrada se a propriedade
DriverProvider for Microsoft.

Powershell
 Get-NetAdapter -Name <AdapterName> | Select *Driver*

Visão geral dos principais recursos do adaptador

de rede
Os recursos importantes do adaptador de rede usados pelo Azure Stack HCI incluem:

Multifila de Máquina Virtual Dinâmica (VMMQ Dinâmico ou [Link])

Acesso Remoto Direto à Memória (RDMA)
RDMA convidado
SET (Agrupamento Incorporado de Comutador)

VMMQ dinâmico
Todos os adaptadores de rede com a qualificação Compute (Premium) oferecem suporte
ao VMMQ dinâmico. O VMMQ dinâmico requer o uso do Switch Embedded Teaming.

Tipos de tráfego aplicáveis: computação

Certificações necessárias: Compute (Premium)

O VMMQ dinâmico é uma tecnologia inteligente de recebimento. Ele se baseia em seus

predecessores de VMQ (Virtual Machine Queue), vRSS (Virtual Receive Side Scaling) e
VMMQ, para fornecer três aprimoramentos principais:

Otimiza a eficiência do host usando menos núcleos de CPU.

Ajuste automático do processamento de tráfego de rede para núcleos de CPU,
permitindo que as VMs atendam e mantenham a taxa de transferência esperada.
Permite que cargas de trabalho "intermitentes" recebam a quantidade esperada de
tráfego.

Para obter mais informações sobre o VMMQ dinâmico, consulte a postagem do blog
Acelerações sintéticas .

RDMA
RDMA é um descarregamento de pilha de rede para o adaptador de rede. Ele permite que
o tráfego de armazenamento do SMB ignore o sistema operacional para processamento.

O RDMA permite redes de alta taxa de transferência e baixa latência, usando recursos
mínimos de CPU do host. Esses recursos da CPU do host podem ser usados para executar
VMs ou contêineres adicionais.
Tipos de tráfego aplicáveis: armazenamento de host

Certificações necessárias: Armazenamento (Padrão)

Todos os adaptadores com qualificação de armazenamento (padrão) ou armazenamento

(premium) oferecem suporte a RDMA do lado do host. Para obter mais informações sobre
como usar o RDMA com cargas de trabalho de convidado, consulte a seção "RDMA de
convidado", mais adiante neste artigo.

O Azure Stack HCI dá suporte ao RDMA com as implementações do protocolo Internet

Wide Area RDMA Protocol (iWARP) ou RDMA over Converged Ethernet (RoCE).

） Importante

Os adaptadores RDMA só funcionam com outros adaptadores RDMA que

implementam o mesmo protocolo RDMA (iWARP ou RoCE).

Nem todos os adaptadores de rede de fornecedores oferecem suporte a RDMA. A tabela a

seguir lista os fornecedores (em ordem alfabética) que oferecem adaptadores RDMA
certificados. No entanto, há fornecedores de hardware não incluídos nesta lista que
também oferecem suporte a RDMA. Consulte o Catálogo do Windows Server para
localizar adaptadores com a qualificação de Armazenamento (Padrão) ou Armazenamento
(Premium) que exigem suporte a RDMA.

７ Observação

Não há suporte para InfiniBand (IB) com o Azure Stack HCI.

ﾉ Expandir a tabela

Fornecedor de NIC iWARP RoCE

Broadcom Não Sim

Intel Sim Sim (alguns modelos)

Marvell (Qlogic) Sim Sim

Nvidia Não Sim

Para obter mais informações sobre como implantar RDMA para o host, é altamente
recomendável usar o ATC de rede. Para obter informações sobre implantação manual,
consulte o repositório SDN GitHub.
iWARP
O iWARP usa TCP (Transmission Control Protocol) e pode ser opcionalmente aprimorado
com PFC (Priority-based Flow Control) e ETS (Enhanced Transmission Service).

Use o iWARP se:

Você não tem experiência no gerenciamento de redes RDMA.

Você não gerencia ou não se sente confortável em gerenciar seus switches top-of-
rack (ToR).
Você não gerenciará a solução após a implantação.
Você já tem implantações que usam iWARP.
Você não tem certeza de qual opção escolher.

RoCE
O RoCE usa o protocolo UDP (User Datagram Protocol) e requer PFC e ETS para fornecer
confiabilidade.

Use RoCE se:

Você já tem implantações com RoCE em seu datacenter.

Você está confortável em gerenciar os requisitos de rede DCB.

RDMA convidado
O RDMA convidado permite que cargas de trabalho do SMB para VMs obtenham os
mesmos benefícios de usar RDMA em hosts.

Tipos de tráfego aplicáveis: Armazenamento baseado em convidado

Certificações necessárias: Compute (Premium)

Os principais benefícios do uso do RDMA convidado são:

Descarregamento da CPU para a NIC para processamento de tráfego de rede.

Latência extremamente baixa.
Alta taxa de transferência.

Para obter mais informações, baixe o documento do repositório SDN GitHub.

SET (Agrupamento Incorporado de Comutador)

SET é uma tecnologia de agrupamento baseada em software que foi incluída no sistema
operacional Windows Server desde o Windows Server 2016. SET é a única tecnologia de
agrupamento com suporte do Azure Stack HCI. O SET funciona bem com tráfego de
computação, armazenamento e gerenciamento e é suportado com até oito adaptadores na
mesma equipe.

Tipos de tráfego aplicáveis: computação, armazenamento e gerenciamento

Certificações necessárias: Compute (Standard) ou Compute (Premium)

SET é a única tecnologia de agrupamento com suporte do Azure Stack HCI. O SET funciona
bem com tráfego de computação, armazenamento e gerenciamento.

） Importante

O Azure Stack HCI não oferece suporte ao agrupamento de NIC com o LBFO
(Balanceamento de Carga/Failover) mais antigo. Consulte a postagem do blog
Agrupamento no Azure Stack HCI para obter mais informações sobre LBFO no
Azure Stack HCI.

O SET é importante para o Azure Stack HCI porque é a única tecnologia de agrupamento
que permite:

Agrupamento de adaptadores RDMA (se necessário).

RDMA convidado.
VMMQ dinâmico.
Outros recursos importantes do Azure Stack HCI (consulte Agrupamento no Azure
Stack HCI ).

O SET requer o uso de adaptadores simétricos (idênticos). Os adaptadores de rede

simétricos são aqueles que têm o mesmo:

marca (fornecedor)
modelo (versão)
velocidade (taxa de transferência)
configuração

Em 22H2, o Network ATC detectará e informará automaticamente se os adaptadores

escolhidos são assimétricos. A maneira mais fácil de identificar manualmente se os
adaptadores são simétricos é se as velocidades e as descrições da interface forem
correspondências exatas . Eles podem se desviar apenas no numeral listado na descrição.
Use o Get-NetAdapterAdvancedProperty cmdlet para garantir que a configuração relatada
liste os mesmos valores de propriedade.

Consulte a tabela a seguir para obter um exemplo das descrições de interface que se
desviam apenas por numeral (#):
 ﾉ Expandir a tabela

Nome Descrição da interface Velocidade do link

NIC1 Adaptador de rede #1 25 Gbps

NIC2 Adaptador de rede #2 25 Gbps

NIC3 Adaptador de rede #3 25 Gbps

NIC4 Adaptador de rede #4 25 Gbps

７ Observação

O SET oferece suporte apenas à configuração independente de switch usando

algoritmos de balanceamento de carga de Porta Dinâmica ou Hyper-V. Para obter um
melhor desempenho, a porta Hyper-V é recomendada para uso em todas as NICs que
operam em ou acima de 10 Gbps. O ATC de rede faz todas as configurações
necessárias para o SET.

Considerações sobre tráfego RDMA

Se você implementar o DCB, deverá garantir que a configuração do PFC e do ETS seja
implementada corretamente em todas as portas de rede, incluindo comutadores de rede.
DCB é necessário para RoCE e opcional para iWARP.

Para obter informações detalhadas sobre como implantar o RDMA, baixe o documento do
repositório SDN GitHub.

As implementações de HCI do Azure Stack baseadas em RoCE exigem a configuração de

três classes de tráfego PFC, incluindo a classe de tráfego padrão, na malha e em todos os
hosts.

Classe de tráfego de cluster

Essa classe de tráfego garante que haja largura de banda suficiente reservada para
pulsações de cluster:

Obrigatório: Sim
Habilitado para PFC: Não
Prioridade de tráfego recomendada: Prioridade 7
Reserva de largura de banda recomendada:
Redes RDMA de 10 GbE ou inferior = 2%
Redes RDMA de 25 GbE ou superior = 1%
Classe de tráfego RDMA
Essa classe de tráfego garante que haja largura de banda suficiente reservada para
comunicações RDMA sem perdas usando o SMB Direct:

Obrigatório: Sim
Habilitado para PFC: Sim
Prioridade de tráfego recomendada: Prioridade 3 ou 4
Reserva de largura de banda recomendada: 50 por cento

Classe de tráfego padrão

Essa classe de tráfego carrega todo o outro tráfego não definido no cluster ou nas classes
de tráfego RDMA, incluindo tráfego de VM e tráfego de gerenciamento:

Obrigatório: Por padrão (nenhuma configuração necessária no host)

Habilitado para controle de fluxo (PFC): Não
Classe de tráfego recomendada: Por padrão (Prioridade 0)
Reserva de largura de banda recomendada: por padrão (nenhuma configuração de
host necessária)

Modelos de tráfego de armazenamento

O SMB fornece muitos benefícios como o protocolo de armazenamento para o Azure Stack
HCI, incluindo o SMB Multichannel. O SMB Multichannel não é abordado neste artigo, mas
é importante entender que o tráfego é multiplexado em todos os links possíveis que o
SMB Multichannel pode usar.

７ Observação

Recomendamos o uso de várias sub-redes e VLANs para separar o tráfego de

armazenamento no Azure Stack HCI.

Considere o exemplo a seguir de um cluster de quatro nós. Cada servidor tem duas portas
de armazenamento (lado esquerdo e direito). Como cada adaptador está na mesma sub-
rede e VLAN, o SMB Multichannel espalhará as conexões por todos os links disponíveis.
Portanto, a porta do lado esquerdo no primeiro servidor ([Link]) fará uma conexão
com a porta do lado esquerdo no segundo servidor ([Link]). A porta do lado direito
no primeiro servidor ([Link]) se conectará à porta do lado direito no segundo
servidor. Conexões semelhantes são estabelecidas para o terceiro e quarto servidores.

No entanto, isso cria conexões desnecessárias e causa congestionamento no interlink

(grupo de agregação de link de vários chassis ou MC-LAG) que conecta os switches ToR
(marcados com Xs). Confira o seguinte diagrama:

A abordagem recomendada é usar sub-redes e VLANs separadas para cada conjunto de

adaptadores. No diagrama a seguir, as portas à direita agora usam a sub-rede 192.168.2.x
/24 e VLAN2. Isso permite que o tráfego nas portas do lado esquerdo permaneça no TOR1
e o tráfego nas portas do lado direito permaneça no TOR2.
 

Alocação de largura de banda de tráfego

A tabela a seguir mostra exemplos de alocações de largura de banda de vários tipos de
tráfego, usando velocidades comuns de adaptador, no Azure Stack HCI. Observe que este é
um exemplo de uma solução convergente, em que todos os tipos de tráfego (computação,
armazenamento e gerenciamento) são executados nos mesmos adaptadores físicos e
agrupados usando SET.

Como esse caso de uso apresenta a maioria das restrições, ele representa uma boa linha de
base. No entanto, considerando as permutações para o número de adaptadores e
velocidades, isso deve ser considerado um exemplo e não um requisito de suporte.

As seguintes suposições são feitas para este exemplo:

Há dois adaptadores por equipe.

Tráfego SBL (Storage Bus Layer), CSV (Volume Compartilhado de Cluster) e Hyper-V
(Live Migration):
Use os mesmos adaptadores físicos.
 Use SMB.

O SMB recebe uma alocação de 50% de largura de banda usando DCB.

SBL/CSV é o tráfego de maior prioridade e recebe 70% da reserva de largura de
banda SMB.
A migração ao vivo (LM) é limitada usando o Set-SMBBandwidthLimit cmdlet e
recebe 29% da largura de banda restante.

Se a largura de banda disponível para migração ao vivo for >= 5 Gbps e os

adaptadores de rede forem capazes, use RDMA. Use o seguinte cmdlet para
fazer isso:

Powershell

Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

Se a largura de banda disponível para o Live Migration for < de 5 Gbps, use a
compactação para reduzir os tempos de blackout. Use o seguinte cmdlet para
fazer isso:

Powershell

Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

Se você estiver usando o RDMA para tráfego de migração ao vivo, verifique se o

tráfego de migração ao vivo não pode consumir toda a largura de banda alocada
para a classe de tráfego RDMA usando um limite de largura de banda SMB. Tenha
cuidado, pois esse cmdlet recebe entrada em bytes por segundo (Bps), enquanto os
adaptadores de rede são listados em bits por segundo (bps). Use o cmdlet a seguir
para definir um limite de largura de banda de 6 Gbps, por exemplo:

Powershell

Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

７ Observação

750 MBps neste exemplo equivale a 6 Gbps.

Aqui está o exemplo de tabela de alocação de largura de banda:

ﾉ Expandir a tabela
 Velocidade Largura Reserva SBL/CSV Largura % de Largura Batimento Largura
da NIC de banda de % de migração de banda cardíaco de
agrupada largura banda ao vivo máxima % banda
de SBL/CSV de de
banda migração pulsação
SMB** ao vivo

10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps * 200

Mbps

25 Gbps 50 Gbps 25 Gbps 70% 17,5 29% 7,25 %1 250

Gbps Gbps Mbps

40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11,6 %1 400

Gbps Mbps

50 Gbps 100 Gbps 50 Gbps 70% 35 Gbps 29% 14,5 %1 500

Gbps Mbps

100 Gbps 200 Gbps 100 70% 70 Gbps 29% 29 Gbps %1 1 Gbps
Gbps

200 Gbps 400 Gbps 200 70% 140 29% 58 Gbps %1 2 Gbps
Gbps Gbps

* Use compactação em vez de RDMA, porque a alocação de largura de banda para o

tráfego de migração ao vivo é <de 5 Gbps.

** 50 por cento é um exemplo de reserva de largura de banda.

Aglomerados esticados
Os clusters estendidos fornecem recuperação de desastres que abrange vários datacenters.
Em sua forma mais simples, uma rede de cluster HCI do Azure Stack estendida tem a
seguinte aparência:
 

Requisitos de cluster estendidos

） Importante

A funcionalidade de cluster estendido só está disponível no Azure Stack HCI, versão

22H2.

Os clusters estendidos têm os seguintes requisitos e características:

O RDMA é limitado a um único site e não tem suporte em diferentes sites ou sub-
redes.

Os servidores no mesmo site devem residir no mesmo rack e limite de Camada 2.

A comunicação do host entre sites deve cruzar um limite de Camada 3; Não há

suporte para topologias de Layer-2 esticadas.

Ter largura de banda suficiente para executar as cargas de trabalho no outro site. No
caso de um failover, o site alternativo precisará executar todo o tráfego.
Recomendamos que você provisione sites com 50% da capacidade de rede
disponível. No entanto, isso não é um requisito se você puder tolerar um
desempenho inferior durante um failover.

Adaptadores usados para comunicação entre sites:

Pode ser físico ou virtual (host vNIC). Se os adaptadores forem virtuais, você deverá
provisionar uma vNIC em sua própria sub-rede e VLAN por NIC física.
 Deve estar em sua própria sub-rede e VLAN que pode rotear entre sites.

O RDMA deve ser desabilitado usando o Disable-NetAdapterRDMA cmdlet.

Recomendamos que você exija explicitamente que a Réplica de Armazenamento
use interfaces específicas usando o Set-SRNetworkConstraint cmdlet.

Deve atender a quaisquer requisitos adicionais para a réplica de armazenamento.

Próximas etapas
Saiba mais sobre os requisitos de comutador de rede e rede física. Consulte
Requisitos de rede física.
Saiba como simplificar a rede de host usando o Network ATC. Consulte Simplificar a
rede de hosts com o Network ATC.
Aprimore as noções básicas de rede de clustering de failover.
Consulte Implantar usando o portal do Azure.
Consulte Implantar usando o modelo do Gerenciador de Recursos do Azure.

Comentários
Esta página foi útil?  Yes  No

Fornecer comentários sobre o produto | Obter ajuda no Microsoft Q&A

Gerenciar o Comutador Virtual do
Hyper-V
Artigo • 12/04/2023

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para acessar o conteúdo de gerenciamento do Comutador
Virtual do Hyper-V.

Esta seção contém os seguintes tópicos.

Configurar VLANs nas Portas do Comutador Virtual do Hyper-V

Criar políticas de segurança com listas de controle de acesso de porta estendida
Criar Políticas de Segurança com Listas
de Controle de Acesso de Porta
Estendida
Artigo • 09/03/2023

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico fornece informações sobre as ACLs (listas de controle de acesso) de porta
estendida do Windows Server 2016. É possível configurar ACLs estendidas no
comutador virtual do Hyper-V para permitir e bloquear o tráfego da rede de/para as
VMs (Máquinas Virtuais) conectadas ao comutador através de adaptadores de rede
virtuais.

Este tópico inclui as seções a seguir.

Regras de ACL detalhadas

Regras de ACL com monitoração de estado

Regras de ACL detalhadas

As ACLs estendidas do Comutador Virtual do Hyper-V permitem criar regras detalhadas
que podem ser aplicadas a adaptadores de rede de VM individuais conectados ao
Comutador Virtual do Hyper-V. A capacidade de criar regras detalhadas permite às
Empresas e aos CSPs (provedores de serviços de nuvem) lidar com as ameaças à
segurança baseadas em rede em um ambiente multilocatário de servidores
compartilhados.

Com as ACLs estendidas, em vez de ter que criar regras abrangentes que bloqueiem ou
permitam todo o tráfego de todos os protocolos de ou para uma máquina virtual, é
possível bloquear ou permitir o tráfego de rede de protocolos individuais que estão
sendo executando nas VMs. Você pode criar regras de ACL estendida no Windows
Server 2016 que incluam o seguinte conjunto de parâmetros de cinco tuplas: endereço
IP de origem, endereço IP de destino, protocolo, porta de origem e porta de destino.
Além disso, cada regra pode especificar a direção específica do tráfego da rede (entrada
ou saída), bem como a ação que a regra apoia (bloquear ou permitir tráfego).

Por exemplo, é possível configurar ACLs de porta para uma máquina virtual para
permitir todo o tráfego que entra e sai de HTTP e HTTPS na porta 80, ao mesmo tempo
que bloqueia o trafego de rede de todos os demais protocolos em todas as portas.

Essa capacidade para designar o tráfego do protocolo que pode ou não ser recebido
pelas VMs do locatário proporciona flexibilidade durante a configuração de políticas de
segurança.

Configurando regras de ACL com o Windows PowerShell

Para configurar uma ACL estendida, é necessário usar o comando do Windows
PowerShell Add-VMNetworkAdapterExtendedAcl. Esse comando possui quatro sintaxes
diferentes, cada uma com uso distinto:

1. Adicione uma ACL estendida a todos os adaptadores de rede de uma VM

nomeada, que é especificada pelo primeiro parâmetro, -VMName. Sintaxe:

７ Observação

Caso você deseje adicionar uma ACL estendida a um adaptador de rede em

vez de adicioná-la a todos, especifique o adaptador de rede com o parâmetro
–VMNetworkAdapterName.

Add-VMNetworkAdapterExtendedAcl [-VMName] <string[]> [-Action]

<VMNetworkAdapterExtendedAclAction> {Allow | Deny}
[-Direction] <VMNetworkAdapterExtendedAclDirection> {Inbound |
Outbound} [[-LocalIPAddress] <string>]
[[-RemoteIPAddress] <string>] [[-LocalPort] <string>] [[-
RemotePort] <string>] [[-Protocol] <string>] [-Weight]
<int> [-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID
<int>] [-Passthru] [-VMNetworkAdapterName
<string>] [-ComputerName <string[]>] [-WhatIf] [-Confirm]
[<CommonParameters>]

2. Adicione uma ACL estendida a um adaptador de rede virtual específico em uma

VM específica. Sintaxe:

Add-VMNetworkAdapterExtendedAcl [-VMNetworkAdapter]
<VMNetworkAdapterBase[]> [-Action]
<VMNetworkAdapterExtendedAclAction> {Allow | Deny} [-Direction]
<VMNetworkAdapterExtendedAclDirection> {Inbound |
Outbound} [[-LocalIPAddress] <string>] [[-RemoteIPAddress]
<string>] [[-LocalPort] <string>] [[-RemotePort]
<string>] [[-Protocol] <string>] [-Weight] <int> [-Stateful <bool>]
 [-IdleSessionTimeout <int>] [-IsolationID
<int>] [-Passthru] [-WhatIf] [-Confirm] [<CommonParameters>]

3. Adicione uma ACL estendida a todos os adaptadores da rede virtual, reservados

para utilização pelo sistema operacional de gerenciamento do host do Hyper-V.

７ Observação

Caso você deseje adicionar uma ACL estendida a um adaptador de rede em

vez de adicioná-la a todos, especifique o adaptador de rede com o parâmetro
–VMNetworkAdapterName.

Add-VMNetworkAdapterExtendedAcl [-Action]
<VMNetworkAdapterExtendedAclAction> {Allow | Deny} [-Direction]
<VMNetworkAdapterExtendedAclDirection> {Inbound | Outbound} [[-
LocalIPAddress] <string>] [[-RemoteIPAddress]
<string>] [[-LocalPort] <string>] [[-RemotePort] <string>] [[-
Protocol] <string>] [-Weight] <int> -ManagementOS
[-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID <int>]
[-Passthru] [-VMNetworkAdapterName <string>]
[-ComputerName <string[]>] [-WhatIf] [-Confirm]
[<CommonParameters>]

4. Adicione uma ACL estendida a um objeto da VM que tenha sido criado no

Windows PowerShell, como $vm = get-vm "my_vm". Na linha seguinte do código,
é possível executar este comando para criar uma ACL estendida com a sintaxe a
seguir:

Add-VMNetworkAdapterExtendedAcl [-VM] <VirtualMachine[]> [-Action]

<VMNetworkAdapterExtendedAclAction> {Allow |
Deny} [-Direction] <VMNetworkAdapterExtendedAclDirection> {Inbound
| Outbound} [[-LocalIPAddress] <string>]
[[-RemoteIPAddress] <string>] [[-LocalPort] <string>] [[-
RemotePort] <string>] [[-Protocol] <string>] [-Weight]
<int> [-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID
<int>] [-Passthru] [-VMNetworkAdapterName
<string>] [-WhatIf] [-Confirm] [<CommonParameters>]

Exemplos de regras de ACL detalhadas

A seguir, apresentamos alguns exemplos de como usar o comando Add-
VMNetworkAdapterExtendedAcl para configurar ACLs de porta estendida e para criar
políticas de segurança para VMs.

Impor segurança em nível de aplicativo

Impor segurança em nível de usuário e em nível de aplicativo

Oferecer suporte de segurança a um aplicativo que não seja TCP/UDP

７ Observação

Os valores para o parâmetro da regra de Direção nas tabelas abaixo baseiam-se no

fluxo do tráfego de ou para a VM para a qual a regra está sendo criada. Se a VM
estiver recebendo tráfego, o tráfego é de entrada; se a VM estiver enviando
tráfego, o tráfego é de saída. Por exemplo, se você aplicar uma regra a uma VM
que bloqueia o tráfego de entrada, a direção do tráfego de entrada será dos
recursos externos para a VM. Se você aplicar uma regra que bloqueia o tráfego de
saída, a direção do tráfego de saída será da VM local para recursos externos.

Impor segurança em nível de aplicativo

Tendo em vista que muitos servidores de aplicativos utilizam portas TCP/UDP
padronizadas para comunicação com computadores clientes, é fácil criar regras que
bloqueiem ou permitam o acesso a um servidor de aplicativos, filtrando-se o tráfego
que vai ou vem da porta designada para o aplicativo.

Por exemplo, se você quisesse permitir a um usuário fazer login em um servidor de

aplicativos no datacenter usando a RDP (Conexão com Área de Trabalho Remota). Uma
vez que a RDP usa a porta TCP 3389, é possível configurar rapidamente a regra a seguir:

IP de IP de Protocolo Porta de Porta de Direção Ação

origem destino origem destino

* * TCP * 3389 Em Allow

Apresentamos a seguir dois exemplos de como criar regras com os comandos do

Windows PowerShell. A primeira regra de exemplo bloqueia todo o tráfego para a VM
chamada "ApplicationServer". A segunda regra de exemplo, que é aplicada ao
adaptador de rede da VM chamada "ApplicationServer", permite apenas o tráfego RDP
de entrada na VM.
 ７ Observação

Ao criar regras, você pode usar o parâmetro -Weight para determinar a ordem em
que o Comutador Virtual do Hyper-V processará as regras. Os valores de -Weight
são expressos como inteiros. As regras com um inteiro maior são processadas
antes das regras com inteiros menores. Por exemplo, se você tiver aplicado duas
regras a um adaptador de rede da VM, uma com um peso de 1 e outra com o peso
de 10, a com peso de 10 será aplicada primeiro.

Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -

Direction "Inbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Allow"
-Direction "Inbound" -LocalPort 3389 -Protocol "TCP" -Weight 10

Impor segurança em nível de usuário e em nível de

aplicativo
Uma vez que a regra pode corresponder a um pacote IP com 5 tuplas (IP de Origem, IP
de Destino, Protocolo, Porta de Origem e Porta de Destino), a regra pode impor uma
política de segurança mais detalhada do que uma ACL de porta.

Por exemplo, caso você deseje fornecer o serviço DHCP a um número limitado de
computadores cliente usando um conjunto específico de servidores DHCP, configure as
seguintes regras no computador Windows Server 2016 que executa o Hyper-V no qual
as VMs do usuário estão hospedadas:

IP de origem IP de destino Protocolo Porta de Porta de Direção Ação

origem destino

* [Link] UDP * 67 Saída Allow

* [Link]/25 UDP * 67 Saída Allow

[Link]/25 * UDP * 68 Em Allow

Apresentamos a seguir dois exemplos de como criar regras com os comandos do

Windows PowerShell.
 Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Deny" -
Direction "Outbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
Direction "Outbound" -RemoteIPAddress [Link] -RemotePort 67 -
Protocol "UDP"-Weight 10
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
Direction "Outbound" -RemoteIPAddress [Link]/25 -RemotePort 67 -
Protocol "UDP"-Weight 20
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
Direction "Inbound" -RemoteIPAddress [Link]/25 -RemotePort 68 -
Protocol "UDP"-Weight 20

Oferecer suporte de segurança a um aplicativo que não

seja TCP/UDP
Enquanto a maior parte do tráfego da rede em um datacenter é TCP e UDP, ainda existe
tráfego que utiliza outros protocolos. Por exemplo, se desejar permitir que um grupo de
servidores execute um aplicativo com multicast do IP que depende do protocolo IGMP,
é possível criar a regra a seguir.

７ Observação

O IGMP tem um número de protocolo IP designado de 0x02.

IP de IP de Protocolo Porta de Porta de Direção Ação

origem destino origem destino

* * 0x02 * * Em Allow

* * 0x02 * * Saída Allow

Apresentamos a seguir um exemplo de como criar essas regras com os comandos do

Windows PowerShell.

Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -

Direction "Inbound" -Protocol 2 -Weight 20
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
Direction "Outbound" -Protocol 2 -Weight 20

Regras de ACL com monitoração de estado

Outro recurso novo das ACLs estendidas permite a configuração de regras de
monitoração de estado. Uma regra com estado filtra os pacotes baseado nos cinco
atributos de um pacote: IP de Origem, IP de Destino, Protocolo, Porta de Origem e Porta
de Destino.

As regras de monitoração de estado têm os seguintes recursos:

Elas sempre permitem o tráfego e não são usadas para bloquear o tráfego.

Se especificar que o valor do parâmetro de Direção é de entrada e o tráfego

corresponde à regra, o comutador virtual do Hyper-V cria uma regra
correspondente dinamicamente, a qual permite que a VM envie o tráfego de saída
em resposta ao recurso externo.

Se especificar que o valor do parâmetro de Direção é de saída e o tráfego

corresponde à regra, o comutador virtual do Hyper-V cria uma regra
correspondente dinamicamente, a qual permite que a VM receba o tráfego de
entrada do recurso externo.

Elas incluem um atributo de tempo limite, medido em segundos. Quando um

pacote da rede chega ao comutador e ele corresponde à regra de monitoração de
estado, o comutador virtual do Hyper-V cria um estado, de modo que todos os
pacotes subsequentes – em ambas as direções do mesmo fluxo – sejam
permitidos. O estado espirará se não houver tráfego em nenhuma das direções no
período de tempo especificado pelo valor do tempo limite.

A seguir, apresentamos um exemplo de como usar as regras de monitoração de estado.

Permitir o tráfego de entrada do servidor remoto

somente depois de ele ter sido contactado pelo servidor
local
Em alguns casos, uma regra de monitoração de estado deve ser empregada tendo em
vista que somente uma regra desse tipo pode monitorar uma conexão estabelecida
conhecida e diferenciar uma conexão da outra.

Por exemplo, se desejar permitir que um servidor de aplicativos da VM inicie conexões

na porta 80 com os serviços Web na Internet e desejar que os servidores remotos da
Web consigam responder ao tráfego da VM, será possível configurar uma regra de
monitoração de estado que permita o tráfego de saída inicial da VM para os serviços
Web; uma vez que a regra é de monitoração de estado, o tráfego de retorno para a VM
dos servidores Web será igualmente permitido. Por motivos de segurança, é possível
bloquear todo o tráfego de entrada da rede para a VM.
Para configurar essa regra, será possível utilizar as definições da tabela abaixo.

７ Observação

Devido às restrições de formatação e à quantidade de informações na tabela

abaixo, as informações estão exibidas de forma diferente das tabelas anteriores
neste documento.

Parâmetro Regra 1 Regra 2 Regra 3

IP de origem * * *

IP de destino * * *

Protocolo * * TCP

Porta de origem * * *

Porta de destino * * 80

Direção Em Saída Saída

Ação Negar Negar Allow

Com estado No No Sim

Tempo limite (em segundos) N/D N/D 3600

A regra de monitoração de estado permite que o servidor de aplicativos da VM

conecte-se a um servidor remoto da Web. Quando o primeiro pacote é enviado, o
comutador virtual do Hyper-V cria dinamicamente dois estados de fluxo, a fim de
permitir que todos os pacotes sejam enviados para e todos os pacotes de retorno sejam
enviados do servidor remoto da Web. Quando o fluxo de pacotes entre os servidores
para, o fluxo estabelece o tempo limite no valor de tempo limite de 3.600 segundos ou
uma hora.

Apresentamos a seguir um exemplo de como criar essas regras com os comandos do

Windows PowerShell.

Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -

Direction "Inbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -
Direction "Outbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Allow"
-Direction "Outbound" 80 "TCP" -Weight 100 -Stateful -Timeout 3600