If you are in Bangalore, India between March 21st and March 23rd, visit us at TechEd, India!

We have a product tent and a booth for Hyper-V Replica - drop in, meet us and learn more about HVR.

- Praveen

Image may be NSFW.
Clik here to view.

Authorization

For better control and security, it is recommended to specify the list of authenticated servers that can replicate rather than allowing replication traffic from any authenticated server. While enabling a Replica server, there are two sets of inputs which are required - Authentication and Authorization.

Image may be NSFW.
Clik here to view.

When allowing replication from specific servers, each entry in the list is called an "authorization entry". An authorization entry contains:

·         Server(s) that are allowed to replicate (Primary Server)

·         Default location where the Replica virtual hard disk files is to be created (Storage Location)

·         Tag to group a set of such allowed primary servers into a trust zone (Security Tag).

Primary Server

The primary server can be one of the following:

·         A single server identified by the Fully Qualified Domain Name (FQDN) (e.g., R2.constoso.com)

·         FQDN using wild-card (*.advertisement.contoso.com). Wild-card is supported only in the first octet, e.g., "*.advertisement.*", but not "advertisement*"

·       If the primary server is part of a cluster, you should specify the FQDN of the CAP (Client Access Point) of the Hyper-V Replica Broker of the primary side cluster. This allows you to add or remove nodes from the primary cluster without having to change the authorization entry in the Replica server.

Storage Location

The storage location specifies the folder where the virtual hard disk files for the Replica virtual machines will be created. If the Replica server is part of a cluster, then only a CSV or SMB file path can be provided.

If the storage location for an authorization entry is changed after a replica VM has been created, only subsequent replica VMs will be created in the new location.

Security Tag

A security tag needs to be specified for each authorization entry. A group of primary servers, with the same security tag can be considered to be part of a “trust zone”.

How is this useful? Hyper-V Replica allows replication to continue seamlessly when virtual machines are migrated either on the primary server/cluster or Replica server/cluster. Hence the replication traffic for a given Replica virtual machine cannot be tied only to the server that enabled replication of the virtual machine.

For the Replica server to allow replication traffic for a Replica virtual machine from a set of primary servers (the servers amongst which the primary virtual machine can move), those set of primary servers should be grouped into the same trust zone i,e the same security tag.

Image may be NSFW.
Clik here to view.

The security tag can be used for another scenario - in the above picture, servers in “Trust Zone 2” (say, security tag "TZ-2") will be able to send replication traffic for Replica virtual machines that were created by any of the servers in that trust zone. A server in “Trust Zone 2” will not be able to send replication traffic for a Replica virtual machine that was created by a server in “Trust Zone 1” (say, security tag "TZ-1"). This will ensure that in case a server from trust zone 2 gets compromised, the attacker cannot use replication to tamper the Replica virtual machine belonging to “Trust Zone 1”.

Security tag is a plain text, and can be created on the fly. No meta-data needs to be created for the same.

Using Powershell

• To add a new authorization entry

New-VMReplicationAuthorizationEntry -AllowedPrimaryServer <Server to be authorized> -ReplicaStorageLocation <Location where Replica files should be created> -SecurityTag <Tag>

Example:

New-VMReplicationAuthorizationEntry -AllowedPrimaryServer *.constoso.com -ReplicaStorageLocation E:\Replica -SecurityTag Finance

• To remove an existing authorization entry

Remove-VMReplicationAuthorizationEntry -AllowedPrimaryServer <authorized primary server> 

Example:

Remove-VMReplicationAuthorizationEntry -AllowedPrimaryServer *.constoso.com

• To add authorization entries, the "AllowAnyServer" property on the server should be set to FALSE.

Set-VMReplicationServer -AllowAnyServer $FALSE

• To query the current authorization entries, use the following cmdlet:

Get-VMReplicationAuthorizationEntry

Image may be NSFW.
Clik here to view.

Hyper-V Replica reduces the Recovery Time Objective (RTO) providing the ability to configure the static IP address of the Replica VM before it is failed over. This IP address setting is injected into the failed over VM. This post written by Vinod Atal who is one of the developers in the Hyper-V team demonstrates this feature.

Network Adapter status on Replica VM

When replication is enabled for a VM, the replica VM's network adapters are disconnected by default.

Image may be NSFW. Clik here to view.			Image may be NSFW. Clik here to view.
Primary Virtual machine			Replica Virtual machine

Inject IP address from UI

Administrators need to connect the replica VM to the appropriate switch in the Replica server. The IP address which needs to be used in the guest VM during failover can be configured now.

Open the Hyper-V manager and open the settings of the replica VM. Click on Network Adapter and click on the Failover TCP/IP below the setting.

Image may be NSFW.
Clik here to view.

Enter the IP (v4/v6) details including the address, subnet mask and DNS server(s) information. To verify the settings, invoke the "Test Failover" operation. It is recommended that this operation is run in an isolated network which can be achieved by using the Test Failover setting under the Replica VM’s network adapter setting. In the picture below, the replica VM is connected to one such private network.

Image may be NSFW.
Clik here to view.

By default, the network settings under Test Failover is not-connected to any switch. Once the above step is performed, when a test failover is invoked, the newly created VM will be connected to "Private Test Network" switch and the IP address provided under "Failover TCP/IP" will be injected into the test VM.

How does Guest IP injection work?

The Replica VM is blocked from starting unless the Failover workflow is initiated. The Failover TCP/IP settings which are provided are stored in the VM configuration file till then. When the replica VM is failed over, the KVP (Key Value Pair) Exchange integration component running within guest operating system picks up the staged settings and applies it inside the VM. Any failure to apply the settings is logged on root partition event viewer.

Few points to note:

• This feature is available only when the latest integration services installed for the VM.
• At the time of writing this article, this feature is available for Windows Guest OS'es only.
• This feature is supported only for synthetic network adapters.
• This feature cannot be used to inject IP addresses into non-replicated VMs

Inject IP address using PowerShell

The above functionality can be achieved using PowerShell as well. To set a IPv4 Failover TCP/IP settings on the replica VM, issue the following cmdlet: 

Set-VMNetworkAdapterFailoverConfiguration 'Windows 8 SQL Server' 

-IPv4Address 192.168.1.1 

-IPv4SubnetMask 255.255.255.0 

-IPv4DefaultGateway 192.168.31.1

To connect the VM to a different switch which would be used for Test Failover, use the following cmdlet:

Set-VMNetworkAdapter 'Windows 8 SQL Server' 

-TestReplicaSwitchName 'Private Test Network'

where ‘Private Test Network’ is the name of a virtual switch which provides an isolated network environment.

Inject IP address using WMI

A frequent question which we get is around providing the ability to inject multiple IP addresses on the same network adapter.

Though this cannot be achieved using UI or PowerShell, the same can be achieved in WMI. This address set is represented by WMI class Msvm_FailoverNetworkAdapterSettingData. A WMI snippet is given below which allows you to achieve the above functionality:

#Get vm object 

$vm = Get-WmiObject -Namespace 'root\virtualization\v2' -Class 'Msvm_ComputerSystem' | Where-Object { $_.ElementName -eq 'Windows 8 SQL Server' } 

# Get active settings 

$vmSettings = $vm.GetRelated('Msvm_VirtualSystemSettingData') | Where-Object { $_.VirtualSystemType -eq 'Microsoft:Hyper-V:System:Realized' } 

# Get all network adapters 

$nwAdapters = $vmSettings.GetRelated('Msvm_SyntheticEthernetPortSettingData') 

# Find associated failover network settings 

$failoverNetworkSettings = @() 

foreach($nwAdapter in $nwAdapters) 

{ 

     $failoverNetworkSettings = $failoverNetworkSettings + $nwAdapters.GetRelated("Msvm_FailoverNetworkAdapterSettingData") 

}   

#Set two IPv4 addresses for first network adapter 

$settingForFirstAdapter = $failoverNetworkSettings[0] 

#Each field is an array so multiple inputs can be given 

$settingForFirstAdapter.IPAddresses = {'192.168.1.1', '192.168.1.2'} 

$settingForFirstAdapter.Subnets = {'255.255.255.0', '255.255.255.0'} 

$settingForFirstAdapter.DefaultGateways = {'192.168.31.1'}   

# Address family values for settings IPv4 , IPv6 Or Boths 

# For IPv4:   ProtocolIFType = 4096; 

# For IPv6:   ProtocolIFType = 4097; 

# For IPv4/V6:ProtocolIFType = 4098; 

$settingForFirstAdapter.ProtocolIFType = 4096

#Set the failover IP address using replication service object 

$replicationService = $vm.GetRelated('Msvm_ReplicationService') 

$replicationService.SetFailoverNetworkAdapterSettings($vm.Path, {$settingForFirstAdapter.GetText(1)}) 

The post demonstrates the ease with which IP addresses can be injected during failover. If you wish to inject IP address into a running VM from the root partition, SetGuestNetworkAdapterConfiguration is a new API which allows you to achieve this.

Image may be NSFW.
Clik here to view.

Image may be NSFW. Clik here to view.

Posting this on behalf of Jeff Woolsey who delivered an amazing demo in the Day 1 Keynote address by Satya Nadella. The video is available here and the transcript for the keynote address is available here.

Some key takeaways from Jeff's presentation:

• 64 virtual processors in a VM
• 985,000 IOPs from a single Windows Server 2012 Hyper-V VM
• 4k Random IO; Queue Depth 32, 40 concurrent threads
• VMware tops out at 300,000 per VM; needs 6 VMs to achieve this
• Offloaded Data Transfer ODX (file copies of 1 GigaBYTE per second). Yes folks, copy a 10 GB file in 10 seconds.
• Works with SANs and the new Windows Server 2012 File Server
• Cisco Nexus 1000v for Hyper-V
• PowerShell as the engine for Run Book Automation with Hyper-V Replica
• Extending on premise private cloud to service provider

Image may be NSFW.
Clik here to view.

In Windows Server 2012 Release Candidate, Hyper-V administrators can monitor the ‘health’ of the replicating VMs using the Replication Health attribute. This property allows administrators to answer common questions such as:

• When did the primary and replica VMs last synchronize?
• What is the average size of the replica file?
• Were there any errors encountered during replication which requires your attention? etc.

The two-part FAQ post explains the concept of Replication Health and provides guidance on how to interpret the attribute values.

Q1: How do I view the health of the replicating VM?

• Click on the replicating VM and choose ‘View Replication Health…’ from either the Hyper-V Manager or Failover Cluster Manager

Image may be NSFW. Clik here to view.

Image may be NSFW. Clik here to view.

Image may be NSFW.
Clik here to view.

• (or) Click on the Replication tab in the bottom pane of the Hyper-V Manager to get a summary view

Image may be NSFW.
Clik here to view.

Q2: What is the ‘Replication State’ and what are the values?

Replication state shows the current state of the replicating VM. It indicates whether the VM is being replicated, whether initial replication is pending etc.

ReplicationState can be queried from:

• UI – As seen in the above picture
• PowerShell – Using the Measure-VMReplication cmdlet.
• WMI – From Msvm_ComputerSystem class where ReplicationState is a property

The table below captures the states as seen in WMI, UI and PowerShell.

Q3: Isn’t Replication State sufficient to track whether replication is in progress, why do I need Replication Health?

Good question! While Replication State is comprehensive, it provides the current replication status – it does not provide any ‘trending' information or warnings to watch out for.

On the other hand, Replication Health provides an aggregated view of events in a certain interval. Hyper-V Replica uses inbuilt heuristics to warn the administrator that replication is sub-optimal.

Let’s consider an example where your organization’s network connectivity is over burdened between 2am to 6am everyday. This could result in a sub-optimal replication of the VM (i.e replication is not occurring every 5mins or the replica VM is behind the primary VM by more than an hour). When you check the Replication State of the VM at 10am everyday, it would indicate that replication is normal (Replication Enabled, as described in the above table).

However, this does not paint a true picture as your replica is behind the primary VM. Replication Health on the other hand would either be set to Warning or Critical which would prompt you to debug the issue further.

Q4: Ah, so what are the possible values for Replication Health?

Hyper-V Replica aggregates these events into 3 potential values which can be queried from:

• UI – As seen in Q1 (above)
• PowerShell – Using the Measure-VMReplication cmdlet.
• WMI – From Msvm_ComputerSystem, where ReplicationHealth is a property

The table below captures the states as seen in WMI, UI and PowerShell.

Q5: When is Replication Health considered ‘Critical’?

The Replication Health is flagged as Critical if one of the following occurs:

• If the primary server is unable to send replication traffic to the Replica server (say due to network connectivity issues, storage issues on the primary or replica or if the primary VM requires resynchronization)
• If replication is paused on the replica VM

In the Replication Health pane, click on ‘View Events’ to see a filtered set of events corresponding to this VM which helps you root-cause the issue.

Image may be NSFW.
Clik here to view.

Q6: When is Replication Health flagged as ‘Warning’?

The Replication Health is shown as Warning when the replication is ‘not optimal’. The conditions which would result in a Warning health include:

• >20% of replication cycles have been missed in a monitoring interval – Common reasons which lead to this condition include insufficient network bandwidth, storage IOPS bottleneck on your replica server.
• More than an hour has elapsed since the last send replica (on the primary VM) was sent or the last received replica (on the replica VM) was received – This could result in a loss of more than 60mins worth of data loss if the replica VM is failed over (due to a disaster)
• If Initial Replication has not been completed
• If Failover has been initiated, but ‘reverse replication’ has not been initiated
• If the primary VM’s replication is paused.

Q7: So does ‘Normal’ mean that the replication is on track?

Correct, this health indicates that replication has the following characteristics:

• Less than or equal to 20% of the replication cycles are missed
• The last synchronization point was less than an hour
• The average latency is less than or equal to 5mins

Primary VM	Image may be NSFW. Clik here to view.
Replica VM	Image may be NSFW. Clik here to view.

That’s neat! Tell me more…

We will cover further details such as PowerShell cmdlets, tips to extend the platform capability to monitor the health by setting up alerts, interpreting the attribute in the Replication Health view, concept of a monitoring interval, monitoring start time etc., in the next post. So keep watching this space!

Image may be NSFW.
Clik here to view.

Continuing from where we left off the last time…

Q1: The Replication Health pane has loads of information, how do I  interpret these attributes?

Image may be NSFW. Clik here to view.

Image may be NSFW. Clik here to view.

I thought you would never ask Image may be NSFW.
Clik here to view.

1. On both the Primary and Replica VM, the following attributes are displayed:

Replication State	Refers to the current state of the replicating VM. The set of values are captured in Q3 under the UI column, in the previous post
Replication Type	Indicates whether the VM a Primary VM or a Replica VM
Current Primary Server	Provides the FQDN of the server on which the primary VM resides
Current Replica Server	Provides the FQDN of the destination server on which the replica VM resides
Replication Health	Refers to the health of the replicating VM. The set of possible values are Normal, Warning or Critical.
From Time	The start time for the monitoring interval
To Time	This calls out the current time or time at which this window was launched

The statistics below are collected between ‘From Time’ and ‘To Time’

Average size	The average size of the replica file (sent in every replication interval)
Maximum size	Maximum size of the replica file
Average Latency	Average time taken to transfer the replica file in a replication interval
Errors encountered	Number of errors encountered (eg: network disconnects, resynchronization etc.)
Successful replication cycles	Hyper-V Replica attempts to send the replica file every 5 mins (=>the number of replication cycles in an hour is 12). This counter captures the number of successful replication attempts.

  
• Last synchronized at: This refers to the last time the replica was sent to the primary server (or) received and applied in the replica server. The difference between the current time and this value, indicates the loss of data (measured in time) if a failover is initiated.

   2. On the primary VM:

• Size of data yet to be replicated: This refers to the size of the replica file which is being tracked but not sent to the replica server yet. The value signifies the loss of data (measured in MBs) if a failover is initiated on the replica VM.

   3. On the Replica VM:

• Test failover status: If Test failover is enabled at the time of measuring the statistics, then this attribute is set to ‘Running’ – else, it is set to ‘Not Running’
• Last Test Failover initiated at: This refers to the wall-clock time when the last test-failover operation was initiated.

   4. Buttons:

• Refresh: Refreshes the statistics by updating the ‘To time’.
• Reset Statistics: Zeros out the statistics for the current interval and starts afresh. You would typically used this option after rectifying a problem
• Save As: Saves the monitoring information as a CSV file which can be archived

Q2: Some follow-up questions – what is the replication interval? How can I change it?

Hyper-V Replica tracks the writes to the VM in a log file. This log file is sent every 5mins which is also called the replication interval. Administrators cannot configure this interval.

Due to network or storage issues or due to excessive churn in the VM, the replica file transfer might take more than 5mins to reach the destination server (and applied to the replica VM). Hyper-V Replica has inbuilt semantics to handle such situations by delaying the transfer of the next replica file. This impacts the ‘Successful Replication Cycles’ and Average Latency statistics.

 Q3: What is the Monitoring Interval and Monitoring Start Time and how do I get/set this?

The monitoring interval is a server level attribute which refers to the interval for which the replication statistics are captured and computed. This attribute can be viewed from Get-VMReplicationServer

PS C:\Windows\system32> Get-VMReplicationServer | select monitoringinterval, monitoringstarttime

The MonitoringInterval refers to the time interval for which the replication statistics should be collected. By default this is set to 12 hrs. The minimum value which can be set is 1hr and the maximum value is 7 days. It is recommended that a reasonably high value is used as smaller intervals might lead to incorrect conclusions.

The MonitoringStartTime refers to the time at which Hyper-V Replica should start monitoring the replicating VM. The input is denoted in a 24hr clock and is set to 9AM local time by default.

Both these values can be changed using the Set-VMReplicationServer. Eg: To modify the Monitoring interval to 12hrs and start time to 6AM, issue the following cmdlet:

Set-VMReplicationServer -MonitoringStartTime 06:00:00 -MonitoringInterval 12:00:00

In this example, when a VM is enabled for replication at 2pm, statistics are collected from 2pm to 6pm on the same day and health is reflected for this interval. The statistics are then reset and collected 6pm to 6am the next day and health is reflected for this interval.

Q4: Are the statistics from the previous monitoring intervals available?

Yes. In the event viewer, under the Hyper-V VMMS node, an Information message is recorded. The event ID for this is 29174.

Image may be NSFW.
Clik here to view.

Q5: Is the health attribute preserved when the VM migrates?

Yes, when the VM migrates from one node to another, the replication statistics are preserved and used in the new node.

Q6: I manage a N-node-cluster with many replicating VMs, I (obviously) cannot click on each VM to know it’s health. Is there an easier way to manage from UI?

Yes! From the Failover Cluster Manager you can run a query to get VMs with a specific replication Health. Under Roles, click on ‘Add Criteria’, choose ‘Replication Health’ and specify the criteria (Critical/Normal/Warning)

Image may be NSFW. Clik here to view.

Image may be NSFW. Clik here to view.

Q7: Is there any such provision in the Hyper-V Manager?

You can add the column ‘Replication Health’ from the Add/Remove Column option in Hyper-V Manager

Image may be NSFW. Clik here to view.

Image may be NSFW. Clik here to view.

Q8: Is there a PowerShell cmdlet to get all this information?

Yup, Measure-VMReplication captures the health and state related information

PS E:\Windows\system32> Measure-VMReplication -vmname SampleVM | select ReplicationHealth, ReplicationHealthDetails | fl

ReplicationHealth        : Critical

ReplicationHealthDetails : {Replication for virtual machine 'SampleVM' is in error. Fix the error(s) and resume

                           replication., More than 20 percent of replication cycles have been missed for virtual

                           machine 'SampleVM'. Replication might be encountering problems., Replica virtual machine

                           'SampleVM' is behind the primary by more than an hour.}

Q9: Is this sufficient to build an alerting mechanism?

Yes, using the cmdlet, you can set up custom warnings, send mail, run it frequently from Task scheduler etc. The options are limitless.

Our resident PS expert Rahul Razdan, has this nifty PS script which sends out a mail detailing the health of the replicating VM.

Add-PSSnapin Microsoft.Exchange.Management.Powershell.Admin -erroraction silentlyContinue

##### Configuration Section Starts ##### 

$SMTPName = "TTExchange.TailspinToys.com"

$EmailMessage = new-object Net.Mail.MailMessage

$SMTPServer = new-object Net.Mail.SmtpClient($SMTPName)

$EmailMessage.From = "TonyV@tailspintoys.com"

$EmailMessage.To.Add("JimH@tailspintoys.com")

$EmailMessage.To.Add("TonyV@tailspintoys.com")

##### Configuration Section Ends##### 

#Build a nice file name

$date = get-date -Format M_d_yyyy_hh_mm_ss

$csvfile = ".\AllAttentionRequiringVMs_"+$date+".csv"

#Build the header row for the CSV file

$csv = "VM Name, Date, Server, Message `r`n"

#Find all VMs that require your attention

$VMList = get-vm | where {$_.ReplicationHealth -eq "Critical" -or $_.ReplicationHealth -eq "Warning"}

#Loop through each VM to get the corresponding events

ForEach ($VM in $VMList)

    {

        $VMReplStats = $VM | Measure-VMReplication

        #We should start getting events after last successful replication. Till then replication was happening.

        $FromDate = $VMReplStats.LastReplicationTime 

        #This string will filter for events for the current VM only

        $FilterString = "<QueryList><Query Id='0' Path='Microsoft-Windows-Hyper-V-VMMS-Admin'><Select Path='Microsoft-Windows-Hyper-V-VMMS-Admin'>*[UserData[VmlEventLog[(VmId='" + $VM.ID + "')]]]</Select></Query></QueryList>" 

        $EventList = Get-WinEvent -FilterXML $FilterString  | Where {$_.TimeCreated -ge $FromDate -and $_.LevelDisplayName -eq "Error"} | Select -Last 3

        #Dump relevant information to the CSV file

        foreach ($Event in $EventList)

            {

                If ($VM.ReplicationMode -eq "Primary") 

                    {

                        $Server = $VMReplStats.PrimaryServerName

                    }

                Else

                    {

                        $Server = $VMReplStats.ReplicaServerName

                    }

                $csv +=$VM.Name + "," + $Event.TimeCreated + "," + $Server + "," + $Event.Message +"`r`n"

            }

    } 

#Create a file and dump all information in CSV format

$fso = new-object -comobject scripting.filesystemobject

$file = $fso.CreateTextFile($csvfile,$true)

$file.write($csv)

$file.close()

#If there are VMs in critical health state, send an email to me and my colleague

If ($VMList -and $csv.Length -gt 33)

    {

        $Attachment = new-object Net.Mail.Attachment($csvfile)

        $EmailMessage.Subject = "[ATTENTION] Replication requires your attention!"

        $EmailMessage.Body = "The report is attached."

        $EmailMessage.Attachments.Add($Attachment)

        $SMTPServer.Send($EmailMessage)

        $Attachment.Dispose()

    }

Else

    {

        $EmailMessage.Subject = "[NORMAL] All VMs replicating Normally!"

        $EmailMessage.Body = "All VMs are replicating normally. No further action is required at this point."

        $SMTPServer.Send($EmailMessage)

        $Attachment.Dispose()

    }

The script which works for a standalone node can be easily extended to query across a cluster (using Get-ClusterNode). Give it a shot in your deployment!

In summary, it is extremely important to monitor the health of the replicating VMs. The system has inbuilt retry semantics to address transient issues (eg: network outage) but there are certain events which require your intervention (eg: disk issues). Analyzing the replication health from time to time will help you identify and fix these issues.

Image may be NSFW.
Clik here to view.

The certificate requirements for Hyper-V Replica were discussed earlier – this post provides details on how to request a certificate from a Certification Authority (CA), which can then be used for Hyper-V Replica for certificate based authentication.

Step #1: Create an INF file

Copy-paste the text below to a .inf file which specifies the settings for the certificate request. Modify the Subject attribute to the server name (FQDN if applicable).

[Version] 

Signature="$Windows NT$"

[NewRequest] 

Subject = "CN=SERVER.CONTOSO.COM"   

Exportable = TRUE                   ; Private key is exportable 

KeyLength = 2048                    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384 

KeySpec = 1                         ; AT_KEYEXCHANGE 

KeyUsage = 0xA0                     ; Digital Signature, Key Encipherment 

MachineKeySet = True                ; The key belongs to the local computer account 

ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 

ProviderType = 12 

RequestType = CMC[EnhancedKeyUsageExtension] 

OID=1.3.6.1.5.5.7.3.1 ;Server Authentication

OID=1.3.6.1.5.5.7.3.2 ;Client Authentication

Save the above file as HVR.inf.

Step #2: Create a request

Issue the following command from an elevated command prompt, to create a certificate request from an .inf file.

certreq –new HVR.inf HVR.req

A request file with the name HVR.req is created in the same directory.

Step #3: Submit the request

There are three possible outcomes here:

• Submit the certificate request to an internal CA
• Submit the certificate request using the following command

certreq –submit –config “corpca1.fabrikam.com\Corporate Policy CA1” HVR.req HVR.cer

• The –config switch can be used (with certreq) to direct the request to a specific CA.  In the above command, this is “corpca1.fabrikam.com\Corporate Policy CA1”.
• Ensure that RPC traffic is allowed between the computer requesting the certificate and the CA.
• It is assumed that the root CA certificate is already installed in the Trusted Root Certification Authorities store of the local computer
• (OR) Submit the certificate request to an external CA
• Many external CAs take a Certificate Signing Request (CSR) block which contains information about your organization name, domain name etc. To get the CSR block from the req file, issue the following command:

certutil -encode HVR.req HVR.csr

• Open the csr file in notepad and send the contents to your external CA through the preferred medium (mail/web page upload) as dictated by your CA. A sample csr file (which I have manually edited) would look as follows:

-----BEGIN CERTIFICATE-----

LS0tLS1CRUdJTiBORVcgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tDQpNSUlETXpD

Q0Fwd0NBUUF3TURFdU1Dd0dBMVVFQXd3bGNISjJhV3BoZVhKak1pNW1ZWEpsWVhO

VElGSUNBVEUgTURFdU1Dd0dBMVVFQXd3bGNISjJhV3BoZVhKak1pNW1ZWEpsWVhO

URFdU1Dd0dBMVVFQXdRVcgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tDQpNSUlETW

MVVFQXdRVcgQ0VSVElGSUNBVEUQ0VSVElGSUNBVEUgURFdU1Dd0dBMVVFQXd3bGN

RSBSRVFVRVNULS0tLS0NCg==

-----END CERTIFICATE-----

Step #4: Finishing up…

Once the certificate is issued, issue the following command to install the certificate

certreq -accept HVR.cer

This command imports the certificate into the appropriate store.

Notes:

• In a clustered configuration, ensure that the certificate with the Hyper-V Replica Broker’s CAP name is installed on all the nodes of the cluster.
• Wildcard certificate: If you wish to deploy wildcard certificates, modify the subject attribute in the INF file to indicate the wildcard (eg: *.department.contoso.com) and follow the same steps as mentioned earlier
• SAN certificate: If you wish to deploy Subject Alternate Name certificates, use the following INF file and follow the same steps as mentioned earlier.

[Version] 

       Signature="$Windows NT$"

       [NewRequest] 

       Subject = "CN=dc.contoso.com"   

       Exportable = TRUE                   ; Private key is exportable 

       KeyLength = 2048                    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384 

       KeySpec = 1                         ; AT_KEYEXCHANGE 

       KeyUsage = 0xA0                     ; Digital Signature, Key Encipherment 

       MachineKeySet = True                ; The key belongs to the local computer account 

       ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 

       ProviderType = 12

       RequestType = CMC

       [RequestAttributes]

       SAN="dns=server1.dept.contoso.com&dns=server2.dept.contoso.com&dns=hvrbroker.dept.contoso.com"    ;Include the Hyper-V Replica Broker CAP name 

       [EnhancedKeyUsageExtension] 

       OID=1.3.6.1.5.5.7.3.1 ;Server Authentication

       OID=1.3.6.1.5.5.7.3.2 ;Client Authentication

• After the certificate is installed, run the following command from the command prompt on both the primary and replica server:

certutil –store my 

At least one of the certificates in your output should resemble the following sample output such that the Encryption test (not just Signature) has passed.

==============================Certificate 1 =====================================================

Serial Number: 6c028cf0d47c0db8490dbd18191eaeb1

Issuer: CN=corp-DC1-CA, DC=corp, DC=contoso, DC=com

NotBefore: 2/7/2012 9:39 PM

NotAfter: 12/31/2039 3:59 PM

Subject: CN=CLIENT1.corp.contoso.com

Non-root Certificate

Cert Hash(sha1): ba 20 b0 1a c1 dd d8 5c c9 4a 73 0f 61 e2 f0 ca a5 8d ed 6d

Key Container = 6199522e-cbe4-4a69-b27d-edcbdf06911e

Unique container name: b2c457fabbb5acb7fbac1c3585f8c079_2176a3a0-cd09-417b-87d7-826e858f5461

Provider = Microsoft RSA SChannel Cryptographic Provider

Encryption test passed

================================================================================================

Image may be NSFW.
Clik here to view.

While the concept of an “Authorization table” remains the same between Windows Server “8” Beta (as explained in an earlier post) and Windows Server 2012 RC, we have made some changes in the PowerShell cmdlet and UI surrounding this.

The phrase ‘Security Tag’ in Windows Server 8 Beta is now called Trust Group. We believe that the new phrase captures the concept better.

Image may be NSFW.
Clik here to view.

Similarly, the PowerShell cmdlets to modify the Authorization entries have changed

• Add an authorization entry

PS C:\Windows\system32> New-VMReplicationAuthorizationEntry -AllowedPrimaryServer "*.woodgrovebank.com" -ReplicaStorageLocation "C:\ClusterStorage\Volume1\WoodgroveBank" -TrustGroup Woodgrove

AllowedPS           StorageLoc                              TrustGroup

---------           ----------                              ----------

*.woodgrovebank.com C:\ClusterStorage\Volume1\WoodgroveBank Woodgrove

• Get Authorization entries

PS C:\Windows\system32> Get-VMReplicationAuthorizationEntry

AllowedPS                             StorageLoc                              TrustGroup

---------                             ----------                              ----------

*.contoso.com                         C:\ClusterStorage\Volume1\Contoso       Contoso

*.fabrikam.com                        C:\ClusterStorage\Volume1\Fabrikam      Fabrikam

*.tailspintoys.com                    C:\ClusterStorage\Volume1\TailspinToys  Tailspin

*.woodgrovebank.com                   C:\ClusterStorage\Volume1\WoodgroveBank Woodgrove

• Remove authorization entry based on trust group

PS C:\Windows\system32> Remove-VMReplicationAuthorizationEntry -TrustGroup Tailspin

PS C:\Windows\system32> Get-VMReplicationAuthorizationEntry

AllowedPS                             StorageLoc                              TrustGroup

---------                             ----------                              ----------

*.contoso.com                         C:\ClusterStorage\Volume1\Contoso       Contoso

*.fabrikam.com                        C:\ClusterStorage\Volume1\Fabrikam      Fabrikam

*.woodgrovebank.com                   C:\ClusterStorage\Volume1\WoodgroveBank Woodgrove

Image may be NSFW.
Clik here to view.

In an earlier post, we discussed the steps required to get a certificate from a Standalone CA or from a third party CA. For an Enterprise CA, the INF file needs to be modified and suitable templates need to be available to honor the certificate request.

To make things interesting, the post is written for a deployment where both the primary and replica serves are part of a cluster where a SAN (Subject Alternative Name) certificate is being used for achieving certificate based authentication. It’s worth calling out two points:

• The steps below can be used to create and manage wildcard and subject-name certificates by using an appropriate INF file (see earlier post for the INF file)
• This post captures just one potential deployment model. The steps below will vary based on your enterprise CA policies and templates

Step #1: Setup an Enterprise CA

For this post, I have setup an Enterprise CA (called frtest-new-ent-ca) on Windows Server 2012 RC build. The configuration is straight forward and is achieved by enabling the Active Directory Certificate Services (ADCS) role and configuring an Enterprise CA.

To deploy SAN certificates, the CA needs to be configured to accept the SAN attribute from the request file. Issue the following commands from an elevated command prompt on the machine on which the Enterprise CA is configured:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc

net start certsvc

Step #2: Manage/Create a template

An out-of-box installation of the ADCS role does not have a template which can be reused for Hyper-V Replica. You would need to duplicate an existing template using the following steps:

• Open ‘Certification Authority’ (certsrv.msc) from ‘Administrative Tools’
• Right click on ‘Certificate Template' and click on Manage

Image may be NSFW.
Clik here to view.

• Right click on Workstation Authentication and choose the Duplicate Template option

Image may be NSFW.
Clik here to view.

• The tabs which can be modified in the template are:
• Compatibility: (Optional) Certificate recipient and authority can be set to Windows Server 8/Windows Server 2012
• General: Provide display name, template name, validity period, renewal period as per your requirements.
• Security: Ensure that Authenticated Users are allowed to Read and Enroll. Depending on your deployment, domain users need to have similar privileges but Authenticated Users should usually suffice. 
• Extensions: Edit Application Policies and add Server Authentication
• Issuance Requirements: (Optional) It is recommended that the CA certificate manager approves the request (as opposed to Auto enrollment)
• Subject Name: Change the option to Supply in the Request

Snips from a sample template (called Hyper-VReplica) are shown below.

General: Image may be NSFW. Clik here to view.		Compatibility: Image may be NSFW. Clik here to view.
Extensions: Image may be NSFW. Clik here to view.		Security: Image may be NSFW. Clik here to view.
Issuance Requirements: Image may be NSFW. Clik here to view.		Subject Name: Image may be NSFW. Clik here to view.

In case you missed the blog post introduction, this is just one possible template configuration which can be used to issue SAN certificates for Hyper-V Replica. If the above conditions are broadly met in other templates, skip step #2, and use any existing template.

Step #3: Create SAN certificate on the primary cluster

• On any node in the primary cluster, retrieve the certificate for the certification authority by issuing the following command from an elevated command prompt

certutil -f -config "servername\frtest-new-ent-ca" -ca.cert EntCA.CER

Import this certificate into the Trusted Root Certification Authorities store of the Local computer. This is an optional step as the root certificate might already be installed in your servers.

• Create an INF file which would allow you to request SAN certificate from the Enterprise CA

[Version] 

Signature="$Windows NT$ 

[NewRequest]

Subject = "CN=SANCert" ; Can be any server name/string

Exportable = TRUE; Private key is exportable

KeyLength = 2048; Common key sizes: 512, 1024, 2048, 

KeySpec = 1             

KeyUsage = 0xA0     ; Digital Signature, Key Encipherment

MachineKeySet = True

ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

ProviderType = 12

RequestType = CMC

[RequestAttributes]

CertificateTemplate = "Hyper-VReplica" ; Name of the template which was created

SAN="dns=demo-pri1.contoso.com&dns=demo-pri2.contoso.com&dns=pribroker.FRTEST.nttest.microsoft.com"  ; FQDN of the nodes which make up the cluster, plus the Hyper-V Replica Broker CAP

Save the above file as SAN.inf

• Create a new request from the inf file

certreq -new SAN.inf SAN.req

• Submit the request to the Enterprise CA

certreq -submit -config "servername\frtest-new-ent-ca" SAN.req SAN.cer

• Work with your CA admin to issue the pending request. In this example, the request ID is 19

Image may be NSFW.
Clik here to view.

• Once the request is issued, on the primary node, issue the following command to retrieve the response (cer file) from the CA. The request ID is 19 in this example.

certreq -retrieve 19 SAN.cer

• Import this certificate into the Personal store of the Local machine. Once imported, the entry would look as follows (the Issued to attribute is set to the Subject name specified in the INF file)

Image may be NSFW.
Clik here to view.

• Export the SANCert (with the private key) as a pfx file
• Import the pfx file on each node of the cluster in the Personal store of the Local Machine. Ensure that the root certificate is available in each node as well.

Step #4: Create SAN certificate on the replica cluster

• Repeat the same steps as Step #3 after modifying the dns entries (under RequestAttributes) in the inf file

That’s it, you are good to go! You now have a setup which has SAN certificates which have been issued by your Enterprise CA. These certificates can be used on the replica and primary cluster to receive and enable replication respectively.

Image may be NSFW.
Clik here to view.

This post discusses a subtle change in the certificate workflow for Hyper-V Replica in Windows Server 2012 Release Candidate build and beyond.

Note:

• The pre-requisites certificate based authentication remains unchanged (as seen in an earlier post “Hyper-V Replica - Prerequisites for certificate based deployments”)
• Only the workflow for picking the certificate has changed – all other functionality (such as handling seamless replication during VM migration) and requirements (certificates, firewall rules) remain unchanged

Windows Server “8” Beta Workflow:

• A post explaining the workflow in Beta was published earlier. In summary, Hyper-V administrators picked a certificate from the Trusted Root Certification Authorities store of the Local Machine for certificate based authentication.
• The certificate thumbprint was used to find an appropriate certificate in the Personal store of the Local Machine.
• While the functionality was well received, we also got feedback around two aspects in the workflow:
• Picking root certificates: Many users felt that this was not intuitive and indicated that they were more comfortable dealing with Personal store certificates. Users wanted and expected the product to use the certificate which they picked.
• Error conditions: In certain scenarios, the errors which stemmed from picking the root certificate did not help users debug the problem. As Hyper-V Replica attempted to use a certificate which was different from the user input, root-causing the error proved to be cumbersome.

Summary of change:

• We listened to your feedback and introduced a minor change in the workflow which now requires you to pick the Personal store certificate.
• This post discusses the new workflow by using a SAN certificate as an example. The same steps can be used for other supported certificates.

Step #1: Enabling Replication on a Replica Cluster

• Let’s consider a clustered deployment on which a Hyper-V Replica Broker (called RepBroker) has been created.
• The administrator wants to allow the cluster to receive replication traffic and clicks on the Replication Settings of RepBroker. On a fresh cluster where the certificate have not been installed, the following error message is seen on clicking the Select Certificate… button.

Image may be NSFW.
Clik here to view.

• Using the information from the error message (and a little help from this post Image may be NSFW.
  Clik here to view.), the administrator creates and installs a SAN certificate which meets the requirement.

• Now, on clicking the Select Certificate… button, a filtered list (which matches the certificate pre-requisites) of certificates from the Personal Store of the Local Machine is shown:

Image may be NSFW.
Clik here to view.

(OR) To achieve the same from PowerShell, the following cmdlets can be used

• Get a list of certificates from the Personal store and note the thumbprint

PS C:\Windows\system32> cd cert:

PS Cert:\> cd .\\LocalMachine\My

PS Cert:\LocalMachine\My> dir

Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My

Thumbprint                                Subject

----------                                -------

0662D576C8726DBAD1CE029AFC20EB502990ADC2  CN=SANCert

• To enable the cluster to receive replication traffic from all authenticated servers by using certificate based authentication, on port 4000, the administrator should issue the following cmdlet:

PS Cert:\LocalMachine\My> Set-VMReplicationServer -ReplicationEnabled $true -AllowedAuthenticationType Certificate -CertificateAuthenticationPort 4000 -CertificateThumbprint "0662D576C8726DBAD1CE029AFC20EB502990ADC2" -ReplicationAllowedFromAnyServer $true -DefaultStorageLocation "C:\ClusterStorage\Volume1\Hyper-V Replica"

Step #2: Enabling Replication on a VM

• On a fresh primary cluster, if the administrator tries to enable replication using certificate based authentication before configuring the certificates, he is shown an error message:

Image may be NSFW.
Clik here to view.

• The administrator creates and installs a SAN certificate by following the same guidance as the replica server

• When the administrator now clicks on the Select Certificate… button, a filtered list of certificates from the Personal Store of the Local Machine which matches the certificate pre-requisites.

Image may be NSFW.
Clik here to view.

(OR) To achieve the above using PowerShell, the administrator issues the following cmdlets:

• Get certificate thumbprint which can be used to enable replication on a VM

PS C:\Windows\system32> cd cert:

PS Cert:\> cd .\\LocalMachine\My

PS Cert:\LocalMachine\My> dir

Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My

Thumbprint                                Subject

----------                                -------

DF2383991B18DBC45D10F17A7AE39DED6AA8C7AF  CN=PrimarySAN

• To enable replication on a VM (called SQLDB) to the configured replica cluster, the administrator should issue the following cmdlet.

PS Cert:\LocalMachine\My> Enable-VMReplication -VMName "SQLDB" -AuthenticationType Certificate -CertificateThumbprint "DF2383991B18DBC45D10F17A7AE39DED6AA8C7AF" -ReplicaServerName "repbroker.FRTEST.nttest.microsoft.com" -ReplicaServerPort 4000

• To complete initial replication over the network, the administrator should issue the following cmdlet

PS Cert:\LocalMachine\My> Start-VMInitialReplication -VMName "SQLDB"

Image may be NSFW.
Clik here to view.

When you enable replication on a virtual machine, the Replica virtual machine files are created under the location specified by you in the Replica server configuration on the Replica side. Under the specified location, the files are created under a folder structure that looks like:

Image may be NSFW.
Clik here to view.

The folders are named using GUIDs.

Why are GUIDs used to name the folders?

A fair question to ask. The same Replica server could be receiving replication from multiple primary servers and there is likelihood that two virtual machines being replicated from different primary servers could have same name, or have virtual hard disks with the same name. Hence, the folder names are used as GUIDs to ensure uniqueness is maintained.

Instead of this default folder structure, you may want to have a simpler folder structure as you are sure that you will not get such name conflicts in your setup. You may want a folder structure that looks like:

Image may be NSFW.
Clik here to view.

The good news is that you can achieve this using simple steps Image may be NSFW.
Clik here to view.. Here are the steps that could accomplish this for you:

1. Enable replication for the virtual machine, and ensure initial replication is not started immediately (You can choose to schedule the initial replication for a later time)
2. Once Replica virtual machine is created, use the Move wizard to move the storage of the virtual machine to the path of your choice (Storage migration)
3. Once the storage migration is complete, you can start the initial replication for the virtual machine

You can do the same steps using Powershell. Here is a sample script that accomplishes this task for you. This script assumes both primary and replica sides to be clustered setups. This script also assumes certificate-based authentication being used. You can easily customize the script if you have a different environment.

Function Enable-VMReplicationCustomStorageOneLocationUsingCertificate

    {

        [CmdletBinding()]

        Param

            (

                [Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$VMName,

                [Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$PrimaryCluster,

                [Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$ReplicaCluster,

                [Parameter(Mandatory=$FALSE,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$AllowedPrimaryServer

            )

        PROCESS 

            {   

                $PrimaryOwnerGroup = Get-ClusterResource -Cluster $PrimaryCluster | where {$_.ResourceType -eq "Virtual Machine Replication Broker"} 

                $PrimaryBrokerName = Get-ClusterResource -Cluster $PrimaryCluster | where {$_.ResourceType -eq "Network Name" -and $_.OwnerGroup -eq $PrimaryOwnerGroup.OwnerGroup} | Get-ClusterParameter -name "DNSName"

                $PrimaryBrokerDomain = get-item -path env:userdnsdomain

                $PrimaryBrokerFQDN = $PrimaryBrokerName.Value + "." + $PrimaryBrokerDomain.Value

                $ReplicaOwnerGroup = Get-ClusterResource -Cluster $ReplicaCluster | where {$_.ResourceType -eq "Virtual Machine Replication Broker"} 

                $ReplicaBrokerName = Get-ClusterResource -Cluster $ReplicaCluster | where {$_.ResourceType -eq "Network Name" -and $_.OwnerGroup -eq $ReplicaOwnerGroup.OwnerGroup} | Get-ClusterParameter -name "DNSName"

                $ReplicaBrokerDomain = get-item -path env:userdnsdomain

                $ReplicaBrokerFQDN = $ReplicaBrokerName.Value + "." + $ReplicaBrokerDomain.Value

                #Get the Primary VM object from the Primary Server

                $PrimaryVM = Get-ClusterGroup -Cluster $PrimaryCluster | ?{ $_ | Get-ClusterResource | ?{ $_.ResourceType -like "Virtual Machine" } } | get-vm | where {$_.Name -eq $VMName}

                #Get the Replica server configuration so that user doesnt have to explicitly provide the Replica port

                $ReplicaServerConfig = Get-VMReplicationServer -ComputerName $ReplicaBrokerFQDN

                #Determine whether the Replica allows all servers to replicate, or specific ones

                If ($ReplicaServerConfig.AllowAnyServer)

                    {

                        $ReplicaPath = $ReplicaServerConfig.DefaultStorageLocation + "\" + $VMName

                    }

                Else

                    {

                        IF (!$AllowedPrimaryServer) {Throw "Allowed Primary Server of the Replication authorization entry on Replica cluster is required to decide the path on which Replica files should be created. You can find the Allowed Primary Server by following cmdlet: Get-VMReplicationAuthorizationEntry -ComputerName " + $ReplicaBrokerFQDN}

                        $ReplicaAuthEntry = Get-VMReplicationAuthorizationEntry -ComputerName $ReplicaBrokerFQDN -AllowedPrimaryServer $AllowedPrimaryServer

                        $ReplicaPath = $ReplicaAuthEntry.ReplicaStorageLocation + "\" + $VMName

                    }

                $PersonalCert = $NULL

                $Date = Get-Date

                $PersonalCert = Get-ChildItem -Path Cert:\LocalMachine\My | ?{$_.DNSNameList.Unicode -contains $PrimaryBrokerFQDN}

                If (!$PersonalCert)

                    {

                        $PersonalCertList = Get-ChildItem -Path Cert:\LocalMachine\My | where {$_.subject -like "*"+$PrimaryBrokerFQDN+"*" -and $_.EnhancedKeyUsageList.friendlyname -contains "Server Authentication" -and $_.EnhancedKeyUsageList.friendlyname -contains "Client Authentication" -and $_.NotAfter -gt $Date -and $_.HasPrivateKey -eq $TRUE}

                        foreach ($PersonalCertIterator in $PersonalCertList)

                        {

                            $RootCert = Get-ChildItem -Path Cert:\LocalMachine\Root | where {$_.subject -like "*"+$PersonalCertIterator.Issuer+"*"}

                            If ($RootCert) 

                                {

                                    "Found the cert: " + $PersonalCertIterator.Thumbprint

                                    $PersonalCert = $PersonalCertIterator

                                    Break

                                } 

                        }

                    }

                If (!$PersonalCert) {throw "Error: No valid certificate found."}

                #Enable replication using Kerberos authentication

                Enable-VMReplication -VM $PrimaryVM -ReplicaServerName $ReplicaBrokerFQDN -ReplicaServerPort $ReplicaServerConfig.CertificateAuthenticationPort -AuthenticationType Certificate -CertificateThumbprint $PersonalCert.Thumbprint

                #Get the Replica VMs object. This is the VM whose storage needs to be migrated

                $ReplicaVM = Get-ClusterGroup -Cluster $ReplicaCluster | ?{ $_ | Get-ClusterResource | ?{ $_.ResourceType -like "Virtual Machine" } } | get-vm | where {$_.Name -eq $VMName}

                #Move the Replica VHDs to chosen locations

                $ReplicaVM | Move-VMStorage -DestinationStoragePath $ReplicaPath

                #Now start the initial replication. This cmdlet uses online mode and starts initial replication immediately. You can modify it to choose any other mode, or schedule

                Start-VMInitialReplication $PrimaryVM

            }

    }

Once you run this script on you primary cluster, you will get a function that can then be used to enable replication to get the desired folder structure on the Replica cluster. Here is an example usage for this script:

Enable-VMReplicationCustomStorageOneLocationUsingCertificate -VMName MyVM -PrimaryCluster MySeattleCluster -ReplicaCluster MyLondonCluster -AllowedPrimaryServer MySeattleBroker.contoso.com

Here MySeattleCluster is the name of the primary cluster, MyLondonCluster is the name of the replica cluster, and MyLondonCluster authorizes MySeattleCluster to replicate by an authorization entry where AllowedPrimaryServer value is MySeattleBroker.contoso.com

The certificate for replication is queried from the installed certificates. The first certificate valid for replication is picked. If you want to explicitly specify a certificate, you can replace $PersonalCert.Thumbprint used in the Enable-Replication cmdlet to the thumbprint of the certificate you want to use.

Here is a sample script for stand-alone primary replicating to stand-alone replica server using kerberos authentication:

Function Enable-VMReplicationCustomStorageOneLocation

    {

        [CmdletBinding()]

        Param

            (

                [Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$VMName,

                [Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$PrimaryServer,

                [Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$ReplicaServer,

                [Parameter(Mandatory=$FALSE,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)] [string]$AllowedPrimaryServer

            )

        PROCESS 

            {   

                #Get the Primary VM object from the Primary Server

                $PrimaryVM = get-VM $VMName -ComputerName $PrimaryServer

                #Get the Replica server configuration so that user doesnt have to explicitly provide the Replica port

                $ReplicaServerConfig = Get-VMReplicationServer -ComputerName $ReplicaServer

                #Determine whether the Replica allows all servers to replicate, or specific ones

                If ($ReplicaServerConfig.AllowAnyServer)

                    {

                        $ReplicaPath = $ReplicaServerConfig.DefaultStorageLocation + "\" + $VMName

                    }

                Else

                    {

                        IF (!$AllowedPrimaryServer) {Throw "Allowed Primary Server of the Replication authorization entry on Replica server is required to decide the path on which Replica files should be created. You can find the Allowed Primary Server by following cmdlet: Get-VMReplicationAuthorizationEntry -ComputerName " + $ReplicaServer}

                        $ReplicaAuthEntry = Get-VMReplicationAuthorizationEntry -ComputerName $ReplicaServer -AllowedPrimaryServer $AllowedPrimaryServer

                        $ReplicaPath = $ReplicaAuthEntry.ReplicaStorageLocation + "\" + $VMName

                    }

                #Enable replication using Kerberos authentication

                Enable-VMReplication -VM $PrimaryVM -ReplicaServerName $ReplicaServer -ReplicaServerPort $ReplicaServerConfig.KerberosAuthenticationPort -AuthenticationType Kerberos

                #Get the Replica VMs object. This is the VM whose storage needs to be migrated

                $ReplicaVM = get-VM $VMName -ComputerName $ReplicaServer                         

                #Move the Replica VHDs to chosen locations

                $ReplicaVM | Move-VMStorage -DestinationStoragePath $ReplicaPath

                #Now start the initial replication. This cmdlet uses online mode and starts initial replication immediately. You can modify it to choose any other mode, or schedule

                Start-VMInitialReplication $PrimaryVM

            }

    }

For both these scripts, if your Replica side allows any authenticated server to replicate, as opposed to allowing specific servers, you should skip the AllowedPrimaryServer parameter. The script will then use the default storage location returned by the Get-VMReplicationServer cmdlet as the base path for creating the Replica virtual machine files.

Here are some cmdlets that will help you query how you have set up the Replica side for allowing incoming replication:

On the Replica side, you could have authorized all authenticated servers to replicate, in which case the location where Replica virtual machine files will get created can be queried using the Get-VMReplicationServer cmdlet:

Get-VMReplicationServer -ComputerName MySeattle.contoso.com | Select ReplicationAllowedFromAnyServer, DefaultStorageLocation | fl

If the ReplicationAllowedFromAnyServer value returned by this cmdlet is FALSE, then you have chosen to allow only specific primary servers to replicate to the given Replica server (or cluster). In this case, the default location for creating Replica virtual machine files can be queried using the Get-VMReplicationAuthorizationEntry:

Get-VMReplicationAuthorizationEntry -ComputerName MySeattle.contoso.com

This will return all authorization entries on the specified Replica server. To query the authorization entry corresponding to a specific primary server, you can filter the query using the –AllowedPrimaryServer parameter. Specify the value that corresponds to the primary server from which you would be replicating virtual machines, e.g.,

Get-VMReplicationAuthorizationEntry -ComputerName MySeattle -AllowedPrimaryServer MyLondon.contoso.com

You can customize the scripts are per your specific setup. Keep watching this space for more such utility scripts.

Image may be NSFW.
Clik here to view.

If you are wondering “I have enabled replication and it looks like everything is in progress, but how do I know that I am truly protected”, then keep reading the next few posts as we walk you through the various types of failover, how and when to use them and the gotchas in different deployments.

At a high level, Hyper-V Replica supports three types of Failover:

• Test Failover
• Planned Failover
• Unplanned Failover

Each of these is built to meet specific and different needs. As you might know by now, using Hyper-V Replica you can replicate between different primary and replica site deployments – your primary server could be a standalone server or part of a cluster and similarly your replica server could be a standalone server or part of a cluster. Independent of your deployment, the workflow and the set of features offered are the same and the 3 types of failovers work in all deployments.

For this article, let’s assume the name of the virtual machine is VirtualMachine_Workload.

Test Failover (TFO)

1.What is Test Failover?

Test Failover is an operation initiated on your replica virtual machine which allows you to test the sanity of the virtualized workload without interrupting your production workload or ongoing replication.

2. When should I use Test Failover?

Think of Test Failover as an ability to non-disruptively simulate your recovery procedure in an isolated network. You should initiate this operation if you wish to:

• Run minimal tests to validate if your replication is on track
• Train your personnel on what is to be done in case of a disaster.
• Test the recovery plan that you have built to test your preparation when disaster does strike.

3. How should I use this feature?

TFO is performed on the replica virtual machine by right-clicking on the VM and choosing the Test Failover operation (either from the Hyper-V Manager or from the Failover Clustering Manager)

Image may be NSFW.
Clik here to view.

You are given a choice to pick one of the available recovery points.

Image may be NSFW.
Clik here to view.

After this, a NEW virtual machine is spun up on the replica site. The name of the new virtual machine is the name of the replica virtual machine with “ - Test” appended. In our example, it would be VirtualMachine_Workload – Test

Image may be NSFW.
Clik here to view.

The TFO virtual machine should then be started in an isolated network and client tests can be run against the same to validate replication. You can pre-assign a network and an IP address using the guest IP address injection feature. Once satisfied that replication is kosher, you should do “Stop Test Failover” on the Replica virtual machine, which will clean up the duplicate virtual machine.

Since Test Failover does NOT impact your production workload and does NOT impact your ongoing replication, it is recommended that you perform TFO regularly. There are a couple of mechanisms which help you track the frequency of this event – BPA rules and replication health.

The above procedure can be achieved using Powershell using the following cmdlets.

Image may be NSFW.
Clik here to view.

4. Anything to watch out for?

• For any replica virtual machine, the system allows only one TFO operation at a time. This prevents proliferation of test virtual machines.
• On a cluster, the replica VM and its associated test failover VM should be on the same node always. If these move to different nodes, the association between the replica VM and test-replica VM is broken. When that happens, the user can do another TFO and this will lead to two test failover VMs for one replica VM. Therefore care should be taken to ensure the replica VM and its test failover VM migrate together.

The next post will cover Planned Failover and the last in the series will cover the unplanned failover.

Image may be NSFW.
Clik here to view.

In the first part of this 3-part series, you learnt about Test Failover. In this part, I will talk about the Planned Failover (PFO).

1. What is Planned Failover?

PFO is an operation initiated on the primary VM which allows you to do an e2e validation of your recovery plan. PFO requires the VM to be shut down to ensure consistency.

PFO is *NOT* a substitute for High Availability which is achieved through clustering. PFO allows you to keep your business running with minimal downtime even during planned downtimes and guarantees zero data loss.

2. When should I use Planned Failover?

Planned Failover is used in the following cases

• I want to perform host maintenance on my primary and would like to run from the replica site.
• My primary site is expecting some power outage – I want to move over to the replica site.
• There’s an impending typhoon – I want to proactively take action to ensure business continuity.
• My compliance requirements mandate that every quarter, I run my workloads from the replica site for a week.

3. How should I use Planned Failover?

After turning off the primary virtual machine, PFO is performed on the primary virtual machine by right-clicking on the VM and choosing the Failover operation (either from the Hyper-V Manager or from the Failover Clustering Manager).

Image may be NSFW.
Clik here to view.

Please note – for the PFO to work from UI, remote WMI has to be enabled on the replica site and the user running the PFO should have the necessary privileges. More on remote WMI in a later blog.

4. How does Planned Failover work?

PFO does the following

• Performs pre-requisite checks to ensure the operation can succeed. These pre-requisite checks are:
  • As PFO is a “planned” activity with zero data, the primary virtual machine should be shut down before initiating the operation.
  • Once the VM is failed over in the replica site, Hyper-V Replica starts replicating the changes back to the primary server. For this to work, the primary server should be configured to receive replication from the Hyper-V Replica Broker on the replica side if the replica is a cluster or the replica server if the replica is a standalone.
• Sends the last set of tracked changes which ensures zero data loss.
• Reverses the direction of replication – so if you were replicating from Cluster-P (on the primary site) to Cluster-R (on the replica site), then the replication will happen from Cluster-R to Cluster-P. The primary virtual machine will become the replica virtual machine and vice-versa and all the recovery points are merged. This step is done at the end of PFO.
• If you have selected to start the virtual machine, the virtual machine is started on the Cluster-R site at the end of the operation. This boots off the latest point. You might decide not to start the virtual machine if the virtual machine is part of a multi-tiered application.

The above procedure can be achieved using Powershell using the following cmdlets.

Run these cmdlets on the primary side.

   1: Stop-VM VirtualMachine_Workload

   2:  

   3: Start-VMFailover -VMName VirtualMachine_Workload –prepare

Run these cmdlets on the replica side.

   1: Start-VMFailover -VMName VirtualMachine_Workload

   2:  

   3: Set-VMReplication -reverse -VMName VirtualMachine_Workload

   4:  

   5: Start-VM VirtualMachine_Workload

On a cluster, these cmdlets should be run against the node which is currently owning the virtual machine.

In the last part of this series, I will talk about unplanned failover and summarize the differences between these 3 failovers. Stay tuned!

Image may be NSFW.
Clik here to view.

In the first two parts of this 3-part series, you learnt about Test Failover (TFO) and Planned Failover (PFO). In this closing part of the series, I will talk about unplanned failover and summarize the differences of these 3.

1. What is Unplanned Failover?

Unplanned Failover is an operation initiated on the replica VM when the primary VM/site is hit by a disaster. During Unplanned Failover, a check is done using Remote WMI to see if the primary VM is running.This is to protect against accidental administrator actions on the replica VM. This check prevents a ‘split-brain’ scenario where both the production and the replica VMs are running.

2. When should I use Unplanned Failover?

Unplanned Failover is used in the following cases

• My primary site is experiencing unexpected power outage or a natural disaster
• My primary site/VM has had a virus attack and I want to restore my business quickly with minimal data loss by restoring my replica VM

3. How should I use Unplanned Failover?

Unplanned failover is performed on the replica virtual machine by right-clicking on the VM and choosing the Failover operation (either from the Hyper-V Manager or from the Failover Clustering Manager).

Image may be NSFW.
Clik here to view.

If you have turned on recovery history, Unplanned Failover can be performed against a previous point-in-time. This is usually done in case the most recent point is either corrupt or not application consistent. Once you failover, you should run some tests to check that the point-in-time is good. If the point-in-time has issues, you can cancel the failover using “Cancel Failover” on the replica VM. Then you can choose a different point-in-time and do a Failover.

After you have validated that the failed over VM is kosher, you should do a ‘Complete’ of the failover by performing an action on the replica virtual machine – this will ensure that the recovery points are merged.

The above procedure can be achieved using Powershell using the following cmdlets. Use Complete-VMFailover only  after ensuring that the failed over VM serves the purpose.

   1: $snapshots = Get-VMSnapshot -VMName VirtualMachine_Workload -SnapshotType Replica

   2:  

   3: Start-VMFailover -Confirm:$false -VMRecoverySnapshot $snapshots[0]

   4:  

   5: Complete-VMFailover -VMName VirtualMachine_Workload -Confirm:$false

Characteristics

The table below calls out the characteristics of the 3 failovers

Summary

In closing, use Test Failover frequently to check the fidelity of your replication and test your recovery plans. Use Planned Failover occasionally for either planned maintenance or disaster simulation or compliance reasons. Use Unplanned Failover when your primary site is hit by a disaster.

Image may be NSFW.
Clik here to view.

We have seen multiple queries on the steps required to create the Hyper-V Replica Broker using Powershell, a previous post describes the process but adding more details on the end to end workflow.

To create a Hyper-V Replica Broker in a DHCP environment, use the following cmdlets:

   1: #Specify the name for the Broker and static IP address

   2: $BrokerName = "ReplicaBroker"

   3:   

   4: #These are derived parameters and need not be specified

   5: $BrokerResourceName = "Virtual Machine Replication Broker"

   6: $TempBrokerGroupName = $BrokerName + "Group"

   7:   

   8: #Creating a cluster server role to create the Broker CAP

   9: Add-ClusterServerRole -Name $BrokerName | Out-Null

  10:   

  11: #Creating Hyper-V Replica Broker Group using WMI

  12: ([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup($TempBrokerGroupName, 115) | Out-Null

  13: Add-ClusterResource -Name $BrokerResourceName -Group $TempBrokerGroupName -ResourceType "Virtual Machine Replication Broker" | Out-Null

  14:   

  15: #Moving the Broker CAP to the right group"

  16: Move-ClusterResource -name $BrokerName  -Group $TempBrokerGroupName | Out-Null 

  17: Add-ClusterResourceDependency  $BrokerResourceName $BrokerName | Out-Null

  18:   

  19: #Moving the temoporary group used to create the Broker CAP"

  20: Remove-ClusterGroup -name  $BrokerName -RemoveResources -Force | Out-Null

  21:   

  22: #Rename cluster group to get parity in name between the group and CAP"

  23: Get-ClusterGroup $TempBrokerGroupName | %{ $_.Name = $BrokerName }

  24:   

  25: #Starting Hyper-V Replica Broker Resource"

  26: Start-ClusterGroup -Name $BrokerName | Out-Null

To specify a static IP address for the Hyper-V Replica Broker, specify the IP address in the StaticAddress parameter of the Add-ClusterServerRole 

   1: #Specify the name for the Broker and static IP address

   2: $BrokerName = "ReplicaBroker"

   3: $IPAddressOfBroker = "172.22.57.87"

   4:   

   5: #These are derived parameters and need not be specified

   6: $BrokerResourceName = "Virtual Machine Replication Broker"

   7: $TempBrokerGroupName = $BrokerName + "Group"

   8:   

   9: #Creating a cluster server role to create the Broker CAP

  10: Add-ClusterServerRole -Name $BrokerName -StaticAddress $IPAddressOfBroker | Out-Null

  11:   

  12: #Creating Hyper-V Replica Broker Group using WMI

  13: ([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup($TempBrokerGroupName, 115) | Out-Null

  14: Add-ClusterResource -Name $BrokerResourceName -Group $TempBrokerGroupName -ResourceType "Virtual Machine Replication Broker" | Out-Null

  15:   

  16: #Moving the Broker CAP to the right group"

  17: Move-ClusterResource -name $BrokerName  -Group $TempBrokerGroupName | Out-Null 

  18: Add-ClusterResourceDependency  $BrokerResourceName $BrokerName | Out-Null

  19:   

  20: #Moving the temoporary group used to create the Broker CAP"

  21: Remove-ClusterGroup -name  $BrokerName -RemoveResources -Force | Out-Null

  22:   

  23: #Rename cluster group to get parity in name between the group and CAP"

  24: Get-ClusterGroup $TempBrokerGroupName | %{ $_.Name = $BrokerName }

  25:   

  26: #Starting Hyper-V Replica Broker Resource"

  27: Start-ClusterGroup -Name $BrokerName | Out-Null

Once the Hyper-V Replica Broker is created, enable the cluster to receive replication traffic by using the Set-VMReplicationServer cmdlet.

Image may be NSFW.
Clik here to view.

Hi, I’m Lalithra Fernando, a program manager on the Hyper-V team, working in various areas including clustering and authorization, as well as with our Hyper-V MVPs. In this post, I’ll be talking about resource metering, a new feature in Hyper-V in Windows Server 2012.

As you’ve probably heard by now, Windows Server 2012 is a great platform for the private cloud. When we began planning this release, we realized that one of the things you need in order to run a cloud is to be able to charge your users for the resources they use.

This is the need resource metering fills. It allows you to measure the resource utilization of your virtual machines. You can use this information as a platform for your own dynamic chargeback solutions, where you can charge customers based on the resources they use instead of a flat upfront cost, or to plan your hosting capacity appropriately.

There are four resources that you can measure: your CPU, memory, network, and storage utilization. We measure these resources over the period of time between when you measure and when you last reset metering.

CPU (MHz): We report the average utilization in megahertz.

Now, you’re probably wondering why we don’t report this as a percentage. After all, that’s what we do in Hyper-V Manager. Well, we know that you like to move your virtual machines. With Windows Server 2012, you can live migrate your virtual machines all over the place. Naturally, the record of how much resources your virtual machine has used moves with it.

We want the virtual machine’s CPU utilization to make sense across multiple machines. If we report a percentage and you move the virtual machine to a host with different processing capabilities, it’s no longer clear what the percentage refers to.

Instead, we report in megahertz. For example, if your virtual machine had an average CPU utilization of 50% over the past billing cycle on a host with a CPU running at 3GHz, we would report 1500MHz.

If your virtual machine spent one hour on a host with a 3GHz CPU and used 50% and another hour on a host with 1GHz CPU and used 75%, we would report the following:

(3GHz * 1000MHz/1GHz * .5 * 1hr) + (1GHz * 1000MHz/1GHz * .75 * 1hr) = 2250MHz-Hr

Here I am converting the CPU capacity from GHz to MHz and figuring out how much of that capacity was used over each hour.

2250MHz-Hr / 2 Hours = 1125 MHz.

Then, I simply divide over the two hours to get this value.

One final note: we don’t report minimum and maximum utilization values for CPU. If you think on it a moment, you’ll come to the same realization we did: it is very likely that the minimum will be 0 and the maximum will be the full capacity of the hosts’ CPU at some point over the timespan you’re measuring. Since that’s not very useful, we don’t report it.

Memory (MB): We report the average, maximum, and minimum utilization here, in megabytes.

The minimum memory utilization captures the least memory used over the timespan measured. Since it’s not very useful to know that the minimum memory usage was zero if the virtual machine was ever turned off, we only look at the minimum memory utilization when the virtual machine is running.

We do include the offline time of the virtual machine when calculating the average memory utilization. This provides an accurate view of how much memory the virtual machine was using over that billing cycle, so that you can charge your users accurately.

Network (MB): We report network utilization in megabytes. Of course, we want this metric to be useful, so we considered how you would want to see this information broken down. One way you might want to distinguish between network traffic is to see how much traffic is inbound to the virtual machine, and how much is outbound.

The most important breakdown you will want is how much traffic does the virtual machine send or receive from the internet, which costs you money, and how much is just communication between virtual machines you host, which costs you nothing since it is just using your intranet. With this breakdown, you can charge your user accurately for their internet usage.

So how do we provide these breakdowns? We use ACLs set on the virtual machine’s network adapter. Each ACL has

• Direction
• “Inbound” or “Outbound”
• Remote IP Address
• The source or destination of the network packet, depending on direction
• For example, 10.0.0.0/8
• Action
• Allow, Deny, or Meter

These ACLs are used for more than just resource metering; note the Allow and Deny actions. For our purposes, you set the action to “Meter”.

Enabling resource metering creates two sets of default metering ACLs, provided none are already configured. The first set of ACLs, one inbound and one outbound, has a remote IP address of *.*; this wildcard notation indicates that it will meter all IPv4 traffic that is not covered by another ACL. The second set has an IP address of *:*, which meters all IPv6 traffic.

With these metering ACLs, you can measure the total network traffic sent and received by the virtual machine, in megabytes. You can configure your own ACLs to count intranet traffic separately from internet traffic, and charge accordingly.

Disk (MB): As we spoke with customers, we realized that for chargeback purposes, they were only interested in the total disk allocation for a virtual machine. So, here we report that in megabytes.

The total value is the capacity (not the current size on disk) of the VHDs attached to the virtual machine plus the size of the snapshots. Take the following examples:

Fixed size disk: 

VM with a single 100GB fixed size VHDs attached
-------------------------------------------------------------
Total Disk Allocation reported: 100GB

Dynamic disk:

VM with a single dynamic VHD attached,
Current size 30GB, maximum size 100GB
-------------------------------------------------------------
Total Disk Allocation reported: 100GB

With snapshots:

VM with a single dynamic size VHDs attached,
Current size 30GB, maximum size 100GB,
Plus a 20GB snapshot
-------------------------------------------------------------
Total Disk Allocation reported: 120GB

Pass-through disks, DAS disks, guest iSCSI connections, and virtual Fibre Channel disks are not included in the total disk allocation metric.

Once you enable resource metering, Hyper-V will begin collecting data. You can reset metering at any time. We will then discard the data we have collected up to that point and start fresh. So, you will typically measure the utilization first, and then reset. When you measure, you are measuring the utilization over the timespan since you last reset metering. Metering is designed to collect this data over long periods of time. If you need greater granularity, you can look at performance counters. 

Having resource metering enabled and just capturing utilization data per your billing cycle has no noticeable performance impact. There will be some negligible disk and CPU activity as data is written to the configuration file.

You can try this all out for yourself now, with Windows Server 2012. In the next part, we’ll talk about how to actually use resource metering with our PowerShell cmdlets.

We hope this is useful for you. Please let us know how you’re using it! Thanks!

Image may be NSFW.
Clik here to view.

Hey, it's Lalithra again. In the last part, we talked about what resource metering is. Now, we’ll get into how to use it with PowerShell.

A quick note: if this is your first foray into PowerShell, here are some resources you may find helpful to go through. First, a couple of posts from the Scripting Guy to give you a good overview: An Introduction and PowerShell and Pipelining. Also, check out the Windows PowerShell for the Busy Admin series of webcasts by Scripting Guy Ed Wilson. Highly recommended.

Let’s get started. First, let’s find the cmdlets we’re looking for.

PS C:\> Get-Command *VM*

This prints out a list of cmdlets with VM in their names. If we look through this list for something related to resource metering, we’ll find the cmdlets we’re looking for.

PS C:\> Get-Command *VMResourceMetering*

If you want more details on a particular cmdlet, use Get-Help.

Now, let’s enable resource metering.

PS C:\> Enable-VMResourceMetering –VMName Greendale-VM

We can see if a virtual machine has resource metering enabled by looking at its properties:

PS C:\> Get-VM –VMName Greendale | Format-Table Name, ResourceMeteringEnabled

Name                                                                        ResourceMeteringEnabled
----                                                                        -----------------------
Greendale-VM                                                                                   True

Here, I’m piping the VM Object into the Format-Table cmdlet, which will print out a table with the name of the virtual machine and whether resource metering is enabled or not. In this case, I see that metering is enabled.

If you want to disable metering, it’s simple. Just swap out the verb:

PS C:\> Disable-VMResourceMetering –VMName Greendale-VM

Let’s see what the resource utilization is like so far.

PS C:\> Measure-VM –VMName Greendale-VM

VMName       AvgCPU(MHz) AvgRAM(M) MaxRAM(M) MinRAM(M) TotalDisk(M) NetworkInbound(M) NetworkOutbound(M)
------       ----------- --------- --------- --------- ------------ ----------------- ------------------
Greendale-VM 86          1750      2608      1119      40960        9930              2945

Now I can see the CPU, memory, disk, and network utilization, as covered in the last post.

If I want to see the utilization in greater detail…

PS C:\> $report = Measure-VM –VMName Greendale-VM
PS C:\> $report | Format-List
AvgCPU                      : 86
AvgRAM                      : 1750
MinRAM                      : 1119
MaxRAM                      : 2608
TotalDisk                   : 40960
ComputerName                : LALITHRF-N1
VMId                        : 2aeec321-08e2-47c6-a360-dfafecff4525
VMName                      : VMM 2012 SP1
MeteringDuration            : 19.03:57:44.2660000
AverageProcessorUsage       : 86
AverageMemoryUsage          : 1750
MaximumMemoryUsage          : 2608
MinimumMemoryUsage          : 1119
TotalDiskAllocation         : 40960
NetworkMeteredTrafficReport : {Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                              Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                              Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                              Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport}

Here, I’m storing the output of Measure-VM into a variable, $report. I’m printing out everything in this report in list form.

A quick aside, you may have noticed that we have seemingly redundant properties such as AvgCPU and AverageProcessorUsage. We use the shorter parameter names for the column headings in our tables, as seen above. This allows the table to fit on a PowerShell prompt. Since it is likely that you would use the names you see in the tables to access the various properties, we added the shorter names as aliases, so that the properties remain intuitive to work with.

If I want more details on the network utilization, I’ll want to look at the NetworkMeteredTrafficReport property:

PS C:\> $report.NetworkMeteredTrafficReport

LocalAddress RemoteAddress Direction TotalTraffic(M)
------------ ------------- --------- ---------------
             *.*           Outbound  308
             *:*           Inbound   6047
             *.*           Inbound   3883
             *:*           Outbound  2637

What if I want to add another ACL? As we talked about on the last post, ACLs, set on a virtual machine’s network adapter, allow you measure traffic that uses your internet versus your intranet, or any other division you choose.

PS C:\> Add-VMNetworkAdapterAcl –VMName Greendale-VM –Action Meter –Direction Inbound –RemoteIpAddress 10.0.0.0/8

If I want to remove it, simply swap the verb:

PS C:\> Remove-VMNetworkAdapterAcl –VMName Greendale-VM –Action Meter –Direction Inbound –RemoteIpAddress 10.0.0.0/8

One side note: Disable-VMResourceMetering does not remove the default *.* and *:* metering ACLs. If you want to remove them, use the Remove-VMNetworkAdapterAcl cmdlet. If you want to use SR-IOV, you will want to remove them, as metering and SR-IOV are not compatible.

Finally, now that I’ve measured the data I’m interested in, and saved it for your chargeback solution, I need to reset resource metering, so that it collects the data just for this next billing cycle.

PS C:\> Reset-VMResourceMetering –VMName Greendale-VM

Now, if I measure again, I see that the values are reset:

PS C:\> Measure-VM –VMName Greendale-VM

VMName       AvgCPU(MHz) AvgRAM(M) MaxRAM(M) MinRAM(M) TotalDisk(M) NetworkInbound(M) NetworkOutbound(M)
------       ----------- --------- --------- --------- ------------ ----------------- ------------------
Greendale-VM 1557        1198      1198      1198      40960        2                 1

That’s it! You should be able to put those pieces together for your own purposes. Please let us know how you’re using it!

Image may be NSFW.
Clik here to view.

Windows Server 2012 is generally available for evaluation and purchase by all customers around the world. Additionally, there is great news for organizations that are looking for a way to migrate virtual machines hosted on VMware vSphere to the Hyper-V host in Windows Server 2012. The production (RTW) version of the Microsoft Virtual Machine Converter (MVMC) and the Beta version of the VMware console plugin version are both available to download. We extend a huge thank you to our beta participants who have taken the time to evaluate the pre-release versions of the tools and provided us with extremely valuable feedback. MVMC is one resource available as part of the Switch to Hyper-V program announced at Microsoft’s Worldwide Partner Conference earlier this year. The Switch to Hyper-V program helps partners and customers go beyond virtualization to true cloud computing by providing guidance, resources, and tools that take the risk out of virtual migrations, reduce the time and effort required, and define best practices.

Click on the links provided below to download MVMC and the MVMC Plug-In for vSphere Client

• MVMC Standalone solution (Production Release)
• MVMC Plug-In for VMware vSphere Client Beta

In case you haven’t had a chance to evaluate the pre-release versions of these tools, MVMC provides a Microsoft-supported, freely available, standalone solution and a VMware console plugin solution. In each case, it converts VMware virtual machines (VMs) and VMware virtual disks (VMDKs) to Hyper-V virtual machines and Hyper-V virtual hard disks (VHDs). The virtual machine conversion capability can be invoked through a graphical user interface (GUI) or a command- line interface. The wizard-driven GUI has all of 5 simple screens where user input is required and you are ready to convert a virtual machine from vSphere to Hyper-V. It doesn’t get more simple than that!

MVMC converts VMware virtual machines created with:

• VMware vSphere 4.1
• VMware vSphere 5.0
• VMware vSphere 4.0 if the host is managed by vCenter 4.1 or vCenter 5.0. You have to connect to vCenter 4.1 or 5.0 through MVMC for virtual machines on vSphere 4.0 to be converted.

To virtual machines for:

• Windows Server® 2012 Hyper-V
• Microsoft Hyper-V Server 2012
• Windows Server 2008 R2 SP1 Hyper-V
• Microsoft Hyper-V Server 2008 R2 SP1

Hope you have a great experience using MVMC.

Cheers,
Microsoft Virtual Machine Converter Team 

Image may be NSFW.
Clik here to view.