six demon bag
Wind, fire, all that kind of thing!
I've been working on a project where I needed to migrate (clone actually, in order to maintain a fallback scenario) virtual machines from external (standalone) Hyper-V hosts to a Hyper-V cluster. The external hypervisors were not members of the same domain as the cluster nodes. The networks were separated by a firewall. A trust relationship between the domains was not desired.
System Center Virtual Machine Manager 2012 (SCVMM) supports this scenario, but there are several steps that must be performed to prepare for the migration.
Name resolution must be working on both sides. Ideally the names would be resolvable via public DNS. However, with corporate LANs that usually isn't an option. As a workaround, the remote hosts could be added the local
hostsfile on each server. However, this only worked on the release candidate for me. On the RTM version it failed for some reason, so I had to make changes to DNS. There are several options for this:
- If you can open port 53 (both UDP and TCP) and allow zone transfers, create a stub zone on either side.
- If you can open port 53, but can't allow zone transfers, create conditional forwarders for the remote domain on either side.
- If for some reason you can't do any of the above, you can create authoritative zones for the remote domains on either side. This is the least desirable configuration, though, because your DNS server will lie about being authoritative for a domain when it actually isn't. If you have to resort to this workaround, make sure you revert it as soon as possible.
Enable WinRM on src.example.com by running
Make sure you allow NTLM v1 authentication. NTLM v2 only will not work. You'll see logon failures in the Security eventlog on src.example.com later on (source Microsoft-Windows-Security-Auditing, event ID 4625), for instance when you're trying to deploy the agent. The event message contains the following lines (among others):
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Define the following three security settings in either the local computer policy or a group policy:
- Network security: LAN Manager authentication level → Send NTLMv2 response only, Refuse LM
- Network security: Restrict NTLM: Incoming NTLM traffic → Allow all
- Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers → Audit all
pingbetween all hosts in either direction.
Allow the following connections:
- scvmm.example.net → src.example.com:443/tcp
- scvmm.example.net → src.example.com:5985-5986/tcp
- dst.example.net → src.example.com:443/tcp
Deploy the SCVMM agent on src.example.com:
For automatic deployment SMB and RPC are required:
- scvmm.example.net → src.example.com:445/tcp
- scvmm.example.net → src.example.com:135/tcp
- scvmm.example.net → src.example.com:49152-65535/tcp
Normally RPC would also require access to UDP ports 49152-65535, but in my tests TCP alone was sufficient. According to MSKB article 929851 it's possible to restrict the dynamic port range, but I didn't check that.
For manual deployment copy
vmmAgent.msifrom the respective subfolder of
%ProgramFiles%\Microsoft System Center 2012\Virtual Machine Manager\agentsto src.example.com (via USB stick or whatever) and manually install it there.
Launch SCVMM, switch to the Fabric section and add the Hyper-V host via Add Resources → Hyper-V Hosts and Clusters. Define/use a runas account that has admin permissions on src.example.com.
Migrate or clone the VMs from src.example.com to dst.example.net.
At one point I received the following error when I tried to add the external hypervisor to SCVMM:
Access has been denied while contacting the server src.example.com.
1. Verify that the specified user account has administrative privileges on src.example.com.
2. Verify that DCOM access, launch, and activation permissions are enabled on src.example.com Administrators group. Use dcomcnfg.exe to modify permissions, and then try the operation again.
The account I used had domain admin privileges, and the DCOM permissions were also correct. As it turned out, I had neglected to run
winrm quickconfig on src.example.com, so that SCVMM couldn't access the WinRM service on that host. Actually enabling WinRM resolved the issue.
A similar problem may arise when you're trying to add a vanilla Server 2008 hypervisor, because WinRM 1.0 uses other ports than WinRM 2.0. Make sure you have upgraded all servers to WinRM 2.0 before doing a migration.
Posted 20:03 [permalink]