How to properly unpresent/remove LUN from Vmware.

Thanks for the quick reply. Could you explain what you mean by unmount volume? Also, i'm under the impression that once i remove a LUN from one host, the removal will replicate across all hosts since it's technically shared storage. The same idea applies when you create a new volume, you only do it once on a single host, and rescan HBA's on all other hosts to see the newly added LUN.

Also, i would imagine i would need to remove the datastore then REMOVE IQN access on the array BEFORE i rescan storage on all hosts. If the IQN is still part of the array, the rescan would still pick up the volume on the hosts for which IQN access is configured and granted...at least that's my thought and I could be wrong.

Thanks for the clarification Dev. I still don't quite understand why i would rescan storage on ESX BEFORE removing the IQN's on the volume inside EQL. If the IQN's are still active, once i rescan i would imagine ESX attempts to make the iscsi connection to already deleted volume.

But thank you for the quick replies nonetheless and I'll give this a shot.

Best Regards,

H

vSphere 4 doesn't have an unmount option, so ignore that step.

So, from Kenny's post:

1. Verify no I/O is going to the volume.

2. Remove datastore from hosts.

3. rescan storage adapter inside ESX.

4. Remove IQN access inside array.

5. Set volume offline.

6. Delete volume.

The short steps are:

- verify/double check so you know for sure which volume you're wanting to delete

- offline the volume in the EQL group manager

- rescan the storage adapters in VMware and verify the correct disk disappeared (if the wrong one disappeared you did kill the VMs on it, but at least you can online the disk again to bring it back (instead of having deleted the volume already))

- delete the volume from the EQL group manager

So this is a completely different method that you've have confirmed works just as well ? Thanks!

I believe the first part of the last post from Dev Mgr was to removing the vms from the volume so there is no activity and then deleting the datastore from ESX and then you would move to the EQL Group Manager to offline and delete the volume.

This nice thing about deleting the datastore in ESX is just a cleaner way of doing it.  You're removing the datastore from the SQL database.  As opposed to just yanking it out from underneath the servers.

 The way I use is:

1.)  Move any VMs

2.)  Delete the datastore in the VCS GUI

3.)  Refresh the storage views in the ESX servers.  

        To make sure they have updated info that the datastore is no longer there.

4.)  offline the volume in the EQL GUI.  

5.)  Rescan the storage adapters on the ESX servers.

6.)  Delete the volume in the EQL GUI

If you don't offline it at least first, then the static mappings on each ESX server will constantly attempt to re-login to that volume until the ESX servers are rebooted.

Regards,

There it is. Thanks dwilliams. The key difference being Refresh vs Rescan and making sure I offline the volume. Great. Thanks!

You are most welcome.

Either would work, doing another rescan doesn't harm anything but it most times takes longer.  Most important is the volume being offline.  

PS.  There is one footnote, if you are using a Qlogic iSCSI card (405x/406x series), you have to manually remove the static mappings in the iSCSI adapter "Static Discovery" tab.  When you connect to a volume with Qlogic is stores the static mapping in NVRAM.  The offline/rescan won't remove it from that card.   Good news it's easy to do, Storage Adapters->Qlogic->Properties->Static discovery.  Highllight the old volume (you have to widen the field to see it), press remove button.

Have a great day!

Removing the static discovery is one method i was told would be recommended of removing a datastore. Instead of deleting the datastore from VCS, i would remove the static mapping from the static discovery page, and the datastore should disappear.

this method is not recommended for the built-in software iscsi imitator on the ESX host ?

The SW initiator has the information in memory as well.  Depending on the version of ESX that may or may not work.  Since I'm not sure removing it from the GUI actually removes it from the database.  The offline/rescan always works, from ESX 3.x-5.x.  

Don -

This worked like a charm! I'm running ESX 4.1 U1 and once the DS was deleted from the VCS gui, it refreshed storage on all three hosts. I then offline'd the volume, rescaned HBA's and the number of connected paths dropped by 1. I then gracefully deleted the volume and reclaimed some much needed space.

It's funny that you bring up the issue withe Qlogic and removing via static discovery. I had a nightmare of an issue, what vmware refers to "APD' when i tried to delete a datastore from the gui. It essentially crashed ESX and my storage. I had to restart every physical component...needless to say i try to take every precaution when deleting a volume.

Thanks again to you and all for your feedback.

I'm glad I could help out.

re: APD   APD w/Qlogic or SW iSCSI?    There was a problem with MEM 1.0 where paths would be incorrectly marked as failed.  Fixed in 1.0.1.   The Broadcoms w/iSCSI offload are very sensitive to Broadcoim FW  (.5.2.7 min req) and ESX drivers.  Recent builds have updated versions of the broadcom drivers.  

You also said "1 connection"  are you not running MPIO?  Teaming only provides a physical layer redundancy.  MPIO gives you that plus iSCSI session redundancy

APD with Qlogic and a cybernetics SAN.

When i said "1 connection" i meant after i rescanned HBA's the number of static iscsi connections dropped by 1, as it should since I offlined the volume.

I have mem and MPIO up and running. I believe it's 1.0.1 but it's been a while so just not sure on which verison.