Ran into another interesting little issue or nuance last week with Hitachi Command Suite’s (HCS) Data Retention Utility (DRU).
“One or more volumes (00:AF:00, 00:AF:01, 00:AF:02, 00:AF:03, 00:AF:04)
cannot be unallocated. The last path of one or more volumes (00:AF:00,
00:AF:01, 00:AF:02, 00:AF:03, 00:AF:04) that are specified in copy pairs
cannot be unallocated. Release the copy pairs and retry. (KAIC18149-E)”
This error cropped up after I received a request to decommission some servers. Usually all this consists of is deleting the host groups and reclaiming the storage off of the array. For some reason these particular servers were giving me fits.
Anyone that has dealt with local or remote replication on a Hitachi VSP will be familiar with the error above, and the fix is to find and split/delete the pairs. So I split the pairs and I am able to successfully delete the host groups, but wait, what’s this? I can’t delete the volumes now?
“Error: These volumes cannot be specified: 00:AF:00, 00:AF:03, 00:AF:01,
00:AF:02, 00:AF:04. Volumes for which replication control is set cannot be
deleted. Use different volumes. (KAIC15359-E)”
But I just split them and deleted the pairs?
I logged into Storage Navigator for this particular array to see if I could get some more information and got this error instead
“The selected LDEV has an access attribute setting. Check the setting(s).” Error code: 03022-105143″
Okay, that’s not very helpful, actually…
So I start digging in all the old applications within Storage Navigator to try and track down this “access attribute”, due to past experience my first thought is to go look in the “Data Retention” utility (DRU).
Slight tangent, if you manage to have a DP/DT pool hit 100% used then any volumes that have a write activity attempted on them will be set to “Protected” in the DRU preventing you from doing pretty much anything with this volume until the issue is addressed. This behavior was similar so this is where I went.
If you’ve never used this utility I don’t recommend playing around in it, you can cause some major problems for yourself if you’re not careful
So here we are in DRU and everything appears to be fine. (Note the volumes in the error above are gone, because I didn’t think to screenshot this while I was having the issue)
So from here I went on a tangent looking in all manner of places, so to save you some time I recommend just looking at some other volumes that you’re pretty sure are right. You’ll notice here that something IS different from the picture above.
Notice how S-VOL is enabled here? Yeah, that was the problem. Apparently, depending on how and where you set up and break your ShadowImage pairs, this setting may or may not set itself back to the enabled state. My understanding is that “S-VOL disabled” indicates that the volumes are already in a pair and therefore can’t be used for any other array operations until it is set back, this includes deleting the volumes.