Based on the actual experiance, my coleage an i found a real scenario for nested virtualisation.
From time to time in the production world of virtualisation, there are some applications where requires a GUI Interface.
Based on the actual state of development, containering is not a possible solution for that. So why not using nested virtualistation
for applcations, which required single OSE instance for there presence and are not stackable on a Windows system.

That nested virtualisation between Server 2016 and higher works thats clear, because i was one of the most commented features
in the last roadshows, but did nested virtualisation also works in combination with VmWare ESXi? Yes it do but its not so simple.

First the VmWare VM need the minimal Hardware Version 11.
Then the .VMX file of the created VM has to be modified by entering the following two lines

************
hypervisor.cpuid.v0 = “FALSE”
vhv.enable= “TRUE”

*************

In the VM you should also enable “Exposed hardware assisted virtualisation to the guest os” in your VSphere Webconsole.
With these configuration your will be able to install HyperV on a ESX VM, creating HyperV VMs and start them.

So but what is with communication? These VMs are for testing, if you cannot communicate to your network. VLAN tagging is normaly no issue, because the BaseVM is already tagged.
The most issues came over the fact, that HyperV makes the communication for nested VMs by using “MacAddressSpoffing” so you have to enable that on each VM seperatly.

On the VMware you have also to configure the assosiated VMNetwork by allowing
_Premiscousue mode
_MAC Address change
_Forged transmitts

After that your HyperV VM cann communicate to the world. But if you choosen the way to share
your virtual network card of the host with the VM (allow management traffic over the virtual netzwork)
you Hyper-V VM will interupt the communication of the host every time.
So you have to seperate the network cards on two virtual network cards for beeing successfull.

The last step to to is having time. Because the HyperV Server has to learn, which MAC, has which IP an how communicate
each VM of your System with the network. After you have created and startetd the VM and Pinging your default gateway
you don’t receive an answer. Let the VM ping continuasly and after 2-4 minutes you receive answers from the target,
because the HyperV Server learned which communication has to be routed to which VM.

THX to Flo, which was my VMware conterpart for this mission