SCSI-3 Persistent Reservations test warning on Windows Server 2019 cluster using single VMWare host

[kenappel]

ESXi 6.5 EP 12 (Build 11925212) on a single host with Windows Server 2019 guests using both local and iSCSI datastores.

I've tried several combinations of sharing disks between two Windows Server 2019 cluster servers. Every time, I get some sort of SCSI-3 Persistent Reservations warning or error. When configured exactly like it says in documentation (https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-setup-mscs.pdf) I get the following warning:

Failure issuing call to Persistent Reservation REGISTER RESERVATION KEY 0x10000000a SERVICE ACTION RESERVATION KEY 0x10000000b for Test Disk 1 from node node1.contoso.local: Incorrect function.

Test Disk 1 does not support SCSI-3 Persistent Reservations commands needed by clustered storage pools that use the Storage Spaces subsystem. Some storage devices require specific firmware versions or settings to function properly with failover clusters. Contact your storage administrator or storage vendor for help with configuring the storage to function properly with failover clusters that use Storage Spaces.

By configured exactly like it says in documentation I mean that I have:

• Used Local Storage
• Created a secondary SCSI device using LSI SAS and Virtual Sharing mode
• Added a second hard disk, attached to the second SCSI device, in thick provision eager zeroed mode.
• Set Disk Mode to Independent - Persistent.
• Set Sharing mode to multi-writer
• Added the new disk as an "Existing Hard Disk" on the secondary node
• I've also duplicated these settings using an iSCSI Datastore instead of local storage.

However, I have also tried several different combinations (all result in warnings or hard fail errors related to persistent reservations):

• Using local storage or iSCSI storage
• Using RDM disks or VMDKs
• Using SCSI bus mode of Virtual or Physical
• Using Disk compatibility mode of Virtual or Physical (RDM disks)
• Using LSI SAS and VMWare Paravirtual SCSI adapters

Additionally, I have a second site, with identical hardware but it has multiple hosts. I followed the directions to configure a multi-host shared RDM disk with iSCSI storage and it passes all cluster verification tests without warnings or errors. So, it appears the issue occurs as part of this being setup as a cluster-in-a-box, whereas cluster-across-box seems to work fine with the same hardware.

I understand this is a warning. I also understand that it appears to be warning me that I can't use storage spaces, but it appears that it will still support clustering. However, the warnings worry me, and I'm concerned about compatibility, performance or reliability issues. I also am not sure if I will need or want storage spaces as I move forward with this project.

Any ideas?

[wrightis]

Hallo Kenappel,

I don't know if it is related, but we are having problems with LSI-SAS and PVSCSI controllers on Server 2019 - the main reason I came here.

After a few hours of use, the server claims it needs to restart to complete configuration, rinse and repeat. I did right click on the controllers in Device Manager and got an update through Windows Update installed and thought, "aha!" Installed and rebooted. But the next morning Windows wanted to restart again to complete configuration.

I've just installed on another cluster to see if that has the same problems.

The installation causing the problems is a 6.5 Build 7515524, the new test VM is on a 6.7 cluster. I'm going to leave the VM running over the weekend to see if it suffers from the same problem.

[wrightis]

Hmm, no warning on the test install on 6.7 over the weekend.

I also noticed that VMWare issued a new VMWare Tools collection last week. I'm going to try and get them installed on our 6.5 server this week and see if that allieviates the problem.

[wrightis]

So, unfortunately the new Tools don't make a difference either. It looks like there is some sort of incompatibility between Windows 2019 and the VMWare drivers in conjunction with ESXi 6.5. It doesn't seem to affect stability or reliability, but it does cause annoying warnings that the configuration is not completed and the server needs a reboot.

The same Windows 2019 configuration running on ESXi 6.7 doesn't suffer from the same problems.

I hope that helps you further with your own diagnosis of the problem.

[FernandoA_USI]

I don't know if you fixed or not, but for me was a matter that the multipath was not enabled so only 1 path was reaching the SAN, this leads to this error.

Once I enabled the 2nd path the error was gone.