VMware Cloud Community
MonkeyMagic1979
Contributor
Contributor

Virtual Machine Datastore Decisions

Hi All

I am currently looking at reconfiguring my VMware environment as we are moving to new SAN's and I am looking at how the virtual machines are currently seated in our datastores.

At the moment we split our datastores depending on server demands etc.. But we always split off the virtual machine configuration from any VMDK's. A basic example of this I have shown below:

Datastore A (Typically R1\10 Arrays): Virtual Machine Configuration

Datastore B (Typically R1\10 Arrays): Operating System VMDK

Datastore C (Array dependent on IOP requirements) : Data Disks VMDK

Now is there anything with this setup that would cause me problems in the future that anyone could see? The reason I ask is because I am implementing SRM in the very near future and if this configuration would cause issues with that I will change it. The other reason is that I have been caught out with snapshots on the virtual machine configuration datastores filling disks.

As a rule we only use snapshots for backups using Veeam but sometimes the snapshots have stayed on VM's and caused issues due to the confguration datastores being smaller.

Any input would be greatly appreciated.

0 Kudos
8 Replies
a_p_
Leadership
Leadership

I can't answer the question about SRM, however regarding snapshots, things changed. With ESXi 5.0 snapshots are now created in their parent's datastores by default.

André

0 Kudos
AureusStone
Expert
Expert

As long as all of your datastores are protected (replicated) then you shouldn't have any issues.

It does seem like a complicated configuration through.  Do you configure it in this way because you have deduped SAN and want to save space or is it based on IOPS requirements.

0 Kudos
MonkeyMagic1979
Contributor
Contributor

Well in answer to your question it is more IOPS requirement as we are not currently using dedupe. Although I am thinking it is just causing more of a headache for admin of the datastores. We seem to be doubling up on datastores for VM's and it does become complicated for admins to sometimes track down quickly the locations of servers.

If we had both the config and OS VMDK contained together in one datastore we could add and remove servers depending on performance. Really I want to guage how other people go around configuring their datastores.

Thanks all for your comments it is most appreciated.

0 Kudos
JPK871
Enthusiast
Enthusiast

I agree with your assessment, this can easily become unwieldy to support especially as your environment begins to scale out.  Imagine trying to manage this when you have hundreds of VMs, I'm a firm believer in keeping is simple from a configuration standpoint.  I'd be much more apt to put the vmx, OS, and data drives together and then manage the IOPs on a machine-by-machine / datastore-by-datastore basis.

sketchy00
Hot Shot
Hot Shot

+1 on the "Seems complicated" thought.  While it seems like you have some justified reasons for doing so, I think it doesn't take advantage of the self-contained/portability of typical arrangements with datastores.  (VM so-and-so in datastore x...)  Aside from VM swap files (not necessarily guest OS swap files), and perhaps some large vmdk that doesn't need to be replicated, I think you will find most carving up 500GB to 1TB LUNS, then cramming a bunch of VM's in there.  If one datastore proves to demostrate itself as a hotspot, then you find the problem machine, and adjust accordingly.

In other words, I'm sure your configuration works, but I'd be scared trying to recover it in DR scenarios, as well as trying to figure out how to scale out, or for geo-political or security divisions.  I can't help but think of some networking analogies to this as well, where a lot of times you have to design with these considerations in mind (e.g. having a VLAN that includes every printer in an organization seems neat and logical, but it doesn't represent the organizational, geographical, or business related objectives).  Its my postion that similar principals should be applied to computing and storage resources.  Sorry for digressing, but I'm just trying to better illustrate the concern.

AureusStone
Expert
Expert

Yeah that is right.

The only thing I will add is if you have vSphere 5 with Enterprise+ licensing you can use SDRS which would be perfect for your situation.

http://www.vmware.com/products/datacenter-virtualization/vsphere/vsphere-storage-drs/overview.html

0 Kudos
MonkeyMagic1979
Contributor
Contributor

Thanks for all for you replies to my queston it has given me food for thought.

I am going to look at redesigning the layout going forward moving to a much more simpler layout. As going forward this will help our admins and DR solution of replicating volumes between SAN's.

I am also going to be looking at site recovery manager in the near future so will check out the guides online to see exactly how that deals with replicated data.

0 Kudos
tscott2340
Contributor
Contributor

We just got a new SAN and VM environment as well and I was going to post a very similar question.. So how is everyone carving out their SAN and placing their VMs?

We have a 42TB (raw) LeftHand SAN and we are going to P2V probably around 180 servers in the long term.. 95% of these are all production for a variety of apps.. How do you group them? DO you group them? Do you just create 1.5TB or 2TB datastore and put as many VMs as you can in and then just create another one and so on and so forth?

0 Kudos