While creating a Hyper-V replica broker in my HV cluster, I came across a problem. No matter what workaround I tried, my broker wont work. I tried pre-staging the computer account etc, as mentioned here but for my particular environment, it did not work. I read this:
Here is how I resolved it :
- I deleted the pre-staged computer account in AD, (which I had created manually, earlier for the replica broker)
- Configured the role in FCM, no errors while creation
- After that… yes, I got errors in the log (ignore for a minute)
- Then I recreated the AD computer name by hand and gave full control over that new account to the cluster’s computer account
- Went to FCM > cluster name > roles
- Noticed the HV replica role there (but it was in red, stopped)
- clicked “start role” on the right side action menu
- The role came online in a few seconds.
Now I can even ping the virtual IP address of this Hyper-V replica broker role!
I guess, for whatever reason, (at least in some environments) FCM cannot really use a “pre-staged” account for this role.
I have a few observations about CSVs in a Hyper-V 2012 cluster:
1. Online/Offline status in Disk Management.
Take a look at the screenshot below. I was troubled by seeing the CSV offline. I thought there was a problem (not really).
Here is how the cluster works:
The CSV shows up as an online disk only on the cluster node which is managing is (or is the owner of that CSV). If you change the owner of that CSV to another node, the CSV disk will go offline on this node. However both nodes can still access the CSV via C:\ClusterStorage\vol2
2. Cannot map a drive to view CSV contents:
You cannot map a drive to C$ and try to view the contents of C:\ClusterStorage\VolX. There will NOT be any error but the contents of that directory will be blank. You can RDC to the hyper-V machine and view the contents of that directory successfully.
3. No drive letter is assigned to a CSV
The moment you add a disk to cluster storage volume, it will lose its drive letter. This is by design (normal). A CSV is supposed to be accessed via its map point under C:\ClusterStorage\VolX. This is noticeable in the screenshot above.
While trying to setup a Windows 2012 cluster (to be used by Hyper-V) I ran into an issue where the cluster validation tool failed. it said that the MPIO software versions were different on the nodes. Upon searching the net, I found the solution was to install all Windows updates.
Unfortunately our WSUS server was not working properly. Every time I would run “Download and install Updates” manually on the Hyper-V Server 2012 (core) using the server configuration screen (no GUI) I would get a message that all updates are already installed.
I had to bypass WSUS by running these commands:
REG ADD “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” /v UseWUServer /t REG_DWORD /d 0 /f
net stop “Windows Update”
net start “Windows Update”
After this I was able to check and install updates manually.
1. There is no need to delete or modify this key after you are done installing the updates directly. After a reboot or whenever the Group policy gets re-applied, the key will change back to 1 (enabling WSUS again)
2. There is another tool available called WUinstall I used it on another server. It has a switch to bypass WSUS temporarily and install updates from the internet. Note that this software is available on a “Trial” basis only. I hear at some point in the past, they had a free version also….but I could not find that free version.