Hyper V 2012R2 NIC Teaming / Converged Network Fabric

 

NIC teaming, also known as Load Balancing/Failover (LBFO), allows multiple network adapters to be placed into a team for the purposes of

• bandwidth aggregation, and/or

• traffic failover to maintain connectivity in the event of a network component failure.

 

For Hyper V 2012R2, the recommended and best practice is to use “Switch Independent configuration / Dynamic distribution”

 

This will also include the concept of converged fabric and network virtualization.

 

This configuration will distribute the load based on the TCP Ports address hash as modified by the Dynamic load balancing algorithm. The Dynamic load balancing algorithm will redistribute flows to optimize team member bandwidth utilization so individual flow transmissions may move from one active team member to another. The algorithm takes into account the small possibility that redistributing traffic could cause out-of-order delivery of packets so it takes steps to minimize that possibility.

The receive side, however, will look identical to Hyper-V Port distribution. Each Hyper-V switch port’s traffic, whether bound for a virtual NIC in a VM (vmNIC) or a virtual NIC in the host (vNIC), will see all its inbound traffic arriving on a single NIC.

This mode is best used for teaming in both native and Hyper-V environments except when:

a) Teaming is being performed in a VM,

b) Switch dependent teaming (e.g., LACP) is required by policy, or

c) Operation of a two-member Active/Standby team is required by policy.

To configure NIC teaming in Hyper V, Hyper V must be already installed on the system and switch port is configured as trunk port.

 

Before running the command, make sure the Hyper V role is enabled.

 

 

Command

New-NetLbfoTeam -Name ConvergedTeam -TeamMembers NIC1,NIC2,NIC3,NIC4 -LoadBalancingAlgorithm Dynamic -TeamingMode SwitchIndependent

New-VMSwitch -Name VMNET -NetAdapterName ConvergedTeam -AllowManagementOS $False -MinimumBandwidthMode Weight

Set-VMSwitch "VMNET" -DefaultFlowMinimumBandwidthWeight 3

 

Add-VMNetworkAdapter -ManagementOS -Name "Management" -SwitchName "VMNET"

Add-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -SwitchName "VMNET"

Add-VMNetworkAdapter -ManagementOS -Name "HeartBeat" -SwitchName "VMNET"

 

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Management" -Access -VlanId 210

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "HeartBeat" -Access -VlanId 211

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "LiveMigration" -Access -VlanId 212

Set-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -MinimumBandwidthWeight 20

Set-VMNetworkAdapter -ManagementOS -Name "HeartBeat" -MinimumBandwidthWeight 40

Set-VMNetworkAdapter -ManagementOS -Name "Management" -MinimumBandwidthWeight 5

 

# Set IP Address Management

New-NetIPAddress -InterfaceAlias "vEthernet (Management)" -IPAddress 192.168.210.21 -PrefixLength "24" -DefaultGateway 192.168.210.7

Set-DnsClientServerAddress -InterfaceAlias "vEthernet (Management)" -ServerAddresses 192.168.204.34, 192.168.204.219

 

# Set LM and CSV

New-NetIPAddress -InterfaceAlias "vEthernet (LiveMigration)" -IPAddress 192.168.211.21 -PrefixLength "24"

New-NetIPAddress -InterfaceAlias "vEthernet (HeartBeat)" -IPAddress 192.168.212.21 -PrefixLength "24"

Repeat the same command on another node if running in cluster mode (Of course IP address must be change)

 

 

Lastly, configure your switch, switchport as trunk port, and specified all VLAN used in your switch.

 

When creating a new Virtual machine, remember to add vlan ID to the network adaptor,

 

Reference:

https://technet.microsoft.com/en-au/library/dn550728.aspx#BKMK_Example

http://www.microsoft.com/en-us/download/details.aspx?id=40319

NTP time for Domain Controller

Time in windows domain is crucial. 5 minutes different between server and client will not allowed client to login to the computer, subsequently all authentication and encryption might just failed. by default, all domain joined client will get their time from Domain controller. If your domain controller is virtualized, strongly suggest you don’t use any hypervisor tool(VMWare tool or HyperV integration tool) to sync time between domain controller and the hypervisor hosts. Time syncing option must unchecked.

 

To configure the domain controller to sync with external time source.

 

1. Login to primary domain controller
2. Start cmd or powershell with administrator privilege
3. Execute to command as below,
   # w32tm.exe /config /manualpeerlist:”0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org.us.pool.ntp.org” /syncfromflags:manual /reliable:YES /update
   
   

Notes: You can find the closest time server near you by browsing the following page and clicking on the nearest zone:!http://www.pool.ntp.org/zone/@

4. run the command to update,
   # w32tm.exe /config /update
5. Restart windows time service
   (For Powershell)
   # Restart-Service w32time
   (For CMD)
   # net stop w32time
   # net start w32time
   
   
   

 

 

That’s all !

if you have any domain member, you can either wait until the next synchronization or restart w32time service to sync time with domain controller.

Two unknown devices in Windows Server 2008 R2 under Hyper-V 2012 R2

 

Hyper-V integration components for Windows Server 2012 R2 do not install the device drivers for two devices on servers running Windows Server 2008 R2.  They are listed as unknown devices in device manager:

More detailed analysis shows the device information as follows:

Device 1 Hardware Ids:
VMBUS\{f8e65716-3cb3-4a06-9a60-1889c5cccab5}
VMBUS\{99221fa0-24ad-11e2-be98-001aa01bbf6e}

Device 2 Hardware Ids:
VMBUS\{3375baf4-9e15-4b30-b765-67acb10d607b}
VMBUS\{4487b255-b88c-403f-bb51-d1f69cf17f87}

Resolutions:

1. Insert the HyperV integration disk, open it up go to the folder - support/amd6,

2. Extract Windows6.2-HyperVIntegrationServices-x64.cab file to a location (In this example the desktop)

3. Manually launched the update driver wizard from device manager and pointed to the extracted files from the cab file. 

The first device prompts you with a driver publisher warning, not quite sure why this is the case since Microsoft is the publisher of these drivers:

Installing the driver software has not caused me any issues. 

Hyper V 2012 R2 Replica between different domains (Cluster-to-cluster)

Hyper V replica between two different domains (cluster-to-cluster)

Background

For Hyper V to replica between 2 different domains, we must enable certificate based authentication, preferable a wild card certificate. Our scenario, Hyper V 2012R2 with 2 nodes cluster on primary site (cluster name MYRSVMH8.primary.local). On the replica site, Hyper V 2012R2 with 2 nodes cluster (cluster name is HVC02.replica.local). This is assumed your cluster is configured and running.

In summary, the steps are

1. Pre-stage replica broker object

2. Create cluster replica broker

3. Generate certificate for authentication

4. Enable replica broker on replica site

5. Host files

6. Configure VM for replication

7. Configure storage location on replica site

 

Pre-stage the computer objects

1. Pre-stage a computer object in the Hyper-V OU that is the name of the Replica Broker role you wish to create (e.g. Replica). Once the object is created, you will then need to go to the Security tab, add the cluster computer object; finally, give it full control.

Here you can see the pre-staged computer object I created in my Hyper-V OU:

2. After creating the object, called REPLICA, I right-clicked on it then went to the Security tab. Next, I added the Cluster computer object and gave it full control. (In this screenshot, you’ll notice my cluster is named HV1-HV2-2012CLU.) Click Apply then OK.

3. Repeat steps 1 the same on the replica site AD, change the object named to REPLICABROKER

 

Create cluster replica broker

1. On the primary site cluster node,

2. Open the Failover Cluster

3. Configure Role

4. Select Hyper-V Replica Broker and hit "Next"

5. Add the Name of the replica broker e.g “replica” (Note: this will be translated as an fqdn and also will be add on the domain controller the a record replica.primary.local)

6. Add the IP for the Replica Broker (172.18.70.121), same subnet as management IP

7. Then click "Finish"

8. Repeat the same on the replica site, change the replica Broker name to “replicabroker”

 

Generate certificate for authentication

1. Download a tool named makecert.exe on your local machine (window 8, windows 8)

http://www.microsoft.com/en-us/download/confirmation.aspx?id=8279

2. Generate the wildcard certificate for primary and replica site

C:\Windows\system32>cd "C:\Program Files (x86)\Windows Kits\8.0\bin\x64"

# create a root certificate

C:\Program Files (x86)\Windows Kits\8.0\bin\x64>makecert -pe -n "CN=PrimaryRootCA" -ss root -sr LocalMachine -sky signature -r "PrimaryRootCA.cer"

#create primary site certificate, *.primary.local

C:\Program Files (x86)\Windows Kits\8.0\bin\x64>makecert -pe -n "CN=*.primary.local" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryRootCA" -is root -ir LocalMac

# create replica site certificate, *.replica.local

C:\Program Files (x86)\Windows Kits\8.0\bin\x64>makecert -pe -n "CN=*.replica.local" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryRootCA" -is root -ir Loca

3. Export the certificates to all nodes in primary and replicate site

*.primary.local certificate goes to primary site

*.replica.local goes to replica site

4. Open the MMC -> Add/Remove Snap-In -> Add Certificate -> Computer Account -> Next,Next & Finish

5. We go to Personal -> Certificates and with right-click Export the *.primary.local and *.replica.local Certificate. We proceed with Export including the key and the file will be as .pfx also you have to give a password for the certificate.

6. Copy the .pfx file to every Hyper V server,

*.primary.local certificate goes to all nodes in primary site

*.replica.local goes to all nodes in replica site

7. Import the certificate on every nodes, to do this,

MMC -> Add/Remove Snap-In -> Add Certificates -> Computer Account -> Next, Next & Finish

then we navigate to Personal -> Certificates -> Right-click and Import -> You must give the password that you have setup on the step 5

8. Copy the primary root certificate to Trusted Root Certificate Authorities

9. Before we proceed with the replica configuration we have to disable the Revocation Check. This we have to do it on every Hyper-V server (primary site (stand alone nodes) and replica site (cluster nodes). To do this we must run this two commands bellow from an elevated command prompt (cmd):

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

 

Enable replica broker on replicate site

After we have finished with the Import of the CA certificate and the ReplicaSite certificate and also with the disable of the Revocation Check we must select it to the Replica Broker configuration. To do this follow the steps bellow:

1. Open The Failover Cluster on replica site and Navigate to Roles

2. Right-click on the replica broker and select "Replication Settings"

3. Check the "Enable this Cluster as a Replica Server"

4. Check the "Use certificate-based Authentication (HTTPS)"

5. Specify the port on 443 (leave it as it is)

6. Now you must select the ReplicaSite Certificate that we have created and imported it to the Hyper-V Cluster nodes

7. Specify the Cluster Storage directory

8. And click OK

9. open the Inbound Replica Broker rule on the Advanced Firewall of all Hyper-V nodes (the rule has been automatically created and named as: Hyper-V Replica HTTPS Listener (TCP-In)), for all profiles

 

Host files

1. Since they are in 2 different domains, they might not use the same DNS server

2. For every nodes on primary site, update the host file to include

172.18.70.120 replicabroker.replica.local

172.18.70.101 HVC02N1.replica.local

172.18.70.102 HVC02N2.replica.local

3. For every nodes on replica site site, update the host file to include

172.18.70.121 replica.primary.local

172.18.70.11 MYRSVMH8N1.primary.local

172.18.70.12 MYRSVMH8N2.primary.local

 

Configure VM for replication

1. Open The Failover Cluster on primary site

2. Right-Click on the VM you want to replicate and select Enable Replication

3. Just hit "Next" on the first page with the description "Before You Begin"

4. Specify the Replica Server, you must add the FQDN for the replica site (just to mention, all the Hyper-V nodes and the Replica Broker must have access to Internet and have FQDNs in the public dns servers of your Infrastructure so thay can "communicate" also they must have open the port 443 on the local firewall or if you use a dedicated appliance and NAT you must do the Network config there too) for me the FQDN is replicabroker.replica.local and hit "Next"

5. After the Verification of the Replica we must specify the Connection Parameters. The only thing in that page that we must change (of course based on our scenario) is the Certificate, so we must select the Certificate with FQDN that we have been created based on the current server.

6. "Next" on the Replication VHD In the Configure Recovery History you can configure whatever you want on your scenario and "Next"

7. Initial Replication again whatever you want to do on your scenario "Next"

8. "Finish" if all of the above is setup correct you must see the Enable Replication pop-up window and after a second (based on your network) you must see in the Hyper-V Manager on the Status, the percentage of the Replication.

 

Configure storage location on replica site

1. Locate the VM which you want to replicate to a storage location other than the default you configured in step 1 and right-click the VM, then drag down to Enable Replication.

2. The Enable Replication Wizard starts and takes you through a series of questions to configure replication for this VM. At the Choose Initial Replication Method screen, make sure you schedule the initial replication by selecting "Start replication on" and specify a date. This process will create the initial files and place them in the default location for replicating VM but the files are relatively small in size and can be very easily moved.

3. Now go to Hyper-V Manager, select the VM and choose to move the VM.

4. Select the storage destination you want this VM to replicate to.

5. Return to the primary server where the VM is hosted and where you want to initiate the replication from; to do this, right-click the VM | Replication | Start Initial Replication.

6. Select Start replication immediately. Locate the VM which you want to replicate to a storage location other than the default you configured in step 1 and right-click the VM, then drag down to Enable Replication.

7. The Enable Replication Wizard starts and takes you through a series of questions to configure replication for this VM. At the Choose Initial Replication Method screen, make sure you schedule the initial replication by selecting "Start replication on" and specify a date. This process will create the initial files and place them in the default location for replicating VM but the files are relatively small in size and can be very easily moved.

8. Now go to Hyper-V Manager, select the VM and choose to move the VM.

9. Select the storage destination you want this VM to replicate to.

10. Return to the primary server where the VM is hosted and where you want to initiate the replication from; to do this, right-click the VM | Replication | Start Initial Replication.

11. Select Start replication immediately.

Linux - test hard disk performance

1. Linux, test hard disk performance

# dd if=/dev/zero of=test.dat bs=1M count=10000; rm -f test.dat

Two unknown devices in Windows Server 2008 R2 under Hyper-V 2012 R2

 

For whatever reason the Hyper-V integration components for Windows Server 2012 R2 do not install the device drivers for two devices on servers running Windows Server 2008 R2.  They are listed as unknown devices in device manager:

More detailed analysis shows the device information as follows:

Device 1 Hardware Ids:
VMBUS\{f8e65716-3cb3-4a06-9a60-1889c5cccab5}
VMBUS\{99221fa0-24ad-11e2-be98-001aa01bbf6e}

Device 2 Hardware Ids:
VMBUS\{3375baf4-9e15-4b30-b765-67acb10d607b}
VMBUS\{4487b255-b88c-403f-bb51-d1f69cf17f87}

What I did to get these devices working is extract the Windows6.2-HyperVIntegrationServices-x64.cab file to a location (In this example the desktop).  The cabinet file is located in the Integration Services setup ISO under support/amd64.  From there, I manually launched the update driver wizard from device manager and pointed to the extracted files from the cab file. 

The first device prompts you with a driver publisher warning, not quite sure why this is the case since Microsoft is the publisher of these drivers:

Installing the driver software has not caused me any issues. 

The first device is the Microsoft Hyper-V Remote Desktop Control Channel.  The second device does not present the same publisher verification warning message.  The second device is the Microsoft Hyper-V Activation Component.  I am not quite sure what these two devices actually do, but since I hate looking at unknown devices within device manager I needed to figure this out.  If someone knows the benefit of these two devices please leave a comment below.

Windows God mode

1. Windows God mode
Windows hidden "god mode" folder Windows offers a centralized Control Panel for all of the OS settings, which makes it easy for users to tweak everything from desktop background to setting up a VPN. To enter this mode, create a new folder with this exact name (copy and paste it): God Mode.{ED7BA470-8E54-465E-825C-99712043E01C}. The folder icon will change to a Control Panel-style icon, and you will be able to jump in and change all kinds of settings. Note: Don't try this on Windows Vista 64-bit as it's known to cause a reboot loop.