Denn die Last auf dem SAN ist nicht merkbar, außer man konsolidiert die Snapshots. Dann passiert nämlich die Magie: dann werden die Snapshots files wieder ins Ursprungsfile geschrieben. Vorher tritt praktisch keine höhere Last auf.
Das stimmt definitiv nicht!
Snapshots erzeugen von Haus aus, rein durch ihr Verfahren höhere Last. Dazu muss/sollte man wissen, wie die Snapshots funktionieren... Ein Snapshot wird idR in 16MB Blöcken erstellt (wenn mich nicht alles täuscht). Das heist, werden Daten geschrieben, wird der Block des Snapshots immer in 16MB Schritten erstellt(vergrößert). Jedes erweitern des Snapshot Blockes erzeugt dabei Last, die man nicht hätte, hätte man keinen Snapshot erstellt! Das hat den eklatenten Nachteil, dass dies quasi Random Access like passiert. Vor allem bei mehreren gleichzeitigen Snapshots im selben LUN. Einfach aus dem Grund, weil idR nicht alle VMs, die einen (oder mehrere) Snapshots haben, gleich viele Daten zur gleichen Zeit schreiben. (im selben Volume/LUN)
Dazu kommt, der Snapshot ist dazu da, den Ist-Datenbestand festzuhalten. Eine Änderung an diesen Daten heist dann nicht ändern im Snapshot, sondern neu schreiben! Deswegen wird die Größe auch bei simpler Änderung anwachsen, anstatt wie ohne Snapshot, eben nicht.
Unterm Strich, diese 16MB Blöcke können so wild verteilt auf dem Storage liegen, was unterm Strich den Charm einer massiv fragmentierten NTFS Partition hat. Selbst wenn man dann größere Datenmengen sequenziell lesen würde (bspw. bei einem Backup) wären diese nicht physisch am Stück auf den Platten, sondern eben wild durcheinander... -> Random Access, weniger Speed.
Normal werden die meisten Nutzer von ESXi wohl bei blockbasierten Storages keine Schnellzuweisung machen. Ggf. sogar, wenn von Vorteil, die Bereiche sogar nullen. Das alles machen Snapshots nicht. Bei NFS Shares verhält sich das etwas anders... Da ist grundsätzlich der Bereich schnell bereitgestellt.
gut wenns Vorteile hat dann werd ich das tun.
Lass dich nicht beirren, das läuft auch so wie du es hast... Und hat eben den Vorteil der Lastverteilung... Zwar nicht dynamisch, aber eben händisch, weil du die VMs halt auf die beiden NICs/vSwitches aufteilst.
Ich sehe keinen Vorteil daran, das umzubiegen. Aber auch keinen Nachteil es (nicht) zu tun. Es ist im Grunde wurscht...
Port auf dem Ziel ist offen. Von anderen Clients und von einer anderen VM kann ich mich verbinden.
Das könnte noch ein MAC Adress oder ARP Problem sein... Gerade wenn du zwischen den beiden vSwitches hin und her springst...
Ansonsten, was mir spontan einfällt, lösch mal die vmxnet3 aus der VM und leg mal eine neue an, eventuell behebt das dein Problem schon.
Ansonsten, via "Telnet xxx.xxx.xxx.xxx Port" mal versucht den Port aus der VM aus zu öffnen?
Gehst du auf den Namen des Ziels (also NetBios Name oder FQDN) oder auf die IP?
FQDN/NetBios Name könnte ein Problem mit der Namensauflösung sein, gerade wenn man keinen "richtigen" DNS/Wins Server verwendet. DNS via Fritzbox/Speedport ist bestenfalls dürfting. Und NetBios ohne Serverunterstütztung heist, dass sich die Clients das untereinander selbst aushandeln. Was entweder arsch lahm ist oder manchmal gar nicht sauber funktioniert.
PS: wenn du sagst, Firewall ist aus auf dem Client, Firewall auf dem Ziel? Und Firewall auf dem Client generell aus oder nur für ein Profil? (private/public/domain)?
Auch mal nach den Proxy Settings schauen...
Ggf. ists auch ein Problem mit der IE Website Security... Sprich mal gucken, ob du die IP nebst Port in die Intranet/internal Sites hinterlegen kannst... -> auch wenn das eher unsinnig erscheint, manchmal bewirkt es Wunder
VMWare sagt auch dass man bald 64vCPU pro VM zuweisen kann und das Snapshots ne coole Sache sind 
