Articles‎ > ‎Computing‎ > ‎

Hyper-V VM Best Practices for Configuration and Deployment

Are you building a new a Hyper-V virtual machine (VM) environment, or maintaining an existing configuration?  There are several deployment and configuration considerations when determining the best practices for managing any VM implementation.

Below is a list of best practices for the configuration and deployment of Hyper-V VMs:
  • Make sure you understand the application scale and scope, before trying to build an environment to support it.
    • Application requirement considerations from the project owner:
      • Application system resource (e.g. RAM, CPU, network, and storage [local or SAN]) requirements
      • High availability (HA), disaster recovery, administration, monitoring and backup requirements.
      • Service Level Agreements, fixing problems (major and minor), deployment and maintenance.
  • Monitor VM Host utilization (e.g. RAM, CPU, network, and storage), then balance the VM workload across your environment
    • You want to make sure that you don't overload one VM host with too many guest VMs or VMs that are resource intensive.
  • Utilize standardize VHD based images for building application VMs (e.g. Web Front-Ends, SQL, etc.)
    • This best practice provides based line images that can be used to quickly deploy standard applications.
  • Utilize Virtual Machine Manager (SCVMM) to manage the environment to deploy the VMs to the host.
  • Utilize build scripts/deployment tools to setup standard applications and environment builds.
    • This best practice is time consuming, but it provides a uniform deployment across all your host VMs
    • All build scripts are all going to have to be custom written, while you may be able to find 3rd party deployment tools
  • Utilize scripts/testing tool to validate applications and environment builds
    • This best practice is time consuming, but it provides a uniform testing methodology across all your host VMs
    • All test scripts are all going to have to be custom written, while you may be able to find 3rd party testing tools
  • Validate all production changes in a PPE (Pre-Production Environment) before deploying to production
    • Its important to make sure that developer and engineers validate all production changes in PPE first before deploying them to production.  If any issues arise with a specific change it doesn't effect the production environment.
  • Make sure that you're managing your Hardware, OS and application licensing, services and support agreement/contracts.
    • Virtualization makes it easy to get out compliance with your OS and application licensing.
Below are some Hyper-V best practices for setting up VM hosts and guests:
  • Make sure that critical infrastructure (such as: domain controllers, or other critical applications) are not all running on the same VM Host which can create a single point of failure. You need to stagger these assets across multiple VM hosts.  For example, you would want your primary domain controller being on one VM Host, and backup controller on another. 
    • That way if you lose the VM Host (e.g. due to a hardware or software failure) you won't lose access to your critical infrastructure.
  • It is a good idea to group VMs to specific HOSTs based on roles (Internet facing WFE vs SQL) or value of the data/asset (e.g. domain controllers, PII or confidential data). 
    • This way if an Internet facing WFE is compromised by an attacker utilizing a VM escape attack, the won't have easy access to valuable data or infrastructure.
  • Deploy your VM hosts with the server core features then GUI
    • Minimizes OS footprint on the server, which reduces the number of services that are required to run, which make it easier to patch, less OS resource overhead on the server, and reduces the attack surface of the machine.
  • Isolate the HOST server and GUEST VM interfaces on different networks/VLANs
    • This serves two purposes, prevents the VMs from being used as a target for attacking the host server.  It also isolates host/guest traffic.
  • Make sure the VM HOST machines has enough processors (both physical/logical), RAM and NICs to support the applications that will be running.
    • In Performance Monitor watch Host disk performance Counters:
      • Avg. Disk Sec/Read (ideally between .001 -.010 under peak load)
      • Avg. Disk Sec/Write  (ideally between .001 -.010 under peak load)
      • Operating System Thresholds:
        • Under .010 (10 milliseconds) is Good
        • over .015 (15 milliseconds), under 025ms average is Acceptable to Poor
        • Over .025 (25 milliseconds) average is Serious to Critical
  • Run the VM HOST servers in an HA configuration, and use a SAN (utilizing Fiber or iSCSI and LUNs w/redundancy) to host the VM files (configuration/VHDs in Cluster Shared Volumes on the SAN). 
    • If you have utilize local drives instead of a SAN, it would help performance/redundancy to store data across multiple drives (and controllers) utilizing RAID
  • Make sure that VM system resources are properly allocated (e.g. RAM, Storage, CPUs, and Network) for the application.
    • When setting up the storage configuration on the VM, its better to SCSI interface option then IDE
      • SCSI provides up 256 disks on a VM, and also allows you to hot add or remove VHDs
  • Make sure all VHDs are fixed disk and not dynamically expanding.
  • Make sure to use the same virtual switch and network interface names 
    • Critical for migrating VMs between hosts and fail-over clustering
  • Make sure that all (or critical) data is backed up on a regular basis
  • Make sure the latest security patches were deployed to the GUEST VMs/HOST
  • Make sure the Hyper-V integration components on the GUEST VM are up-to-date
    • This is very important if you upgrade your HOST VM OS from an older version, the integration components will be required for compatibility and to take advantage of the new features of the hypervisor.
  • Make sure to impose CPU limits on the GUEST VMs to prevent one machine from dominating all the system resources.
  • Make sure that the both the VM HOST and GUEST synchronize their time with a trusted host (e.g. domain controller)
    • This sounds like a minor issue, but if time goes out of sync it can cause a lot of problems.
  • Make sure your hard drive volumes are uing the correct block size
    • Use the command fsutil fsinfo ntfsinfo <drive_letter> (e.g. fsutil fsinfo ntfsinfo c:)
      • The Bytes Per Cluster should be 4096.

Tips and Tricks

  • Make sure that your anti-malware software is designed compatible with your VM software environment.  It needs to be optimized to reduce the impact on system resources while not interfering with the criticalVM processes or files (such as the VHD) at the host level.  You also may need to stagger the schedule AV scans to avoid creating high load on the VM host and slowing down performance across the server.
  • Instead of connecting to the SAN storage via iSCSI or Fiber Channel from within VM, make the external storage connections at the host OS level.  Then you can connect the guest OS to the external storage by treating the iSCSI or Fiber connected volume as a SCSI pass-through disk.  This should give you the best possible performance to the SAN storage because you're not having to initiate the connect at the guest OS level (which can be slower because it has to be virtualized). 
    • Note: results may vary depending on the hardware/software that you're using.
Comments