Many years ago we used to use floppy disks, hundreds of the things, each normally holding 1.44MB, and they were all we had to copy data around on.
Fast-forward to 2011 and its been a long time since I saw a PC with a 3.5” floppy drive fitted, let alone have someone send me data on one, probably about 11 years is my guess. So, what a surprise when I was building a cluster with Windows Server 2008 R2 today when I got the following error message:
The wrong diskette is in the drive
Insert %2 (Volume Serial Number: %3) into drive %1.
I got this error on the "List potential cluster disks” section of the Cluster Verification Report (CVR) when I was preparing Windows Failover Clustering.
Some background. Both servers in the soon-to-be cluster had several LUNs attached to them using the SAN vendor’s MPIO and Fibre Channel HBA drivers. Each LUN was presented as a disk to Windows, from where Windows had initialized the disk and put a GPT on it as a Simple disk. Each disk had a single partition created and formatted as NTFS. All very normal.
The issue was escalated to Microsoft and the SAN vendor where the focus of investigation was on the SAN and LUN configuration.
The initial consideration was the “Host operating system” value assigned to each of the hosts within the SAN controllers configuration; was this set to Window Server 2008/with Clustering? Interestingly, while recommended, apparently the actual value makes no difference to the storage’s underlying functionality, but was still “highly recommended”.
Ultimately, the issue was resolved by clearing the Persistent Reservations for the LUNs assigned to the cluster nodes at the SAN controller level. I borrow from Symantec the following definition for those not familiar with the term:
“SCSI-3 Persistent Reservations (SCSI-3 PR) are required for I/O fencing and resolve the issues of using SCSI reservations in a clustered SAN environment. SCSI-3 PR enables access for multiple nodes to a device and simultaneously blocks access for other nodes.” The full link is available here.
Essentially, PRs are like write locks on a file, they allow at a storage communications level for a specific host to reserve full control over a storage item, while their peers for the time being can only achieve a lower level of access to the same storage item.
Clearing the Persistent Reservations allowed the previously failing CVR to succeed from where I could then build the cluster knowing Microsoft would happily support it.
So in the end, the actual error had nothing to do with floppy disks. Instead, as a Google search will show, the Win32 API used and the error message raised date back to when that was the most likely cause of the failure obviously being trapped.