Curious about optimizing storage performance in your Hyper-V environment? Discover the differences between thick and thin provisioning and how they impact performance in your virtual environment.

You may need to move a couple of Azure Virtual Machines from on-premises to your Azure subscription. Thanks to Windows PowerShell, uploading a VM to Azure is really easy to do! You must check only one prerequisite before uploading your VM to Azure: you will need to check what type of virtual hard disk is being used by the virtual machine. Hyper-V can use either VHD or VHDX based virtual hard disks. However, only VHD disks can be uploaded to Azure. Azure does not support VHDX disks.

In our support work very often we face different environments. They can range from three VMs to a hundred of those, with the number of nodes from two to ten. Today, I will tell you about the main features of Failover Cluster 2016, which are applicable to any environment.

Migrating your VMs from one hypervisor to another may be a bit of a challenge if you don’t have some decent virtual machine converter at hand. Different hypervisors have their own proprietary VM formats: VMDK, VHD and VHDX, QCOW, you name it. The problem is that one VM format can be not supported on other platforms. In this case, a V2V converter is a must-have. Now, the question arises: which converter should I choose?

In Windows Server 2016 Microsoft introduced storage Quality of Service (QoS) policies.  Previously in Windows Server 2012 R2, we could set minimum and maximum IOPS individually virtual hard disk but this was limited even if you could automate it with PowerShell. The maximum was enforced but the minimum not. That only logged a warning if it could be delivered and it took automation that went beyond what was practical for many administrators when it needed to be done at scale. While it was helpful and I used it in certain scenarios it needed to mature to deliver real value and offer storage QoS in environments where cost-effective, highly available storage was used that often doesn’t include native QoS capabilities for use with Hyper-V.

A few years ago, we have tried to place a VM on an NFS share. We used Windows Server 2012 because Hyper-V is a native hypervisor from Microsoft. Now we have decided to reproduce the experiment on Windows Server 2016. Just because of boundless curiosity  So, we have 2 nodes: S3n11 serves as NFS Fileserver and S3n12 takes the Hyper-V server role. We will do exactly the same thing as we did before, but this time on Windows Server 2016 on both VMs. Let’s start!

Last year I have written a topic on Starwind to create VMs from PowerShell. That enables to automate the creation process without using a GUI, either from Virtual Machine Manager or Hyper-V Manager. But a VM deployment is not finished when the VM is created but when the application is deployed. Before deploying the application, the OS must also be installed and specialized. This topic shows you the method I use to deploy and specialize a VM without a single click.

In this topic, I’ll show you how to prepare a Nano Server image which will be deployed in a virtual machine. The operating system will be configured to run containers. To create the Nano Server image, I’ll use the Nano Server Image Builder tool which is a graphical interface to prepare the image in VHD, VHDX or WIM file format.

VM Fleet is a collection of scripts that enables to deploy virtual machines which perform I/O to stress the underlying storage system. To achieve I/O, the VMs leverages DiskSpd which is a Microsoft tool. When you implement an infrastructure based on Hyper-V, you usually want to get the maximum IOPS and MB/s that your storage can deliver. This tool helps you to get this information by stressing your storage. In this topic, we will see how to deploy a VM Fleet to benchmark the storage system.