SVM: When you try using non-Sun disks, and it doesn’t work quite right
The Solaris Volume Manager (formerly known as DiskSuite) is quite easy and straightforward to configure, or that is what the documentation would have you believe. However if you try using it with non-Sun disk devices, it may not work in ways that will leave you perplexed.
Back when I got the CLARiiON storage array, which I discuss elsewhere on this site, I wanted to hook it up to my Sun server running Solaris 9. Furthermore, I wanted to use SVM to manage volumes on it. However, I quickly ran into a problem. You see, SVM does not purely identify drives by their device ID. Instead, SVM uses a device serial number, of sorts, read off the device. The two disk volumes provided by the CLARiiON RAID controllers, which showed up as two separate devices, presented the exact same device serial number. As such, SVM was getting all confused and thought I was trying to run the same commands on the same disk volume, even though I was really trying to run them on a second disk volume.
More recently I ran into a different problem that sounds totally unrelated. I installed Solaris 10 on a Sun machine which used a non-Sun-stamped hard drive. Then I went to configure SVM, since I ultimately wanted to mirror the root disk. This is a procedure I’ve done several times before on Solaris 9, and was very straight forward. However, this time I ran into a confusing problem. When I ran "metadb" with the proper parameters to create the state database replicas, it seemed to work fine. I could see the db replicas with all the proper commands, and all the relevant configuration files were populated with information about them. However upon reboot, it seemed as though all those files were ignored. Basically, SVM was ignoring my state db replicas until I created them again. Just for reference, Solaris 9 and 10 tell the "md" kernel module about these db replicas with those same ugly device serial strings in "/kernel/drv/md.conf" that were causing me problems the last time.
As it turns out, both of these problems can be fixed with the exact same procedure. This procedure essentially involves tricking the SCSI driver into doing something with the serial number string so that SVM is happy and works. The trick was shamelessly discovered in this posting to a mailing list, and is described below:
The first step is to determine the vendor/product string for your SCSI device.
As root type: "format -e" Then select the disk, go to the "scsi" menu, and choose "inquiry".
The string we need is an 8 character vendor string followed by a 16 character product string, as shown below in sample output:
Inquiry: 00 00 04 02 3b 00 41 32 4e 45 58 53 41 4e 20 20 ....;.A2NEXSAN ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^^^^^^^ 41 54 41 62 6f 79 28 30 41 30 42 30 43 30 44 29 ATAboy(0A0B0C0D) ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^^^^^^^^^^^^^^^ 34 30 31 33 00 00 00 00 00 00 00 00 00 00 00 00 4013............ 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 ...............
Now go and edit "/kernel/drv/sd.conf" and add the following 3 lines (changing the appropriate string to match your drive’s output from the "inquiry"):
sd-config-list= "NEXSAN ATAboy(0A0B0C0D)", "bad-serial-number"; bad-serial-number=1,0x8,0,0,0,0,0;
That should do the trick! Now reboot, and configure SVM as you normally would.