Background/Setup
I've got a running Hyper-V 2012 cluster with 2 nodes. It's already got a VM-role in the cluster managing a VM; failover works and all that nice stuff. There's another, standalone Hyper-V 2012 machine that I just joined to the AD domain so I could do a Live Migration. I LM'd the VM over to a node in the cluster just fine, then I went to add it to the cluster. The VM has its files sitting on a CSV, so that's as expected.
What happened
The "Configure Role…" wizard did its thing, but when I saw the VM in the list of roles, the Status was set to "Off"—but the VM was on and running; you can even see it in the node's properties. So I think to myself that maybe there's some stupid glitch of some sort with the "Status". I don't want it to come back and bite me, so I "Remove" the VM role. But when I go to re-add it, this time around I get an error. In the "wizard", the error message is this grammatically confusing gem:
Please, override 'Header' property The object has been deleted from the cluster.
After completing the wizard, I see the new role is in the list with the status of "Stopped", and it's obviously not setup OK. Selecting the role, and going to "Information Details…", I see this message in the dialog box:
A virtual machine resource was not found in clustered virtual machine 'xxxxx'.
A virtual machine resource is expected for every clustered virtual machine. Please add a virtual machine resource to the clustered virtual machine.
I don't know how to proceed. Is there some cluster configuration file I'm supposed to manually edit to get this fixed? At this point, through this entire procedure, I've been using the VM, so I know the VM itself is OK.
Best Answer
Unexpected, but I found the solution: PowerShell.
I removed the VM-role from the Failover Cluster Manager GUI. Then I RDP'd into the cluster-node where my new VM lived. From a PowerShell prompt, I simply ran this (where the 'xxxx' is the name of my VM):
It added it without any problems. No errors, no status mismatches, no warnings. And I rebooted each of the nodes in turn to confirm that the cluster would migrate the VMs as expected. It worked just fine.
PS: The way I confirmed things were OK was to have a query window open, connected to the Sql Server instance running on the VM. I created a "#temp" table before starting my original Live Migration, and it's still there after everything I've done. Nice!