Preparing your host systems
Many Prepare Your System chapters start by asking you to update all your hardware and software components to the latest releases. This chapter doesn't make an exception to this rule. In no other technical area have I seen so many successfully fixed environments due to firmware and driver updates. Windows Server with Hyper-V has undergone a very rapid development cycle with many releases in a short timeframe. Most hardware vendors released firmware and drivers with greatly shortened testing periods and were forced to release several updates due to firmware and driver updates to their products. Before you start setting up your Hyper-V host, update BIOS, RAID Controller, and the Network Interface Card (NIC) firmware to their latest release. Use the home page of the server-vendor, not the vendor of the individual components, for reference to the latest certified releases. Only use downloads from the individual component's' vendor if you see those problems you encounter fixed by the corresponding release notes.
Note
A Hyper-V host is highly dependent on the underlying hardware. Be very careful with the implementation; try and test every hardware component, every driver and firmware. Do not add in the production before double checking every single part of your newly created Hyper-V host. Moreover, use only supported driver and firmware.
Other than this, you only need your Hyper-V installation media, the Windows 10 Assessment and Deployment Kit (ADK) (shortlink http://bit.ly/29Ub3G5), and a USB drive to prepare for rapid Hyper-V installations. Download either the full version of Windows Server 2016 with Hyper-V from your Volume License Portal or the 180-day Evaluation version of Hyper-V. In fact, it does not make any difference whether you use the Evaluation edition or the full version media- they are interchangeable -the only difference will be made by the product key you enter. All Hyper-V features are also supported by the free editions of Hyper-V Server 2016; all the screenshots and configurations you see in this book are created using the full version of Windows Server 2016 with Hyper-V and could vary slightly from the free edition. Hyper-V is very easy to install.
Windows Server 2016 comes with a new licensing model based on core. Microsoft sells the license pack to support two cores. You need to buy at least eight license packs that support 16 cores. If you have beyond 16 cores in the server, you will have to buy extra license packs. In the following table, you can find the features provided by each edition:
Comparison between both Windows server editions
To familiarize yourself with Hyper-V, just insert the installation media, select it as the boot device, and click through the various options in the setup wizard. If this will be the only Hyper-V host you will ever install, this will be a great installation experience. Most of the time you will not stick to just one host and, to speed things up, we will mainly use unattended installations of the Hyper-V hosts from now on. The unattended setup uses configurations saved in a precreated unattended.xml
file, which can be either slipstreamed into the installation media or saved on a USB drive so that it's available to the host during installation. This enables a standardized and very rapid Hyper-V deployment with a onetime preparation.
About Nano Server
Nano Server is a new headless installation option in Windows Server 2016. Nano Server is similar to Windows Server in the server core mode, but without logon capabilities and the support of only 64-bit applications, tools, and agent. It provides a small OS footprint, a quick restart, and a far fewer updates. Since there is no GUI and no logon capabilities on Nano Server, the management is made remotely using PowerShell, WinRM, WMI or MMC. To run Nano Server in production, you need the Software Assurance. Nano Server (shortlink http://bit.ly/2acV3Q2) supports a lot of features such as Hyper-V, Failover Cluster, storage, and so on.
However, the servicing model provided with Nano Server requires a lot of build upgrade in a year. Nano Server follows the same servicing model as Windows 10 in enterprise called Current Branch for Business (CBB). CBB should be updated at least twice a year and it will be applied to Nano Server. These updates must be activated manually but Microsoft supports only the current branch and its immediate predecessor.
Because of the CBB servicing model, I do not recommend that you use Nano Server in production for Hyper-V and storage features. These features require efficiency and stability and need to be operational as long as possible. This is the exact opposite of what is provided by the CBB servicing model.
Creating unattended installation files
To create an unattended.xml
file, you can either start from scratch with a simple text editor or use a GUI. To leverage the second option, follow these steps:
- Start the setup of the Windows ADK you downloaded earlier. At the setup prompt, select only Deployment Tools, as shown in the following screenshot.
- After the completion of the installation, start Windows System Image Manager from the Start screen:
Windows ADK 10
- After the tool is fully loaded, select the File menu, open the Select an Image wizard, and browse to the
Install.wim
file or your installation media in the source's subdirectory. - Select the Windows Server 2016 SERVER STANDARD edition for your first unattended installation file and allow the creation of a new catalog file:
- If you receive a warning message stating that you are unable to write the catalog file, open Windows Explorer, navigate to the
Install.wim
file, open its properties, and uncheck the read only checkbox - If you have your installation media on a physical read-only media, copy
Install.wim
to a local hard drive first. Select the Server Standard Edition using GUI:
Select Windows Edition
- If you receive a warning message stating that you are unable to write the catalog file, open Windows Explorer, navigate to the
- After the catalog file is created, select the File menu again, create a New Answer File, and save it as
unattended.xml
to a place of your choice. - Windows System Image Manager will then create the basic XML structure of your unattended file, as shown in the following screenshot:
Windows System Image Manager
- Opening this XML file in Internet Explorer will show you the actual file contents. Every Windows Server 2016 setup will check for an existing
unattended.xml
file at the start of every available drive letter, but it will only work if the XML structure is correct. - We will now continue to fill this
unattended.xml
file with contents specific to the Hyper-V setup to allow a Zero-Touch installation of your Hyper-V hosts.
Adding basic components
Start by adding the most basic components by expanding the Components tree under the Windows Image section in the left-hand corner of the tool. Let's now add language and locale information, through following steps:
- First, add the
amd64_Microsoft-Windows-International-Core-WinPE
components toPass1
and fill the basic language options. The generated XML part with all the mandatory parameters will look like the following code:<?xml version="1.0" encoding="UTF-8"?> <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SetupUILanguage> <UILanguage>en-US</UILanguage> </SetupUILanguage> <InputLocale>en-US</InputLocale> <UILanguage>en-US</UILanguage> <SystemLocale>en-US</SystemLocale> <UserLocale>en-US</UserLocale> </component>
If you prefer language settings other than US English, make sure that the language components are included in the installation media and refer to the correct locale IDs, which can be found on Microsoft MSDN (shortlink http://bit.ly/1gMNu2B).
- Next, add
amd64_Microsoft-Windows-Setup_neutral
toPass1
to configure some basic OS configurations such as Disk Layout. A generated sample XML part for a BIOS-based system is as follows:<?xml version="1.0" encoding="UTF-8"?> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DiskConfiguration> <Disk wcm:action="add"> <CreatePartitions> <CreatePartition wcm:action="add"> <Order>1</Order> <Size>350</Size> <Type>Primary</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Order>2</Order> <Extend>true</Extend> <Type>Primary</Type> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="add"> <Active>true</Active> <Format>NTFS</Format> <Label>Bitlocker</Label> <Order>1</Order> <PartitionID>1</PartitionID> </ModifyPartition> <ModifyPartition wcm:action="add"> <Letter>C</Letter> <Label>HostOS</Label> <Order>2</Order> <PartitionID>2</PartitionID> </ModifyPartition> </ModifyPartitions> <DiskID>0</DiskID> <WillWipeDisk>true</WillWipeDisk> </Disk> </DiskConfiguration> </component>
This configuration will make sure that there are clean partitions that follow Microsoft's default deployment model. The small partition at the start of the disk is created to support Bitlocker. Microsoft's full disk encryption can be used with Hyper-V hosts and can also be activated later. The use of Bitlocker is only recommended in high-security environments.
- If your host does not have BIOS anymore and uses an UEFI-based setup routine, the XML file will be edited to include the following code as well:
<?xml version="1.0" encoding="UTF-8"?> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DiskConfiguration> <Disk wcm:action="add"> <CreatePartitions> <CreatePartition wcm:action="add"> <Order>2</Order> <Size>100</Size> <Type>EFI</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Order>3</Order> <Extend>false</Extend> <Type>MSR</Type> <Size>128</Size> </CreatePartition> <CreatePartition wcm:action="add"> <Order>4</Order> <Extend>true</Extend> <Type>Primary</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Size>350</Size> <Type>Primary</Type> <Order>1</Order> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="add"> <Active>false</Active> <Format>NTFS</Format> <Label>Bitlocker</Label> <Order>1</Order> <PartitionID>1</PartitionID> </ModifyPartition> <ModifyPartition wcm:action="add"> <Letter>C</Letter> <Label>HostOS</Label> <Order>3</Order> <PartitionID>3</PartitionID> <Format>NTFS</Format> </ModifyPartition> <ModifyPartition wcm:action="add"> <Order>2</Order> <PartitionID>2</PartitionID> <Label>EFI</Label> <Format>FAT32</Format> <Active>false</Active> </ModifyPartition> </ModifyPartitions> <DiskID>0</DiskID> <WillWipeDisk>true</WillWipeDisk> </Disk> </DiskConfiguration> </component>
Which edition to install
In Windows Server 2012 R2, the Standard and the Datacenter editions have exactly the same features. The main difference between the Standard and Datacenter editions is the virtualization rights. Each Windows Server Standard edition allows you to run two guest Operating System Environments (OSEs) with Windows Server editions, and a Datacenter edition allows you to run an unlimited number of Windows Server VMs on this particular licensed Hyper-V host. There is only one technical difference between the two editions-on a Datacenter edition, all Windows Server guest VMs will be automatically activated when provided with a corresponding key during setup. There is no need for a MAK or KMS-based OS activation anymore.
With Windows Server 2016, some features are not present in the Standard edition compared to the Datacenter edition. The mainly missing features in the Standard edition are related to Storage (as Storage Spaces Direct), networking stack, and Shield VMs. As of Windows Server 2012 R2, the Datacenter edition allows you to run unlimited guest OSEs (or Hyper-V containers) while the Standard edition allows you to run two of them.
If you want to leverage Automatic Virtual Machine Activation (AVMA), storage features, and unlimited number of Windows Server VMs, install a Datacenter edition on the host. It is easy to upgrade a Standard edition to a Datacenter edition later, but there is no option to downgrade.
If you are not sure which edition you are using, open a PowerShell window with administrative privileges and run the following command:
get-windowsedition -online
To find out which editions are available for upgrade, run the following command:
Get-WindowsEdition -online -target
Finally, to upgrade to the target edition, run the following command:
dism.exe /online /Set-Edition:ServerDatacenterCor /AcceptEula
/ProductKey: <ProductKey>
Upgrade from the Standard edition to the Datacenter edition
While it's suitable to install a Datacenter edition on a Hyper-V host, you should never do this inside a virtual machine, except if you need specific features only available in the Datacenter edition. For example, if you want to make a virtual Storage Spaces Direct lab, you need the Datacenter edition to deploy this feature. In most environment, the Datacenter edition is deployed because it enables you to run unlimited guest OSes while the Standard edition enables you to run just two guest OSes. The next step in building our unattended installation is to set up the installation target and the edition. Navigate to the ImageInstall
string under the Microsoft-Windows-Setup
node and add the following code:
<ImageInstall><OSImage><InstallFrom><MetaData wcm:action="add"><Key>/Image/Name</Key><Value>Windows Server 2016 Technical Preview 5 SERVERSTANDARD</Value></MetaData></InstallFrom><InstallTo><DiskID>0</DiskID><PartitionID>2</PartitionID></InstallTo></OSImage></ImageInstall>
If you have chosen the UEFI-based setup, choose PartitionID 4
according to your disk setup. This will make sure that you install the Standard edition of Windows Server 2016 to the correct partition.
As the last step in Pass1
, we will fill out the UserData
tree under the Microsoft-Windows-Setup
node and edit the following code:
<UserData><ProductKey><WillShowUI>OnError</WillShowUI></ProductKey><AcceptEula>true</AcceptEula><FullName>YourName</FullName><Organization>YourOrg</Organization></UserData>
Fill in Name and Org Data with anything you like; however, these fields are mandatory. The product key field is optional. If you intend to use a 180-day trial version of Windows Server or are leveraging KMS Server activation capabilities, do not enter a product key. If you are using MAK-based OS activations, enter your product key. You can also install a MAK product key at a later time by opening a PowerShell window with administrative privileges and running the following command:
slmgr -upk #(this uninstalls the current product key) slmgr -ipk <key> #(including dashes)
Decide whether to GUI
After adding the basic parameters, it's now time to add some comfort to our Zero-Touch installation.
In Windows System Image Manager, add amd64_Microsoft-Windows-Shell-Setup_neutral
to Pass4
and Pass7
.
Edit the XML file to set your time zone settings (run tzutil /l
in a Shell to get a list of all the valid time zones) and your local administrator password. Don't worry about entering a password into Windows System Image Manager; it will encrypt the password while saving the file. The following code shows how to set the regional and user information:
<settings pass="specialize"><component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-Shell-Setup"><TimeZone>W. Europe Standard Time</TimeZone></component></settings><settings pass="oobeSystem"><component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-Shell-Setup"><UserAccounts><AdministratorPassword><Value>UABAAHMAcwB3ADAAcgBkAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value><PlainText>false</PlainText></AdministratorPassword></UserAccounts></component></settings>
To allow a rapid deployment of hosts, I have not entered a computer name at this stage, so the setup will generate a random computer name for each node installed. If you want to enter a computer name, add the following code to your XML-specialized section:
<ComputerName>Hyper-V01</ComputerName>
Note
Downloading the example code:
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Another optional feature was selected right at the beginning of our XML creation-the GUI. By selecting the Windows Server Standard edition and not the Standard Core edition, we have included the complete GUI of Windows Server in our setup. Unlike Windows Server 2012 R2 version with Hyper-V, the GUI is now a feature that can't be activated or deactivated at a later stage. Note that the GUI is not available on the free Hyper-V Server 2016. The full GUI installation process offers the same great user experience we know from many versions of Windows Server and Windows Client operating systems, but Server Core is the installation method recommended by Microsoft for Windows Server 2016 and Hyper-V. The Core installation option offers a reduced attack surface with less patching efforts and fewer reboots. It even comes with a smaller resource footprint than its Full GUI equivalent. However, offering only a PowerShell Window as the single point of local administration discouraged many system administrators in the past, so Core setups aren't found often. Don't forget that all administrative APIs are active on a Core Server, so you can connect with your MMC consoles from other servers or clients without the need to use the PowerShell modules. Unfortunately, in Windows Server 2016 you can't switch from GUI installation to Core installation or vice versa.
The Minshell is also no longer available. In Windows Server 2012 R2, Minshell was a deployment option similar to the Core installation option but with Remote Server Administration Tools (RSAT).
GUI or Core installation
Hyper-V hosts in Active Directory domains
The basic operating system setup will now already be based on a Zero-Touch installation, but we want to achieve more than this and will include some additional options.
Add the amd64_Microsoft-Windows-TerminalServices-LocalSessionManager
component to Pass4
and configure it to enable Remote Desktop Access to the server:
<?xml version="1.0" encoding="UTF-8"?> <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TerminalServices-LocalSessionManager"> <fDenyTSConnections>false</fDenyTSConnections> </component>
To reach the Server via RDP, via its designated IP address, we will also set the basic network settings. Keep in mind that based on your converged network setup for Hyper-V, these might be overwritten at a later step (Chapter 5, Network Best Practices).
Add the amd64_Microsoft-Windows-TCPIP
component to Pass4
and configure a static IP Address-in this case, based on the name of the interface. This is also possible using the MAC address. Configure the network as shown in the following code:
<?xml version="1.0" encoding="UTF-8"?> <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TCPIP"> <Interfaces> <Interface wcm:action="add"> <Ipv4Settings> <DhcpEnabled>false</DhcpEnabled> <Metric>10</Metric> <RouterDiscoveryEnabled>true</RouterDiscoveryEnabled> </Ipv4Settings> <UnicastIpAddresses> <IpAddress wcm:action="add" wcm:keyValue="1">192.168.1.41/24</IpAddress> </UnicastIpAddresses> <Identifier>Local Area Connection</Identifier> </Interface> </Interfaces> </component>
Whether Hyper-V hosts should be added to an Active Directory domain is a topic that is often discussed. Having seen a lot of Hyper-V environments, either domain-joined or workgroup-joined, my answer to this is a strong yes. Windows Server 2016 Servers can boot up even clusters when domain-joined without an Active Directory domain controller available, so this chicken-or-egg problem from earlier Hyper-V versions is not a problem anymore. Hyper-V will run without an Active Directory domain; however, very basic capabilities such as live migration won't be available on workgroup environments. Huge Hyper-V installations or high-security companies even leverage their own management domain to place their Hyper-V hosts into an Active Directory domain.
There is little security consideration standing against a huge management benefit, through credential management, group policies, and so on, so you should domain-join all Hyper-V hosts to your existing Active Directory domain. If your Hyper-V hosts will be placed in high-security environments, join them to a dedicated management domain (within a separated Active Directory forest) and not to your production domain.
Add the amd64_Microsoft-Windows-UnattendedJoin
component to Pass4
and configure it to join an existing Active Directory domain:
<?xml version="1.0" encoding="UTF-8"?> <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-UnattendedJoin"> <Identification> <Credentials> <Domain>int.homecloud.net</Domain> <Password>Hannover96</Password> <Username>joindomain</Username> </Credentials> <JoinDomain>int.homecloud.net</JoinDomain> <MachineObjectOU>OU=Hyper- V,DC=int,DC=homecloud,DC=net</MachineObjectOU> </Identification> </component>
A typical configuration that is seen in this step is the disabling of the Windows Firewall. In my opinion, this is a bad practice. The Windows Firewall is a great layer of security and should be configured to your needs, but not disabled. For a central Firewall configuration, we'll use Group Policy settings, so we don't need to include any configuration in our unattended.xml
.
Activating Hyper-V features
After our operating system is prepared to host Hyper-V, it's time to activate the Hyper-V components. Add the following product packages and their roles and features to your unattended.xml
file:
<?xml version="1.0" encoding="UTF-8"?> <servicing> <package action="configure"> <assemblyIdentity language="" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows- ServerStandardEdition" version="6.3.9600.16384" /> <selection name="Microsoft-Hyper-V-Common-Drivers-Package" state="true" /> <selection name="Microsoft-Hyper-V-Guest-Integration-Drivers- Package" state="true" /> <selection name="Microsoft-Hyper-V-Server-Drivers-Package" state="true" /> <selection name="Microsoft-Hyper-V-ServerEdition-Package" state="true" /> </package> <package action="configure"> <assemblyIdentity language="" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-ServerCore- Package" version="6.3.9600.16384" /> <selection name="Microsoft-Hyper-V" state="true" /> <selection name="Microsoft-Hyper-V-Offline" state="true" /> <selection name="Microsoft-Hyper-V-Online" state="true" /> <selection name="VmHostAgent" state="true" /> <selection name="AdminUI" state="true" /> <selection name="ServerManager-Core-RSAT" state="true" /> <selection name="ServerManager-Core-RSAT-Feature-Tools" state="true" /> <selection name="ServerManager-Core-RSAT-Role-Tools" state="true" /> </package> </servicing>
After adding these Hyper-V components, the creation of our unattended.xml
file is completed. You can download the complete sample XML file from http://bit.ly/1xBIQb2. Place the file in the root folder on the USB drive and boot the Server system from your installation media. You will now experience a fully Zero-Touch Hyper-V installation. In Chapter 2, Deploying Highly Available Hyper-V Clusters, you will learn how to advance this even further into a Zero-Touch cluster installation.
Unattended.XML file for automatic Hyper-V setup
Note
The unattended XML file can also be used in Virtual Machine Manager (VMM) in the Physical Computer Profiles that enable you to deploy Hyper-V hosts from the VMM console.
Post-installation tasks
Be sure to remove the USB drive with the unattended setup file prior to moving the host to production. A host reboot could otherwise force a reinstallation, including a wipe of all hard drives, due to the trigger of another unattended installation.
Run Windows Update to make sure that you have installed all the available updates. Are there any Windows updates you should not install on Hyper-V hosts? Yes, drivers should not be installed over a Windows Update unless support tells you to do so. However, besides this, install every available Windows Update in all of your Hyper-V hosts.
The Hyper-V role is already enabled, and we are ready to create VMs. To ensure network connectivity and safe operations of our VMs, we will configure some additional parameters after the installation.
First of all, we need some basic network connectivity for our VMs. If you have a second NIC available in your host, run the following command in an elevated PowerShell session:
New-VMSwitch -Name SW-1G -NetAdapterName "Local Area Connection 2"
If you have only one NIC, run the following command:
New-VMSwitch -Name SW-1G-NetAdapterName "Local Area Connection" -
AllowManagementOS $true
When the virtual switch is created, you can manage it from Hyper-V manager:
Virtual switch settings from Hyper-V manager
Now, your virtual machines can use an external Hyper-V switch named external to communicate over the network.
Ever wondered about the many errors your RDP-mapped printer can create on a Hyper-V host? I could not believe this for a long time, but recently, I have seen a Hyper-V Server with the blue screen due to improper printing drivers. Do you need to print from a Hyper-V host? Absolutely not! So, make sure that you disable RDP Printer Mapping through a Group Policy (or Local Policy).
Navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Printer Redirection | Do not allow client printer redirection and select Enable in a Group Policy.
Disable RDP printer mapping
Hyper-V uses some default paths to store virtual machine configuration and its hard disks. I find this very interesting, but it is definitely not suitable for a production environment. Make sure that you change the default paths, if possible to a nonsystem drive, by running the following commands in an elevated PowerShell window:
Set-VMHOST -computername localhost -virtualharddiskpath 'D:\VMs' Set-VMHOST -computername localhost -virtualmachinepath 'D:\VMs'
I have not seen any issues in placing VM configuration files and virtual hard disks into the same folder structure. You have everything your VM configuration depends on in one place.
Note
Another important post-installation task is to follow the rule: do not install other roles on Hyper-V hosts except Storage and related features (Hyperconverged model, for example).
A Hyper-V host is a Hyper-V host and nothing else. Move all the other services into virtual machines that run on the Hyper-V host.
Moreover, also keep the following points in mind:
- Do not install any features other than Failover Clustering and Multipath I/O (MPIO) on a Hyper-V host
There are exceptions in an SMB3 scenario where you also want to install Datacenter Bridging (DCB) and SMB bandwidth limits.
- Limit software installations to an absolute minimum, that is, backup and monitoring agents
Antivirus on a Hyper-V host
Another great topic for discussion is whether you should install an antivirus client on a Hyper-V host or not. Many companies have compliance rules stating that on every Server or every Windows machine, an AV client needs to be installed. If there is a rule like this in place, follow it and install an AV agent on your Hyper-V hosts. Make sure that you also implement the long list of files, which contain all the Hyper-V configuration files and virtual machine data, you have to exclude from your scans.
I have seen antivirus engines on Hyper-V hosts doing bad things such as breaking a virtual hard disk, deleting an essential system file, or just producing a very intense amount of storage IOs. Excluding all relevant files and folders regarding Hyper-V and its VMs, there is nothing left worth scanning on a Hyper-V host. If you are not bound by a compliance policy, I highly recommend that you do not install antivirus products on Hyper-V.
There are some approaches for Hyper-V-aware antivirus products; however, I have not seen one flawless working solution as of today, so you should protect your VMs from malware from inside the VM by installing your AV agents into the virtual machines.
Setting the pagefile
One of the most frequent configuration tips around Hyper-V hosts is to manually configure the pagefile. The values described are sometimes quite creative.
After doing many tests with Hyper-V hosts with all different kinds of RAM configurations and deep technology-oriented exchanges with Microsoft Product Teams, including the Hyper-V Product Team itself, on how pagefile management work in Windows Server 2016, there is only one recommendation I have today-leave it alone.
The Windows pagefile is, by default, managed by Windows. If you have followed all other best practices described up to this point, and most importantly, you did not install other services on the Hyper-V host itself (management OS), you are all set. There is no way you can reach the same or even a better efficiency in pagefile management by manually altering this automatic configuration. I have not seen a single Hyper-V installation on Windows Server 2016 as of now that had problems with automatic pagefile management.
Again, this only affects the Hyper-V host and not the pagefile configuration of the virtual machines.
There are some more valuable post-installation tasks for performance management in Chapter 7, Hyper-V Performance Tuning. You can manage the pagefile as shown in the following screenshot:
Pagefile configuration