While trying to switch around my Hyper V replication scheme so I could take one of my servers offline for a while so I could expand its RAID 10 array and change the way I had it the array partitioned to “One Big RAID 10”. I ran into an issue where I wasn’t able to replicate to an old server I had stood up temporarily running Hyper V Server 2012r2, this was just the free hyper v server, not 2012r2 std. The error I got was “Hyper-V failed to enable replication for virtual machine ‘DC2’: The operation timed out (0x00002EE2).”After many failed attempts and lots of scratching on my rapidly balding head I found this post on the microsoft technet forum that fixed the issue for me. I was sceptical that it would work since I had already disabled the firewall, but adding these rules via powershell did the trick. Here is how I implemented the fix.
log in to the offending server(s), either locally or via RDP, you could also run the commands remotely if you choose.
open powershell, if you are running the free hyper-v server this can be done by just typing “powershell” at the command prompt. If you are running standard windows server or the like I’ll assume you know how to launch it from the menu or search.
run the following commands: Enable-Netfirewallrule -displayname “Hyper-V Replica HTTP Listener (TCP-In)” then this one: Enable-Netfirewallrule -displayname “Hyper-V Replica HTTP Listener (TCP-In)”
Now try to enable replication for one of your VMs.
I’ve been running a windows OpenVpn server for over 5 years now. Part of that as a VM and for the last 3 years or so on dedicated hardware. That hardware consisted of an old Dell desktop PC running Windows XP. It was an emergency setup that I just never got back around to fixing permanently. So this week I decided to migrate it to one of my Hyper-V hosts and run it on a 2008r2 Std. VM. I’ve always ran OpenVpn in bridged mode, so when I tried to create the bridge in 2008r2 I found that I would lose network connectivity. I tried deleting and recreating the bridge several times along with multiple reboots, always with the same results. After much googling I ran across an article describing this problem in server 2003r2 and a link to another article describing how to force the TAP nic into compatibility mode due to some NICs not automatically entering into Promiscuous mode which causes the bridge not to be able to pass traiffic. The fix for me was forcing compatability mode on the Microsoft Hyper-V adapter instead of the virtual OpenVpn TAP adapter. To do this simply open an elevated command prompt and type “netsh bridge show adapter” then locate the identification number of the NIC you wish to put into compatibility mode. Next type the following command substituting the number of your prefered NIC for the 1 “netsh bridge set adapter 1 forcecompatmode=enable” Next run the “netsh bridge show adapter” command again to verify that the ForceCompatabilityMode field for the NIC is displayed as Enabled.
I’m working on setting up a brand spanking new HP ProLiant ML310 Gen8 V2 for a small local agency that I also support at my day job. Their old SBS2003 r2 server lost a drive in its RAID 5 array, and the hot spare also failed while trying to rebuild. So instead of trying to find some replacement drives for a 5 and a half year old server we decided to replace it. Luckily I was able to use disk2vhd and get a good copy of the old server and virtualize it temporarily on a nice core i7 laptop (only thing they had that was capable) that I installed Server 2012 r2 Standard (eval version) on a spare hard drive to get them back up and running quickly and hopefully keep them operating until the new server could be ordered and setup. So far it was worked great! I have it backing up to an external hard drive using the free version of Altaro Hyper-V Backup , which is excellent software I might add, and they can’t tell the difference in their day to day operations. So that brings us to setting up the new server. I was ready to install Server 2012 r2 Std. on the new server using HP’s Intelligent Provisioning but it was unable to see the install ISO on my flash drive, after several re-scans, and plugging flash drive into my desktop to make sure the iso was actually on the drive and readable. Then I got the idea that maybe the problem was the way the file was named, maybe it was too long, or perhaps it didn’t like the spaces. So I shortened the file name to just server2012r2, instead of the default crazy long name it has when you download it from the volume licensing center, plugged it back into the server, clicked re-scan and there it was, ready to go. So if you run into the same situation, try renaming the iso and see if it works for you.
If you are running a Hyper-V 2012 r2 host with guest VMs that are of earlier versions of windows you will notice a couple of unknown devices in the device manager, even after installing the hyper-v integration services on the guest. When I first noticed this I thought maybe some driver didn’t install correctly, but after doing a little digging i found a Microsoft Knowledge Base article dealing with this very subject kb2925727. The article states “On a Windows Server 2012 R2 Datacenter Hyper-V host, you may see 2 unknown device under Other Devices in device manager of any virtual machine running operating systems earlier than Windows Server 2012 R2. These Virtual Devices (VDev) are provided for Automatic Virtual Machine Activation (AVMA) to communicate with the host. AVMA is only supported on virtual machines running Windows Server 2012 R2 or later versions of operating systems. The unknown devices are harmless and can be ignored. ” So there you go.