Forum Discussion
Solved
Exporting a single virtualized W2012 r2 Hyperv guest
Hello fellow adminstrators, I am planning to export my Hypervisor 2012-DC guest in the Hypervisor Manager. I only have a single DC as we are running a small company ( < 20 staff ) .
Is this possible? If so, what are the things or hidden surprises I should be aware of?
Appreciate any input.
Eric
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
7 Replies
- Why do you want to export it? You're moving to a new host? As a backup? What are the reasons? 🙂
- Harm_Veenstra, we are moving the client to another host machine. So, I need to make a backup as a precaution. I will export the guest VM to another location before I move the machine. Thanks
It's probably worth flagging that Server 2012 R2 only has a little over a year of extended support left.
Assuming you're comfortable with promoting and demoting domain controllers, it would take less time and effort to simply build and promote (i.e. join it to the existing domain) a current generation guest (so long as the client has the relevant licence) than to move the existing Server 2012 R2 domain controller guest.
Of course, if you're not comfortable with this then I guess leave bring their environment up-to-date for a later activity to tackle.
Windows Server 2012 R2 - Microsoft Lifecycle | Microsoft Docs
That said, the answer to your question is that yes, there are multiple ways to relocate your existing guest from one hypervisor to another. If it's well-planned, there's no real surprises involved.
Regardless of which method you use, one tip that makes things a little easier is to ensure that you use the same virtual switch names on the new hypervisor as those found on the old hypervisor. You don't have to, of course, but it can save time and avoid simple mistakes like the name mismatches between the guest and virtual switches on he new hypervisor.
Cheers,
Lain
