Windows VMs running on Datacenter are licensed through Automatic Virtual Machine Activation, which lets a VM activate via the Hyper-V service on the host.
All you need to do is to provision the VM with the appropriate AVMA product key, which are provided in Microsoft's documentation.
What you did wrong is adding the key. Which you needed because... ah.
You should have installed Datacenter on Hyper-V. With a proper key that would auto activate any VM on it. Hyper-V on the host is not beneficial licensing wise in most cases, and technically means no auto activation.
There is pretty much zero benefit from installing Datacenter on a VM. ...
No, this is not a Best Practices configuration.
Generally, a Hyper-V host should run only the minimum necessary software to be a Hyper-V host. That means the Hyper-V role, anti-virus, storage services (iSCSI, Storage Spaces, etc.), backup agents, and systems monitoring agents. No user facing services should be running on the Hyper-V host
Running a DC inside ...
You need to ...
(1) ... use something like Windows Server 2016 built-in Storage Replica (DR, so active-passive replication only).
Unfortunately it's Datacenter-only feature, there's some Lite version in Windows Server Standard but it's limited to 2TB or so, ...
Take something like Starwinds and create Highly Available shared storage with your two nodes. AFAIR, they have a lot of manuals which may help you. BTW, it's for free.
Check the NUMA spanning in Hyper-V settings. Looks like you tried to assign more RAM memory that you have on a single NUMA. By enabling this option you will be able to assign more memory to the VM! https://www.starwindsoftware.com/blog/a-closer-look-at-numa-spanning-and-virtual-numa-settings
Does it mean that Hyper-V on Windows Server is Type 1 Hypervisor, and on Windows 10 Type 2 Hypervisor?
No. It means that the memory tuning assumes on Windows 10 the root partition (VM) runs apps, and not if Hyper-V Server.
The root partition is a VM, see the Hyper-V Architecture diagram.
People love to debate type 1 and type 2 for some reason. Here's one ...
I mean if you want implement a File sharing server in cluster some of the disk have to be shared between the VMs so for that disk the only choice is VHD set which is designed for this purpose.
If sharing disk is not necessary I'm suggesting you to use VHD which (as per the description in the image) seems more stable then VHDX which provide up ...
That recommendation is specific to Azure, in which the Azure Linux Agent creates swap elsewhere as described in the document you linked to.
In your own Hyper-V images, which are being run on-premise, you should have an appropriate amount of swap.
If you might migrate such virtual machines to Azure in the future, you can create a swap file instead of a swap ...
As for getting the nested Hyper-V guests to connect to the external network, you probably need to enable Promiscuous Mode on the ESXi vSwitch, and additionally you may need to enable MAC Address Spoofing on the network adapter of the Hyper-V guest. Images below:
Hyper-V guest network adapter:
I have used Hyper-V replication as a method to migrate VMs. It can work fine. You can't failover(migrate) via replication without stopping the VM during the failover, but that should only take a minute or two.
Just setup replication, of all the VMs you want to migrate. Wait for everything to sync up. When you are ready to migrate, stop the VM(s) and use ...
Can you see "Insert Integration Services Setup Disk" in Action tab? If yes, by mounting ISO you will be able to install the integration services and after reboot, the mouse must be available. (Must be available according to Microsoft reference).
However, you can try to create new VM and mount existing VHDX to the new VM. (do it at your own risk)
Your engineers are following a good practice, but for the wrong reasons.
You are correct in that the VHDX (or whatever virtual disk technology is being used) will:
Re-use written blocks on rewrite rather write all-new
Have a hard size limit equal to the maximum configured size for the parent virtual disk. The reason that you cannot specify a maximum size ...
Your Hypervisor should be a Hypervisor and nothing else.
If there is an actual performance based need to keep SQL non-virtualized, then your better bet would be to get a second server to run SQL on. However, most likely if this is the entire infrastructure you can get away with virtualizing SQL, and separating the storage in Hyper-V to dedicate some to your ...
I believe the best way to proceed in your case would be:
Create .VHDX with required size: https://www.windowscentral.com/how-create-and-set-vhdx-or-vhd-windows-10
Move all your files to a newly created and attached disk (.VHDX-based)
You can use the New-NetNat powershell command to create a NAT connection for the VMs to connect to the Internet using the host IP address. That's how I achieved this in the past without having to assign external IP addresses (in the same network of the host) to the VMs. Check this technet article
One question: You say that your Windows Server has a public IP ...
In fact Windows 2019 is very buggy now. I would suggest avoiding it for now and wait for the new stable release.
According to the Microsoft Evaluation Center:
"We have temporarily removed all media for Windows Server 2019 and Windows Server, version 1809. We have also paused the rollout of the latest feature update to Windows 10 inclusive of versions 1809, ...
If the file you downloaded is a raw image of the virtual hard drive, then you will need to convert it to a VHD or VHDX first. The tools available in VirtualBox are a good fit for this situation.
VBoxManage.exe clonehd "diskimage.img" "diskimage.vhd" -format vhd
VBoxManage.exe clonehd "diskimage.img" "diskimage.vhdx" -format vhdx
In a production deployment, you would ideally have a management network separate from the network that your virtual machines use. This text refers to setting up such a management network. You can operate Hyper-V without a separate management network, but that traffic will contend with VM traffic.
This is a DNS issue. You need to be able to ping the domain by name to join/login to a domain. Run ipconfig /all from the affected machine and make sure the windows DNS servers IP address is listed under DNS servers. No other dns should be in the list.
The biggest thing I would worry about would be the differences in CPU features. If the CPU In your R730 has more features, you might not be able to live-migrate it back unless you have the CPU compatibility option set for the VM.
If you can migrate back and forth between the two right now without problems, then you should be fine. So you could bring up a ...
It might be DNS or TCP/IP related error. Make sure that replica and source host can ping each other using ping or nslookup by DNS name, FQDN and IP. Here is some info (#3) - https://www.altaro.com/hyper-v/advanced-troubleshooting-of-hyper-v-replica-part-1/
PS C:> Move-VM "VMNAME" "DestinationServerName" -IncludeStorage -DestinationStoragePath D:\"VMNAME"
Alternatively, you can do it with Windows 10 Pro machine and Hyper-V manager on it, connect the hosts and Move the VM.
The following requirements must be met to implement nested virtualization in Hyper-V:
The host operating system must be Windows Server 2016 or Windows 10 (Anniversary update or later). Older Windows versions don’t support nested virtualization.
The Hyper-V VM must be of version 8 or higher.
The physical server must have a compatible CPU that supports the ...
One of the methods of gathering information about VMs is "Measure-VM" PowerShell cmdlet. It will require "Enable-VMResourceMetering" in the VM.
The example of using it:
Get-VM | Enable-VMResourceMetering
Also, you can take a look at Veeam One Community edition (https://www.veeam.com/virtual-server-management-one-free.html) which is one of the ...