So this is an interesting topic… Server virtualization technologies have become so simple and efficient for most organizations.. Using the advanced technologies to provide high availability like ( Hyper-V Live and Quick migration or VMWare  VMotion ) had make things easier to keep your VMs HA and retain your SLA. Although that using Clustering technologies have some recommendations based on the used technology.. MS Exchange team already published recommendations for running Exchange in the Virtualization Environments.

Part of it was “We recommend using the built-in Exchange Server high availability solutions for virtualized Exchange servers instead of hypervisor-provided clustering or portability solutions (such as Hyper-V’s quick migration feature). The features found in Exchange Server (in particular, cluster continuous replication (CCR)) provide greater benefits than those found in hypervisor solutions that move virtual machines between physical root machines.

We do not recommend using hypervisor-based virtual machine migration (such as Hyper-V’s quick migration) for virtualized Exchange servers. In a virtual machine migration configuration, an unscheduled outage can result in data loss. In a CCR environment, this type of data loss is largely mitigated by a feature called transport dumpster. The transport dumpster takes advantage of the redundancy in the environment to reclaim some of the data affected by the failover.”

So what about the rest of technologies like File Server clusters or DHCP. What if you want to implement DHCP and File Server Clusters ( Guest Clustering ) over Hyper-V hosts Cluster ( Cluster over Cluster ) ?

is that supported ? Do we have any limitations or well known problem with that ?

It takes some search and some support from Microsoft and hereunder the answer

This would be a combination of guest clustering and host clustering. This scenario would be working as long as you pass the cluster validation report.

Here are some tips for combing guest and host clustering for your information.
• Affinity – It is recommended that the nodes of a guest cluster should reside on different hosts to achieve the highest levels of availability.  If a host were to crash, having VM’s associated with the same guest cluster distributed across multiple hosts will enable applications to recover faster.  To accomplish this, configure the cluster group property AntiAffinityClassName.  The host cluster will attempt to keep VM’s with a consistent string value (such as the VM name) off the same host.  See this KB for additional details:  http://support.microsoft.com/kb/296799
• Heartbeat Thresholds – It may be necessary to increase the cluster heartbeat thresholds of a guest cluster when a mobile guest VM node is being moved to a new host, through a process such as live migration.  During the migration of the VM it will be temporarily unavailable for a brief period of time which cluster health detection may detect, increasing the thresholds will mitigate clustering assuming the node is down and incorrectly taking recovery actions.  This can be accomplished by increasing the SameSubnetThreshold and SameSubnetDelay cluster common properties.  See this document for additional details:  http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx

So you can provide more redundancy for your VMs by providing a combination of host and guest clustering and get rid of your down time.

Some useful links

Hyper-V Guest Clustering Step-by-Step Guide

http://blogs.technet.com/b/mghazai/archive/2009/12/12/hyper-v-guest-clustering-step-by-step-guide.aspx

Failover Clustering & NLB Documents and Resources

http://blogs.msdn.com/b/clustering/archive/2009/08/21/9878286.aspx

Hyper-V: Using Hyper-V and Failover Clustering

http://technet.microsoft.com/en-us/library/cc732181(WS.10).aspx