This process is fairly fast but typically makes the VM unavailable for about 30 seconds (or longer, depending on configuration), which causes users to be disconnected.One of biggest shortcomings of Server 2008’s Hyper-V is its inability to move a VM between nodes in a failover cluster without any downtime.In a failover cluster, shared disks (i.e., disks that all the nodes in a cluster have a path to—which means they’re typically LUNs on a SAN) are resources of the cluster.Like other resources in a failover cluster, these resources have only one owner at any one time.This restriction means that in Server 2008, each VM must have its own LUN so that each VM can be moved independently of other VMs around the cluster, by dismounting the LUN and mounting on the new node.A limit of one VM per LUN means administrators must deal with a lot of LUNs, as well as a lot of potential wasted space, because each LUN is provisioned with a certain amount of space and room to grow.Consider Hyper-V using failover clusters—particularly VMs. This lack of sharing introduces several design considerations.
Moving one VM on its own that shares a LUN for storage with another VM isn’t possible; all the VMs sharing the LUN must move as a collective unit.
Therefore, multiple mounts of a LUN are blocked because only one node can own the resource.
The resource owner mounts the LUN and can access the NTFS volumes stored in the LUN.
Another solution is to fundamentally change NTFS and how it handles metadata updates; however, changing NTFS in this manner would be a Herculean task and would require numerous changes to the Windows OS, as well as changes to many applications and services that use NTFS—not to mention the additional testing required.
Microsoft’s solution to the shared nothing problem was to make NTFS sharable without changing the file system at all—which seems like an obvious solution but is more difficult to implement than you might think.