When working on an eight node Storage Spaces Direct (S2D) deployment, cluster validation fails for Storage Spaces Direct.
Components are validated by running the following PowerShell command:
Test-Cluster -Node X500S2D1,X500S2D2,X500S2D3,X500S2D4,X500S2D5,X500S2D6,X500S2D7,X500S2D8 -Include “Storage Spaces Direct”,Inventory,Network,”System Configuration”
Failover Cluster Validation Report:
Click into Storage Spaces Direct, all all tests have failed or been cancelled.
The following tests all fail with the error below:
- List All Disks for Storage Spaces Direct (list all disks visible to one or more nodes).
- List File Shares (list all file shares on storage pools and their health status).
- List Storage Enclosures (list all enclosures and their health status).
- List Storage Pools (list all storage pools and their health status).
- List Un-Poolable Disks (list all disks that can not be added to a cluster storage pool).
- List Virtual Disks (list all Virtual Disks and their health status).
- List Volumes (list all Volumes on storage pools and their health status).
- Validate Storage Spaces Direct Support (validate that Storage Spaces Direct is supported by the operating system installed on the machine, that the Storage Spaces Direct feature is installed and that Storage Spaces Direct cache is supported).
ERROR CODE : 0x80131500;
NATIVE ERROR CODE : 1.
The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.
The following tests are cancelled:
- Verify Node and Disk Configuration (verify whether node and disk configuration is suitable for Storage Spaces Direct).
- Verify Unique Device Identifiers (verify uniqueness of device identifiers).
The S2D machines aren’t joined to an AD domain.
PowerShell remote connections must be secure. When the Test-Cluster PowerShell command is ran from one of the machines (here it’s X500S2D1), the remote machines do not mutually authenticate in the same way they would when joined to a domain.
As the text in the error message suggests, the destination machines need to be added to the Trusted Hosts list. Hosts added are basically considered as trusted and mutual authentication is bypassed at machine level.
As I may need to validate the cluster again from another machine, I added all machines in the S2D solution (excluding the machine itself) to the Trusted Hosts list.
For example, on X500S2D1:
Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value “X500S2D2,X500S2D3,X500S2D4,X500S2D5,X500S2D6,X500S2D7,X500S2D8”
Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value “X500S2D1,X500S2D3,X500S2D4,X500S2D5,X500S2D6,X500S2D7,X500S2D8”
… and so on.
No reboot or service restarts are necessary. After applying the above, Test-Cluster successfully validated all Storage Spaces Direct components.
To view the contents of the trusted hosts list:
Get-Item -Path WSMan:localhostClientTrustedHosts