Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo explora diferentes opções e considerações para ajustar o desempenho de entrada/saída (E/S) de armazenamento em uma máquina virtual (VM). O caminho de E/S de armazenamento se estende por quatro estágios sucessivos:
- Pilha de armazenamento hóspede
- Camada de virtualização de 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:
Eletrônica de acionamento integrada (IDE)
Interface de sistema de computador pequeno (SCSI)
Adaptadores de barramento de host Fibre Channel virtuais
IDE
Recomendamos que você use apenas discos IDE para discos do sistema operacional. Os discos do SO têm limitações de desempenho com base no tamanho máximo de E/S dos seus dispositivos.
Os controladores IDE são controladores emulados que expõem discos IDE à VM. Este tipo de controlador é a única opção para VMs convidadas a correr versões anteriores de Windows sem serviços de integração de VMs Hyper-V. O driver de filtro IDE que os serviços de integração fornecem pode executar E/S de disco melhor do que o controlador IDE emulado.
SCSI (controlador SAS)
Os controladores SCSI virtuais expõem discos SCSI à VM. Cada controlador SCSI suporta até 64 dispositivos. O caminho SCSI não é emulado, o que o torna o controlador preferido para qualquer disco que não seja o disco do sistema operacional. O Windows Server 2012 R2 e posteriores suportam controladores SCSI, mas apenas em cenários em que se reporta o controlador como um Serial Attached SCSI (SAS) para suportar um disco rígido virtual partilhado (VHDX).
Para obter o melhor desempenho, recomendamos que você anexe vários discos a um único 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 Fibre Channel Virtuais
Configure HBAs Fibre Channel virtuais para permitir que as VMs acessem diretamente os LUNs (números de unidade lógica) Fibre Channel e Fibre Channel over Ethernet (FCoE). Os discos Fibre Channel virtuais ignoram o sistema de arquivos NTFS na partição raiz, o que reduz o uso da CPU (unidade central de processamento) de E/S de armazenamento. Os discos Fibre Channel virtuais são ótimos para unidades de dados grandes e unidades compartilhadas entre várias VMs em cenários de cluster convidado.
Para usar discos Fibre Channel virtuais, você deve instalar um ou mais HBAs Fibre Channel na máquina host. Cada HBA anfitrião deve utilizar drivers HBA que suportem Windows Server 2016 capacidades de Virtual Fibre Channel ou N_Port ID Virtualization (NPIV). A malha SAN (Storage Area Network, rede de armazenamento de dados) também deve oferecer suporte a NPIV e você deve configurar as portas HBA para o Fibre Channel em uma topologia de Fiber Channel que ofereça suporte a NPIV.
Para maximizar o rendimento em hosts com mais do que um HBA, recomendamos que configure muitos HBAs virtuais dentro da VM Hyper-V. Você pode configurar até quatro HBAs para cada VM. O Hyper-V equilibra automaticamente HBAs virtuais para HBAs anfitriões que acedem à 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 vêm nos formatos VHD ou VHDX. Cada formato suporta três tipos de ficheiros de disco rígido virtual.
Se atualizar a sua implementação para Windows Server 2016 ou versão posterior, recomendamos que converta todos os ficheiros VHD para formato VHDX. Para obter mais informações, consulte Formato VHDX.
Formato VHD
Versões posteriores do Hyper-V incluem melhorias no seu formato VHD que permitem um melhor alinhamento. O Hyper-V no Windows Server 2012 e posteriores suporta tanto os formatos VHDX como VHD, ao contrário das versões anteriores que apenas suportam formato VHD. Como resultado, versões posteriores do Hyper-V têm melhor desempenho em discos de grande setor.
Qualquer VHD que crie no Windows Server 2012 ou versões posteriores tem o alinhamento ótimo de 4 KB. Este formato alinhado é totalmente compatível com versões anteriores do Windows Server. No entanto, a propriedade de alinhamento não suporta novas alocações de parsers que não estejam configurados para o alinhamento de 4 KB, como um parser de uma versão anterior do Windows Server ou um parser de outra empresa que não seja a Microsoft.
Converter disco para formato VHD
Quando migra um VHD de uma versão anterior do Hyper-V ou Windows Server para uma posterior, o sistema não converte automaticamente o disco para 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 planeavas converter um disco de origem chamado test.vhd na unidade E para um disco convertido e renomeado chamado test-converted.vhd na mesma pasta, executarias este comando:
Convert-VHD –Path E:\vms\testvhd\test.vhd –DestinationPath E:\vms\testvhd\test-converted.vhd
Note
Quando você converte um VHD, o PowerShell usa os dados do VHD de origem com base na opção Copiar do disco de origem . Para obter mais informações, consulte Convert-VHD.
Verificar o alinhamento do disco
Depois de converter um disco, você pode verificar sua variável Alignment para certificar-se de que está usando o alinhamento ideal de 4 KB executando o Get-VHD comando no PowerShell. Certifique-se de executar o comando para o disco de origem e o disco convertido e, em seguida, compare os valores para certificar-se de que o disco convertido reconhece alinhamento de 4 KB.
Para ver o alinhamento dos seus discos:
Abra uma janela do PowerShell.
Execute o
Get-VHDcomando para exibir a configuração de alinhamento para o disco de origem.Get-VHD –Path <SourceVHDFilePath>Na saída, observe o valor da
Alignmentpropriedade. Neste exemplo, o valor é0, o que significa que o disco não reconhece 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
Get-VHDcomando novamente, mas desta vez use o caminho do arquivo para o disco convertido.Get-VHD –Path <ConvertedDiskFilePath>Na saída, verifique o valor da
Alignmentpropriedade. O valor deve ser1, o que significa que o disco é convertido com êxito para o formato VHD mais recente e reconhece 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
VHDX é um formato atualizado de disco rígido introduzido no Windows Server 2012. Esse formato pode criar discos virtuais resilientes e de alto desempenho com até 64 terabytes de capacidade.
Se estiver a atualizar para o Windows Server 2016 ou mais recente, recomendamos que converta todos os ficheiros VHD para formato VHDX. Só guarda os ficheiros em formato VHD se precisares de mover a VM para uma versão anterior do Hyper-V que não suporte formato VHDX.
Aqui estão alguns benefícios do formato VHDX:
Suporte para capacidade de armazenamento em disco rígido virtual de até 64 terabytes
Proteção contra corrupção de dados durante falhas de energia registrando atualizações nas estruturas de metadados VHDX
Armazena metadados personalizados para um arquivo com base no que o usuário que o configura deseja gravar, como a versão do sistema operacional ou patches aplicados
O formato VHDX também oferece vários recursos de desempenho:
Melhor alinhamento do formato de disco rígido virtual, melhorando o desempenho em discos de setor grande
Tamanhos de bloco maiores para discos dinâmicos e diferenciais, que permitem que os discos se ajustem aos requisitos de carga de trabalho
Um disco virtual de setor lógico de 4 KB para suportar maior desempenho quando usado por aplicativos e cargas de trabalho projetados para setores de 4 KB
Eficiência na representação de dados para produzir tamanhos de arquivo menores e permitir que o dispositivo de armazenamento físico subjacente recupere espaço não utilizado
Note
O corte requer discos de passagem ou SCSI, e hardware compatível com o trim.
Arquivos virtuais
Existem três tipos de ficheiros VHD:
Os arquivos fixos são para melhorar a resiliência e o desempenho, e você deve usá-los quando o armazenamento no valor de hospedagem não é monitorado ativamente. Verifique se há espaço em disco suficiente ao expandir o arquivo VHD em tempo de execução. Você pode usá-los em qualquer formato de disco.
Os arquivos dinâmicos são para garantias de resiliência e alocação de espaço em disco conforme a implantação precisa. Você só pode usá-los em VHDX.
Os ficheiros diferenciais mantêm as cadeias de capturas instantâneas da VM curtas para manter um bom desempenho de E/S de disco. Você pode usá-los em qualquer formato de disco.
Tipo de ficheiro fixo
Quando você cria um arquivo VHD fixo, o sistema aloca espaço para ele. Os arquivos fixos têm menos probabilidade de fragmentação, reduzindo a taxa de transferência de E/S quando uma única E/S se divide em várias. Ele também tem a menor sobrecarga de CPU entre as três opções de arquivo, pois as operações de leitura e gravação não precisam consultar o mapeamento dos blocos.
Recomendamos que você use o tipo de arquivo fixo quando precisar de resiliência e desempenho ideais.
Tipo de ficheiro 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 apoia os blocos não alocados. Quando um bloco recebe sua 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. Lê e grava em blocos existentes, incorre em acesso ao disco e sobrecarga de CPU ao procurar o mapeamento dos blocos nos metadados.
Se estiveres a usar um ficheiro VHDX, usa o tipo de ficheiro dinâmico quando monitorizares ativamente o armazenamento no volume de alojamento. Verifique se você tem espaço em disco suficiente ao expandir o arquivo VHD em tempo de execução.
Tipo de ficheiro diferencial
Os ficheiros diferenciais são instantâneos de uma máquina virtual que armazenam as alterações nos discos. Se você gravar em um bloco sem gravações existentes, o sistema alocará espaço no arquivo VHD como um VHD em expansão dinâmica. Os serviços do sistema leem operações de leitura do ficheiro VHD se o bloco já tiver gravações. Caso contrário, ele processa blocos do ficheiro VHD pai. Em ambos os casos, o sistema lê metadados para determinar o mapeamento de blocos. As leituras e gravações neste VHD podem consumir mais CPU e resultar em mais E/S do que um arquivo VHD fixo.
Quando há apenas alguns snapshots, as E/S de armazenamento podem potencialmente usar mais CPU do que o normal, mas isso não afeta visivelmente o desempenho, exceto em cargas de trabalho de servidor altamente intensivas em E/S. Criar e usar uma grande cadeia de instantâneos de VM pode causar problemas de desempenho. Em arquivos de diferenciação, o sistema precisa verificar os blocos solicitados em muitos VHDs diferenciais diferentes apenas para ler a partir do VHD. Se você usa arquivos diferenciais, recomendamos manter as cadeias de snapshot curtas para manter um bom desempenho de E/S de disco.
Considerações sobre tamanho
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 aloca blocos em blocos de 16 MB, o ideal é usar um tamanho de bloco VHD de 16 MB. Tamanhos de bloco maiores que 2 MB só são possíveis em VHDs usando o formato de arquivo VHDX. Quando o tamanho do bloco é maior do que o padrão de alocação para uma carga de trabalho de E/S aleatória, isso aumenta a quantidade de espaço que o VHD usa no host.
Dimensão do setor
As organizações de software frequentemente 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 os problemas de compatibilidade que podem surgir de mudanças no tamanho do setor, os fornecedores de discos rígidos estão introduzindo um tamanho de transição conhecido como unidades de emulação 512 (512e).
As unidades de emulação oferecem algumas das vantagens fornecidas pelas unidades nativas do setor de disco de 4 KB, como eficiência de formato aprimorada e um esquema aprimorado para códigos de correção de erros (ECC). 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 pleno uso de setores de 4 KB, recomendamos que você use o formato VHDX em vez de setores de disco de 512 bytes. Para reduzir os problemas de compatibilidade entre tamanhos de disco, implemente drives 512e para dimensionamento de transição.
Suporte a tamanho transitório em discos 512e
Um disco 512e pode executar uma operação de gravação somente em termos de um setor físico. Esse tipo de disco não consegue gravar diretamente um setor de 512 bytes a que o sistema o direciona. O disco tem um processo interno que possibilita operações de gravação, que envolve operações de Leitura-Modificação-Gravação (RMW) na seguinte ordem:
Primeiro, o disco lê o setor físico de 4 KB para a sua cache interna. 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.
Finalmente, o disco grava o buffer de 4 KB atualizado de volta ao seu setor físico no disco.
O efeito geral que o processo RMW tem no desempenho depende da carga de trabalho. O processo RMW pode causar degradação de desempenho em discos rígidos virtuais pelos seguintes motivos:
VHDs dinâmicos e diferenciais têm um bitmap de setor de 512 bytes na frente de sua carga útil de dados. Os localizadores de rodapé, cabeçalho e pai alinham-se 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, o que faz com que o disco execute o processo RMW.
Os aplicativos geralmente executam operações de leitura e gravação em múltiplos de tamanhos de 4 KB, já que 4 KB é o tamanho de cluster padrão do NTFS. Os discos rígidos virtuais dinâmicos e diferenciais têm um bitmap de setor de 512 bytes na frente do bloco de carga útil de dados. Esse bitmap faz com que os blocos de 4 KB não estejam alinhados ao limite físico de 4 KB. O diagrama a seguir mostra um bloco VHD de 4 KB realçado que não está alinhado com o limite físico de 4 KB.
Cada operação de gravação de 4 KB pelo analisador atual para atualizar os dados de carga resulta em duas leituras para dois blocos no disco. Em seguida, o sistema atualiza os blocos e grava-os de volta nos dois blocos de disco. Hyper-V no Windows Server 2016 mitiga alguns dos efeitos sobre o desempenho de discos 512e na arquitetura VHD. Hyper-V prepara as estruturas para alinhamento a limites de 4 KB no formato VHD. A atenuação evita o efeito RMW no acesso aos dados dentro do arquivo de disco rígido virtual e atualiza as estruturas de metadados do disco rígido virtual.
Como já foi referido, os VHDs copiados de versões anteriores do Windows Server não estão automaticamente alinhados a 4 KB. Você pode converter manualmente o disco para alinhar de forma ideal usando a opção Copiar do disco de origem com o Convert-VHD comando.
Por predefinição, os VHDs são expostos com um tamanho de setor físico de 512 bytes. Este método garante que as aplicações dependentes do tamanho do setor físico não são afetadas quando migra a aplicação e os VHDs de uma versão anterior do Windows Server.
Por padrão, o sistema cria discos VHDX com um tamanho de setor físico de 4 KB para otimizar seu perfil de desempenho em discos regulares e discos de setor maiores.
Para reduzir os problemas de compatibilidade entre tamanhos de disco, recomendamos a implementação de drives 512e para dimensionamento transitório. Para fazer pleno uso dos setores de 4 KB, use o formato VHDX.
Discos nativos de 4 KB
Hyper-V no Windows Server 2012 R2 e posteriores suporta discos nativos de 4 KB. Você também pode armazenar dados de disco VHD num disco nativo de 4 kB ao implementar um algoritmo RMW de software na camada da pilha de armazenamento virtual. O algoritmo converte o acesso de 512 bytes e as solicitações de atualização em acessos e atualizações correspondentes de 4 KB.
Como os arquivos VHD só podem ser expostos como discos de tamanho de 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 satisfaz as 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.
Pode configurar ficheiros VHDX para os expor como discos com tamanho de setor lógico de 4 KB. Essa implementação é uma configuração ideal para desempenho de discos hospedados em um dispositivo físico nativo de 4 KB. No entanto, certifique-se de que o tamanho do setor lógico de 4 KB ofereça suporte ao convidado e ao aplicativo que usam o disco virtual. O formato VHDX funciona corretamente em um dispositivo de tamanho de setor lógico de 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 requer discos nativos de 4 KB, você deve usar o formato VHDX em um dispositivo de tamanho de setor lógico de 4 KB.
Discos de passagem direta
Recomendamos que você evite usar discos de passagem devido às limitações que eles introduzem em cenários de migração de VM.
O mapeamento de um VHD numa VM diretamente para um disco físico ou LUN, 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 da CPU de 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 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.
Qualidade de serviço de armazenamento (QoS)
No Windows Server 2012 R2 e versões posteriores, o Hyper-V inclui a capacidade de definir certos parâmetros de qualidade de serviço (QoS) para armazenamento em VMs. Recomendamos que você implemente a QoS de armazenamento para acessar parâmetros de armazenamento extras, definir limites máximos e mínimos de IOPS para discos rígidos virtuais e monitorar o desempenho do disco. Você pode implementar esses parâmetros para obter os seguintes benefícios:
Configurar o isolamento de desempenho de armazenamento em um ambiente multilocatário
Especificar o máximo e o mínimo de operações de entrada/saída por segundo (IOPS) para discos rígidos virtuais
- Os administradores podem limitar a E/S de armazenamento para evitar que um locatário consuma recursos de armazenamento excessivos que podem afetar outros locatários. Defina o valor mínimo de IOPS e receba notificações quando o sistema não atingir o limite para um desempenho ideal. Especificamos os valores máximos ou mínimos de IOPS em termos de IOPS normalizadas, onde consideramos cada 8 KB de dados como uma operação de E/S.
Receba notificações quando o desempenho de E/S de armazenamento cair abaixo dos limites definidos para executar com eficiência cargas de trabalho de VM
Acesse os parâmetros de armazenamento para a infraestrutura de métricas da VM e permita que os administradores monitorem parâmetros relacionados ao desempenho e à cobrança.
No entanto, também tenha em mente que a QoS de armazenamento tem as seguintes limitações:
Disponível apenas para discos virtuais
O disco diferencial não pode ter o disco virtual superior numa partição diferente
A QoS de um site de réplica é configurada separadamente do site primário
A QoS de armazenamento não suporta VHDX compartilhado
Para mais informações, consulte Qualidade do serviço de armazenamento para Hyper-V.
Configurações do Registro NUMA I/O para VMs grandes
O Windows Server 2012 e posteriores suportam a projeção de uma topologia de acesso à memória virtual e não uniforme (NUMA) em VMs Hyper-V. O suporte a NUMA melhora o desempenho de cargas de trabalho executadas em VMs configuradas com grandes quantidades de memória ou 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 a correr com 64 processadores virtuais.
As seguintes melhorias do Windows Server cumprem os requisitos de escalabilidade de I/O de grandes VMs:
Criação de mais canais de comunicação entre dispositivos convidados e a pilha de armazenamento do host.
Um mecanismo de conclusão de E/S mais eficiente que envolve a distribuição de interrupções entre os processadores virtuais para evitar interrupções dispendiosas entre processadores.
Chaves de registo
Recomendamos que utilize as definições de chave de registo NUMA do Windows Server para melhorar o desempenho de cargas de trabalho a correr em VMs grandes.
Adicionámos e atualizámos algumas entradas de registo para suportar as melhorias na secção anterior e permitir-lhe ajustar o número de canais. Você pode encontrar as entradas em HKLM\System\CurrentControlSet\Enum\VMBUS\<device id>\<instance id>\StorChannel.
A <device id>\<instance id>\ parte do caminho corresponde aos valores relevantes na sua configuração. Essas entradas do Registro alinham os processadores virtuais que lidam com as finalizações de E/S às CPUs virtuais que o aplicativo atribuiu como sendo os processadores de E/S. O sistema configura as definições do registo 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. O valor padrão da contagem de canais é 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 de chave ou definir o valor como 0, a máscara de canal assumirá como padrão o algoritmo de distribuição de canal existente para canais normais de armazenamento ou rede. A ação padrão garante que os 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 de Transferência de Dados Descarregados (ODX) para garantir que a carga de trabalho da VM possa usar o armazenamento habilitado para ODX da maneira que pode em um ambiente físico.
Tarefas de manutenção cruciais para VHDs, como fusão, 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 ter sido usados para a manutenção de VMs.
Os fornecedores de SAN (Storage Area Network, rede de armazenamento de dados) podem fornecer um recurso de hardware chamado ODX. Esse recurso fornece operações de cópia quase instantâneas para grandes quantidades de dados. A ODX permite que o sistema, não os discos, especifique como mover conjuntos de dados específicos de um local para outro.
Hyper-V no Windows Server 2012 e posteriores suporta operações ODX para transferir dados copiados do sistema operativo convidado para o hardware anfitrião. A carga de trabalho pode usar o armazenamento habilitado para ODX da mesma forma que em um ambiente não virtualizado. A pilha de armazenamento Hyper-V também pode emitir operações ODX durante operações de manutenção para VHDs, como a fusão de discos e o armazenamento de meta-operações de migração durante grandes migrações de dados.
Integração de notificações de desmapeamento
Recomendamos que você use notificações de desmapeamento para tornar seus 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 onde compartilham espaço disponível com outros arquivos. Como o tamanho do 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 Windows no sistema operativo 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 nem o dispositivo de armazenamento físico sobre a informação eliminada, o que impediu a pilha de armazenamento Hyper-V de otimizar o espaço para os ficheiros de disco virtual baseados em VHD. Como resultado, o dispositivo de armazenamento subjacente não pôde recuperar o espaço agora não utilizado que os dados excluídos costumavam ocupar.
A partir de Windows Server 2012, Hyper-V suporta notificações unmap. 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 dos arquivos reduzidos e permitindo que a pilha recupere espaço de armazenamento não utilizado para outros usos.
Apenas controladores SCSI, IDE otimizado e Virtual Fibre Channel específicos de Hyper-V permitem que o comando unmap do sistema operativo convidado chegue à pilha de armazenamento virtual do anfitrião. Em VHDs, apenas discos virtuais formatados como VHDX suportam unmap comandos do SO convidado.