For the live migration to be possible there are some prerequisites regarding the host operating systems and their hardware. First, they need to have a shared storage, mounted similarly. They also need to have same OS versions and identical network configurations.
Once these requirements are met, the live migration is about copying the contents of the memory ...
Virtual Domain Controller (DC) is a way to go!
P.S. Two of them with enabled DC replication, actually.
If you use a firewall, you'll likely block all internet traffic from the host. If the goal is to simply prevent Windows updates, there are less severe mechanisms.
I do this with PiHole DNS server. It's pretty simple to set up. Basically, it acts like a DNS blackhole. I use it to blacklist the microsoft update sites. That way, other internet stuff can ...
Pretty old thread here: https://social.technet.microsoft.com/Forums/en-US/ec1c6756-7890-419a-89d0-cf7570901549/error-synthetic-scsi-controller-failed-to-power-on-the-process-cant-access-file-because-being?forum=winserverhyperv
It states that the host should be rebooted and you can try to reattach VHDS to the VMs.
Alternatively, you can try building guest ...
You can easily run DC as VM on Hyper-V nodes, just run it as a local and not clustered VM.
Separate servers may be the best option, if you don’t mind expenses and additional management.
The option with DC role installation directly on host with Hyper-V is against best practices and cannot be recommended. Some explanation here -
You need to change one or two kernel tunables - on client machine. To make TCP keepalive (ENABLE=BROKEN) useful.
By default Linux kernel sends the 1st TCP keepalive probe after 2 hours:
# cat /proc/sys/net/ipv4/tcp_keepalive_time
Delay before the 1st probe is sent - after 2 hours !!!
# cat /proc/sys/net/ipv4/tcp_keepalive_intvl
After some further investigating, we found that the avhdx files were fine and all of our data was on them, but the vhds file was corrupted.
You can confirm this by shutting down all of the VMs that are using the shared disk, then copy and rename the .avhdx file to .vhdx, and then load it up. Warning: once we shutdown the 2nd VM, we were also unable to ...