Forum Discussion
Exporting a single virtualized W2012 r2 Hyperv guest
With only a single domain controller, USN rollback isn't something you would need to worry about - so long as you're not working with snapshots/checkpoints (and you shouldn't be.)
Don't use Hyper-V Replica replication for domain controllers - not ever. Nothing good can come of this.
Conversely, what you can do is leverage the "live migration" functionality but you need to understand how to set up things like Kerberos Constrained Delegation for this.
Domain controllers (plural, which doesn't apply to you but I'll mention this anyway) - by design work in a multi-master replication model at the application layer - which is always preferable to any kind of half-baked hypervisor or hardware-level replication (a common mistake I still see to this day in infrastructure architectures.)
Instead of using Hyper-V replication, you'd pursue the option I mentioned previously and create a new domain controller on the new hypervisor. Those two domain controllers would replicate amongst themselves, and once both report as being up-to-date, you'd simply demote the old 2012 R2 domain controller.
I'm not clear on what you mean by "backup", but it sounds like you're not familiar with PowerShell (please correct me if I'm wrong and I can speak to other PowerShell-based options), so if you're using the Hyper-V management console, then you'd be using the "Export" virtual machine and "Import virtual machine" options.
The optional tip I provided relating to the names of the virtual switches is still relevant independent of any migration approach.
If you are going to use the export/import or live migration models, you would be wise to shut down the domain controller guest first, then export and copy it across (I wouldn't strictly move it unless it's using the live migration option) and finally start it up on the new hypervisor (fixing any misaligned settings beforehand.)
If I were going to migrate the guest from the old hypervisor to the new as-is (which I wouldn't - I'd pursue the new, additional domain controller approach), I'd only remove the stopped original domain controller guest from the old hypervisor once the guest on the new hypervisor is confirmed to be working.
- Export and import virtual machines | Microsoft Docs
- Set up hosts for live migration without Failover Clustering | Microsoft Docs
Cheers,
Lain
I'd recommend not exporting and importing a VM if it's having issues, as depending on what those issues are, you're just going to migrate the issues across to the new host.
I wouldn't personally migrate the guest while it's running, but then I'm quite risk-averse. My process for a single host on poor hardware would be to do the following out-of-hours:
- Shutdown the existing guest;
- Export it;
- Copy it across to the new host;
- Import it;
- Start up the copy on the new host - assuming there's no outstanding configuration issues to resolve (you'd want to resolve those first);
- Once the new guest is confirmed to be working properly, you could consider removing the old original copy.
The rollback process would simply be to stop the new copy of the guest on the new hypervisor and start up the old guest on the old hypervisor.
Cheers,
Lain