2012
11.05

In the past 3 weeks I’ve delivered my 75 minutes long Live Migration session at 2 events in Barcelona (Spain) and Hamburg (Germany). The big topic in WS2012 Live Migration is being able to do Live Migration in new ways:

  • Inside a cluster with traditional storage
  • Inside a cluster with shared SMB 3.0 storage
  • Between non-clustered hosts with shared SMB 3.0 storage
  • Between non-clustered hosts with no shared storage (Shared-Nothing Live Migration)
  • Between clustered hosts in different clusters with no shared storage (Shared-Nothing Live Migration) – requires you to disable HA for the VM before migration and re-enable it after migration (no downtime required)
  • Between clustered hosts and non-clustered hosts with no shared storage (Shared-Nothing Live Migration) – requires you to disable HA for the VM before migration (no downtime required)
  • Between non-clustered hosts and clustered hosts with no shared storage (Shared-Nothing Live Migration) – you should to enable HA for the VM after migration (no downtime required)

Let’s talk security for a moment, to figure out why Kerberos Constrained Delegation is required.  Say you are only going to do LM inside a cluster. You do not have to enable LM in the host settings.  If you do want LM between hosts that are not in a common cluster, then you need to enable LM.  Then you see there are 2 authentication types.

If you want quick and dirty, you pick CredSSP authentication when you enable LM. It allows you to push a VM from the host you are logged into. It’s find for demo, but useless in the real world, e.g. running Hyper-V Manager from your PC or using a centralized management system.  You will get security issues if trying to LM a VM and you are not logged into the host if you use CredSSP.

The alternative is Kerberos authentication. This allows an authorized Hyper-V administrator to run LM from any domain member machine, therefore not requiring you to log into a host to push a VM. You might remember that mounting an ISO over a file share requires CIFS delegation. We have to do something similar to that for LM to work with Kerberos authentication.

The process of enabling Kerberos Constrained Delegation via GUI is:

  1. Enable the advanced view in ADUC
  2. Edit the properties of the host’s computer account
  3. Edit the Delegation tab
  4. Add the required computer accounts
  5. Add the required service types to delegate
  6. And the bit no one in MSFT talks/blogs about: reboot the host that you just modified the computer object of, e.g. reboot Host2 if you edited the Host2 computer account

So what computer accounts and service types you add, and where? There are 2 scenarios that I’ll talk about:

1) Shared SMB 3.0 Storage and Non-Clustered Hosts

You need to edit each host that can be involved in LM:

  • Delegate Microsoft Virtual System Migration Service for every  other possible LM host
  • Delegate CIFS for every possible file share that LM VMs will be stored on. Use the computer account of the Scale-Out File Server (SOFS) if using SOFS, and not the node members.

image

2) Shared-Nothing Live Migration

This one requires more work. For every host that can be involved in LM, you need to delegate:

  • Microsoft Virtual Machine Migration Service for every other possible LM host
  • CIFS for every other possible LM host

image

There’s a lot of clicking involved in all that. This is why PowerShell is so … powerful. Save some time. Reduce the mistakes. Script it:

$HostName = "host1"
$HostFQDN = "$HostName.demo.internal"
Get-ADComputer host2| Set-ADObject -Add @{"msDS-AllowedToDelegateTo"="Microsoft Virtual System Migration Service/$HostFQDN", "Microsoft Virtual System Migration Service/$HostName", "cifs/$HostFQDN", "cifs/$HostName"}

That Set-ADObject cmdlet took me a while to figure out. I actually set the settings I required in the GUI, ran Get-ADObject and copied/pasted the value of msDS-AllowedToDelegateTo Smile

You could go create a function for the last line of the script, and just pass the name of the Host you’re editing and the name of the host you want to delegate to. I’m not going to do everything for you … I’ve got to hold something back for the book.

Speaking of which … this is just a teeny tiny snippet of Windows Server 2012 Hyper-V Installation and Configuration Guide (available on pre-order on Amazon). I just submitted my VM management chapter to the editors. It was 78 pages of text. And I’ve since realised that I need to add more stuff to that chapter!

image

Technorati Tags: ,

2 comments so far

Add Your Comment
  1. Good info Aidan! You can also use securtity groups to configure constraint delegation. This centralizes simplifies delegation configuration & administration. Just add or remove nodes from the security group when the cluster is extended or shrunk.This means the list in AD will look a lot less crowded, especially with large 64 Node clusters. It also reduces the clicking and potentially simpliefies scripting.

  2. @Didier Van Hoye: How did you mange to do constrained delegation with security groups. I haven’t found a way to add a group to the constrained delegation dialog. I have 20 Hyper-V servers with more being added regularly. It becomes a pain to have to add a new server to each of the other server’s constrained delegation dialog.

    @Aidan: Do you know which services can be restarted after enabling delegation to avoid a full server reboot?

Get Adobe Flash player