One-to-One LUNs for VMWare virtual machines, or multiple VMs per LUN?

[quantum-it]

MI am in process of rolling out a CS-215, to be as dedicated storage for a VMWare ESXi 5.5U2 environment.

My question is about whether or not to share out an individual LUN for each dedicated VM, or to share out a LUN large enough to host multiple VMs.   My thinking behind the 1-1 LUN/VM concept is that it will allow me to snapshot the VM LUNs individually, so that I can recover individual VMs using the Nimble snapshot manager quickly, versus having to export a snapshot to the filesystem and then copy the VM's files back to the LUN directory.   It just seems cleaner to be able to roll back the snapshot using the SANs native functions, than the VMWare snapshotting functions.

Currently we're only going to be hosting about 10-15 VMs, each of them being relatively static (Windows machines hosting single purposes applications, and not SQL Server or Exchange).

[jeberhardt42 · Accepted solution]

Part of this decision depends on what you're doing within ESXi, such as if you're licensed and utilizing SDRS. If you're using it, this design doesn't make much sense.

Most of the environments that i've setup/configured have been a 1:1:1 relationship of Nimble vol > VM Datastore > Virtual machine and it works great for smaller environments. This type of setup can consume additional storage space because each volume is formatted separately with VMFS5, but overall, it's fairly minimal.

I've had the same mindset that you had with the snapshots at the SAN level. If we need to recover a VM from a snapshot, it's safer and cleaner to only have 1 VM living within that volume where you can roll back the snap at the SAN level and be back on your feet without needing to worry about reverting other servers back.

There will be a lot of different opinions out there in regards to this, but bottom line is what you're comfortable with for your own environment. There will be more management of this type of environment as you'll be monitoring 10 - 15 datastores (alerting, etc.) but I personally feel that it's a great setup for you're type of environment.

[quantum-it]

Thanks for the confirmation, Joe.

We're not a massive virtualization house (yet) and we don't plan on licensing or using SDRS, which is exactly what my thinking was for doing a 1:1:1.    The VMs themselves aren't that large either (100GB max for the service VMs), so there's plenty of space available (7+ TB) on a single CS-215 shelf.

[cdbeohmer30]

+1 on @Joe Eberhardt's feedback.  I have a mixed environment of some storage arrays with a 1:1 and some many:1.  Having 1:1, if you can afford the admin overhead, gives you more options for snapshots and replication, especially in a use-case in which you don't need/want to have a full replica of your environment at a DR site.  You can do block-level replication of volumes to a DR location for select servers without taking everything.  Arguably there are tools that can keep this from being an issue, but the point is that you have options at your disposal.

If I had the opportunity I'd redo my many:1 array as a 1:1.

[BBloksma]

For getting a VM back from a snapshot you don't need to have a VM per LUN/datastore.
Not even for speed.

As a matter of fact I like doing it this way (described below) as I get to access the old snapshot data as the new (corrupted?) data.

I have multiple VMs per LUN. When a VMs data gets corrupted and I have to fall back on a snapshot I will create a clone DS from the last known good snapshot. I might create several if I am not sure which snapshot to use. If the datastore is called DS01 I will usualy create something like DS01-Clone-11apr2015-1015

I can immediatly start to run the VM from that cloned DS which is what I want most of the time, get that darn server back up and running.

At the same time I still have my original datastore with the corrupted data and I can analyse at my leissure whether any of that data is still useable.

For a time I can access both situations. and maybe mount a VMDK to another VM and salvage some data.

One I have salvaged all I can I will delete the original VM on the original datastore. Then do a VMotion of the running VM on the clone to the old datastore, on any other convenient location.

Once that is all done I can delete the clone I created and all is back to normal.

[Nick_Dyer]

Hello; great question.

I know you mentioned that you're using vSphere 5.5 u1... this discussion becomes slightly mooted with the use of the new VMware Virtual Volume (aka VVOLs) technology in vSphere 6, as it will allow per-vmdk creation and management of storage presentation without the need for VMFS and the downsides that come with it. Albeit VVOLs only really applies for the most important VMs where things such as granularity of block size & caching, snapshot policies, restoration & retention etc - the rest will still reside in VMFS.

Rawlinson Rivera (aka @punchingclouds on Twitter) has a few great blogs on it here...VVOLs | VMware vSphere Blog - VMware Blogs

We'll have a tech preview version of this new technology in our upcoming 2.3 release slated very soon. I'll also be recording an on-demand VVOL & Nimble webinar very shortly which i'll post on the forums when it's ready.

[quantum-it]

Joe,

Just for a follow up. I went with the 1-1 LUN-to-VM ratio and it's exactly what I needed to do.   The snapshot recovery times and ease of restoration are painless with the NS appliance, and it does exactly what I was expecting it to do.

Thanks for the feedback.  It helped.