Troubleshooting | Check hardware requirements na Implantação do Azure Local

Fala pessoal, tudo bem com vcs!

Neste post, exploramos como corrigir um dos possíveis erros de implantação do Azure Local.

Durante o processo de validação de hardware (Environment Checker), alguns erros podem ocorrer, especialmente relacionados aos discos de dados exigidos pelo Storage Spaces Direct. A seguir, vou mostrar um desses erros e como resolvê-lo, com foco no diagnóstico do CanPool dos discos físicos.

Azure Stack HCI Hardware

Se você precisou reimplantar um servidor e simplesmente resetou o disco do sistema antes de prosseguir com a implantação, é provável que receba o erro abaixo. Isso ocorre porque o disco de dados permanece em uma condição que impede sua inclusão no pool de armazenamento, conforme detalhado a seguir.

Name: Azure Stack HCI Hardware
Status: Error
Description: Check hardware requirements
Exception:
Type ‘ValidateHardware’ of Role ‘EnvironmentValidator’ raised an exception:
Message: Hardware requirements not met. Review output and remediate.
Results:
Name: AzStackHci_Hardware_PhysicalDisk
DisplayName: Physical Disk
Status: FAILURE
Detail:
Unsupported DataDisks:
HCISupported, HCISupportedData, UniqueId
False, @{CanPool=False; CannotPoolReason=Discovery Disabled; …}

Troubleshooting

O primeiro passo é confirmar o estado atual dos discos em cada nó, usando o Get-PhysicalDisk. O destaque vai para as colunas CanPool e CannotPoolReason, que revelam exatamente o motivo do bloqueio:

Get-PhysicalDisk | Sort-Object DeviceId | Format-Table DeviceId, FriendlyName, SerialNumber, MediaType, BusType, Size, CanPool, CannotPoolReason, FirmwareVersion

Como alterar/corrigir o CanPool para deployment

É importante entender que CanPool não é uma propriedade que se define diretamente não existe um Set-PhysicalDisk -CanPool $true. Ela é calculada automaticamente pelo Storage Spaces com base no estado real do disco. Ou seja: o que precisamos fazer é eliminar a causa apontada em CannotPoolReason, e o CanPool muda para True sozinho.

No caso de discos com Discovery Disabled, a sequência de remediação é a seguinte, da mais simples para a mais estrutural:

Limpar completamente o disco

Mesmo discos “vazios” costumam reter metadados antigos ou partições residuais que travam a descoberta. Usei o diskpart para resolver:

No PowerShell digite Diskpart,

Digite o comando list disk,

Selecione o disco desejado, select disk <X>,

Digite o comando attributes disk clear readonly,

Digite o comando clean,

Digite o comando offline disk e em seguida online disk,

Para sair e continuar o deploy digite exit,

Se necessário, repita o procedimento para todos os discos do servidor,

Repita o processo do diskpart

Forçar nova descoberta do storage provider

Comandos: Forçar e Reavaliar Discos

Update-StorageProviderCache -DiscoveryLevel Full

Get-PhysicalDisk | Format-Table FriendlyName, SerialNumber, CanPool, CannotPoolReason

Repetindo esses passos, o CanPool passa a True e o disco fica elegível para o pool de armazenamento, permitindo prosseguir com a implantação do Azure Local sem bloqueios.

⚠️ Atenção: os comandos Clean, diskpart clean e Reset-PhysicalDisk são destrutivos, apagam qualquer dado/metadado do disco. Confirme que são os discos corretos (não o disco de boot!) antes de rodar, usando sempre SerialNumber/UniqueId para identificação precisa.

Conclusão

Esse é um erro simples de resolver, mas que gera bastante confusão à primeira vista principalmente porque o disco “parece” limpo e pronto para uso. Na prática, um reset incompleto do disco de sistema durante uma reimplantação pode deixar o disco de dados travado no estágio de descoberta do Storage Spaces. Com o diskpart e o Update-StorageProviderCache, resolvemos rapidamente e seguimos com a implantação.

Espero ajudar com mais este conteúdo.

Até a próxima!