Installation Process of Hyper-V Replica

Hyper-V Replica is installed as part of the Hyper-V Role.

Installation UI/Wizard

To add the Hyper-V Role to a server installation, use the Add Role and Feature Wizard (ARFW), which is part of Server Manager or use the Deployment Image and Servicing Management (DISM) command line tool.  A reboot is required.  This can occur automatically if the installation is being executed in the Server Manager interface by checking a box (Restart each target machine automatically if needed) in the wizard (Confirmation screen).  This allows the server to reboot, if needed.


Installation Command Line Interface (CLI)

The Hyper-V Role can also be installed from the command line interface by using the Deployment Image and Service Management (DISM) command line tool.  At a command prompt, type: dism /online /enable-feature /featurename: Microsoft-Hyper-V.  A reboot is required to complete the installation.  The Server Manager PowerShell cmdlet Install-WindowsFeature can also be used.

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools

When adding the Hyper-V Role using the ARFW, there is an opportunity to create Virtual Switches in Hyper-V.  This step can be accomplished in the wizard when installing the Role or it can be done afterwards using the Hyper-V Manager interface.


You can allow the Hyper-V server to receive Live Migrations


You can also specify the default location for virtual hard disks and virtual machine configuration files


A reboot is required to complete the configuration of the Hyper-V role.


Verifying Installation

Once the installation is completed (following a reboot of the server), the Hyper-V role will show as installed in Server Manager and the Hyper-V Manager will be listed under Administrative tools.  To verify proper functioning of Hyper-V, run the Hyper-V Best Practices Analyzer (BPA) and then create a new virtual machine and verify it starts correctly.


To remove the Hyper-V Role, use the Remove Roles and Features Wizard (RRFW) in Server Manager, use the Deployment Image and Servicing Management (DISM) command line tool, or use the Server Manager PowerShell Cmdlet Uninstall-WindowsFeature.  A reboot is required to complete the process.

Hyper-V Replica PowerShell CMDLETS

The following Hyper-V PowerShell cmdlets apply to Hyper-V Replica.  

Cmdlet Complete-VMFailover
Description This cmdlet completes the Failover process of the virtual machine. The virtual machine’s current recovery point is committed and all other recovery points are removed. Failover cannot be cancelled once the recovery points are removed.
Verb-Noun Complete-VMFailover
Syntax Complete-VMFailover [-VMName] <String> [-ComputerName <String[]>] [-PassThru]
Example Complete-VMFailover -VMName C0-FIN-FS1


Cmdlet Get-VMNetworkAdapterFailoverConfiguration
Description Retrieves the Failover IP settings on a virtual machine network adaptor.
Verb-Noun Get-VMNetworkAdapterFailoverConfiguration
Syntax Get-VMNetworkAdapterFailoverConfiguration [-VMName] <String[]> [[-VMNetworkAdapterName] <String[]>] [-ComputerName <String[]>]
Example  cmd1


Cmdlet Get-VMReplication
Description Retrieve the replication relationship information of one or more virtual machines.
Verb-Noun Get-VMReplication
Syntax Get-VMReplication [[-VMName] <String[]>] [-ComputerName <String[]>] [-ReplicaServerName <String>] [-PrimaryServerName <String>] [-State <String>] [-ReplicationTag <String>]
Example  cmd2


Cmdlet Get-VMReplicationAuthorizationEntry
Description This cmdlet returns the details of an authorization entry as identified by the input parameter. The possible ways to get a particular authorization entry is by using AllowedPrimaryServer, or security tag.
Verb-Noun Get-VMReplicationAuthorizationEntry
Syntax Get-VMReplicationAuthorizationEntry [[-AllowedPrimaryServer] <String>] [-ComputerName <String[]>] [-ReplicaStorageLocation <String
Example Get-VMReplicationAuthorizationEntry -AllowedPrimaryServer hyp3.contoso.local -ReplicaStorageLocation e:\VirtualMachines -SecurityTag CONTOSO


Cmdlet Get-VMReplicationServer
Description This cmdlet retrieves the replication settings of the Replica server. If the server has not been configured as replica server, then the command returns default object.
Verb-Noun Get-VMReplicationServer
Syntax Get-VMReplicationServer [[-ComputerName] <String[]>]
Example  cmd3


Cmdlet Import-VMInitialReplication
Description This cmdlet is used on the replica server to import the IR files transferred by admin using external media. The IR files are expected to be accessible using the specified path.
Verb-Noun Import-VMInitialReplication
Syntax Import-VMInitialReplication [-VMName] <String> [-ComputerName <String[]>] [-Path] <String> [-PassThru] [-AsJob]
Example Import-VMInitialReplication -VMName CO-LEGAL-FS11 -Path I:\Replicas\CO-LEGAL-FS11_B410F33F-55E1-44CB-A81F-6D60F408A756


Cmdlet Measure-VMReplication
Description This cmdlets gets the statistics of VMReplication.
Verb-Noun Measure-VMReplication
Syntax Measure-VMReplication [[-VMName] <String[]>] [-ReplicaServerName <String>] [-ComputerName <String[]>] [-ReplicationTag <String>] [-State <String>] [-PrimaryServerName <String>]
Example  cmd4


Cmdlet New-VMReplicationAuthorizationEntry
Description This cmdlet creates a new authorization entry for the recovery server. The authorization entry consists of the following – AllowedPrimaryServer, ReplicaStorageLocation, KeepPrimaryStorageLocation, and SecurityTag
Verb-Noun New-VMReplicationAuthorizationEntry
Syntax New-VMReplicationAuthorizationEntry -KeepPrimaryStorageLocation [-AllowedPrimaryServer] <String> [-ComputerName <String[]>]
Example New-VMReplicationAuthorizationEntry hyp3.contoso.local -ReplicaStorageLocation d:\ReplicaStorage DEFAULT


Cmdlet Remove-VMReplication
Description This cmdlet is used to remove the replication relationship of a virtual machine. Replication relationship should be individually removed from both primary and replica virtual machines.
Verb-Noun Remove-VMReplication
Syntax Remove-VMReplication [-VMName] <String> [-ComputerName <String[]>] [-PassThru]
Example Remove-VMReplication -VMName CO-FIN1-FS1


Cmdlet Remove-VMReplicationAuthorizationEntry
Description This cmdlet enables the admin to remove an authorization entry from the Replica server, rescinding authorization of replication attempts made against the primary server associated with the entry.
Verb-Noun Remove-VMReplicationAuthorizationEntry
Syntax Remove-VMReplicationAuthorizationEntry [-AllowedPrimaryServer] <String> [-ComputerName <String[]>] [-PassThru]
Example Remove-VMReplicationAuthorizationEntry -AllowedPrimaryServer hyp3.contoso.local


Cmdlet Reset-VMReplicationStatistics
Description This cmdlet resets all the replication statistics for a specific virtual machine.  These statistics can be retrieved using the Measure-VMReplication cmdlet.
Verb-Noun Reset-VMReplicationStatistics
Syntax Reset-VMReplicationStatistics [-VMName] <string[]> [-PassThru] [-ComputerName <string[]>] [-WhatIf] [-Confirm]
Example Reset-VMReplicationStatistics -VMName Contoso-Print1


Cmdlet Resume-VMReplication
Description This cmdlet is used to resume replication of the virtual machine that is passed as input and are paused currently OR used to start resynchronization for a suspended/critical state virtual machine.
Verb-Noun Resume-VMReplication
Syntax Resume-VMReplication [-VMName] <String> [-ComputerName <String[]>] [-ResynchonizeStartTime <DateTime>] [-Resynchronize] [-PassThru]
Example Resume-VMReplication -VMName CO-EXEC-DATA1


Cmdlet Set-VMNetworkAdapterFailoverConfiguration
Description Configures the Failover IP settings for the n/w adapter. These IP settings will be applied to the virtual machines’s operating system whenever the virtual machines is started as part of failover.
Verb-Noun Set-VMNetworkAdapterFailoverConfiguration
Syntax Set-VMNetworkAdapterFailoverConfiguration [-VMName] <String[]> [[-VMNetworkAdapterName] <String[]>] [-ComputerName <String[]>] [-IPv6SubnetPrefixLength <String>] [-IPv6Address <String>] [-IPv6DefaultGateway <String>] [-IPv6AlternateDNSServer <String>] [-IPv6PreferredDNSServer <String>] [-IPv4SubnetMask <String>] [-IPv4Address <String>] [-IPv4DefaultGateway <String>] [-IPv4AlternateDNSServer <String>] [-IPv4PreferredDNSServer <String>]
Example A good example would be to use another Hyper-V cmdlet (Get-VMNetworkAdapter) to get the adapter and then make the setting changes –

Get-VMNetworkAdapter -VMName CO-EXEC-DATA1 | Set-VMNetworkAdapterFailoverConfiguration -IPv4Address -IPv4SubnetMask -IPv4DefaultGateway -IPv4PreferredDNSServer


Cmdlet Set-VMReplication
Description This cmdlet configures the replication relationship for a virtual machine. If the virtual machine is already configured for replication, it modifies the replication relationship of the virtual machine.
Verb-Noun Set-VMReplication
Syntax Set-VMReplication [-VMName] <String> [-ComputerName <String[]>] [[-ReplicaServerName] <String>] [[-ReplicaServerPort] <Int32>] [[-AuthenticationType] <String>] [-AsJob] [-PassThru] [-Reverse] [-AutoResynchronizeIntervalStart <DateTime>] [-AutoResynchronizeIntervalEnd <DateTime>] [-InitialReplicationStartTime <DateTime>] [-AsReplica] [-RecoveryHistory <Int32>] [-ExcludedVhdPath <String[]>] [-ExcludedVhd <Microsoft.Vhd.PowerShell.VirtualHardDisk[]>] [-CertificateThumbprint <String>] [-CompressionEnabled] [-ApplicationConsistentSnapshotFrequency <Int32>] [-DisableAppConsistentReplication] [-AutoResynchronizeEnabled]
Example Set-VMReplication -VMName CO-FIN-FS1 -ReplicaServerName -ReplicaServerPort 8080 -AuthenticationType Integrated -CompressionEnabled 1 -RecoveryHistory 0


Cmdlet Set-VMReplicationAuthorizationEntry
Description This cmdlet edits an existing authorization entry for the Replica server. This cmdlet can be used to modify the following – ReplicaStorageLocation,  KeepPrimaryStorageLocation, and SecurityTag for an existing “AllowedPrimaryServer”.
Verb-Noun Set-VMReplicationAuthorizationEntry
Syntax Set-VMReplicationAuthorizationEntry [-AllowedPrimaryServer] <String> [[-ReplicaStorageLocation] <String>] [-KeepPrimaryStorageLocation] [-ComputerName <String[]>] [-PassThru]
Example Set-VMReplicationAuthorizationEntry -AllowedPrimaryServer hyp3.contoso.local -ReplicaStorageLocation d:\ReplicaStorage


Cmdlet Set-VMReplicationServer
Description This cmdlet is used to provision the replica server, including specification of server authentication and the default storage location to be used. Multiple types of authentication could be allowed for the replica server. If certificate based authorization is chosen, then the certificate thumbprint is required.  You can also choose to enable replication from any servers thereby adding a * entry in the Authorization list
Verb-Noun Set-VMReplicationServer
Syntax Set-VMReplicationServer [-KeepPrimaryStorageLocation] [-ReplicationEnabled] [[-AllowedAuthenticationType] <Enum>] [-ReplicationAllowedFromAnyServer] [-ComputerName <String[]>] [-MonitoringStartTime <DateTime>] [-MonitotingInterval <TimeSpan>] [-CertificateAuthenticationPort <Int32>] [-CertificateThumbprint <String>] [-PassThru] [-IntegratedAuthenticationPort <Int32>]


Example Set-VMReplicationServer -ReplicationEnabled 1 -AllowedAuthenticationType Integrated -IntegratedAuthenticationPort 8080 -DefaultStorageLocation d:RecoveryData  -ReplicationAllowedFromAnyServer 1


Cmdlet Start-VMFailover
Description This cmdlet is used in multiple contexts – Planned Failover, Failover, and Test Failover.
Verb-Noun Start-VMFailover
Syntax Start-VMFailover [-VMName] <String> [-Prepare] [-ComputerName <String[]>] [-PassThru] [-AsJob]

Start-VMFailover [-VMName] <String> [-VMRecoverySnapshot]  [-Prepare] [-PassThru] [-AsJob]

Start-VMFailover [-VMName] <String> [-ComputerName <String[]>] [-PassThru] [-Prepare] [-AsJob] [-AsTest]

Example Planned Failover

Planned Failover is a workflow, and requires a series of cmdlets to be run in a particular order. Some cmdlets need to be run on the primary server, while others on the Replica server. Run the cmdlets in the following order:

  1. 1.     On the primary server:
    1. a.      Stop-VM –VMName CO-FIN-FS1 (Shuts down the VM)
    2. New-VMReplicationAuthorizationEntry -ReplicaStorageLocation d:\ReplicaStorage DEFAULT (Ensure current primary server/cluster allows current replica server/cluster to replicate. If the current primary server already authorizes the current replica server to send replication data, then this step (1b) can be skipped)
    3. Start-VMFailover -VMName CO-FIN-FS1 –prepare (Replicates any unreplicated changes)
  2. On the Replica server:
    1. Start-VMFailover -VMName CO-FIN-FS1 (Fails over the VM)
    2. Start-VMFailover -VMName CO-FIN-FS1 –reverse (Resumes the replication in the reverse direction)
    3. Start-VM –VMName CO-FIN-FS1 (Starts the VM)


Start-VMFailover -VMName CO-FIN-FS1 -VMRecoverySnapshot

Test Failover

Start-VMFailover -VMName CO-FIN-FS1 -AsTest


Cmdlet Start-VMInitialReplication
Description This cmdlet is used to start initial replication of the virtual machine. This cmdlet serves 3 purposes –

a. Starts Initial replication and Delta replication at the end of IR.

b. Starts initial replication if the Initial replication was cancelled manually by an administrator

c. Starts initial replication if the replication stopped due to some unrecoverable failure

Verb-Noun Start-VMInitialReplication
Syntax Start-VMInitialReplication [-VMName] <String> [-ComputerName <String[]>] [-PassThru] [-DestinationPath <String>] [-AsJob]
Example Online initial replication:

Start-VMInitialReplication –VMName CO-FIN-FS1


Initial replication using external media:

Start-VMInitialReplication –VMName CO-FIN-FS1 –DestinationPath “F:\ExportData”


Initial replication seeding from backup copy on Replica server

On Replica server

Set-VMReplication VM01 –AsReplica –AllowedPrimaryServer hyp3.contoso.local


On primary server

Start-VMInitialReplication –VMName CO-FIN-FS1 -UseBackup


Cmdlet Stop-VMFailover
Description This cmdlet allows the admin to cancel the ongoing failover of a virtual machine or the test failover for the virtual machine.
Verb-Noun Stop-VMFailover
Syntax Stop-VMFailover [-VMName] <String> [-ComputerName <String[]>] [-PassThru]
Example Stop-VMFailover –VMName CO-FIN-FS1


Cmdlet Stop-VMInitialReplication
Description This cmdlet is used to cancel the online Initial Replication that is going on. This cmdlet can also be used to cancel the ongoing export/import of OOB IR.
Verb-Noun Stop-VMInitialReplication
Syntax Stop-VMInitialReplication [-VMName] <String> [-ComputerName <String[]>] [-PassThru]
Example Stop-VMInitialReplication -VMName CO-FIN-FS1


Cmdlet Stop-VMReplication
Description This cmdlet is used to cancel the resync Replication that is going on.
Verb-Noun Stop-VMReplication
Syntax Stop-VMReplication [-VMName] <String> [-ComputerName <String[]>] [-PassThru]
Example Stop-VMReplication -VMName CO-FIN-FS1


Cmdlet Suspend-VMReplication
Description This cmdlet pauses replication in the virtual machine that is passed as input.
Verb-Noun Suspend-VMReplication
Syntax Suspend-VMReplication [-VMName] <String> [-ComputerName <String[]>] [-PassThru]
Example Suspend-VMReplication -VMName CO-EXEC-DATA1

Dynamic Optimization on SCVMM 2012

SCVMM 2012 introduced the ability to constantly monitor and rebalance load on clusters by using “Dynamic Optimization”.  How Dynamic Optimization works, will help understand its behavior and get the most out of this feature.

What does Dynamic Optimization do?  Simply put, it searches for live migrations within a Host Cluster that will improve the overall health of the cluster.  “Health” describes two main facets – Host load and VM configuration.

Dynamic Optimization versus PRO-tips

Users of VMM 2008 know both the benefits and the challenges of using PRO-tips to respond to load issues in their environment. Dynamic Optimization capitalizes on the brand new Intelligent Placement engine to more effectively and proactively handle changing load in your host clusters. PRO used an Operations Manager agent to monitor the host for critical thresholds being crossed, and then initiated migrations away from that host. Dynamic Optimization improves a few aspects of the process.

  • Dynamic Optimization monitors and acts natively in the VMM service,      without the need for Operations Manager integration.
  • Dynamic Optimization runs on the VMM server, not on each host, so      decisions are centralized and plans are formulated that are best for the      cluster as a whole, rather than potentially conflicting actions from each      host.
  • Dynamic Optimization is aware of all the rules and requirements of      each VM, without the need for different management packs to monitor many      aspects of VM health. Networking requirements, custom placement rules,      host reserves – Dynamic Optimization can respond centrally to issues with      all of these considerations.

For many health monitoring requirements Operations Manager is still the right choice and custom management packs allow deep monitoring of a wide range of specific hardware or configurations. In the case of VMM’s load management however, Dynamic Optimization is almost always the right tool for the job.

Dynamic Optimization’s logic

The dynamic optimizer is guided by a simple set of rules, given here in priority order.

Dynamic Optimization priority #1: Never introduce a new problem into the system

Any action that Dynamic Optimization takes is first checked to ensure that it doesn’t trigger any placement warnings or errors.  Warnings or errors will block Dynamic Optimization from considering that action, no matter how much it might rebalance the environment.  Also, certain VMs are marked as “Exclude from Dynamic Optimization”. These VMs will never be moved by Dynamic Optimization.

Dynamic Optimization priority #2: Resolve VM configuration issues (warnings or errors)

As Dynamic Optimization assesses the VMs being hosted in a cluster, the most important issue that will cause it to take action are rules being violated that are causing warnings or errors to placement. Has the VM been configured to require Network Optimization (VMQ) but the current host doesn’t have that available? Is the VM on a host that doesn’t have access to the correct logical networks that the VM needs?

Dynamic Optimization priority #3: Resolve violated host load thresholds

When you configure Dynamic Optimization at a HostGroup level, you will be asked to specify what your target maximums are for host load. When Dynamic Optimization detects that one of these thresholds has been crossed, it will make it a priority to attempt to migrate VMs in such a way as to reduce the load on the affected host.

Dynamic Optimization priority #4: Balance load across hosts

(Only applicable at aggressiveness settings High, Medium-High and Medium)
Once no issues from the first 3 priority levels can be found or corrected, Dynamic Optimization starts to search all possible migrations within the cluster to evaluate their net effect on the star ratings of the VM being migrated.  If the net increase in star rating meets the requirements of the HostGroup’s aggressiveness setting, the migration will be planned by Dynamic Optimization.  The star ratings necessary to trigger migrations are:

Dynamic Optimization Aggressiveness Star rating increase required
High 0.1 stars
Medium-High 0.2 stars
Medium 0.3 stars

Remember, these migrations will only be approved by Dynamic Optimization if they can occur without triggering any warnings or errors on the destination host.

Dynamic Optimization Modes – Manual vs Automatic

By default, Dynamic Optimization ships in manual mode. That means that it will take no automatic actions, but is available for you to trigger on-demand. You can run a manual Dynamic Optimization by right-clicking your cluster and choosing “Optimize Hosts” or choosing that option from the ribbon when a Host Cluster has focus.

Running Dynamic Optimization in manual mode will first do a calculation-only run, showing the proposed migrations and confirming before actually making any changes to the environment.

In the host group properties, you can elect to put Dynamic Optimization into automatic mode, and choose a calculation interval. (Default 10 minutes)  This will cause all the clusters in that host group to automatically calculate and execute a Dynamic Optimization plan periodically, without it being necessary for you to intervene.  Automatic Dynamic Optimization runs are not added to the task trail unless they result in migrations.

Dynamic Optimization Performance Data

Dynamic Optimization uses the same data that drives all placement, with two minor variations.
Firstly, for most placement functions (New VM, migrate VM, new service etc), performance data is aggregated and averaged over a long period of time to get a profile of the typical usage expected from a VM under normal conditions.

Dynamic Optimization needs to take actions based only on the most recent information, so it only looks at the most recent performance information gathered from VMs and hosts.  These performance samples are, by default, captured every 9 minutes, and the data used is a rolling average of the VM performance over that sample period.

Secondly, since Dynamic Optimization never does storage migrations, disk performance data is irrelevant and ignored when a host’s load is calculated. In VMM 2012, only CPU and Memory are considered to make up the host load metric used by Dynamic Optimization. Remember, however, that absolutely any piece of placement information will be used to evaluate if a VM is correctly configured or operating over the reserves or levels that you define.

Investigating Dynamic Optimization issues

We have had some tremendously positive feedback on Dynamic Optimization. Customers who contact us usually have only one major question. “How can I investigate whether Dynamic Optimization should be taking action on my cluster?”

Your first and most important diagnostic tool is VM migration ratings. All VMM 2012 functions are powered by the same Intelligent Placement engine, and Dynamic Optimization is no exception. The ratings and warnings that you see when considering a migration are based on the identical data and logic that drives Dynamic Optimization.  If you are expecting a VM to migrate from one host to another, just initiate that migration through the UI and take a look at the host ratings dialog. (You don’t need to actually do the migration, just get as far as ratings and then cancel.)

The primary issue that might be blocking Dynamic Optimization’s operation is the presence of warnings or errors in the migration rating. Dynamic Optimization will almost never make a migration that results in warnings or errors. The most common cause of Dynamic Optimization queries are clusters where some cluster-wide warning such as VMQ, cluster overcommit or agent health are causing a warning against every host. Resolving these warnings will allow Dynamic Optimization to run normally.

The next thing to consider is the level of overall imbalance and the aggressiveness setting. Dynamic Optimization will not migrate unless these is a considerable difference in host health. Having 10 small idle VMs on a large host will not be enough to necessarily start migrations to an empty host. The host has to be full enough that its star ratings start to decline perceptibly from those of another host.  Increasing aggressiveness to high will cause migrations to start sooner, as will applying CPU load to the VMs.
Lastly, check that VMs that you expect to migrate are not marked as “Exclude from Dynamic Optimization”.  VMs can opt out of Dynamic Optimization management, and if the only viable migrations are to VMs which are not available for Dynamic Optimization, no actions will occur.

Multitenant security and isolation with Hyper 2012

Virtualized data centers are becoming more popular and practical every day. IT organizations and hosting providers have begun offering infrastructure as a service (IaaS), which provides more flexible, virtualized infrastructures to customers—“server instances on‑demand.” Because of this trend, IT organizations and hosting providers must offer customers enhanced security and isolation from one another.

If you’re hosting two companies, you must help ensure that each company is provided its own privacy and security. Before Windows Server 2012, server virtualization provided isolation between virtual machines, but the network layer of the data center was still not fully isolated and implied layer-2 connectivity between different workloads that run over the same infrastructure.

For the hosting provider, isolation in the virtualized environment must be equal to isolation in the physical data center, to meet customer expectations and not be a barrier to cloud adoption.

Isolation is almost as important in an enterprise environment. Although all internal departments belong to the same organization, certain workloads and environments (such as finance and human resource systems) must still be isolated from each other. IT departments that offer private clouds and move to an IaaS operational mode must consider this requirement and provide a way to isolate such highly sensitive workloads.

Windows Server 2012 contains new security and isolation capabilities through the Hyper‑V Extensible Switch.

The Hyper‑V Extensible Switch is a layer‑2 virtual network switch that provides programmatically managed and extensible capabilities to connect virtual machines to the physical network with policy enforcement for security and isolation. The figure below shows a network with Hyper‑V Extensible Switch.


With Windows Server 2012, you can configure Hyper‑V servers to enforce network isolation among any set of arbitrary isolation groups, which are typically defined for individual customers or sets of workloads.

Multitenant security and isolation using the Hyper-V Extensible Switch is accomplished with private virtual LANs (PVLANs).

Virtual machine isolation with PVLANs. VLAN technology is traditionally used to subdivide a network and provide isolation for individual groups that share a single physical infrastructure. Windows Server 2012 introduces support for PVLANs, a technique used with VLANs that can be used to provide isolation between two virtual machines on the same VLAN.

When a virtual machine doesn’t need to communicate with other virtual machines, you can use PVLANs to isolate it from other virtual machines in your data center. By assigning each virtual machine in a PVLAN one primary VLAN ID and one or more secondary VLAN IDs, you can put the secondary PVLANs into one of three modes (as shown in the following figure). These PVLAN modes determine which other virtual machines on the PVLAN a virtual machine can talk to. If you want to isolate a virtual machine, put it in isolated mode.

The figure bellow shows how the three PVLAN modes can be used to isolate virtual machines that share a primary VLAN ID. In this example the primary VLAN ID is 2, and the two secondary VLAN IDs are 4 and 5.


You can put the secondary PVLANs into one of three modes:

  • Isolated. Isolated ports cannot exchange packets with each other at layer 2.
  • Promiscuous. Promiscuous ports can exchange packets with any other port on the same primary VLAN ID.
  • Community. Community ports on the same VLAN ID can exchange packets with each other at layer 2.


Other tools

Other tools that provide enhanced multitenant security and isolation through the Hyper-V Extensible Switch are:

Protection from Address Resolution Protocol/Neighbor Discovery (ARP/ND) poisoning (ARP spoofing) The Hyper‑V Extensible Switch provides protection against a malicious virtual machine stealing IP addresses from other virtual machines through ARP spoofing (also known as ARP poisoning in IPv4). With this type of man-in-the-middle attack, a malicious virtual machine sends a fake ARP message, which associates its own MAC address to an IP address it doesn’t own. Unsuspecting virtual machines send the network traffic targeted to that IP address to the MAC address of the malicious virtual machine instead of the intended destination. For IPv6, Windows Server 2012 provides equivalent protection for ND spoofing.

Dynamic Host Protocol (DHCP) guard protection blocks virtual machines from providing services to other virtual machines. In a DHCP environment, a rogue DHCP server could intercept client DHCP requests and provide incorrect address information. The rogue DHCP server could cause traffic to be routed to a malicious intermediary that sniffs all traffic before forwarding it to the legitimate destination. To protect against this particular type of man-in-the-middle attack, the Hyper-V administrator can designate which virtual switch ports can have DHCP servers connected to them. DHCP server traffic from other virtual switch ports is automatically dropped. The Hyper-V Extensible Switch now protects against a rogue DHCP server attempting to provide IP addresses that would cause traffic to be rerouted.

Virtual port ACLs

Virtual port access control lists (ACLs) provide the ability to block traffic by source and destination virtual machine. Port ACLs provide a mechanism for network isolation and metering network traffic for a virtual port on the Hyper‑V Extensible Switch. By using port ACLs , you can meter the IP or MAC addresses that can (or can’t) communicate with a virtual machine. For example, you can use port ACLs to enforce the isolation of a virtual machine by allowing it to talk only to the Internet or communicate only with a predefined set of addresses. By using the metering capability, you can measure network traffic going to or from a specific IP or MAC address, which allows you to report on traffic sent or received from the Internet or from network storage arrays.

You can configure multiple port ACLs for a virtual port. Each port ACL consists of a source or destination network address and a permit to deny or meter action. The metering capability also supplies information about the number of instances where traffic was attempted to or from a virtual machine from a restricted (“deny”) address.

Trunk mode to virtual machines. A VLAN makes a set of host machines or virtual machines appear to be on the same local LAN, independent of their actual physical locations. With the Hyper-V Extensible Switch trunk mode, traffic from multiple VLANs can now be directed to a single network adapter in a virtual machine that could previously receive traffic from only one VLAN. As a result, traffic from different VLANs is consolidated, and a virtual machine can listen in on multiple VLANs. This feature can help you shape network traffic and enhance multitenant security in your data center.

Monitoring. Many physical switches can monitor the traffic from specific ports flowing through specific virtual machines on the switch. The Hyper‑V Extensible Switch also provides this port mirroring. You can designate which virtual ports should be monitored and to which virtual port the monitored traffic should be delivered for further processing. For example, a security monitoring virtual machine can look for anomalous patterns in the traffic flowing through other specific virtual machines on the switch. In addition, you can diagnose network connectivity issues by monitoring traffic bound for a particular virtual switch port.

Windows PowerShell/Windows Management Instrumentation (WMI). Windows Server 2012 now provides Windows PowerShell cmdlets for the Hyper‑V Extensible Switch that let you build command-line tools or automated scripts for setup, configuration, monitoring, and troubleshooting. These cmdlets can be run remotely. Windows PowerShell also enables third parties to build their own tools to manage the Hyper-V Extensible Switch.



Windows Server 2012 multitenant isolation keeps customer virtual machines isolated, even when they are stored on the same physical server. Windows Server 2012 provides better multitenant security for customers on a shared IaaS cloud through the new Hyper‑V Extensible Switch. Benefits of the Hyper‑V Extensible Switch for better multitenant security and isolation are:

  • Security and isolation. The Hyper‑V Extensible Switch provides better security and isolation for IaaS multitenancy with PVLAN support, protection against ARP poisoning and spoofing, protection against DHCP snooping, virtual port ACLs, and VLAN trunk mode support.
  • Monitoring. With port mirroring, you can run security and diagnostics applications in virtual machines that can monitor virtual machine network traffic. Port mirroring also supports live migration of extension configurations.
  • Manageability. You can now use Windows PowerShell and WMI support for command-line and automated scripting support plus full event logging.

Multitenant isolation in Windows Server 2012 addresses concerns that may have previously prevented organizations from deploying Hyper-V within their data centers. Two such concerns are (1) the additional management overhead of implementing VLANs on their Ethernet switching infrastructure to ensure isolation between their customers’ virtual infrastructures, and (2) the security risk of a multitenant virtualized environment. With Hyper-V in Windows Server 2012, you can now use port ACLs to isolate customers’ networks from one another and not be required to set up and maintain VLANs. Also, your security needs are provided by protection against ARP spoofing and DHCP snooping.


The requirements for using the Hyper-V Extensible Switch for multitenant security and isolation are:

  • Windows Server 2012
  • The Hyper-V server role