Weingeist

Ist doch mit VM's eigentlich voll easy. Zusätzliche vDisc und lokal da drauf sichern. Zur Sicherheit kannst noch die vDisc ab und wann wegsichern. Wenn Du auf dem Ding noch Dedupe laufen lässt, kannst ne halbe Ewigkeit Daten sichern ohne wahnsinnig viel Platzbedarf. =) Anschliessend kannst ja zusätzlich mit dem Backupprogramm deiner wahl die vDiscs mit den Backups drauf sichern oder per Backup-Tasks die sicherungsfiles in ein Verzeichnis Deiner Wahl mit den Credentials Deiner Wahl wegkopieren. Mache das mit dem Umweg über eine zusätzliche vDisc bei Applikationsserver sehr gerne. Trivial, mit bordmitteln, viele Backupstände, wenig Speicherbedarf, schneller Restore. Vor allem bist mit allen Software-Herstellern immer im Grünen, da oft einer der wenigen Varianten innerhalb des Supports.

Stimmt, nicht gesehen... Beitrag war zuoberst

In solchen Dingen immer systematisch ausschliessen. Als erstes NB an einem anderen Netzwerkport einstecken wo ein Client dranhängt der keine Problem hat, sind die Probleme noch da, liegt es vermutlich nicht an der Leitung. Wird Dockingstation verwendet, zuerst ohne Dockingstation usw. Hat ein Client der sonst keine Probleme hat, an dieser Leitung Probleme. Liegt es an höchstwahrscheinlich an der Leitung. Der einfachste Test, Port von 1Gibt auf 100Mbit Gigabit drosseln. Wenn nicht möglich, einen 100er Switch dazwischen hängen. Sind die Probleme Weg, dann ist die Leitung oft unbrauchbar. War bei mir immer Fehlerquelle Nummer 1 sobald es Random mit einzelnen Quellen war. Insbesondere in älteren Gebäuden wo entweder Kabel durch zu kleine oder verwinkelte Leerohre gewürgt wurden oder schlicht noch alte Leitungen liegen. --> Leitung ausmessen lassen Auch ein Stück ungeschirmtes Kabel mit nem Verbindungsstecker dazwischen hängen hat schon geholfen --> Deutet auf irgendwelche Potentialprobleme hin, manchmal hilfts dann einfach einseitig den Schirm auf dem Patchpanel nicht anzuschliessen.

Ich frage mich immer bei solchen Dingen wie dem Credential-Guard immer, ob das tatsächlich so viel bringt. Eigentlich schafft man mit einem zusätzlichen HyperVisor in einem Client/Server, UEFI auf der Platte abseits der Kontrolle etc. doch auch unglaublich viel Komplexität mit viel Code und entsprechendem Fehlerpotential. Ich bin kein Spezialist in solchen Dingen, aber irgendwie hat das ganze Zeug jedenfalls einen faden Beigeschmack. Wo sich ein Angreifer dazwischenschaltet ist ja egal, wenn er sich Admin und/oder Systemrechte auf einem System aneignen kann - die Basis von fast jedem erfolgreichen Angriff - dann kann er sich doch auch immer zwischen die Kommunikation von egal was schalten und die "notwendigen" Dinge bekommen/manipulieren. Ein Bemerken/Aufspüren könnte noch schwieriger sein wenn er sich in solchen Bereichen einnistet. Oder sehe ich das falsch? Klar kurzfristig hilfts ja bestimmt, schlicht weil die meisten es nicht einsetzen und somit kein grösseres Interesse besteht weil man genügend andere attackieren kann. Aber mittel- bis langfristig? Oder habe ich das was nicht verstanden? Bezüglich der Admins-Workstation: Wenn eine ganze Umgebung in einem Cluster läuft, wie beim TO und auch in den meisten kleinen bis mittleren Umgebungen, hat man ja immer das Risiko, dass eine übernahme des HyperVisors auch T0-System wie AD komprimitiert. In der Regel hat man da ja nicht ausfallsichere Cluster für jede Stufe. Laufen also auf dem selben Host. Lohnt es sich dann überhaupt mehrere Admin-Workstations zu haben oder reicht nicht einfach eine aus? Admin-Workstation>Zugriff auf die VM's über dasVerwaltungsnetz mittels Hyper-Visor-Remote-Protokollen (Arbeits-VM für E-Mail, die Server an sich). Oder man verwendet zum surfen grad komplett andere physische Hardware. Sprich Zugriff nichtmal über ein Remote-Protokoll. Zumindest könnte man so die Admin-Workstation relativ gut insolieren, würde nur im Verwaltungs-Netz hängen. Für Fernzugriff müsste man sich noch etwas anderes einfallen lassen damit man von externe keine Passwörter eingeben muss, ist ja sonst wieder PillePalle.

Früher hatte ich immer Unternehmen.local, später ad.zz verwendet. Bei ad.zz traf das Problem deutlich weniger bis nicht auf. Wobei ich bei ad.zz auch die Freigabenamen jeweils möglichst kurz gehalten habe, was wieder ein paar Zeichen gab. Insofern waren es dann wohl 20-25 Zeichen. Aber eben, mit Azure, Zertifikaten etc. ist eine "sprechende" Adresse die einem gehört eher wieder "besser" bzw. ausschliesslich geeignet.

Vermutlich schon. Heute hat man doch den Kram eh unter SA oder? Vielleicht lehne ich mich jetzt aus dem Fenster, aber reine Machine/Machine Kommunikation müsste eigentlich CAL-frei sein. Hat ja nix mit der Arbeit an sich des User zu tun. Weder direkt noch indirekt. Aber sollen bitte die Super-Lizenz-Spezis hier abschliessend beantworten. ;)

Was noch nicht genannt wurde und ich in Vergangenheit schon ein paar mal drüber gestolpert bin: Die Probleme bei zu langen Domain-Namen. Ist super nervig in Verbindung mit DFS. Da zählt manchmal jedes Zeichen wenn die Leute allzu sprechende Namen in Ihrer Ordnerstruktur verwenden. Je weniger Zeichen die Domain hat, desto mehr steht für den Rest zu Verfügung, desto tiefer ist die Wahrscheinlichkeit, dass das Problem aufschlägt. MS hat es auch nach über 20 Jahren NTFS immer noch nicht geschafft, dass Ihr Code - allen voran der vom Explorer - durchgängig Pfadlängen über 255 Zeichen unterstützt. Dann gibt es noch ein weiteres Problem mit generischen Namen/TLD's die einem nicht gehören: Zertifikate. Siehe z.Bsp: https://cabforum.org/internal-names/ Tja, meine älteren Umgebungen sind/waren auch fast alle "falsch" mit dem kürzel zz oder local. Mir grauts immer vor den Umstellungen wegen DFS/Verknüpfungen in Dokumenten/CAD-Bibliotheken/Vorlagen etc. Ein paar mal habe ich das schon gemacht, es war jedes mal kein Spass. Weder für mich noch die MA's. Auch wenn es Stunden gegeben hat.

Wens klemmt, kannst eventuell auch gleich ne neue VM mit 22 hochziehen statt neu zu aktivieren. Dann ist wieder für ne Weile Ruhe ;)

Überbuchung ist übrigens im KMU Umfeld in der Regel deutlich problematischer als im grossen Umfeld. Grund: Die Anwendungen sind öfter nicht so optimiert wie im grössen Umfeld, sei es Datenbanken und deren Indexe, Clients die Videos abspielen, vielleicht Filer + Clients auf dem gleichen Host (ohne einbremsung der IO's, wird die volle CPU-Leistung für die LAN-Ports verbraten) usw. Alles Dinge die man im grösseren Umfeld in der Regel steuert, im kleinen aber entweder nicht kann (z.Bsp ESXi Essentials) oder schlicht zu aufwendig in der Pflege ist. ;) Auch sollte man eher viel MHZ statt viel Kerne haben. Grund: Viele KMU-Anwendungen sind Single Core basiert, Clients die man als VDI oder RDS laufen lässt profitieren enorm von hoher Single Core Leistung --> User Feeling --> KMU's sind meist Inhaber geführt = Computer soll gefälligst schnell sein, schnell heisst nicht insgesamt sondern genau dann wenn etwas gewünscht wird (Latenz) ;) Daher schaue ich immer das ich normal nicht mehr als 16 Kerne pro Host (Lizenzierung bzw. deren Kosten) und Taktrate von möglichst >3GHZ habe. Sprich das + an Leistung/Stromkosten ist oft deutlich günstiger als viele Stunden Optimierung auf welche man oft nichtmal einen Einfluss hat. Wie immer zu diesem Thema: Nur meine ganz persönliche Meinung.

Nicht nur Deutsch ist eine schwere Sprache *g*

Ironischerweise gibts beim Userfeeling mit am meisten Ärger mit dem Fileserver wenn da planlos vorgegangen wird (Verknüpfungen auf Dateien, Verknüpfungen innerhalb Datei z.Bsp. Excel in Word etc.). Aber wie die Vorredner schon sagten, loslegen und machen, vielleicht am Anfang und immer zwischendurch noch , soll auch helfen. Ne mal im Ernst, hole entweder Hilfe dazu oder übe vorher eingehend in einer Testumgebung. HowToos findet man bei MS und im weiten Netz.

Gut möglich, dass es das ist. So ganz habe ich die Thematik/Logik hinter den SSU nicht verstanden. Manchmal muss das SSU vom gleichen Monat vorher installiert sein, manchmal darf es das nicht. ;) In der Vergangenheit war es bei mir oft so, dass es zielführender war, erst die Updates zu installieren und dann die SSU obwohl es genau anders rum kommuniziert wurde. Vor W10 habe ich den Stack wegen manchen Update-Probleme meistens ein paar Monate gar nicht installiert und 1 oder 2x pro Jahr aktualisiert. Bei Maschinen-Steuerungen eigentlich gar nie solange die Updates trotzdem eingespielt werden konnten. Später habe ich dann einfach immer das SSU vom Vormonat oder zwei Monate vorher freigegeben. Seit die Updates kombiniert sind, geht das natürlich nicht mehr. Klappt es mal nicht, was aktuell vielleicht 1x pro Jahr vorkommmt, dann trenne ich das Update aus dem Update-Katalog auf und versuche es separat, das klappt dann in der Regel (manchmal muss vorher 1-2x neu gestartet werden, Windows muss sich evtl. teilweise erst sammeln ). Seltsamerweise sind nicht immer die gleichen Clients betroffen die rumzicken.

Würde ich mir in diesem Fall jetzt keine Sorgen machen bei einer reinen Browser-Anwendung... Doku erstellen und gut ist. Allerdings sind 0815 Windows-PC's relativ pflegeleicht für so eine Anwendung. Da sie nicht viel können müssen, auch ziemlich kostengünstig. Einfache Fat Clients kosten ja nicht mehr als Thin-Clients/Terminals.

Für die Ursachenfindung bleibt Dir nichts anderes übrig als Systematisch zu analyisieren bevor sie sich weghängt. Und/Oder erweitertes logging usw. Arbeitsspeicherauslastung prüfen ob der Kram jeweils freigegeben wird oder nicht usw. Da gibts so viel Möglichkeiten was schief laufen kann... Netz durchforsten mit den ersten Events die geworfen werden usw.

Ein untattended.xml zu erstellen mit ein paar Änderungen ist nicht wirklich schwierig. Wenn es Dir dennoch zu aufwändig ist, einfach da wo Du die Disk auswählen musst mit Shift + F10 in die CMD und mit diskpart alle Partitionen selbst erstellen. Ist jetzt auch nicht die Hexerei, ist aber je nach dem eine mühsame Tippslerei. Oder aber Du erstellst ein kleines Script oder ein Textfile für Copypaste der GUID's. Für BIOS ohne Wiederherstellungsdisk ist das zum Beispiel easy: - select disk 0 - create partition primary - active - format fs=ntfs quick --> danach eifach die die Platte auswählen bei der Installation und man hat ausschliesslich die Windows-Partition. Selbstredend, dass dies nicht gleichermassen easy für UEFI ist. Anbei etwas Lektüre: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11 https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-partition_information_gpt Im Grunde musst alle Partitionen von Hand erstellen die entweder zwingend für die Funktion von Windows sind oder Du deren Funktion haben möchtest. Ganz ehrlich, für UEFI ist einfacher mit Automation. ;)

NTFS-Errors klingen gerne mal nach sterbendem Storage oder Storage mit zu hoher Latenz z.B. aufgrund eines Rebuilds oder schlichtweg überfordertem Storage aufgrund Sicherung etc. was dann die VM in Bedrängnis bringt. Abhilfe: Storage Checken, eventuell Disk-Timeout innerhalb der VM erhöhen. Allgemeines aufhängen nach Zeit ist auch gerne mal ein Fehler mit dem Arbeitsspeicher. Also entweder eine Software welche sich nicht sauber entlädt und so irgendwann in die Kiste in die Knie zwingt oder aber ein defekter Riegel. Abhilfe: Z.Bsp. mal auf nen anderen Host schieben sofern möglich und beobachten ob die Probleme identisch bleiben. Ansonsten wenn Du keine NTFS Error auf den Servern selbst hast sondern nur auf den Broker und die nicht direkt nach dem durchstarten sondern mit starker Verzögerung kommen, kannst auch testweise einfach mal jede Nacht durchstarten lassen, sofern das Arbeitsfenster diese zulässt.

ooops, hast ja Recht... @TO: Ich würde den Kram auch einfach löschen bzw. gar nicht erst erstellen beim Setup. Normal ist es besser wenn Windows von Anfang an weiss, dass etwas nicht da oder da ist. Denke zwar nicht, dass es hier von Belang ist, aber man meiss ja nie.

Diese Lösung ist zwar OK aber eigentlich nur ein Teil des Problems. Manche Komponenten ignorieren den Reg-Entry und gehen trotzdem auf IPv6 und man hat interessante und unerklärliche Phänomene. Insbesondere wenn eben das Binding deaktiviert wird. Ansonsten fallen sie oft nicht auf, weil trotzdem via IPv6 kommunziert wird. Kann man leicht überprüfen wenn mit der Firewall IPv6 geblockt wird und das logging aktiviert. =) Wenn man keinen Ärger möchte und sicherstellen will das alles, z.bsp auch der Anmeldevorgang, das laden der GPP's via IPv4 läuft und Loopback ebenfalls zuverlässig IPv4 genutzt wird, muss man das Routing noch anpassen. Zum verändern netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4 netsh int ipv6 set prefixpolicy ::/96 55 3 netsh int ipv6 set prefixpolicy ::1/128 50 0 netsh int ipv6 set prefixpolicy ::/0 40 1 netsh int ipv6 set prefixpolicy 2002::/16 30 2 netsh int ipv6 set prefixpolicy 2001::/32 5 5 netsh int ipv6 set prefixpolicy fc00::/7 3 13 netsh int ipv6 set prefixpolicy 3ffe::/16 1 12 netsh int ipv6 set prefixpolicy fec0::/10 1 11 IPv6 deaktivieren inklusive tunnel ----------------------------------- netsh interface ipv6 6to4 set state state=disabled undoonstop=disabled netsh interface ipv6 isatap set state state=disabled netsh interface teredo set state disabled Neuere OS auch mit Powershell: ------------------------------ Set-Net6to4configuration -state disabled Set-Netisatapconfiguration -state disabled Set-NetTeredoConfiguration -type disabled So kann man auch das Binding völlig problemlos rauskicken. Natürlich gibts dann noch die ganzen Dienste für Teredo und wie sie alle heissen usw. die man auch deaktivieren kann aber nicht zwingend muss. Auch den IPv6 Subdienst kann man deaktivieren, dann ist der Stack quasi wirklich lahmgelegt. Mache ich aber in der Regel nur bei Industriemaschinen. Das Zeug war übrigens mal das Standard-Verfahren gemäss MS um Exchange supported mit IPv4 zu betreiben obwohl eigentlich nur IPv6 supported ist. Musste dann durch einen MS-Spezialist extra geprüft und freigegeben werden. Seit ich das mal mitgeschnitten habe, mache ich das immer so. Funktioniert auch bei Server 2022 noch prächtig. Via Firewall kann man es dann prüfen und es gehen so tatsächlich keinerlei IPv6 Pakete mehr raus. Am besten macht man das via Script/Gegenscript um den Ursprungszustand easy wiederherzustellen. Updates pfuschen einem in der Regel darin auch nicht rum.

Die planen - oder tun es ja sogar bereits - die Speicher-Chips direkt auf die Platine zu löten statt als Einheit zu verbauen... Immer wieder interessant wie bei Herstellern das grüne Marketing so vollständig gegenteilig am Produkt wieder zu finden ist, je mehr darauf hingewiesen wird, desto weniger ist es am Produkt zu finden. Aber ist ja irgendwie überall so... =)

So wie ich das mal verstanden habe war das Absicht mit ganz hinten. Und zwar genau aufgrund des Platzproblems. Sprich wenn dieser aus geht, dann wird die Partitionsgrenze angeblich dynamisch verschoben. Sprich die Wiederherstellungsplatte wird beschnitten und auf C mehr Platz zu Verfügung gestellt. Ich habe keine Ahnung ob und wie gut das funktioniert, ich partitioniere die Platten in der Regel im Voraus und da gibt es sie dann nicht. Wenn die Kiste spinnt, dann setze ich meist neu auf oder hole ein Backup (bei VM's sowieso). Bei Notebooks ist dann meist die Festplatte defekt und dann brauche ich die Partition auch nicht, da schlichtweg eh nix mehr da ist bei SSD's. ;)

Die Indexierung ist in Windows mittlerweile leider auch Flickwerk. Da wird wegen Cortana dran rumgebastelt ohne Ende. Sprich es wird alles mögliche indexiert aber dafür funktioniert das was man eigentlich möchte und immer funktioniert hat, nicht mehr zuverlässig. ;) Deinstallation funktioniert immer, Reinstallation wird dagegen eventuell schwierig Aaaber: Oft hilft es, wenn einfach das aktuellste Outlook verwendet wird. Das wird noch am ehesten getestet, dass es reibungslos funktioniert. Weil mich das immer soviel Zeit gekostet hat und weil Exchange mühsam geworden ist, habe ich viele kleine Umgbungen auf Thunderbird und IMAP umgerüstet. Keinerlei Ärger, ist sowas von robust. Früher habe ich mich gerne mal mit zerschossenen PST rumgeschlagen bei grossen Postfächer, nicht funktionierender Suche usw. Einzig wirkliches Manko: Der Kalender/Terminplaner ist bei weitem nicht so gut wie Outlook. Zumindest nicht, wenn es benutzerübergreifend sein soll. Aber punkto E-Mail Arbeits-Qualität Übersicht schlägt es Outlook meiner Meinung nach locker. Auch wenn da vielleicht auch etwas Gewohnheit dabei ist.

Bei einer Firma mit einer internen Software die permanent gebraucht wird, habe ich es so gelöst, dass der Entwickler eine Funktion eingebaut hat, die beim beenden fragt, ob man sich gleich von Windows abmelden möchte oder nur sperren (standard). Funktioniert 1A. Ansonsten Alt + F4 beibringen. Kann man auch an den Bildschirm schreiben. Das haut immer zum abmelden bei RDP.

Das Menü scheint irgendwie mit den Energie-Presets/Power-Dienst zusammenhängen. Zumindest suggeriert das der "Ausschaltknopf" der bei VDI keine Einträge hat. Wäre so meine erste Anlaufstelle. Möglicherweise könnte man es daher mit einem speziellen Power-Schema beinflussen. Ob man sich die Mühe antun möchte? Wohl eher nicht. Das war schon in alten Windows-OS der totale Wahnsinn ein eigenes zu erstellen. Zumal es dann nicht gesichert ist, dass es auch tatsächlich so ist. ;)

Und vor X Jahren - müssten auch um die 20 sein - hat Bill Gates extra eine Abteilung geschaffen die sich alleine um die Patchqualität kümmert weil es ein permanentes Desaster war und die halbe IT-Welt keine Patches mehr eingespielt hat. Diese Abteilung wurde vor ein paar Jahren aufgelöst weil die "Insider" und die Telemetrie ja deren Job machen... Seither nimmt die Qualität gefühlt permanent weiter ab. Bis dahin war die Patchqualität eigentlich bis auf wenige meist spezifische Probleme doch viele Jahre excellent. Hatte so gut wie nie Probleme in meinen Umgebungen. Ansonsten bin ich auch der Meinung das man sich die Zeit nehmen muss sich zu informieren. Aber wennn es niemand machen würde, dann gibts auch keine Meldungen Ahja, die immer ewige Leier man könne doch auf Linux wechseln ist doch einfach Habakuk. Man hat keine echte Wahl sondern nur eine Pseudo-Wahl. Schlicht weil man nicht jede Software selber entwickeln kann. Besser wäre sie dann auch nicht. Schon gar nicht als kleine Firma. Der Markt bringt Software für die Breite auf Windows, speziell für die produktive Branche. So ist nunmal die Realität. Ob sie einem gefällt oder nicht. Aber eigentlich ist das noch nichtmal der springendste Punkt. Hersteller wie MS mit Produkten die eine solche Verbreitung haben, dermassen viele Menschen direkt oder indirekt von deren Funktion abhängig sind, haben auch eine sehr hohe gesellschaftliche Verantwortung. Insofern ist da auch ein sehr berechtigter Anspruch vorhanden, dass man möglichst viel für gute Produkte - bei Software heisst das nunmal auch gute Patches - tut. Den gleichen Anspruch darf bzw. muss man im Mobil-Bereich z.Bsp. auch an Google und Apple haben. Es werden Bankomaten mit deren Software betrieben, Maschinensteuerungen, Kraftwerke, ganze Bundesverwaltungen/Länder, Spitäler usw. Sprich eigentlich die ganze Gesellschaft hängt davon ab! Allerdings - da muss man die Konzerne etwas in Schutzt nehmen - wäre hier auch der Gesetzgeber gefragt, hier entsprechende Vorgaben zu machen. Ohne diese gilt nur das Max-Profit-Prinzip. Das heisst nunmal, vergraule die Kunden nur soweit, dass nicht zu viele abspringen.

Was man auch gerne vergisst ist die Tatsache, dass Windows mittlerweile verschiedensten Berechnungen an die GPU auslagert. Das hat deutlich zugenommen in den letzten paar Jahren. Ist zwar hilfreich für normale PC's/Notebooks, aber eben nicht mit Virtualisierung. Muss das durch die CPU via virtueller GPU erledigt werden, ist das nicht gerade hilfreich und der Performance abträglich. Sprich im Endeffekt braucht man für das gleiche plötzlich mehr CPU-Zyklen als auch schon. Wird zwar teilweise dadurch aufgefangen, dass diese Berechnungen auf dem zugreifenden Client passiert - Zumindest bei RDP - , aber wohl längst nicht alles. Erhöht man z.Bsp. auch noch die Auflösung an den zugreifenden Clients, wird das ganze nochmals verschärft. Auch sind immer mehr Dienste Userbasiert. Das verschlingt zusätzliche Ressourcen. Der vermehrte Einsatz von Video-Calls, Echtzeit-Audio und Home-Office macht alles noch schlimmer weil das priorisiert werden muss damit man keine unerwünschten Unterbrüche hat. Das pfuscht in die ganzen Verteilungsmechanismen rein. Bei anderen Prozessen spielt das keine Rolle bzw. ist ja erwünscht, sonst würde es nicht funktionieren. Die Priorisierung bremst den Rest aber dann irgendwann zu stark ein weil die notwendigen Zyklen nicht freigegeben werden. Dann gibts da auch noch ganz banale Dinge: Ist ja eigentlich fast schon etwas bekloppt was alleine ein Starmenüaufruf insgesamt für IOPS/CPU-Zyklen verursacht und wie lange da im Hintergrund Daten analysiert und gespeichert werden. Zu guter letzt ist die Telemetrie enormst ausgebaut worden. Was da im Hintergrund alles berechnet und gespeichert wird ist schon fast mehr als was ein 0815 User selber an IOPS/CPU Zyklen beim Arbeiten verursacht. Zumindest in VDI hilft das daher enorm, wenn man den Rotstift bei dem ganzen Krempel ordentlich ansetzt. Schätze mal, das tut es auch bei RDP. ;) Die Verwendung von SSD's/NVMe's wurde ja bereits genannt. Da wird dann aber mehr die virtuelle Netzwerkkarten zum Problem als die IOPS welches das OS verursacht. Sprich das was an Traffic über das Netz der VMs generiert wird. Wenn ein Client z.Bsp. eine grössere Video-Datei mit 500 MB/s kopiert, dann verursacht das eine enorme CPU-Last. Je nach Storage sowohl auf dem Host als auch innerhalb der VM. Ganz Krass von VM zu VM, sind dann zwei virtuelle Karten und Hostressourcen. Solange das Storage nicht hinterherkommt, 0 Problemo, schaufelt das IOs, dann wirds zum Problem. Sind die CPU's überbucht, wirds zum massiven Problem. Als Fazit würde ich sagen: Überbuchen sollte man möglichst vermeiden/tief behalten sobald man zeitkritische Prozesse wie Video/Audio hat. Da werden eine Menge der ausgefeilten Prozesse ausgehebelt weil die VM eben darauf angewiesen ist, dass sie die Ressourcen ohne Verzögerung bekommt. Sprich die notwendigen CPU-Zyklen möglichst exklusiv im Voraus reserviert werden. Ein Client ohne Video/Audio/unnötige Animationen etc. ist da anspruchsloser.