Tip: 7 Best Practices for Physical Servers Hosting Hyper-V Roles

http://technet.microsoft.com/en-us/magazine/dd744830.aspx

Before setting up a physical server to host the Hyper-V role, download, read, and understand information included in the white paper “Performance Tuning Guidelines for Windows Server 2008”. Three sections in this white paper that can have a significant impact on the performance of the physical server discuss tuning the server hardware and setting up the networking and storage subsystems. These are especially critical for Hyper-V because the hypervisor itself sits on top of the hardware layer as described earlier and controls all hardware in Windows Server 2008. The operating system itself essentially runs in a virtual machine, better known as the Parent Partition.

Here are seven best practices for physical servers hosting the Hyper-V role.

Avoid Overloading the Server
Determining the number of virtual machines that will be hosted on the Hyper-V server and the workloads they will be handling is critical. The version of the operating system that will be installed on the physical server can help in this regard, so the first “best practice” is to consider using Windows Server 2008 Datacenter x64 with Hyper-V. The Datacenter x64 edition supports up to 64 processors, 2 terabytes of physical memory, and 16 failover cluster nodes for Quick Migration scenarios and allows unlimited virtual machines to be run in Hyper-V. Selecting a Server Core installation provides added benefits, including enhanced security and lower maintenance.

Ensure High-Speed Access to Storage
For storage, consider using a storage area network (SAN) that is configured with highspeed (10,000 rpms or greater) drives (SATA or SAS) that support queued I/O and Raid 0 +1 configurations. You can use either Fibre Channel or iSCSI SAN hardware.

Install Multiple Network Interface Cards
For networking, be sure to have more than one network card installed on the physical server and dedicate one network interface to Hyper-V server administration. This means no virtual networks in Hyper-V will be configured to use this NIC. For high-workload virtual machines, you might want to dedicate a physical network adapter on the server to the virtual network the virtual machine is using. Ensure virtual machines that share a physical adapter do not oversubscribe to the physical network. Use the Reliability And Performance Monitor to establish a performance baseline for the load and then adjust NIC configurations and loads accordingly.

If you have only a single NIC in the machine that you are configuring the Hyper-V role on and you are doing the configuration remotely (say, in an RDP session) if you choose to bind the Virtual Switch Protocol to the single NIC in the machine, you will be disconnected from your session and a reconnection might not be possible until the newly created virtual network adapter has been properly configured.

Avoid Mixing Virtual Machines That Can Use Integration Services with Those That Cannot
Do not mix on the same physical server virtual machines that can take advantage of Hyper-V Integration Services with those that cannot. Virtual machines that cannot use Integration Services must use legacy network adapters to gain access to the physical network. To accommodate legacy network adapters, you might need to disable some high-end features on the network interface, which can unnecessarily limit the functionality of the synthetic devices. Additionally, using emulated devices places an extra workload on the Hyper-V server.

Configure Antivirus Software to Bypass Hyper-V Processes and Directories
If you are running antivirus software on the physical server, you might want to consider excluding the Vmms.exe and Vmswp.exe processes. Also, exclude the directories that contain the virtual machine configuration files and virtual hard disks from active scanning. An added benefit of using pass-through disks in your virtual machines is that you can use the antivirus software running on the physical server to protect that virtual machine.

Avoid Storing System Files on Drives Used for Hyper-V Storage
Do not store any system files (Pagefile.sys) on drives dedicated to storing virtual machine data.

Monitor Performance to Optimize and Manage Server Loading
When running multiple high-workload virtual machines on a Hyper-V server, ensure a proper aggregate performance baseline is obtained over a specified period of time (say, five days during normal working hours) to ensure the hardware configuration for the physical server is optimal to support the load being placed on it by the virtual machines. If adding more memory, processors, or higher performing storage is not possible, you might need to migrate the virtual machines to other Hyper-V servers.

Understanding where your virtual machine files are [Hyper-V]

http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/03/10/understanding-where-your-virtual-machine-files-are-hyper-v.aspx

To be honest, I am surprised that I have not blogged about this before, but today I would like to talk about how virtual machine files are placed on the hard disk. 
Virtual Machine files
The first thing to know is what files are used to create a virtual machine:

• .XML files
• These files contain the virtual machine configuration details.  There is one of these for each virtual machine and each snapshot of a virtual machine.  They are always named with the GUID used to internally identify the virtual machine or snapshot in question.
• .BIN files
• This file contains the memory of a virtual machine or snapshot that is in a saved state.
• .VSV files
• This file contains the saved state from the devices associated with the virtual machine.
• .VHD files
• These are the virtual hard disk files for the virtual machine
• .AVHD files
• These are the differencing disk files used for virtual machine snapshots

Understanding data roots
Hyper-V has a concept of the “virtual machine data root” and the “virtual machine snapshot root”.  These are the locations where the virtual machine configuration (.XML) and saved state (.BIN & .VSV) files are stored.  For example – a virtual machine which had a virtual machine data root of “D:\Foo” and a snapshot data root of “D:\Foo” and had two snapshots would have a file structure like this:
D:\Foo
D:\Foo\Snapshots
D:\Foo\Snapshots\[Snapshot #1 GUID directory]
D:\Foo\Snapshots\[Snapshot #1 GUID].XML
D:\Foo\Snapshots\[Snapshot #2 GUID directory]
D:\Foo\Snapshots\[Snapshot #2 GUID].XML
D:\Foo\Virtual Machines
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]
D:\Foo\Virtual Machines\[Virtual Machine GUID].XML
If the snapshots and the virtual machine had saved states associated with them – then the file structure would look like this:
D:\Foo
D:\Foo\Snapshots
D:\Foo\Snapshots\[Snapshot #1 GUID directory]
D:\Foo\Snapshots\[Snapshot #1 GUID directory]\[Snapshot #1 GUID].BIN
D:\Foo\Snapshots\[Snapshot #1 GUID directory]\[Snapshot #1 GUID].VSV
D:\Foo\Snapshots\[Snapshot #1 GUID].XML
D:\Foo\Snapshots\[Snapshot #2 GUID directory]
D:\Foo\Snapshots\[Snapshot #2 GUID directory]\[Snapshot #1 GUID].BIN
D:\Foo\Snapshots\[Snapshot #2 GUID directory]\[Snapshot #1 GUID].VSV
D:\Foo\Snapshots\[Snapshot #2 GUID].XML
D:\Foo\Virtual Machines
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]\[Virtual Machine GUID].BIN
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]\[Virtual Machine GUID].VSV
D:\Foo\Virtual Machines\[Virtual Machine GUID].XML
Some key things to highlight about data roots:

• We always create a “Virtual Machines” folder under the virtual machine data root and store the virtual machine configuration files there.
• We always create a “Snapshots” folder under the snapshot data rot and store the snapshot configuration files there.
• We fully support multiple virtual machines having the same virtual machine and snapshot data root

Understanding VHD and AVHD locations
.VHD files can be created pretty much anywhere you want.  In Windows Server 2008 R2, .AVHD files are always created in the same location as their parent .VHD files.
Common Virtual Machine File Configuration #1 – Default Virtual Machine Data Root
A virtual machine with a default virtual machine data root is one where you created the virtual machine and accepted the default options in the new virtual machine wizard, specifically where you did not check to “Store the virtual machine in a different location” on the first page of the new virtual machine wizard:

In this configuration option the virtual machine data root and snapshot data root will be set to the path specified under the Hyper-V Settings in the “Virtual Machines” setting, and the virtual hard disk will be created under the path specified under the Hyper-V Settings in the “Virtual Hard Disks” setting:

These paths are normally set to “C:\ProgramData\Microsoft\Windows\Hyper-V” for the “Virtual Machines” setting and “C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks” for the “Virtual Hard Disks” setting.  That said – I usually change these settings to “D:\Hyper-V\Configuration Files” and “D:\Hyper-V\Virtual Hard Disks” on my systems as I find this easier to work with.
Common Virtual Machine File Configuration #2 – External Virtual Machine Data Root
If you do select to “Store the virtual machine in a different location” you will get what we call a virtual machine with an external virtual machine data root.

With this option we create a new folder named after the virtual machine, and set the virtual machine data root and snapshot data root to this folder.  We also default to creating the virtual hard disk in this new folder.

Common Virtual Machine File Configuration #3 – Exported / Imported virtual machine
If you export a virtual machine a virtual machine and then import it without checking the option to “Duplicate all files so the same virtual machine can be imported again”, you will end up with a virtual machine that looks like a virtual machine with an external data root – but there will be one difference.

Instead of having the virtual hard disks stored in the same location as the virtual machine data root – they will be stored in a “Virtual Hard Disks” folder under the virtual machine data root folder instead.
Changing a virtual machine to a default data root virtual machine
If you have an existing virtual machine that you want to change to a “default data root” configuration – the easiest way to do this is to export the virtual machine and then import it and check the option to “Duplicate all files so the same virtual machine can be imported again”.  The resulting virtual machine will be a default data root virtual machine.
Changing a virtual machine to an external data root virtual machine
If you have an existing virtual machine that you want to change to an “external data root” configuration, you have two options:

• Spend some time scripting the import / export APIs in Hyper-V.  It is possible to do it this way – but it is not easy.
• Move the virtual machine using System Center Virtual Machine Manager.  SCVMM will always transform a virtual machine into an external data root virtual machine in the process of moving it.

Changing the snapshot data root for a virtual machine
The only way to change the virtual machine data root for a virtual machine is by using import / export.  But the snapshot data root for a virtual machine can be changed at any time – as long as all snapshots are deleted first.  If you have deleted all existing snapshots you can change the snapshot data root by changing the “Snapshot File Location” setting for the virtual machine under the virtual machine settings user interface.

Hyper-V CPU limitation

By default Hyper-V only allows max 4 CPU core to be displayed on VM. To get the highest core available in your Hyper V host displayed on VM you simply edit count type value in VM config xml file and ...enjoy your work.

HyperV tips

• Never save state on a Domain Controller doing so can cause domain synchronisation issues.
• Never pause a Domain Controller, this can cause replication issues.
• Do not take Snapshots of Domain Controllers.
• Use Fixed size disks, this will improve performance, and help reduce disk fragmentation.
• Always defragment a physical disk before creating a virtual hard disk.
• Be mindful of the integration services affect on a Domain Controller. If you provide the time synchronisation service to a Domain Controller, you can cause time synchronisation issues in your domain.
• Don't expand the Virtual Hard Disk if you have snapshots which haven't merged with the main VHD. This will make it impossible to remerge them.
• If you cannot merge your snapshot (avhd) files back into the main VHD. You can attempt to use WinImage (http://www.winimage.com) to retrieve the data from within the snapshot file. To do this simply rename the snapshot file from string.avhd to string.vhd then open with winimage.
• Remember to uninstall the VM Additions before migrating Virtual Machines from Virtual PC or Virtual Server 2005 R2, otherwise you will receive the following error when you try to uninstall them from inside Hyper-V:
• You can install Virtual Machine Additions only on a virtual machine that is running a supported guest operating system

Merge avhd to vhd in HyperV by manual

Hyper-V brings to life several additional disaster recovery scenarios that can be leveraged to our advantage when the need arises. One of the features that really comes into play are VM snapshots. A Snapshot is basically a spot in time where the current running configuration of the Virtual Machines is saved to a Snapshot Differencing Disk file (AVHD), from which you can return to from the future. This tip will show you how to manually merge hyper-v snapshots into a single VM for point in time restores.

When you create a differencing disk the original VHD is no longer modified and the snapshots are merged with the original vhd only when it is powered off. In disaster recovery scenarios, There may be cases where we want to manually merge snapshots ( avhd )

In order to do this, You must first change the extension of the Youngest AVHD file to VHD. 
Any VHD differencing disk(avhd) will always go to its parent, not the root parent.

So if you have a bunch of AVHDs, Each depends on the one before it - like the rungs of a ladder - they are sequential.  Most folks have a very simple linear chain of snapshots. Example : VHD - AVHD1 - AVHD2 - AVHD3 - AVHD4. ( Here AVHD4 is the Youngest and AVHD1 is the Oldest)

The parent of AVHD4 is AVHD3.  The parent of AVHD3 is AVHD2  The parent of AVHDn would simply be the one before it.

You need to Start Merge From Young AVHD to Old AVHD to complete the Merge Operation.

To Start Merge follow the below steps

• First Identify the Youngest AVHD ( In Our Ex : AVHD4)

1. Rename the Youngest AVHD (AVHD4)  to VHD ( Should not rename all the AVHDs at a time, Need to Rename only Youngest Avhd First) 
2. You can choose the Edit Disk option from the Actions menu in the Hyper-V Management Console.
3. Click Next through the first screen and select the snapshot file on the following screen.
4. Select Merge on the next screen and choose the To parent virtual disk option and click Finish.
5. After Successfully Completing Merge, Now Automatically AVHD4 will be deleted.

• Now Rename the Second Youngest Avhd (AVHD3) to Vhd. and Repeats the Steps from 1 to 4 until Oldest AVHD ( AVHD1) Get Merge with Parent VHD.

Once this has completed you should create a new virtual machine with the default options you would normally use, selecting to use an existing virtual disk on the hard disk screen. You should select the newly merged VHD file.

Now you have Successfully Completed Manually Merge avhd to vhd in Hyper-V

http://social.technet.microsoft.com/wiki/contents/articles/6257.manually-merge-avhd-to-vhd-in-hyper-v.aspx