Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, July 10, 2018 10:02 PM
A. Windows 2012R2 HV Stand Alone Host.
B. Windows 2016 HV Stand Alone Host.
Server A and server B are in the same subnet.
Would like to move existing VMs from HV Host A to HV Host B. A and B servers are stand alone (workgroup), not joined, therefore Migrations do not appear possible.
I would like recommendation on possible options listed below, or any better option I may not be considering:
- Replication seems possible:
- Involves certificate configurations.
- Not sure about using this to move the VMs is the best idea, as it's primarily for failover.
- Shut down VMs on server A and Robocopy-ing the VHDX files from server A to server B:
- At least one VHDX file is over a TB; may take a long time to copy and will be a lot of downtime.
- Unsure of any issues this method may present. Have seen vhd permissions issues with HV, that while aren't insurmountable, I'd rather avoid.
- Create new VHDX on server B using the "copy contents of the specified virtual disk" method using UNC path to VHDX files on server A:
- Can this method work?
- Must the VM of the VHDX files being copied be shutdown, or can the VM for the VHDX files being copied remain online/running?
If option 3 can work, this may avoid HV permission problems that can occur when copying in VHD(x) files, and if HV can create a VHDX based on another VHDX via UNC while the VHDX being copied is online/running, this would be ideal. It seems possible that it can copy an online VHDX (via VSS), but I wouldn't be surprised that the VHDX file must be offline for option 3 to work at all. As long as option 3 is similar to option 2 (robocopy), with no risk to the original VHDX on server A or permission issues, then I would prefer option 3.
Option 1 (replication) may seem the best in terms of uptime (VMs on server A can remain online). However, we won't be "failing back" to server A. So we'd be setting up replication for a different purpose than it was intended.
As I haven't used replication previously, i'm unsure of the consequences of using it for a one-way move. However, if going one-way isn't a big deal, then it may be worth configuring this option.
Finally, I do not think there will be any issues with running the VHDX VM that were on a W2012R2 HV server, on a W2016 HV server, but please let me know if there are any.
Please advise.
Thank you in advance.
All replies (6)
Wednesday, July 11, 2018 8:24 AM ✅Answered
Hi,
Thanks for your question.
There are a number of different ways to move a Hyper-V VM from one host to another. Here are some of the more common migration methods.
Backup and restore: One method involves using backup and restore. This method is probably the most tedious of the commonly used migration methods, but the nice thing about using the backup and restore method is that the original copy of the VM is left intact. You could conceivably back up the VM, shut it down, and then restore the backup on the new host. If anything goes wrong, you can easily power up the original copy of the VM.
The biggest disadvantage to this method is that it requires the VM to be taken offline during the migration process. As such, this method might not be suitable for some virtual machines. Furthermore, there’s no issue with running the VHDX VM that were on a W2012R2 HV server, on a W2016 HV server. Surely, it need to satisfied the following considerations of VSwitch.
The following article shows you how to export and import a virtual machine, which is a quick way to move or copy them.
/en-us/windows-server/virtualization/hyper-v/deploy/export-and-import-virtual-machines
Live migration: Another technique that you may be able to use is Hyper-V live migration. Live migration moves a running virtual machine from one host to another. Live migration is most often used to move virtual machines among hosts within a cluster, but under the right circumstances you can live migrate a VM from one cluster to another. However, doing so means removing the VM as a clustered resource and then performing a shared nothing live migration. The VM must then be defined as a clustered resource within the destination cluster.
For the guidance of VM Live Migration, we can refer to the following article,
http://techgenix.com/hyper-v-live-migration-guide/
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
Replication: One last method that you can use involves using the Hyper-V replication feature. In my experience, this method is often the least problematic. The basic idea is to enable replication for a virtual machine and then replicate a VM to a different cluster. When it comes time to perform the migration, you can shut down the virtual machine and then perform a planned failover. Unfortunately, this method does involve a little bit of down time, but the required down time is usually minimal.
Step-By-Step: Virtual Machine Replication Using Hyper-V Replica
Considerations:
Migrating a Hyper-V virtual machine to a new host can also be problematic if the new host uses a different virtual network configuration. Remember, Hyper-V VMs connect to the network through a virtual switch. Ideally, you should create a Hyper-V virtual switch on the new host prior to migrating any Hyper-V VMs. This virtual switch should use exactly the same name as the virtual switch that the VM is currently using. If such a virtual switch does not exist on the new host then the VM will lose network connectivity until you manually re-associate it with a new virtual switch.
Hope above information can help you.
Highly appreciate your effort and time. If you have any question and concern, please feel free to let me know.
Best regards,
Michael
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Friday, July 13, 2018 5:54 PM ✅Answered
I'll answer my own questions:
It appears that the original VMs that get failed over to a Replica server can be started on the original Primary server; nothing disables the option to start the servers simply because it was failedover to the replica.
We first completed a Planned Failover for two smaller VMs which were linux based. Both successfully failed over. One we tried with reverse replication to see how it handled that and the impact to storage consumption, but we received an error with that option. Interestingly, when I received the reverse repliation error, I choose to cancel completing the failover, looking to avoid an issue if I continued. However, the VM failedover anyway and left the original server in a replication failed state that we couldn't resolve. Since we meant to permanently failover anyway, this wasn't an issue. We haven't researched the reverse replication error for cause etc., but it may have to do with the quirkiness of the workgroup cert replication configuration (albeit we have replication successfully enabled on both HV hosts with certs configured).
We then removed replication for those failed-over VMs on both HV hosts to "finalize" the one-way move. It appears we can start the original VMs on the original primary HV host, if necessary, as a possible fall-back option.
We then enabled replication for a 600GB VM (in two vhdxs) and successfully executed a planned failover for that VM. We have one larger VM (1.25TB in three vhdxs) that will be replicated and moved next.
Two notable points about HV Replication:
1. Replication disk space consumption needs to be considered and planned for.
2. If not failing back or enabling reverse replication, consider disabling the VM startup or remove the VM virtual switch binding.
Disk Space: It's notable to plan for Replication disk consumption. Our 600GB VM created one .avhdx for each .vhdx and consumed upwards of 30GB. Because we are very low on disk space on the existing primary HV host, we have to delete the 600GB VM that was already failed over in order to avoid any issues replicating the last 1.25TB VM.
Disable VM: For a one-way move, one must also make sure to check the startup options to ensure the original VMs on the old HV host do not start if the HV host restarts, or at least remove the virtual switch binding to avoid a duplicate server from running in the network.
Finally, while we were able to determine the storage impact of enabling Reverse Replication, and know for sure how the Primary HV Host handles the Reverse Replication, I'm guessing it simply creates differencing files, and keeps the existing virtual drives of the VM and doesn't create wholly new virtual drives. it would be simply stupid to create new vhd(x)s for the existing VMs with reverse replication. I only concerned myself with this because of the file and folder structures HV Replicas create.
Not sure if this will help anyone, but felt it worth documenting it.
Wednesday, July 11, 2018 8:43 PM
Thanks for posting the methods. I did forget about backup/restore, though I do recall that as an option now, but yes, not as good as any of the others.
I guess I was looking for experience and insight with the various methods, things that aren't documented.
I did test and determine that you cannot copy the contents of an existing .vhd(x) when creating a new .vhd(x) if the VM is online; not surprised, but thought it possible it may use vss snapshot technology.
As I mentioned, Live Migration is only supported in a domain environment, even for the Hyper-V servers, which is a technical let-down, so this wasn't an option for me.
However, VM Replication did work, though we did need to configure certificates (the support for self-signed, while possible, is another technical let-down). Replication does have some surprises, such as the folder structures used when replicas are made; wasn't expecting that, as it changed our naming conventions etc.
For now, we have replicas made. We'll move on to planned (and permanent) failover this weekend.
Alas, the online documentation these days is so very lacking in details, while at the same time technology continues to complicate. Very sad.
Thursday, July 12, 2018 1:25 PM
Sorry, I failed to follow-up with the final point of my original question: What is the best way to finalize our VM moves from the Primary to the Secondary replica server?
The documentation explains what occurs with the different scenarios, but it's severely lacking in details.
1. Planned Failover to a Replica Server: Notably, this method triggers the following "a planned failover also initiates a 'reverse replication.'" However, the current Primary server is somewhat low on disk space, and since the current Secondary replication server created a new folder structure for replicated VMs, I'm concerned that using this method will create a brand new folder structure and files (particularly duplicate .VHDX files for each VM) for the reverse replication back on the original server, which would then be considered the "secondary" server, including new (essentially duplicated) .VDHX files. As this would double the storage needed (existing VMs and .VDHX files, plus the newly replicated copies), there's simply no room. While we are planning to permanently move to the secondary server, we wouldn't want this behavior effect the existing Primary server, particularly in case something goes wrong with the "switch".
2. **Unplanned Failover to a Replica Server: ** While we can do this, again, the documentation details of impact to both servers and the options available to switch back to the original HV server should something go wrong, are lacking. Also, it's not clear how to force an Unplanned Failover. Finally, would the faillover replica start replicating back to the original primary server if it discovers the original primary is back online?
We would need the current Primary HV host server to remain online, for reasons independent from hosting VMs, for a least a week or two while we prepare to re-purpose the current primary server.
We simply want to failover to the secondary HV server, verify the VMs are working properly, particularly through a backup cycle (so at least one day), then we presumably would remove replication from each of the VMs on the new Primary server.
We are of course executing these VM "moves" of hours, and there would be no salient difference in the VMs, data. If something goes terribly wrong, we would like to simply start the original VMs on the original Primary server.
Please advise.
Thursday, July 12, 2018 1:53 PM
Alas, the online documentation these days is so very lacking in details, while at the same time technology continues to complicate. Very sad.
Older stuff, even though still relevant, is being removed or moved into a large "covers everything" downloadable PDF
there's also a big push to move it all from support.microsoft.com over to GitHub (docs.microsoft.com) and it doesn't seem to be cataloged very well yet.
The three that I generally try are
"some text" site:microsoft.com
"some text" site:docs.microsoft.com
"some text" site:support.microsoft.com
the docs.microsoft uservoice has been closed so maybe use for feedback?
https://github.com/MicrosoftDocs/feedback/issues
Regards, Dave Patrick ....
Microsoft Certified Professional
Microsoft MVP [Windows Server] Datacenter Management
Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.
Thursday, July 12, 2018 3:39 PM
I see for the Planned Failover, there's an option to enable "Reverse the replication direction after failover". So, while we can control whether this occurs or not, I'm still unsure if the reverse replication will keep the existing .vhdx and only replicate the differences, or if it will create a wholly new copy of the complete .vhdx, thereby consuming twice the needed storage for the VMs.
Also, say it only reverse replicates the differences, or say we choose not to enable "reverse replication", so the storage issue isn't a problem. Say we complete a planned failover and all hell breaks loose, and even failing back doesn't work. Could we simply start the original VMs on the original Primary server? Or, does the fact that we executed a "Planned Failedover" make the original VMs unavailable for starting? If we can simply start the original VMs on the original Primary server, should failing over not work for whatever reason, I'm assuming we may want to "remove replication" on the original Primary server, either first, or at some point.
Please advise.
Thank you in advance.