The following constraints fall under recommendations with priority 1:

• Enable HA admission control on all clusters. Reason: protect the running workloads at all times.
• Increase the number of hosts in certain clusters to analyze the various scenarios. Reason: there won't be enough ESXi hosts in some clusters to be able to run all of the existing VMs in the event of hardware failure.
• Use resource pools both to reserve resources for Site Recovery Manager (SRM) failed over VMs and to ensure fair access to resources during contention events. Reason: protect the workloads.

• Remove CPU reservations from VMs in the cluster. Reason: potential for a VM restart failure in the event of ESXi host failure. Configuration isn't providing any genuine benefit. 
• Ensure that the network time protocol (NTP) is configured correctly and that the NTP server has started on all ESXi hosts. Reason: having accurate timekeeping is essential in any IT environment.
• Use the route based on the physical NIC load-balancing algorithm for VM networking. Reason: make the most efficient use of available network bandwidth. Protect the workload.
• Investigate all level 3 recommendations in the vSphere 5.1 Hardening Guide. Unless there is a specific reason not to apply a security recommendation, then all recommendations should be applied. Reason: improved security.
• For the specific cases where VMs have RDMs, place the VM configuration files and .vmdk files on their own datastore and create SRM protection groups containing the datastore and RDMs. Reason: ensure that these specific VMs can be recovered successfully and independently of other VMs.
• Gain a thorough understanding of the recovery priorities and dependencies of VMs and configure SRM as appropriate. Reason: increase confidence that, in the event of disaster recovery, VMs can be recovered correctly and in the expected time frame. Services often have a preferred order of startup, which should still be adhered to during disaster recovery failover.
• Within SRM, configure a 1:1 datastore to protect group mapping where appropriate. Reason: this removes current issues with adding new LUNs to ESXi hosts and having situations whereby disaster recovery may not be possible during consistency group re-synchronization. It will allow multiple recovery groups to be initiated simultaneously and also allow for the testing or failover of specific services as opposed to every single protected VM. It adds complexity but introduces a substantial amount of intelligence and awareness to the disaster recovery plan.
• Have a pre-identified list of the 50% of silver VMs that would be recovered in the event of disaster recovery. Reason: this removes confusion during a disaster recovery event and allows a disaster recovery plan to be tested under controlled conditions.
• Introduce a service-based approach to recovery plans so that individual services can be tested and recovered as necessary. Reason: this brings a service orientated approach to disaster recovery and allows for the testing or failover of specific services as opposed to every single protected VM. It adds complexity but introduces a substantial amount of intelligence and awareness to the disaster recovery plan.

• Perform test recovery on a regular basis to increase confidence that disaster recovery would run as intended. Reason: increase confidence so that, in the event of a disaster recovery, VMs can be recovered correctly and in the expected time frame.
• Configure all virtualized Microsoft SQL Server clusters with best practice recommendations. Reason: ensure the stability of the cluster and remove performance inhibiting configurations.