Desempenho de E/S de armazenamento do Hyper-V

Artigo
12/29/2023

Este artigo explora diferentes opções e considerações para ajustar o desempenho de E/S (entrada/saída) do armazenamento em uma VM (máquina virtual). O caminho de E/S do armazenamento se estende por quatro estágios sucessivos:

Pilha de armazenamento do convidado
Camada de virtualização do host
Pilha de armazenamento do host
Disco físico

As seções a seguir descrevem as otimizações possíveis para cada estágio.

Controladores virtuais

O Hyper-V oferece três tipos de controladores virtuais:

IDE (Integrated Drive Electronics)
SCSI (Small Computer System Interface)
HBAs (Adaptador de barramento do host) Fibre Channel Virtual

IDE

Recomendamos que você use apenas discos IDE para discos do SO. Os discos do SO têm limitações de desempenho com base no tamanho máximo de E/S para seus dispositivos.

Os controladores IDE são controladores emulados que expõem discos IDE para a VM. Esse tipo de controlador é a única opção para VMs convidadas que executem versões anteriores do Windows sem os serviços de integração de VM do Hyper-V. O driver de filtro IDE fornecido pelos serviços de integração pode executar E/S de disco melhor do que o controlador IDE emulado.

SCSI (controlador SAS)

Os controladores SCSI virtuais expõem os discos SCSI para a VM. Cada controlador SCSI é compatível com até 64 dispositivos. O caminho do SCSI não é emulado, o que o torna o controlador preferencial para qualquer disco diferente do disco do SO. O Windows Server 2012 R2 e versões posteriores oferecem suporte a controladores SCSI, mas somente em cenários nos quais você relate o controlador como SAS (Serial Attached SCSI) para oferecer suporte a um VHDX (disco rígido virtual) compartilhado.

Para o melhor desempenho, recomendamos anexar vários discos a um só controlador SCSI virtual. Você só deve criar mais controladores se não tiver outras opções para dimensionar quantos discos estão conectados à VM.

HBAs de Fibre Channel Virtual

Configure os HBAs do Fibre Channel Virtual para permitir que as VMs tenham acesso direto aos LUNs (números de unidade lógica) do Fibre Channel e do FCoE (Fibre Channel over Ethernet). Os discos de Fibre Channel Virtual ignoram o sistema de arquivos NTFS na partição raiz, o que reduz o uso da CPU (unidade de processamento central) de E/S do armazenamento. Os discos de Fibre Channel Virtual são ótimos para unidades de dados grandes e normais compartilhadas entre várias VMs em cenários de clustering de convidados.

Para usar os discos de Fibre Channel Virtual, você precisa instalar um ou mais HBAs do Fibre Channel no computador host. Cada HBA do host precisa usar drivers de HBA compatíveis com as capacidades de Fibre Channel Virtual ou NPIV (Virtualização de ID de N_Port) do Windows Server 2016. A malha de SAN (Rede de área de armazenamento) também deve ser compatível com NPIV, e você deve configurar as portas HBA para Fibre Channel com uma topologia de Fibre Channel que seja compatível com NPIV.

Para maximizar a taxa de transferência em hosts com mais de um HBA, recomendamos configurar vários HBAs virtuais dentro da VM do Hyper-V. É possível configurar até quatro HBAs para cada VM. O Hyper-V equilibra automaticamente HBAs virtuais para hospedar HBAs que acessem a mesma SAN virtual.

Discos virtuais

Os discos virtuais são expostos às VMs por controladores virtuais e podem ser discos rígidos virtuais ou discos de passagem no host.

Os discos virtuais estão nos formatos VHD ou VHDX. Cada formato dá suporte a três tipos de arquivos do disco rígido virtual.

Se você atualizar sua implantação para o Windows Server 2016 ou posterior, recomendamos converter todos os arquivos VHD para o formato VHDX. Saiba mais em Formatar VHDX.

Formato VHD

As versões mais recentes do Hyper-V incluem melhorias para o formato VHD a fim de permitir um melhor alinhamento. O Hyper-V no Windows Server 2012 e posterior oferece suporte aos formatos VHDX e VHD, ao contrário das versões anteriores, que oferecem suporte apenas ao formato VHD. Como resultado, as versões posteriores do Hyper-V têm melhor desempenho em discos com setores grandes.

Qualquer VHD criado no Windows Server 2012 ou posterior terá o alinhamento ideal de 4 KB. Esse formato alinhado é totalmente compatível com as versões anteriores do Windows Server. No entanto, a propriedade de alinhamento não é compatível com novas alocações de analisadores sem reconhecimento de alinhamento de 4 KB, como um analisador de uma versão anterior do Windows Server ou um analisador não pertencente à Microsoft.

Converter o disco para o formato VHD

Quando você migra um VHD de uma versão anterior do Hyper-V ou do Windows Server para uma versão mais recente, o sistema não converte automaticamente o disco para o formato VHD.

Você pode converter um disco virtual existente em VHD abrindo uma janela do PowerShell e executando o seguinte comando:

Convert-VHD –Path <SourceDiskFilePath> –DestinationPath <ConvertedDiskFilePath>

Por exemplo, se você quiser converter um disco de origem com o nome test.vhd na unidade E para um disco convertido renomeado com o nome test-converted.vhd na mesma pasta, execute este comando:

Convert-VHD –Path E:\vms\testvhd\test.vhd –DestinationPath E:\vms\testvhd\test-converted.vhd

Observação

Ao converter um VHD, o PowerShell usa os dados do VHD de origem com base na opção de disco Copiar da origem. Saiba mais em Converter VHD.

Verificar o alinhamento do disco

Depois de converter um disco, você pode executar o comando Get-VHD no PowerShell para verificar se a variável Alinhamento está usando o alinhamento ideal de 4 KB. Execute o comando para o disco de origem e o disco convertido e, em seguida, compare os valores para garantir que o disco convertido tenha 4 KB de reconhecimento de alinhamento.

Para exibir o alinhamento dos discos:

Abra uma janela do PowerShell.
Execute o comando Get-VHD para exibir a configuração de alinhamento do disco de origem.
```
Get-VHD –Path <SourceVHDFilePath>
```

Na saída, observe o valor da propriedade Alignment. Neste exemplo, o valor é 0, o que significa que o disco não reconhece o alinhamento de 4 KB.

Path                    : <SourceVHDFilePath>
VhdFormat               : VHD
VhdType                 : Dynamic
FileSize                : 69245440
Size                    : 10737418240
MinimumSize             : 10735321088
LogicalSectorSize       : 512
PhysicalSectorSize      : 512
BlockSize               : 2097152
ParentPath              :
FragmentationPercentage : 10
Alignment               : 0
Attached                : False
DiskNumber              :
IsDeleted               : False
Number                  :

Execute o comando Get-VHD novamente, mas desta vez use o caminho do arquivo para o disco convertido.
```
Get-VHD –Path <ConvertedDiskFilePath>
```

Na saída, confira o valor da propriedade Alignment. O valor deve ser 1, o que significa que o disco foi convertido com êxito no formato VHD mais recente e reconhece o alinhamento de 4 KB.

Path                    : <ConvertedDiskFilePath>
VhdFormat               : VHD
VhdType                 : Dynamic
FileSize                : 69369856
Size                    : 10737418240
MinimumSize             : 10735321088
LogicalSectorSize       : 512
PhysicalSectorSize      : 512
BlockSize               : 2097152
ParentPath              :
FragmentationPercentage : 0
Alignment               : 1
Attached                : False
DiskNumber              :
IsDeleted               : False
Number                  :

Formato VHDX

O VHDX é um formato atualizado de disco rígido virtual introduzido no Windows Server 2012. Esse formato pode criar discos virtuais resilientes e de alto desempenho com capacidade de até 64 terabytes.

Se atualizar sua implantação para o Windows Server 2016 ou posterior, recomendamos converter todos os arquivos VHD para o formato VHDX. Só mantenha arquivos no formato VHD se precisar mover a VM para uma versão anterior do Hyper-V que não dê suporte ao formato VHDX.

Aqui estão alguns benefícios do formato VHDX:

Suporte à capacidade de armazenamento do disco rígido virtual de até 64 terabytes
Proteção contra dados corrompidos durante falhas de energia, registrando alterações nas estruturas de metadados do VHDX
Armazena metadados personalizados para um arquivo com base no que o usuário responsável pela configuração deseja gravar, como a versão do SO ou patches aplicados

O formato VHDX também oferece vários recursos de desempenho:

Aprimoramento do alinhamento de formato de disco rígido virtual, melhorando o desempenho em discos com setores grandes
Blocos com tamanhos maiores para discos dinâmicos e diferenciais, permitindo ajustes de discos para requisitos de carga de trabalho
Um disco virtual de setor lógico com 4 KB para dar suporte a um desempenho superior quando usado por aplicativos e cargas de trabalho projetados para setores de 4 KB
Eficiência na representação de dados a fim de produzir arquivos de menor tamanho e permitir que o dispositivo de armazenamento físico subjacente recupere o espaço não usado

Observação

O corte requer discos de passagem ou SCSI, bem como hardware compatível com corte.

Arquivos virtuais

Há três tipos de arquivos VHD:

Os arquivos fixos servem para melhorar a resiliência e o desempenho, e você deve usá-los quando o armazenamento no valor de hospedagem não for monitorado ativamente. Verifique se há espaço em disco suficiente ao expandir o arquivo VHD em runtime. Você pode usá-los em qualquer formato de disco.
Os arquivos dinâmicos servem para garantir resiliência e alocar espaço em disco de acordo com a necessidade da implantação. Só é possível usá-los no formato VHDX.
Os arquivos de diferenciação mantêm as cadeias de instantâneo de VM curtas a fim de sustentar um bom desempenho de E/S no disco. Você pode usá-los em qualquer formato de disco.

Tipo de arquivo fixo

Quando você cria um arquivo VHD fixo, o sistema aloca espaço para ele. Os arquivos fixos têm menos probabilidade de se fragmentar, reduzindo a taxa de transferência de E/S quando uma única E/S se dividir em várias. Essa opção também tem a menor sobrecarga de CPU entre as três opções de arquivo porque as operações de leitura e gravação não precisam pesquisar o mapeamento do bloco.

Recomendamos que você use o tipo de arquivo fixo quando precisar de resiliência e desempenho ideais.

Tipo de arquivo dinâmico

Quando você cria um arquivo VHD dinâmico, o sistema aloca espaço para ele sob demanda. Os blocos no arquivo começam como blocos alocados e nenhum espaço no arquivo sustenta os blocos não alocados. Quando um bloco recebe a primeira gravação, a pilha de virtualização deve alocar espaço para o bloco no arquivo VHD e, em seguida, atualizar os metadados. Essa alocação aumenta o número de E/S de disco necessárias para a gravação, aumentando o uso da CPU. Leituras e gravações em blocos existentes incorrem em acesso ao disco e sobrecarga da CPU ao procurar o mapeamento dos blocos nos metadados.

Se você estiver usando um arquivo VHDX, recomendamos que use o tipo de arquivo dinâmico quando não estiver monitorando ativamente o armazenamento no volume de hospedagem. Verifique se há espaço em disco suficiente ao expandir o arquivo VHD em runtime.

Tipo de arquivo diferencial

Os arquivos de diferenciação são instantâneos de uma VM que armazenam gravações nos discos. Se você gravar em um bloco sem gravações existentes, o sistema alocará espaço no arquivo VHD assim como um VHD em expansão dinâmica. O sistema atende a operações de leitura do arquivo VHD se o bloco já contiver gravações. Caso contrário, ele atenderá a blocos do arquivo VHD pai. Em ambos os casos, o sistema lê metadados para determinar o mapeamento do bloco. As leituras e gravações nesse VHD podem consumir mais CPU e resultar em mais E/S do que um arquivo VHD fixo.

Quando houver apenas alguns instantâneos, o E/S de armazenamento pode usar mais CPU do que o normal, mas sem afetar visivelmente o desempenho, exceto em cargas de trabalho de servidor com uso altamente intenso de E/S. Criar e usar uma cadeia grande de instantâneos de VM causa problemas de desempenho. Em arquivos de diferenciação, o sistema precisa verificar os blocos solicitados em muitos VHDs de diferenciação distintos apenas para ler o VHD. Se você usar arquivos de diferenciação, recomendamos que mantenha as cadeias de instantâneo curtas para manter um bom desempenho de E/S de disco.

Considerações de tamanhos

Ao planejar a otimização de disco, você deve considerar o tamanho do bloco e o tamanho do setor. Esta seção descreve recomendações para dimensionar blocos e setores.

Tamanho do bloco

Como o tamanho do bloco pode afetar significativamente o desempenho, recomendamos que você faça a correspondência entre o tamanho do bloco e os padrões de alocação das cargas de trabalho que usam o disco. Se um aplicativo alocar blocos em partes de 16 MB, o ideal será usar um tamanho de bloco VHD de 16 MB. Tamanhos de bloco superiores a 2 MB só são possíveis em VHDs usando o formato de arquivo VHDX. Quando o tamanho do bloco é maior que o padrão de alocação de uma carga de trabalho de E/S aleatória, ele aumenta a quantidade de espaço que o VHD usa no host.

Tamanho do setor

As organizações de software geralmente dependem de setores de disco de 512 bytes, mas o padrão do setor está mudando para setores de disco de 4 KB. Para reduzir problemas de compatibilidade que podem surgir de uma mudança no tamanho do setor, os fornecedores de disco rígido estão introduzindo um tamanho de transição chamado de 512 unidades de emulação (512e).

As unidades de emulação oferecem algumas das vantagens proporcionadas pelas unidades nativas do setor do disco de 4 KB, como a melhora da eficiência de formato e um esquema aprimorado de ECC (códigos de correção de erro). As unidades de emulação apresentam menos problemas de compatibilidade ao expor um tamanho de setor de 4 KB na interface do disco.

Para fazer uso total dos setores de 4 KB, recomendamos usar o formato VHDX em vez de setores de disco de 512 bytes. Para reduzir problemas de compatibilidade entre tamanhos de disco, implemente unidades 512e para dimensionamento transitório.

Suporte para tamanho transitório com discos 512e

Um disco 512e só pode executar uma operação de gravação em termos de setor físico. Esse tipo de disco não pode gravar diretamente um setor de 512 bytes no sistema para o qual ele publica. O disco tem um processo interno que possibilita operações de gravação, envolvendo operações de RMW (Read-Modify-Write, leitura-modificação-gravação) na seguinte ordem:

Primeiro, o disco lê o setor físico de 4 KB no cache interno dele. O cache contém o setor lógico de 512 bytes mencionado na operação de gravação.
Em seguida, o disco modifica os dados no buffer de 4 KB para incluir o setor de 512 bytes atualizado.
Por fim, o disco grava o buffer de 4 KB atualizado de volta no setor físico dele no disco.

O efeito geral do processo RMW sobre o desempenho depende da carga de trabalho. O processo RMW pode causar degradação do desempenho em discos rígidos virtuais devido aos seguintes motivos:

Os VHDs dinâmicos e diferenciais têm um bitmap de setor de 512 bytes na frente de sua carga de dados. Os localizadores de rodapé, cabeçalho e pai se alinham a um setor de 512 bytes. É comum que o driver de disco rígido virtual execute operações de gravação de 512 bytes para atualizar essas estruturas, fazendo com que o disco execute o processo RMW.
Em geral, os aplicativos executam operações de leitura e gravação em múltiplos de 4 KB, pois esse é o tamanho padrão do cluster de NTFS. Os discos rígidos virtuais dinâmicos e diferenciais têm um bitmap de setor de 512 bytes na frente do bloco de payload de dados. Esse bitmap faz com que os blocos de 4 KB não se alinhem ao limite físico de 4 KB. O diagrama a seguir mostra em destaque um bloco VHD de 4 KB que não está alinhado com o limite físico de 4 KB.

Cada operação de gravação de 4 KB executada pelo analisador atual para atualizar os dados de payload resulta em duas leituras para dois blocos no disco. Em seguida, o sistema atualiza e grava os blocos de volta nos dois blocos de disco. O Hyper-V em Windows Server 2016 atenua alguns efeitos de desempenho em discos 512e na pilha VHD. O Hyper-V prepara as estruturas para alinhamento aos limites de 4 KB no formato VHD. A mitigação evita o efeito RMW ao acessar os dados no arquivo de disco rígido virtual e atualiza para as estruturas de metadados de disco rígido virtual.

Conforme mencionado anteriormente, os VHDs copiados das versões anteriores do Windows Server não são alinhados automaticamente a 4 KB. Você pode converter manualmente o disco para alinhar de modo ideal usando a opção de disco Copiar da origem com o comando Convert-VHD.

Por padrão, os VHDs são expostos com um tamanho de setor físico de 512 bytes. Esse método garante que os aplicativos dependentes de tamanho do setor físico não sejam afetados quando você migrar o aplicativo e os VHDs de uma versão anterior do Windows Server.

Por padrão, o sistema cria discos VHDX com um tamanho de 4 KB do setor físico para otimizar o perfil de desempenho deles em discos regulares e em discos de setores maiores.

Para reduzir problemas de compatibilidade entre tamanhos de disco, implemente unidades 512e para dimensionamento transitório. Para fazer uso completo de setores de 4 KB, use o formato VHDX.

Discos de 4 KB nativos

O Hyper-V no Windows Server 2012 R2 e versões posteriores dá suporte a discos de 4 KB nativos. Você também pode armazenar dados de disco VHD em um disco de 4 KB nativo implementando um algoritmo RMW de software na camada da pilha de armazenamento virtual. O algoritmo converte solicitações de acesso e atualização de 512 bytes para acessos e atualizações correspondentes de 4 KB.

Como o arquivo VHD só pode se expor como discos de tamanho do setor lógico de 512 bytes, é provável que haja aplicativos que emitem solicitações de E/S de 512 bytes. Nesses casos, o algoritmo RMW na camada da pilha de armazenamento atende às solicitações e causa degradação do desempenho. O mesmo resultado ocorre para discos VHDX com um tamanho de setor lógico de 512 bytes.

É possível configurar arquivos VHDX para expor como um disco de tamanho do setor lógico de 4 KB. Essa implementação é uma configuração ideal para o desempenho de discos hospedados em um dispositivo físico nativo de 4 KB. No entanto, garanta que o tamanho do setor lógico de 4 KB dê suporte ao convidado e ao aplicativo que usam o disco virtual. O formato VHDX funciona corretamente em um dispositivo com setor lógico de tamanho 4 KB.

Recomendamos que você evite usar discos nativos de 4 KB com arquivos VHD e VHDX, pois isso pode causar degradação do desempenho. Quando o cenário exigir discos nativos de 4 KB, você deverá usar o formato VHDX em um dispositivo com tamanho de 4 KB para o setor lógico.

Discos de passagem

Recomendamos evitar o uso de discos de passagem devido às limitações que eles apresentam em cenários de migração de VM.

O mapeamento de um VHD em uma VM diretamente para um disco físico ou LUN (número de unidade lógica) em vez de um arquivo VHD é chamado de disco de passagem. Os discos de passagem permitem ignorar o sistema de arquivos NTFS na partição raiz, o que reduz o uso de CPU da E/S de armazenamento. No entanto, o uso de discos de passagem também envolve o risco de discos físicos ou LUNs se tornarem mais difíceis de migrar entre máquinas do que os arquivos VHD.

Recursos avançados de armazenamento

Esta seção discute mais algumas otimizações de desempenho que você deve considerar para recursos avançados de armazenamento.

QoS (qualidade de serviço) de armazenamento

No Windows Server 2012 R2 e versões posteriores, o Hyper-V inclui a capacidade de definir certos parâmetros de QoS (Qualidade de Serviço) para armazenamento nas VMs. Recomendamos implementar a QoS de armazenamento para acessar parâmetros de armazenamento adicionais, definir limites máximo e mínimo de IOPS para discos rígidos virtuais e monitorar o desempenho deles. Você pode implementar esses parâmetros a fim de obter os seguintes benefícios:

Configurar o isolamento do desempenho de armazenamento em um ambiente multilocatário
Especificar as operações de IOPS (entrada/saída máximas e mínimas por segundo) para discos rígidos virtuais
- Os administradores podem limitar a E/S de armazenamento a fim de impedir que um locatário consuma recursos de armazenamento excessivos, que possam afetar outros locatários. Defina o valor mínimo de IOPS e receba notificações quando o sistema não satisfizer o limite de desempenho ideal. Especificamos os valores máximo ou mínimo de IOPS em termos de IOPS normalizado, nos quais cada 8 KB de dados é contabilizado como uma E/S.
Receber notificações quando o desempenho de E/S de armazenamento estiver abaixo dos limites definidos para executar cargas de trabalho de VM com eficiência
Acessar parâmetros de armazenamento para infraestrutura de métricas de VM e permitir que os administradores monitorem parâmetros relacionados ao desempenho e ao estorno

No entanto, lembre-se também de que a QoS de armazenamento tem as seguintes limitações:

Disponível apenas para discos virtuais
O disco diferencial não pode ter um disco virtual pai em um volume diferente
QoS para o site de réplica configurado separadamente do site primário
A QoS de armazenamento não oferece suporte a VHDX compartilhado

Para obter mais informações, confira Qualidade de serviço de armazenamento para Hyper-V.

Configurações do Registro de E/S NUMA para VMs grandes

O Windows Server 2012 e versões posteriores dá suporte à projeção de uma topologia virtual NUMA (acesso à memória não uniforme) em VMs do Hyper-V. O suporte à NUMA melhora o desempenho das cargas de trabalho executadas em VMs com grandes quantidades de memória, também conhecidas como VMs grandes. Para habilitar esse suporte, grandes configurações de VM exigem escalabilidade em termos de taxa de transferência de E/S. Um exemplo de VM grande é o Microsoft SQL Server em execução com 64 processadores virtuais.

Os seguintes aprimoramentos do Windows Server atendem aos requisitos de escalabilidade de E/S de VMs grandes:

Criar mais canais de comunicação entre os dispositivos convidados e a pilha de armazenamento do host.
Um mecanismo de conclusão de E/S mais eficiente envolvendo a distribuição de interrupção entre os processadores virtuais para evitar interrupções caras do interprocessador.

Chaves do Registro

Recomendamos usar as configurações de chave de registro NUMA do Windows Server para aprimorar o desempenho das cargas de trabalho executadas em VMs grandes.

Adicionamos e atualizamos algumas entradas do registro para oferecer suporte aos aprimoramentos na seção anterior e permitir que você ajuste o número de canais. As entradas estão disponíveis em HKLM\System\CurrentControlSet\Enum\VMBUS\<device id>\<instance id>\StorChannel.

A parte <device id>\<instance id>\ do caminho corresponde aos valores relevantes em sua configuração. Essas entradas de registro alinham os processadores virtuais que gerenciam as conclusões de E/S para as CPUs virtuais que o aplicativo atribuiu para como os processadores de E/S. O sistema define as configurações do registro por adaptador na chave de hardware do dispositivo.

Aqui estão duas configurações principais a serem consideradas:

ChannelCount (DWORD) é o número total de canais de comunicação que sua implantação pode usar. O valor máximo é 16. A contagem de canais usa como padrão um valor igual ao número de processadores virtuais dividido por 16.
ChannelMask (QWORD) é a afinidade do processador para os canais. Se você não especificar essa configuração principal ou se definir o valor como 0, a máscara de canal usará como padrão o algoritmo de distribuição de canal existente para canais de rede ou armazenamento normal. A ação padrão garante que seus canais de armazenamento não entrem em conflito com os canais de rede.

Integração de transferência de dados descarregados

Recomendamos que você use operações ODX (Offloaded Data Transfer, transferência de dados descarregados) para garantir que a carga de trabalho da VM possa usar o armazenamento habilitado para ODX da maneira possível em um ambiente físico.

Tarefas cruciais de manutenção para VHDs, como mesclagem, movimentação e compactação, envolvem a cópia de grandes quantidades de dados. O método atual de copiar dados requer que o sistema leia e grave dados em locais diferentes, o que é demorado e usa recursos de CPU e memória que poderiam ser usados na manutenção de VMs.

Os fornecedores de SAN (Storage Area Network, rede de área de armazenamento) podem fornecer um recurso de hardware chamado ODX. Esse recurso fornece operações de cópia quase instantâneas para grandes quantidades de dados. O ODX permite que o sistema, não os discos, especifique como mover conjuntos de dados específicos de um local para outro.

O Hyper-V no Windows Server 2012 e versões posteriores dá suporte a operações de ODX para repassar dados copiados do SO convidado para o hardware host. A carga de trabalho pode usar o armazenamento habilitado para ODX da mesma forma que faria em um ambiente não virtualizado. A pilha de armazenamento Hyper-V também pode emitir operações de ODX durante as operações de manutenção de VHDs, como a mesclagem de discos e metaoperações de migração de armazenamento durante grandes quantidades de dados.

Integração de notificações unmap

Recomendamos usar notificações de desmapear para tornar os arquivos VHDX mais eficientes e permitir que o dispositivo de armazenamento físico subjacente recupere espaço não utilizado.

Os arquivos VHD existem em um volume de armazenamento no qual compartilham espaço disponível com outros arquivos. Como seu tamanho de arquivo tende a ser grande, os arquivos VHD podem ocupar muito espaço. A maior demanda por espaço de armazenamento afeta os orçamentos de hardware de TI, o que significa que você deve otimizar o uso do espaço físico sempre que possível.

Em versões do Windows Server anteriores ao Windows Server 2012, a pilha de armazenamento do Windows no sistema operacional convidado e no host Hyper-V tinha limitações que os impediam de otimizar o espaço de armazenamento. Quando os aplicativos excluíam conteúdo em um VHD, o espaço de armazenamento permanecia abandonado. O sistema não notifica o VHD ou o dispositivo de armazenamento físico sobre as informações excluídas, o que impediu a pilha de armazenamento do Hyper-V de otimizar o espaço para os arquivos de disco virtual baseados em VHD. Como resultado, o dispositivo de armazenamento subjacente não conseguiu recuperar o espaço agora não utilizado que os dados excluídos ocupavam.

Desde o Windows Server 2012, o Hyper-V dá suporte a notificações de desmapear. Esse recurso permite que os arquivos VHDX relatem dados excluídos para a pilha de armazenamento, o que maximiza a eficiência, mantendo os tamanhos de arquivo organizados e permitindo que a pilha recupere o espaço de armazenamento não utilizado para outras finalidades.

Somente SCSI específicos do Hyper-V, IDE habilitado e controladores de Fibre Channel Virtual permitem que o comando unmap do SO convidado alcance a pilha de armazenamento virtual do host. Em VHDs, somente discos virtuais formatados como VHDX dão suporte a comandos unmap executados por meio do SO convidado.