Manage Hyper-V and Guest Virtual Machines
Enable Enhanced Session Mode
Enhanced Session Mode in Hyper-V improves how administrators interact with virtual machines by enabling advanced connection features. This mode allows for seamless clipboard sharing, drive redirection, and high-resolution display capabilities during active remote sessions. Without this mode, administrators are limited to basic console interactions, making daily administrative tasks more time-consuming.
To activate Enhanced Session Mode, you must first configure it on the physical host machine using the Hyper-V Manager console or Group Policy for multiple hosts. Once the host-level configuration is enabled, guest virtual machines also need Integration Services installed or upgraded to communicate with the host using enhanced features. After configuring both the host and the guest, you should test device redirection capabilities and verify that the session window supports high-resolution displays to ensure an optimal remote management experience.
Manage VMs Using PowerShell Remoting, PowerShell Direct, and Secure Shell Direct for Linux VMs
Three key technologies—PowerShell remoting, PowerShell Direct, and Secure Shell (SSH) —provide different ways to connect to Windows and Linux VMs. PowerShell Remoting uses the Windows Remote Management (WinRM) service to create authenticated and encrypted connections between devices, allowing administrators to run commands on remote Windows systems. PowerShell Direct executes commands inside a VM directly from the Hyper-V host, bypassing network layers entirely, which makes it useful when a VM has no network connectivity or during network troubleshooting.
For Linux VMs, SSH provides encrypted, secure shell access. Before using SSH, ensure the az extension add --name ssh command is run in the Azure CLI if the extension is not installed. Additional security comes from enforcing Conditional Access policies that require multifactor authentication, device compliance checks, and risk assessment before allowing SSH connections. Firewall rules and network security groups must allow SSH ports (usually TCP 22) only from trusted sources, combining network controls with authentication and policy measures for a layered approach to secure remote shell access.
Enable Nested Virtualization
Nested virtualization allows running Hyper-V inside an Azure virtual machine. To set this up, you must first select a compatible VM size, such as Large (nested virtualization) or Medium (nested virtualization) , and have an active Azure subscription with a configured lab plan. You will also need specific Azure role-based access control (RBAC) permissions like Lab Creator, Owner, or Contributor.
Once the host VM is running, you configure it by establishing a Remote Desktop connection and running Windows PowerShell with administrative privileges. You temporarily bypass the execution policy to allow setup scripts to run, download and execute the nested virtualization script, then restart the VM if prompted. This capability relies on physical hardware features like Intel VT-x or AMD-V virtualization extensions, which the Azure hypervisor passes down to the outer VM. Nested virtualization is restricted to Microsoft technologies, and while it does not block dynamic memory, you cannot adjust memory boundaries while the guest VM is running—you must transition it to an off state first.
Configuring virtual machine memory in Azure involves balancing performance with efficient resource use through Dynamic Memory, which allows a VM's allocated RAM to change based on its needs. You control this by setting three key values: the startup RAM for when the VM boots, the minimum RAM it must always have, and the maximum RAM it is allowed to use. To fine-tune Dynamic Memory, you adjust the memory buffer (extra memory reserved for sudden demand increases) and memory weight (a priority setting that tells the host how to distribute available memory when multiple VMs compete for it).
A related feature is hot-add capability, which lets you add more memory to a running VM without shutting it down, useful for handling growing workloads while maintaining service availability. Getting these settings right improves how quickly VMs respond to workload changes and is a critical part of planning how many VMs a host can support.
Integration Services are a set of drivers and services that allow virtual machines to communicate smoothly with their Hyper-V host. When these services are installed and running, the host can efficiently manage the guest operating system, share files, and handle tasks like backups or time synchronization. You can install or update Integration Services on Windows and Linux VMs using Windows Update, PowerShell cmdlets, or Hyper-V Manager.
When migrating older VMs to Azure, you must prepare them properly first. For a Windows Server 2003 machine from on-premises Hyper-V, check and install Integration Services before beginning the migration. For VMs coming from VMware environments, you may need to create startup tasks that automatically install Integration Services when the machine first starts. After installing or updating, validate that everything works by checking event logs and running PowerShell commands that report the service status, resolving any version mismatches or compatibility conflicts that appear.
Discrete Device Assignment (DDA) enables direct allocation of physical PCIe devices to Hyper-V virtual machines. First, evaluate hardware compatibility using the device manager on the Hyper-V host to identify suitable PCIe devices and verify their physical connection paths. Before assigning a device to a VM, you need to dismount it from the host and mark it as assignable using Hyper-V cmdlets in PowerShell or the Hyper-V Manager interface.
Assigning the PCIe devices to VMs involves configuring the VM settings via Hyper-V cmdlets or the Manager, using commands like Set-VM to configure the assignment. While configuring DDA, consider isolation and performance to prevent interference and ensure optimal operation. After assigning a device, verify its operation within the guest environment by checking that it performs as expected without causing disruptions or errors, using tools within the VM to monitor performance and address any problems promptly.
GPU partitioning on Hyper-V hosts and Azure Stack HCI clusters involves giving virtual machines discrete chunks of GPU resources to handle graphics-heavy workloads. Before setting up GPU partitions, verify that your GPU hardware supports partitioning on Hyper-V hosts to prevent wasted configuration time. Administrators use PowerShell cmdlets like Set-VMGpuPartitionAdapter to assign a specific partition size in megabytes to a VM, while Get-VMGpuPartitionAdapter retrieves the current settings.
After configuring GPU partitions, regular monitoring using tools like Windows Admin Center ensures they perform optimally, helping administrators spot underutilization or performance bottlenecks. Administrators can create profiles that match GPU allocations to specific workload requirements—light graphical tasks need smaller partitions, while demanding applications like rendering or AI workloads require larger allocations. These profiles ensure each VM receives enough GPU resources to function efficiently without taking more than it needs.
VM resource groups in Hyper-V let you set memory and storage quotas to control how much of the host's resources each VM can use, preventing resource starvation for other VMs on the same host. To manage CPU resources, you assign physical CPU cores into logical CPU groups, each acting as a dedicated pool of CPU capacity tied to specific VMs, creating workload affinity that improves cache efficiency and performance.
Hyper-V offers three hypervisor scheduling types that control how the host distributes CPU time among running VMs. Static scheduling gives each VM a fixed slice of CPU time, making performance predictable but potentially wasting cycles when a VM is idle. Dynamic scheduling adjusts the allocation in real time based on demand, so busy VMs get more CPU while idle ones give up their share. Batch scheduling groups similar tasks together and is best for workloads that can tolerate delays, improving overall resource utilization by reducing context switches.
Manage VM Checkpoints
Hyper-V offers two checkpoint types that serve different purposes. Standard checkpoints capture the VM's state, data, and hardware configuration quickly but may not guarantee full data consistency, making them useful for development and testing. Production checkpoints use volume shadow copy or backup technologies to create a consistent snapshot without capturing the memory state, designed for scenarios where data integrity matters most.
When setting up checkpoints, configure where the checkpoint files are stored and how long they are kept. Storage locations should not be on the same volume as the VM's virtual disk to avoid performance issues. Retention policies define how long checkpoints persist, helping you avoid accumulating unnecessary files. After checkpoints serve their purpose, you can either merge them back into the primary virtual disk or delete them entirely. Reverting to a checkpoint restores the VM to that exact state, providing a reliable rollback mechanism for testing updates or recovering from configuration errors.
Implement High Availability for Hyper-V Virtual Machines
A Hyper-V failover cluster is a group of servers that work together to keep VMs running. To protect against a failure in a whole data center, place cluster nodes in different Azure availability zones, so VMs can automatically restart on a healthy node in another zone. The cluster uses a quorum to decide which nodes are in charge and prevent a "split-brain" scenario, requiring a third voting resource called a witness for a two-node cluster.
You can choose between a cloud witness (using an Azure storage account), a disk witness (using an Azure Shared Disk), or a file share witness. The cloud witness is often the best choice for clusters spread across different Azure regions. For the cluster to work, nodes need shared storage that they can all access, such as Azure Shared Disks. Keeping the cluster healthy requires regular checks on network connections between all nodes and the witness, verifying that each node's vote is correctly assigned to maintain proper quorum.
Manage Hyper-V Virtual Hard Disks
When creating a virtual hard disk in Hyper-V, you choose from three disk types. A fixed disk reserves the full storage size at creation, giving steady performance but using space immediately. A dynamically expanding disk starts small and grows as data is written, saving storage space until needed. A differencing disk records only changes made from a parent disk, useful when multiple VMs share a common base image.
Hyper-V supports two virtual hard disk formats: VHD (older, max size 2 TB) and VHDX (up to 64 TB with better protection against corruption). Use the PowerShell cmdlet Convert-VHD to convert between formats without changing the data inside the disk. You can increase the size of a virtual hard disk either while the VM is running (online) or after it is stopped (offline) using Resize-VHD. To get the best disk I/O performance, check partition alignment and interleave settings, typically setting the interleave size to 64 KB for striped volumes.
Hyper-V supports three main types of network adapters. Synthetic network adapters offer the best performance by communicating directly with the Hyper-V virtual switch. Legacy network adapters exist for compatibility with older operating systems. Single Root I/O Virtualization (SR-IOV) adapters give VMs direct access to the physical network hardware, bypassing the Hyper-V virtualization layer for maximum throughput.
To achieve optimal network performance, enable advanced features like Virtual Machine Queue (VMQ) , which allows the physical network adapter to sort incoming traffic directly to the correct VM, and Receive Side Scaling (RSS) , which distributes traffic across multiple processor cores. Accelerated Networking reduces latency and decreases CPU utilization, requiring a synthetic network interface and SR-IOV support. Connecting network adapters to virtual switches is essential for hybrid deployments, using Azure-integrated virtual switches such as Azure VNET for centralized management across on-premises and cloud environments.
NIC teaming allows multiple network interface cards to work together as a single unit to improve performance and ensure network fault tolerance. There are three main modes: switch-independent mode works with any network switch because the host decides how to distribute traffic; LACP (Link Aggregation Control Protocol) mode requires the network switch to support it and dynamically negotiates the connection; and static mode assumes the switch is already configured for aggregation.
To set up NIC teaming on a Hyper-V host, use PowerShell commands or the Hyper-V Manager interface. Inside guest VMs, the virtual network adapters must align with the host's team configuration to achieve the best performance and redundancy. After configuring NIC teaming, verify the team is working correctly using PowerShell cmdlets like Get-NetLbfoTeam and Get-NetLbfoTeamMember. Continuous monitoring using Performance Monitor in Windows Server tracks network throughput across all team members, helping identify bottlenecks or failures before they cause downtime.
Configuring Hyper-V virtual switches creates the network foundation for VMs. An external switch connects VMs to the physical network and the internet. An internal switch lets VMs talk to each other and to the Hyper-V host, but not to any outside network. A private switch allows communication only between VMs on the same host, with no access to the host or external network.
To further organize and secure traffic, use VLAN tagging on virtual switches, assigning a unique VLAN ID (1 to 4094) to a group of VMs. Securing a virtual switch involves Port Access Control Lists (ACLs) that block or allow traffic based on IP addresses or protocols, and switch extensions for advanced features like traffic monitoring. For reliability, use switch teaming to combine multiple physical network adapters into a single logical adapter. In a hybrid environment, connect on-premises Hyper-V hosts to Azure virtual networks using a VPN gateway or ExpressRoute connection, and use services like Azure Firewall to control traffic flow.
Host Guardian Service (HGS) is a Windows Server role that protects VMs from being tampered with by ensuring any Hyper-V host trying to run a sensitive VM proves it is trustworthy through attestation. A guarded fabric is the combination of HGS servers and Hyper-V hosts that work together to run shielded VMs, whose disks and memory are encrypted and cannot be inspected by the host administrator. HGS supports two attestation modes: TPM-baseline mode checks that the host hardware matches a known good baseline, while TPM-attestation mode uses the Trusted Platform Module chip to verify the exact identity and configuration of each host.
Azure uses several layers of protection including the Azure Fabric Controller that manages physical servers and VM communications, smart VM placement to prevent different customers' VMs from sharing the same physical host, and memory and process separation enforced by the hypervisor. When deploying shielded VMs, administrators set up attestation policies that define what requirements a Hyper-V host must meet, with continuous attestation to ensure hosts remain compliant. Azure provides built-in tools including PowerShell, the Azure CLI, and ARM templates to create and deploy shielded VMs, which include features like secure boot and a virtual TPM for hardware-level security.
Move Secure Virtual Machines Between Hyper-V Hosts
To move VMs safely between Hyper-V hosts, administrators must choose the right transfer method. Standard live migration transfers running VMs across hosts that share a common storage backend, moving only system memory and state over the network. When hosts do not share storage, Shared Nothing Live Migration performs the transfer by moving both virtual hard disks and running memory state simultaneously. Alternatively, export and import methods allow saving a VM's state to a file system and rebuilding it on another host, though this is typically slower.
Securing the migration process requires setting up trusted relationships between hosts. If hosts belong to the same Active Directory domain, configure Kerberos constrained delegation for secure authentication. For environments outside a single domain, certificate-based authentication verifies each host's identity using cryptographic certificates. To protect VM data while in transit, enable SMB encryption to shield the data path, while migration compression reduces the overall data footprint to speed up the transfer. After the transfer completes, confirm the VM is running normally on the target host by checking event logs and generating health reports to verify performance and security policies remain intact.