VMs and LUN Allocation

Happy New Year everyone!

A few months into the release of SCVMM, we’ve heard lots of great feedback from customers and the response has been very positive. Keep sending feedback and suggestions on how to make the product even better in future releases!

One thing we’ve heard is that folks want to have multiple VMs stored on a single LUN and still get the capabilities of SAN/quick migration. One of the feature requests we get as a result is “can you guys unblock placing multiple VMs on a LUN in SCVMM 2008?” I thought I'd address this question directly in this blog posting.

At the end of the day, our file system only allows a LUN to be mapped to a single physical host at any given time. This means that the unit of migration using SAN transfer in SCVMM 2008 is the LUN (LAN migration works fine at the VM level). If you were to put multiple VMs on a single LUN, they would all need to move together when migrated which is not the behavior that most customers want. Really they want the ability to put multiple VMs on a LUN and continue to manage the VMs as individual entities so that they can be individually migrated, stored to the library etc.

One way to solve this is to create a completely new file system and have it enable simultaneous access to LUNs across servers. Some vendors have gone down this path but you just trade one problem for a new set of problems. Third party software doesn’t work on custom/boutique file systems, backup systems typically need to be re-engineered, storage security needs to be re-thought through etc. As an example, VMware’s consolidated backup solution goes to great lengths to expose ESX LUNs to Windows Servers so that they can be backed up with your existing infrastructure. You really shouldn’t have to do unnatural things to get access to your data. Windows has plenty of partners that are happy to offload your backup traffic from production to backup proxy servers using snapshots and the Volume Shadow Copy Services (VSS) built into Windows Server but it’s not required. That’s because sometimes it’s easier to back up directly from the production server (during off hours perhaps) since the source data is naturally already distributed and it helps you get your backups done within your backup window. Also, it doesn’t require complicated or expensive hardware and software but ultimately it’s your call on how you want to set this up and you can use either the direct or offload model for backup.

In Windows Server 2008 R2, we’ll provide a layer on top of NTFS that provides a clustered shared volume file system (CSV). Hyper-V and SCVMM Vnext will take advantage of this feature to enable multiple VMs per LUN scenario (Windows Server 2008 R2 will also enable live migration of VMs between servers). You can read more about this here. This solution has the benefit of snapping into your existing Windows environment without seriously disrupting existing processes or procedures. Of course we also work with partners to provide value-added solutions with additional features that help you extend the functionality even further.

Bottom line – we’ve heard the feedback and the solution that you need is almost ready.

P.S. – Most SAN/block level replication software replicates at the LUN level. This means that for most DR solutions (including our competitors and partners) failover typically happens at the LUN level so all VMs on that LUN failover together.

Rakesh