![]() ![]() This is a distributed switch configuration backup of sorts that can be used by ESXi hosts if vCenter Server becomes unavailable. At any rate, be sure to move these files off if you want to keep them. It’s possible that you may find other VMs stored here that have been removed from inventory at some point as well. In my case, I’ve got an ISO sitting in the root of the datastore. Last but not least, you’ll want to look for other files that may be stored on this datastore. Remember to look for lone files, as well as VMs that may have been removed from inventory. I didn’t care about this one, so just deleted it from disk. You’ll need to convert them to VMs first, then migrate them and convert them back to templates. Templates do not show up in the normal view, so be sure to check specifically for these as well. It’s easy to forget about templates as they aren’t visible in the default datastore view. I was able to use Storage vMotion without interrupting the guest. In my case, you can see that the datastore shared-ssd still has a VM on it that will need to be migrated. If you are running 5.5 or 6.0, you may need to go to ‘Related Objects’ first, and then Virtual Machines. The easiest way to do this is to navigate to the ‘Storage’ view in the Web Client, and then select the datastore in question. Update: Below is a recent (2021) video I did on the process in vSphere 7.0:īefore you even consider nuking a LUN from your SAN, you’ll want to ensure all VMs, templates and files have been migrated off. Today, I’ll be decommissioning an SSD drive from my freenas server, which will require me to go through these steps. Despite these improvements, you still don’t want to yank storage out from under your hypervisors. VMware has made many strides in these areas, including better host resiliency in the face of APD (all paths down) events, as well as introducing PDL (permenant device loss) several years back. Often hosts would become unmanageable and reboots were the only way to recover. ESX 4.x was particularly bad when it came to handling unexpected storage loss. Having done a short stint on the VMware storage support team, I knew all too well the chaos that would ensue after improper LUN decommissioning. Unfortunately, improper LUN removal is still something I encountered all too often when I worked in GSS years back. This is admittedly a well-covered topic in both the VMware public documentation and in blogs, but I thought I’d provide my perspective on this as well in case it may help others. ![]()
0 Comments
Leave a Reply. |