For those of you like me who aren't experts at all things Active Directory (AD) and Hyper-V Live Migration (LM) permissions, it can be enough of a pain to LM a Virtual Machine (VM) between domains that you simply decide to take the VMs offline to affect the move. See, I only tolerate AD because it's required for LM'ing VMs; there isn't a choice. (It's also required for Windows Clusters, but that's a different topic.) But I figured it out.
My back-story is that we setup a cluster using Windows 2012 r1 as the AD Domain Controller (DC) and Hyper-V Server 2012 r1 for the VM hosts. Then we decided we wanted to use r2 for the AD DC and Hyper-V hosts. Upgrading Hyper-V was easy. But I found that there's some unresolved Microsoft bug with Windows Clustering when upgrading the AD DC from Windows 2012 r1 to Windows 2012 r2---clustering simply doesn't work correctly anymore. So we gave up and created a from-scratch Windows 2012 r2 AD DC then made a new cluster. At this point, I still had a bunch of VMs on hosts still joined to the old domain and I needed to get those hosts into the new domain. Of course, that requires 2 reboots, so the VMs on those hosts need to be LM'd onto hosts in the new domain.
You'll find that when you search on the topic of LM'ing VMs between domains that people simply say that all you need to do is establish a trust relationship between the two domains (like here). That's a lie. Technet has more about permissions, but I found the information incomplete at best.
For example, I could never get the Kerberos Constrained Delegation (KCD) stuff setup correctly, so I gave up on attempting to use the Hyper-V Manager GUI to do the LM. (And AD's error messages are pretty much worthless; they might as well say "Oh, Crap! Something went wrong. It sucks to be you!".) Additionally, you cannot simply add the administrator account from one domain to the "Domain Admins" group in the other domain; it cannot be done.
So here's what I did:
My back-story is that we setup a cluster using Windows 2012 r1 as the AD Domain Controller (DC) and Hyper-V Server 2012 r1 for the VM hosts. Then we decided we wanted to use r2 for the AD DC and Hyper-V hosts. Upgrading Hyper-V was easy. But I found that there's some unresolved Microsoft bug with Windows Clustering when upgrading the AD DC from Windows 2012 r1 to Windows 2012 r2---clustering simply doesn't work correctly anymore. So we gave up and created a from-scratch Windows 2012 r2 AD DC then made a new cluster. At this point, I still had a bunch of VMs on hosts still joined to the old domain and I needed to get those hosts into the new domain. Of course, that requires 2 reboots, so the VMs on those hosts need to be LM'd onto hosts in the new domain.
You'll find that when you search on the topic of LM'ing VMs between domains that people simply say that all you need to do is establish a trust relationship between the two domains (like here). That's a lie. Technet has more about permissions, but I found the information incomplete at best.
For example, I could never get the Kerberos Constrained Delegation (KCD) stuff setup correctly, so I gave up on attempting to use the Hyper-V Manager GUI to do the LM. (And AD's error messages are pretty much worthless; they might as well say "Oh, Crap! Something went wrong. It sucks to be you!".) Additionally, you cannot simply add the administrator account from one domain to the "Domain Admins" group in the other domain; it cannot be done.
So here's what I did:
- Setup the trust (a two-way, transitive trust like in this silent YouTube video) between the 2 domains.
- Determine the AD user account you'll use on the source host to perform the LM.
- Add that AD user account to the "Hyper-V Administrators" group on the destination host. (Yes, you do not need to change any permissions on the source host.)
- Login to the source host with that account and start PowerShell.
- Run "Move-VM".
- For example, assume the VM is named "TheVM", you're moving it to a machine named "DestHost" in the domain "sample.local", and you want the VM to live, on disk (on "DestHost") at "c:\VMs\TheVM". Here's the command (technically it's all case-insensitive):
- Move-VM TheVM -DestinationHost DestHost.sample.local -DestinationStoragePath "c:\VMs\TheVM"
- That will create the "TheVM" subdirectory if it doesn't exist. (I did not check if it creates all parent directories). It will automatically create the "Virtual Hard Disks", "Virtual Machines", "Snapshots", etc. subdirectories; all of the .vhdx files will go in "Virtual Hard Disks" (which is different then what happens when you do it via the GUI).
- Note that you'll likely get permissions errors if you pre-create those directories (e.g. "TheVM" and its subdirectories), so be aware of that.
Comments