VMware Cloud Community
digglife
Contributor
Contributor
Jump to solution

Need to Consolidate 2 vmdk's into 1 datastore on SAN.

Hi,

I have a situation where I have created a server (Windows 2008) with 2 disks, C and E. C resides in its own SAN datastore (80GB). E resides in another datastore (also on the same SAN), 500GB. ESXi/vCenter 4.0.x

Unforetunately, the SAN's VM snapshot/backup software will not support a VM with multiple datastores (I know, stupid ain't it?). VMWare's Data Recovery product does support this, but anyway ....

If I do elect to reconfigure this VM into using a single SAN datastore to host both C and E drives, I am wondering the best way to do this? I have vCenter (essentials plus, so no Storage vMotion or anything fancy).

I do notice that browsing the datastore I see that the vmdk files can be right-clicked and there is a 'Move To' option. My 80GB datastore contains all of the vmx files, etc.

So, I was thinking I could:

1. Resize the 80GB SAN volume to 580GB or slightly larger.

2. Extend the vmfs datastore from 80GB to 580 GB. I have extended vmfs in the past, it seemed pretty good. Didn't notice any extents, which people say are problematic.

3. Move the 500GB vmdk into the new 580GB-sized datastore. It only has about 60GB of data, and is thin provisioned in VMWare and on SAN.

4. Ensure the VM's settings show the correct new location for its moved hard disk.

5. Power on and test.

Or, perhaps I was thinking I could create a brand new datastore of the appropriate size to hold both disks, then run converter to clone the VM back onto the same host, but with drives changed to go to the same (new) datastore.

In the meantime I have asked Equallogic for an explanation as to why their product cant do backups of VMs with multiple datastores. This will be important for an Exchange 2010 rollout later this fall ... I plan on having 2-3 LUNs used for databases, logs, os.

0 Kudos
1 Solution

Accepted Solutions
golddiggie
Champion
Champion
Jump to solution

I would NEVER make a datastore the exact size of the VMDK files that are contained within it... You need to maintain at least 10% free space (or don't exceed 90% utilization on the datastore). It's a good idea even when you're using thin provisioning, since if your VM's start to use up their allocated space (when you're too far over allocated) you'll quickly run into major issues.

I would make a single LUN of 1TB, migrate the VM (and all it's files) to the new datastore, and go from there. I would advise checking the VMDK file names since you could easily have the exact same file name since you placed them onto two differetn VMFS datastores initially (another good reason to NOT do that)... I've also made it a standard practice to make sure a VM resides on just one datastore/LUN at a time. Going with that method ensures that all software/tools/utilities will not have an issue with the VM (or all the VM's)...

VMware VCP4

Consider awarding points for "helpful" and/or "correct" answers.

View solution in original post

0 Kudos
3 Replies
continuum
Immortal
Immortal
Jump to solution

I would move the vmx and the small vmdk to that large datastore.

To do you do not need any special tools - just a texteditor - to fix the paths of the scsiX:Y.filename entries - and vmkfstools to clone the vmdk to the new location and use thin provisioning.

Not sure if that fits with your free space -can't follow your calculations from above ... ?




_________________________

VMX-parameters- WS FAQ -[ MOAcd|http://sanbarrow.com/moa241.html] - VMDK-Handbook

You also find me in the support crew of PHD Virtual Backup


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

0 Kudos
golddiggie
Champion
Champion
Jump to solution

I would NEVER make a datastore the exact size of the VMDK files that are contained within it... You need to maintain at least 10% free space (or don't exceed 90% utilization on the datastore). It's a good idea even when you're using thin provisioning, since if your VM's start to use up their allocated space (when you're too far over allocated) you'll quickly run into major issues.

I would make a single LUN of 1TB, migrate the VM (and all it's files) to the new datastore, and go from there. I would advise checking the VMDK file names since you could easily have the exact same file name since you placed them onto two differetn VMFS datastores initially (another good reason to NOT do that)... I've also made it a standard practice to make sure a VM resides on just one datastore/LUN at a time. Going with that method ensures that all software/tools/utilities will not have an issue with the VM (or all the VM's)...

VMware VCP4

Consider awarding points for "helpful" and/or "correct" answers.

0 Kudos
digglife
Contributor
Contributor
Jump to solution

So, by migrate I assume doing something like using Veeam's FastSCP to copy\move into the new datastore? If the vmdk names are the same, could I rename one and modify the vmx file?

I tend to make the datastore 10-15% larger than the total of the vmdk's to allow for snapshot space, growth, etc.

The reason I went with >1 LUN was for flexibility for when the data disk (E:) got full and needed to be increased or another disk needed to be added. This VM is a file server, with 3-4 GB of growth each week.

So the only option when the 500GB disk starts to get full would be to either extend the LUN, then the datastore, then the vmfs, and finally increase the partition size in the OS. (or, add another disk into the free space on the datastore, still maintaining 10-15% free, after extending the LUN and the datastore).

In the future, I am wondering if it would be better to have:

1 datastore, 1 vmfs filesystem within it for C (OS), 1 vmfs for E (Data)

or

1 datastore, 1 vmfs filesystem. VM using that as a single disk. OS partitioned to use this a C (OS) and E (Data). This would be trickier to grow out as more space is needed I think.

0 Kudos