On Unisphere, I was running this test of deleting the device, I have removed the masking view and freed up the thin device. It wouldn’t let me delete. I guess next step would be unbind but there’s no unbind when I select and right click the volume.
There is no unbind on VMAX3. The only prerequsites to deletion are to unmap the device from all ports and to free all allocated tracks. If you have performed these actions, I would suggest running a rediscover in Unisphere to force it to re-sync it's local database with the array. If that doesn't work then I would suggest opening an SR with Dell EMC support.
we are running the unisphere directly from the array itself, I will need to check on unmap, not sure if I have done it while removing the masking view. If it’s not default then, I guess that’s stopping me. tomorrow I am going to check again. Thanks!
What level of validation does the symdev -sid xxxx -devs 0123 - 089a free -all command do ?
I had an instance where it did not validate if the LUN was mapped or masked, it went ahead and freed up the data on that LUN / range of LUNs.
THanks for sharing.... this is too dangerous..... i guess data is lost in this case and cannot be recovered.....
it will be helpfull if u share ur approach for deleting devices safely.....
Yes the data was lost, however we were able to recover the data from the back ups.
We remove the devices from the storage groups, delete the masking view - set the devices to not_ready
wait for a 24 hour period to ensure no alerts have generated from the hosts.
after the 24 hour period, run a symdev -sid xxxx -devs yyyy-zzzz free -all .
I have found the best way to check that status of the device data "free" with symcfg -sid XX list -tdev -dev DEV -detail
It will show you total tracks and their status.."bound or U for Unbinding".
the REAL answer seems to be ..be patient. While traditional vmax unbind also took some time to unbind from the pool, especially for large drives, hypermax must background that free process further down because it seems to take a good deal longer. Indeed I have seen as well when checking the status with symcfg that I will go all the way down to 0 tracks left but often sit in "U" status or not flip to "." status/unbound so symconfigure will still fail to delete. Come back an hour later and rerun your delete, and all will be well
I Obeserved that when symdev free command is run the flags of devices shown in in symcfg list -tdev -dex xxxx changes from F..B to F..F (freeingall) and once all the tracks are deallocated it comes back to F..B.....abd then it allows us to delete the device.
so i scripted in the same way..... it works for small devices ... till 512gb
but if the device is 1TB or more then after issueing symdev free command the device flags changes from F..B to F..F (while freeing) to F..B (which now means all tracks deallocated)...... but when i issue command to delete the device, it again throws an error that tracks are still allocated to device even though it shows 0 tracks allocated in symcfg list -tdev - dev xxxx command and could not delete it.....but after some random time it allows me to delete the device.... this is wierd.... let me know if anyone of you face the same......