Hyper-V, VMware Verschachtelung und komisches verhalten VMs

Hallo,

also vorab ist mir klar das das hier ne absolut schräge Nummer ist, aber Sie lief bisher.

Wir haben folgende Konstellation:
VMware mit 6 Hosts und vCenter, hier läuft eine VM Windows Server 2022 Standard drauf mit Hyper-V Rolle.
Es sind 2 Virtuelle Netzwerkkarten in der Hyper-V VM konfiguriert:
- 1 mal Server VLAN 192.168.1.123
- 1 mal Client VLAN 192.168.1.15

im Hyper-V ist ein External Virtual Switch konfiguriert,
hierbei ist der Netzwerk Adapter mit dem Client VLAN ausgewählt.

Bisher war das so das die Option "Allow management Operating System to Share this Network Adapter" nicht ausgewählt war in den Settings,

Auf dem Hyper-V laufen diverse VMs die sporadisch angeschaltet werden bei bedarf.
Diese haben sich dann per DHCP eine IP aus dem Client VLAN geholt.

Lief alles.

Dann seit dieser Woche gehts nicht mehr.
Änderungen an Switchen oder VMware gabs nicht.
Es gab ein update der Zentralen Firewall, aber auch kein Config Change oder so, sondern halt übliches Update.

Nun haben wir folgenden Effekt mit den VMs auf dem Hyper-V
Man schaltet sie ein und sie holen sich normal die DHCP Settings (nein nicht gecached, weil wenn man lease am DHCP löscht sieht man das er eine neue Lease erstellt, aber auch change in ein anderes Client VLAN vom VMware Netzwerkadapter, zeigt das er sich dann aus dem anderen VLAN ebenfalls per DHCP sich die settings holt). Aber das wars auch anschliessend ist er Offline. Mit IPCONFIG sieht man aber alles settings korrekt. Anpingen vom Gateway geht nicht und sonstiges anpingen auch nicht.

Wenn man am Hyper V den External Switch den haken ranmacht bei "Allow management Operating System to Share this Network Adapter" so das der Hyper V Server auch ne IP im gleichen Client VLAN hat kann der Hyper V Server die VM anpingen, und die VM kann den Hyper V Server anpingen. Aber sonst nix...

bin mit dem Latein ein wenig am Ende, vor allem war ich - bis damals alles es einfach so ging - eh der Meinung das sowas garnicht geht. hat jemand ne idee was man hier machen könnte oder ob das überhaupt geht.

Weil es ist ja quasi so:
Physikalischer Port Switch (Trunk) geht Physikalisch in VMware Host, dort Virtueller Switch der Virtuell zum Hyper V geht, und der mach da drauf auch nochmal ein Virtuelles LAN, somit doppelt gemoppelt...

Wenn jemand Ideen hat bescheid geben, danke.

Aktuell wäre der Workarround das man halt erst RDP auf Hyper V Server machen müsste und von dort RDP auf die VM vom Hyper V und kann somit Netzlaufwerke auf die art und weise reinmappen...
Aber hat ja schon mal funktioniert und mir ist unklar warum das auf einmal nicht mehr geht.

Habe 2 Beiträge gefunden aber die bringen mich in meiner konstellation auch nicht wirklich weiter:
https://community.spiceworks.com/t/hyper-v-guest-cant-communicate-but-dh ...
(ganz unten Lösung, geht bei mir nur nicht weil der Hyper V host bei mir Virtuell ist, seiner war wohl Physikalisch)
Interessant auch das der das selbe problem hatte, Firewall Update, aber anderer hersteller....
und
https://learn.microsoft.com/en-us/answers/questions/938988/2019-hyper-v- ...
hier:
If it does not go through, then it could be a security setting on the physical switch. Security types commonly like to restrict MAC address coming from a single port or bouncing across ports, which plays havoc on virtual machines.

aber Port am Physikalischen Switch hat keine speziellen Configs, ist stink normaler Trunk....
keine Security Settings.

request time out.
Reply from 192.168.1.15: Destination Host unreachable.
request time out.
request time out.
Reply from 192.168.1.15: Destination Host unreachable.
Reply from 192.168.1.15: Destination Host unreachable.
Reply from 192.168.1.15: Destination Host unreachable.
request time out.
Reply from 192.168.1.15: Destination Host unreachable.
request time out.
request time out.
request time out.
request time out.
request time out.
request time out.
Reply from 192.168.1.15: Destination Host unreachable.
Reply from 192.168.1.15: Destination Host unreachable.
request time out.
request time out.