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

Comments

• Anonymous
  January 01, 2003
  Hi there, Rakesh just posted a new blog , through which he explains the ins and outs about the model

• Anonymous
  January 01, 2003
  Hi Rakesh,  I know this is an older blog post, so I'm not sure if you still review the comments.  I understand the limitations imposed with non-CFS failover of VMs, and that it takes all the VMs with it. But I still have to plead with you (Microsoft) to make it available in VMM.  I am deploying a Hyper-V cluster in a DR environment for a client right now, and I think it's a bit absurd to have to create upwards of 100+ LUNs to be able to manage their VMs; it's wasteful of SAN space, and it also presents the issue of overcoming the HBA's limitation of 64 persistent bindings to LUNs; I still haven't figured out the latter issue.  I've used 2008 R2, and know that CSV will alleviate these issues, but that's not scheduled for release until Q4. Is there any way to remove this limitation from VMM and allow it to manage multiple VMs on the same LUN? In an environment like this, there's going to be virtually no single-VM failover (no pun intended), so it doesn't make sense to deal with the headache if they don't have to.   Also, what about support for third-party clustered file systems, like Kayo FS? I read a blurb in some documentation or another that it is not supported, but is that "not SUPPORTED" as in it will not work, or "NOT supported" as in VMM will still not work?   Thanks.

• Anonymous
  January 01, 2003
  Thanks for this post Rakesh, this is a feature/design limitation that I am particularly interested in getting rid of.  Can you tell me or find out if there will be any SAN features or configuration required to get CSV working (over and above the configuration and features required for WS08 Failover Clustering)? Cheers, Jeremy.

• Anonymous
  January 01, 2003
  once you have WS08 clustering set up, CSV just sits on top, no other special configuration or features required