I want to merge or consolidate my multiple datastores to fewer datastores. Is it possible?

[SHARJEELK]

Hi everyone.

I cannot locate the KB for my problem which I have mentioned in the short description.

I have vSphere 6.0 and Windows vCenter running on my environment with about 73 VMs and 59 datastores. Pretty much 1 Datastore for every VM.

For storage, we use Cisco Hyperflex (4 nodes). Cisco advises to create 1 datastore per node and as per them we should have had maximum 4 nodes on the storage cluster.

Due to over-exhaustion of the number of datastores, I cannot create new datastores or expand my existing datastores as Cisco HX software (Used for Datastore Management) could not handle the datastore number anymore. This was confirmed by Cisco's Senior Support and they are asking to consolidate datastores on vSphere from 59 to below 10.

Note: I know 59 is way too much of an overkill - but this was set up by someone else in the beginning and now the environment is in production and can't recreate everything.

How do I combine/merge the datastores on vSphere 6.0? Will there be downtime to the VMs during consolidation of datastores? Can you guide me to an article or KB referencing this?

Any help/advice would be appreciated. Thank you.

[sjesse]

You can't combine datastores in terms of any vmware product, you can make a new one and transfer everything into and delete the old ones though. In terms of esxi, 59 isn't that many, its more about how hyperflex works.

[SHARJEELK]

Hi sjesse,

I appreciate your response. Yes, Cisco Hyperflex HX Software seems to be the culprit here.

The current problem is, that I cannot create any new datastores. The Cisco HX Datastore Management Software is not allowing me to and keeps crashing.

Also, if I try moving VMs to my existing datastores, most of them are not big enough to host different VMs as they were sized to host VMDKs of one particular VM only (Yes, I know a design flaw ignoring how Hyperflex works).

I'm not sure what's the way around this. Do you have any additional advice?

Thanks,

Sharjeel

[IRIX201110141]

Increase the size of 1-10 of your favorite LUNs/Datastores and than migrate VMs from the others one into the favorites. If you fully evacuate a Dastatore you can remove it. At the end of the day all VMs are in your 10 Datastores.

You can do this with the help of a VMware Dastore Cluster. Just create a DS Cluster based on all favorites Datastore and a single one of those you wanna to delete. You can use the "Datastore Maintenance Mode" function for that.

Btw. vSphere 6.0 is out of support.

Regards,
Joerg

[sjesse]

You can either attach another storage temporary like a nfs server or iscsi, or download the vms as ovfs till you get enough room and then reupload them. That's really the only options as you need to make space. You may be able to convert any thick provionsed vms to thin and use the command in the link to shrink the vmdks, but that may or may not get you enough space, and if your not used to manage thin provision vms, it's easy to run out of space again really quickly.

https://buildvirtual.net/reclaim-used-space-with-vmkfstools-punchzero/

[Lalegre]

I think that here you will need to think on how you can use multiple solutions to fix your issue.

Try to migrate all the VMs that you can to different datastores and the ones that you cannot migrate you can download them from the platform (of course you will have downtime). In case you have any backup solution you can get a copy of that VM and then restore it once you have at least one bigger datastore.

Once you merge two datastores at least you will have more space to move everything. Also you can connect a USB External driver with a maximum of 2TB to use at datastore maybe to do the temporary Storage vMotion.

[SHARJEELK]

Hi Joerg,

Thank you for your response. Yes, I'm aware its out of support. Fixing the environment is a pre-requisite to our upgrade.

My dilemma is that I cannot increase the size of datastores. Its just not working via Cisco's HX Software.

Looks like the out of box solution with external storage and exporting ovfs is the only way as of now.

[SHARJEELK]

Hi Laegre,

Thank you for your response. Unfortunately this seems to be the only solution as of now.

Can you confirm if I try migrating VMs to different datastores while they are on, will they face downtime during storage vMotion? Can storage vMotion be done both hot and cold?

Your solution sounds more effective but I am a little skeptical of moving around all my production VMs like that.

Thanks,

Sharjeel

[Lalegre]

Hello Sharjeel,

For sure Storage vMotion can be done without downtime at all. Take into account that if you use an external drive it will be only local to one ESXi so the Storage vMotion could be done only locally but if you also need to migrate VMs from another ESXis you can do vMotion + Storage vMotion selecting the option to first move Datastore and then Compute Resources.

If you have to do the second option please make sure that vMotion has an stun time that actually is really low (Actually around 1 second). If you have a very sensitive application in could be impacted by that second. However most of the traditional applications are not impacted by it.

Also please take a look at the requirements for a Non-Shared vMotion in case you have to go with the second option also: Requirements and Limitations for vMotion Without Shared Storage

[SHARJEELK]

Thanks Lalegre,

I did identify around 30 datastores which have VMs that can be Storage vMotioned into other bigger datastores (as a starter for combining/consolidation activities).

With the first storage vMotion, the VM has moved to the another datastore, however I still see '.iorm.sf' and '.vSphere HA' folders inside the datastore.

Can I go ahead and unmount the datastore (from all 4 ESXi nodes)? Its an NFS Datastore by the way.

Will that help me reclaim the space too? Just thought to confirm before doing so. Would appreciate some insight.

[Lalegre]

Sure the file vSphere HA is created for doing Datastore Heartbeat and can be safely ignored as it is deleted once you unmount the datastore. Also the iorm.sf is the configuration file for Storage I/O Control feature and it will also be deleted as you are unmounting the datastore.

After you unmount also delete from the inventory and then go ahead with the reconfiguration in the storage side.