IBM V7000 drive replacements and forcing copy-back
We’re running some V7000′s for some time now, and I’ve seen different results when a drive fails and gets replaced. A few scenario’s I’ve seen:
- After replacing a drive, it’s automatically added back into the array, and a copyback from spare is started.
- After replacing a drive, the new drive isn’t seen without running the wizard (or intervening with CLI), after intervention the new drive is added back into the array, and a copyback from spare is started.
- After replacing a drive, the new drive isn’t seen, and the wizard also doesn’t recognize it, and asks you if you want to add the in use spare permanently to the array, or pick another drive (and you can not pick the new drive you just put in, because it isn’t recognized).
Why I’ve seen different things I haven’t found out yet. All I know is that IBM support has “a fix” for the third scenario, and I don’t like it, since it just adds the spare back into the array, and puts the replacement drive into candidate mode. According to IBM support, this is by design. Of course, it works, but if you have a strict drive/array layout like we do, you won’t like this result. We script our V7000 installs, and want drive and array layout to stay the same.
Yesterday we got into the third scenario again, so I solved it by CLI. It’s actually very easy, and I’m probably going to script this later.
A drive was failed, and a spare was used.

Using CLI we see the following:
IBM_2076:hostname:admin>lsdrive|grep offline 188 offline 2223 failed sas_hdd 558.4GB 9 14 IBM_2076:hostname:admin>lsdrive id status error_sequence_number use tech_type capacity mdisk_id mdisk_name member_id enclosure_id slot_id node_id node_name . 188 offline 2223 failed sas_hdd 558.4GB 9 14 . 196 online member sas_hdd 558.4GB 25 mdisk35 0 9 22 .
Drive ID 188 is failed and offline. Drive ID 196 is it’s spare in use.
So we pull out drive 188, wait a bit, and put in the replacement drive. At this point one would expect to see the SAS discovery messages, but they’re not showing up. Which I think is kinda strange. Drive ID 188 stays in this status, and if we run the wizard, the drive isn’t recognized.
IBM support tells you to do the following:
Drive ID: X has no tray slot info. It’s a ghost entry.
To get rid of it use CLI cmds:
chdrive -use failed X
chdrive -use unused X
chdrive -use candidate X
If you do this, you’ll see the drive come online, with the desired status. You’ll also see the SAS discovery messages in the logs.
![]()
After that, you can either use the wizard, and do NOT pick the default setting, which will be to add the currently in use spare to the array, and leave the new drive as a candidate. If you’re not paying attention and leave it to the wizards, you will be running out of spares after a few of this replacements.. What you can do is use the other option, pick a new drive. And pick the one you just replaced. It’ll start a copy-back.
So I did half the procedure, and added a bit of my own.
IBM_2076:hostname:admin>chdrive -use unused 188 IBM_2076:hostname:admin>lsdrive|grep offline IBM_2076:hostname:admin>lsdrive|grep 188 188 online unused sas_hdd 558.4GB 9 14 IBM_2076:hostname:admin>chdrive -use candidate 188 IBM_2076:hostname:admin>lsdrive|grep 188 188 online candidate sas_hdd 558.4GB 9 14 IBM_2076:hostname:admin>lsdrive|grep mdisk35 196 online member sas_hdd 558.4GB 25 mdisk35 0 9 22 210 online member sas_hdd 558.4GB 25 mdisk35 1 10 14 232 online member sas_hdd 558.4GB 25 mdisk35 2 11 14 254 online member sas_hdd 558.4GB 25 mdisk35 3 12 14 276 online member sas_hdd 558.4GB 25 mdisk35 4 13 14 298 online member sas_hdd 558.4GB 25 mdisk35 5 14 14 320 online member sas_hdd 558.4GB 25 mdisk35 6 15 14 342 online member sas_hdd 558.4GB 25 mdisk35 7 16 14 IBM_2076:hostname:admin>charraymember -member 0 -newdrive 188 mdisk35 IBM_2076:hostname:admin>lsdrive|grep 188 188 online member sas_hdd 558.4GB 25 mdisk35 0 9 14 IBM_2076:hostname:admin>lsdrive|grep 196 196 online member sas_hdd 558.4GB 25 mdisk35 0 9 22
And the logs show you an exchange has been started, and completed:
![]()

![]()
What it didn’t do, as the wizard also won’t do, is put the source drive for the exchange back to spare after it’s done. I have to test further how to resolve this. One guess is that if you put the newly replaced drive in spare mode instead of candidate mode, it’ll also swap the mode after completing the exchange. Not tested this, will test at next replace, or when I get an empty V7000 for testing. I will update of course when I have new results.
So we manual put the old spare back to spare mode again:
IBM_2076:hostname:admin>lsdrive|grep 188 188 online member sas_hdd 558.4GB 25 mdisk35 0 9 14 IBM_2076:hostname:admin>lsdrive|grep 196 196 online candidate sas_hdd 558.4GB 9 22 IBM_2076:hostname:admin>chdrive -use spare 196 IBM_2076:hostname:admin>lsdrive|grep 196 196 online spare sas_hdd 558.4GB 9 22
So there you have it. Easy way to keep your layouts nice and tidy. It’s a bit of a hassle though, and we would like an option to make this happen automatically. We payed extra for support to uplift from CRU to FRU, so we don’t have to do drive replacements. Now a customer engineer replaces the drive, and we still have to take action, which wouldn’t be necessary if this was default behaviour.
Oh, and if you’re wondering how it’s possible to use grep on SVC/V7000:
SVC|V7000 and grep




