rakeshm's VM Management Blog

Managing a virtualized environment

VMs and LUN Allocation

VMs and LUN Allocation

  • Comments 5
  • Likes

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
  • Hi there, Rakesh just posted a new blog , through which he explains the ins and outs about the model

  • 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.

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

  • 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.

  • Hi,
    Create a Differencing vhd disk for share it with multiple VM's with Files.vhd as parent.

    Found some info:

    A Differencing VHD is a so-called 'child disk' based on a linked parent disk. Creating a child disk by specifying the parent disk establishes the parent-child relationship. Since then a child disk stores those changed/modified data of the parent disk, i.e. the write operations to the parent disk.

    A differencing disk is associated with another virtual hard disk that you select when you create the differencing disk. This means that the disk to which you want to associate the differencing disk must exist first. This virtual hard disk is called the "parent" disk and the differencing disk is the "child" disk. The parent disk can be any type of virtual hard disk. The differencing disk stores all changes that would otherwise be made to the parent disk if the differencing disk was not being used. The differencing disk provides an ongoing way to save changes without altering the parent disk. You can use the differencing disk to store changes indefinitely, as long as there is enough space on the physical disk where the differencing disk is stored. The differencing disk expands dynamically as data is written to it and can grow as large as the maximum size allocated for the parent disk when the parent disk was created.

    http://technet.microsoft.com/en-us/library/cc720381(v=ws.10).aspx
    ://blogs.technet.com/b/yungchou/archive/2013/01/23/hyper-v-virtual-hard-disk-vhd-operations-explained.aspx
    http://blogs.technet.com/b/ranjanajain/archive/2010/03/23/virtual-hard-disk-vhd-architecture-explained.aspx

    A differencing VHD is a file representing the current state of the virtual hard disk as a set of modified blocks in comparison to a parent virtual hard disk.

    Differencing VHDs can be associated with either a fixed sized or dynamically expanding VHD.
    Differencing VHDs can also be associated with another differencing VHD but they cannot be associated with a physical disk.
    Differencing VHDs are used to prevent changes from being made in their parent VHD to which they are applied and are used to implement a number of additional features.

    In Hyper-V, differencing VHDs are also created automatically whenever snapshots are taken of a virtual machine.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment