VMware Cloud Community
jmapt
Contributor
Contributor

Removing an iSCSI datastore completely

Hello,

I am using the below two functions that I found elsewhere on the forums for removing a datastore.  I run the Unmount-Datastore followed by the Detach-Datastore functions.

However when I run them, the datastore still shows in vCenter as a red circle with line (inactive and inaccessible).  The only way I've found to eliminate it is to reboot each host.  This seems akin to the All Paths Down (APD) issue, but I thought I am cleanly removing it, as I run these before doing anything on the LUN/SAN side of this.

Can anyone explain how to get these datastores to cleanly disappear on removal?

Thanks!

Function Detach-Datastore {

    #function based on code found here https://communities.vmware.com/docs/DOC-18008

    [CmdletBinding()]

    Param (

        [Parameter(ValueFromPipeline=$true)]

        $Datastore

    )

    Process {

        if (-not $Datastore) {

            Write-Host "No Datastore defined as input"

            Exit

        }

        Foreach ($ds in $Datastore) {

            $hostviewDSDiskName = $ds.ExtensionData.Info.vmfs.extent[0].Diskname

            if ($ds.ExtensionData.Host) {

                $attachedHosts = $ds.ExtensionData.Host

                Foreach ($VMHost in $attachedHosts) {

                    $hostview = Get-View $VMHost.Key

                    $StorageSys = Get-View $HostView.ConfigManager.StorageSystem

                    $devices = $StorageSys.StorageDeviceInfo.ScsiLun

                    Foreach ($device in $devices) {

                        if ($device.canonicalName -eq $hostviewDSDiskName) {

                            #If the device is attached then detach it (I added this to the function to prevent error messages in vcenter when running the script)

                            if ($device.operationalState[0] -eq "ok") {

                                $LunUUID = $Device.Uuid

                                Write-Host "Detaching LUN $($Device.CanonicalName) from host $($hostview.Name)..."

                                $StorageSys.DetachScsiLun($LunUUID);

                            }

                            #If the device isn't attached then skip it (I added this to the function to prevent error messages in vcenter when running the script)

                            else {

                                Write-Host "LUN $($Device.CanonicalName) is not attached on host $($hostview.Name)..."

                            }

                        }

                    }

                }

            }

        }

    }

}

Function Unmount-Datastore {

    #function based on code found here https://communities.vmware.com/docs/DOC-18008

    [CmdletBinding()]

    Param (

        [Parameter(ValueFromPipeline=$true)]

        $Datastore

    )

    Process {

        if (-not $Datastore) {

            Write-Host "No Datastore defined as input"

            Exit

        }

        Foreach ($ds in $Datastore) {

            $hostviewDSDiskName = $ds.ExtensionData.Info.vmfs.extent[0].Diskname

            if ($ds.ExtensionData.Host) {

                $attachedHosts = $ds.ExtensionData.Host

                Foreach ($VMHost in $attachedHosts) {

                    $hostview = Get-View $VMHost.Key

                    $mounted = $VMHost.MountInfo.Mounted

                    #If the device is mounted then unmount it (I added this to the function to prevent error messages in vcenter when running the script)

                    if ($mounted -eq $true) {

                        $StorageSys = Get-View $HostView.ConfigManager.StorageSystem

                        Write-Host "Unmounting VMFS Datastore $($DS.Name) from host $($hostview.Name)..."

                        $StorageSys.UnmountVmfsVolume($DS.ExtensionData.Info.vmfs.uuid);

                    }

                    #If the device isn't mounted then skip it (I added this to the function to prevent error messages in vcenter when running the script)

                    else {

                        Write-Host "VMFS Datastore $($DS.Name) is already unmounted on host $($hostview.Name)..."

                    }

                }

            }

        }

    }

}

Reply
0 Kudos
8 Replies
LucD
Leadership
Leadership

Did you already try doing a Remove-Datastore after calling these two functions?
That should remove the datastore from the vCenter DB afaik.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
jmapt
Contributor
Contributor

I'm farily certain I did....but now that you say that, it seems fairly obvious, so let me go back and double check/test.  Will confirm shortly...

Reply
0 Kudos
jmapt
Contributor
Contributor

The Remove-Datastore command is prompting me for a -VMHost parameter, but I am connecting through vCenter server.  What is the recommended way of handling that?  The other commands it seems to just take without requiring a host.

Reply
0 Kudos
LucD
Leadership
Leadership

Try like this.

Remove the WhatIf when you're sure it is doing what you want

$ds = Get-Datastore -Name MyDS

Get-VMHost -Datastore $ds | Remove-Datastore -Datastore $ds -Confirm:$false -WhatIf


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
jmapt
Contributor
Contributor

Ok -- so Remove-Datastore seems to have done the trick.  However I am noticing one small issue to this, it appears to wipe the partition information from the disk when it does the removal?  I am not sure how, since the devices have been detached from VMware, I thought through the earlier functions that were run.  But I ran the Remove-Datastore and now mounting those disks onto our DR system, it is showing them as unknown partitions and unable to mount the existing VMFS data that was on the disk.

The ultimate goal here, is to take the SAN LUN, and mount it on the DR hosts and have them use the existing signatures/VMFS datastores as they will only ever be mounted in one location.  I am thinking this makes more sense than resginaturing, that way anything that was using these datastores will not notice any real change as the signature and all underlying attributes are not changed.  But I can't seem to get this to work, and if I do the resignature method, then we end up with having to rename all of the volumes from snap-*-<vol name> back to just <vol name>.

Any thoughts or recommendations on how to best achieve this?

Reply
0 Kudos
LucD
Leadership
Leadership

What happens if you "remove" the LUN from the involved ESXi nodes?

I mean something like removing the zoning for that LUN to the ESXi nodes.

That way the LUNs can't be reached anymore.

At that point you should still see the Datastore entry in the vCenter.

Can you then do the Remove-Datastore without consequences?


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
jmapt
Contributor
Contributor

I was able to finally try this, and by doing the remove datastore after the fact, I end up with an error messages saying:

Remove-Datastore : 10/18/2017 2:33:42 PM    Remove-Datastore        An error occurred during host configuration.

Operation failed, diagnostics report: Not a known device: eui.54286c5e15fde7be6c9ce900ff8e515a

At C:\myscript.ps1:211 char:37

+         Get-VMHost -Datastore $ds | Remove-Datastore -Datastore $ds -Confirm:$fa ...

+                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Remove-Datastore], PlatformConfigFault

    + FullyQualifiedErrorId : Client20_VmHostServiceImpl_RemoveDatastoreOfViObject_InvalidArgument,VMware.VimAutomatio

   n.ViCore.Cmdlets.Commands.RemoveDatastore

So it looks like it doesn't want to remove it, if it isn't available.

I am wondering if I should just revert back to resignaturing and dealing with the renamed volumes.  I am not sure I am clear on all of the implications of resignaturing, including if that will reset CBT and things like Veeam backups for example.

That, or, I just simply have to go through a reboot of all hosts after a failover scenario to clear the inactive datastore...

Reply
0 Kudos
LucD
Leadership
Leadership

Personally I think a reboot of the ESXi node(s) would be the path of choice.

You are in a DR scenario after all.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos