mwiederkehr

Allerdings, denn man muss ja noch arbeiten können. Ich habe einen Kunden, bei dem ich ohne Zwischenablage auskommen muss. Zum Einfügen nutze ich ein Tool, welches den Text in der Zwischenablage "eintippt", aber bei grösseren SQL-Scripts dauert das...

RDP ist ein komplexes Protokoll und bietet viele Angriffsmöglichkeiten. Nicht nur auf das Protokoll zur Bildübertragung, sondern auch auf die umgeleiteten Drucker (XPS-Interpreter), Laufwerke, Zwischenablage etc. Die Zusatzfunktionen lassen sich aber abschalten. Die einzigen mir bekannten Schwachstellen beziehen sich auf die Zwischenablage. Der Server kann die Zwischenablage des Clients mitlesen und verändern. Wenn man "harmlose.exe" in der Zwischenablage hat, könnte sie durch "virus.exe" ersetzt werden, siehe https://research.checkpoint.com/2019/reverse-rdp-attack-code-execution-on-rdp-clients/. Zudem gab es eine Lücke, die Codeausführung erlaubt hat: https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2019-0887 Also ja, ist theoretisch möglich, aber sehr unwahrscheinlich, besonders wenn Zwischenablage etc. ausgeschaltet sind. Für TeamViewer gilt das genauso. Wer will, kann Guacamole in einer VM laufen lassen und einen Browser in einer anderen VM und über die Hyper-V-Konsole auf den Browser zugreifen. Galvanische Trennung quasi.

Ich trübe ja ungerne die Freude, aber mal vorsichtig ausgedrückt: Ceph (und auch andere verteilte Speichersysteme) laufen möglicherweise nicht ganz optimal über WAN-Verbindungen, bei denen sowohl Bandbreite als auch Latenz "best effort" sind.

Traumhaft! Muss St. Peter-Ording unbedingt auf die Liste für unsere nächste Reise in den Norden nehmen. Letzten Sommer sind wir von Föhr direkt nach Hamburg. Wer hat jetzt alles Appetit auf einen Fischteller und einen Pharisäer zum Dessert? Gute Reise!

Nicht kostenlos, aber günstig, ist PDQ Deploy. Da bezahlt man pro Admin und Jahr 1575 $ und die Anzahl Clients ist unbeschränkt. Die Verteilung erfolgt per "Push", sobald ein Client erreichbar ist. VPN ist grundsätzlich kein Hindernis. Wenn ein Client während der Übertragung des Installers die Verbindung trennt, bricht die Installation ab und beginnt beim nächsten Versuch wieder von vorn.

Vielleicht geht es ganz simpel mit vier iFrames? Mit etwas JavaScript könnte man noch vier Reload-Buttons hinzufügen, falls sich die Seiten nicht automatisch aktualisieren.

Ja, es ist komplizierter geworden. Ein Kunde hat kürzlich einen DL380 Gen10 mit NVMe ausgestattet. "Die leuchten nicht und werden nicht erkannt, dabei haben sie reingepasst!"

Es gibt NVMe-SSDs für Server. Die haben Anschlüsse vom Typ U.3 und nicht M.2 und passen in die gleichen Einschübe wie SATA und SAS.

Hallo zusammen Einige VMs auf einem Hyper-V-Cluster verlieren in unregelmässigen Abständen die Netzwerkverbindung. VMs und Hosts laufen auf Windows Server 2022. Der Unterbruch passiert pro VM etwa einmal im Monat. Es kann aber auch schon nach zwei Wochen sein oder erst nach zwei Monaten. Die Netzwerkkarte ist dann weg. Es hilft nur noch, die VM aus- und wieder einzuschalten. Eine Live-Migration auf einen anderen Host hilft nicht, ein normaler Neustart scheitert, weil er beim Herunterfahren hängen bleibt. In der Ereignisanzeige sind vor einem Unterbruch keine Fehler zu sehen. Es lässt sich auch nicht eruieren, dass die Benutzer etwas Spezielles gemacht hätten. Wenn der Unterbruch passiert, wird nur eine Meldung vom Typ "Information" erzeugt: Quelle "Hyper-V-Netvsc", ID 10, Text "Die Miniport-NIC 'Microsoft Hyper-V Network Adapter" wurde unterbrochen. Die betroffenen Server waren bis jetzt ausnahmslos Terminalserver und haben Benutzerprofildisks über FSlogix eingebunden. Bei den VMs mit anderen Rollen ist das Problem noch nie aufgetreten. Ich habe im Internet ein paar Meldungen zu Netzwerkproblemen bei Azure-VMs mit FSlogix gefunden, aber leider keine Lösung. Das Problem scheint schon mehrere Jahre zu bestehen, aber es wird nur unter seltenen Umständen auftreten, sonst wäre es längst behoben. Kennt jemand eine Lösung?

Der Extremfall waren 273 zugeteilte vCPUs auf einem Host mit 32 Cores. Das ergibt eine Überbuchung von 8.5:1 bzw. 4.3:1, wenn man HT einberechnet (was ja bekanntlich nicht "voll" zählt). Auf diesen VMs konnte man zeitweise kaum arbeiten, obwohl die Auslastung weder in den VMs noch auf dem Host über 20 % war. Die "CPU Wait Time Per Dispatch" war extrem hoch (habe mir den Wert leider nicht notiert). Als man die zugeteilten vCPUs massiv reduziert hat (zwei für DCs, einen pro zwei bis vier Benutzer auf den Terminalservern etc.), war das System erheblich schneller. Wobei zu erwähnen ist, dass der Host auf Windows Server 2016 lief, bei dessen Scheduler immer alle vCPUs einer VM gleichzeitig Ausführungszeit bekommen mussten. Da dauert es halt schon, bis 24 Cores für den TS frei sind, wenn jeder Webserver auch schon 16 Cores hat... Zudem wurde durch das Überschreiten der NUMA-Grenzen Performance verschenkt.

Ich finde die Geräte interessant. Als "Heimserver" habe ich bisher auf Intel NUCs gesetzt. Der MS-01 könnte dank SFP+ und mehreren M.2-Slots ein guter Nachfolger sein. Als Hypervisor für Kunden würde ich ihn nicht einsetzen. Da fehlen mir das redundante Netzteil, Hot-Swap der SSDs, ein bewährter RAID-Controller... Und wer liefert zeitnah Ersatzteile? Horizontal zu skalieren und einen Cluster zu bauen, ist eine Möglichkeit. Der kurze Unterbruch (Neustart) der VMs bei einem Ausfall würden die Kunden wahrscheinlich akzeptieren. Das Gerät fällt hoffentlich nicht jeden Monat aus. Aber welcher kleinere Kunde bezahlt Dir die Windows-Lizenzen für einen Clusterbetrieb? Und Dir die Mehrarbeit für die Updates? Es gibt Beispiele, wie Unternehmen "Billighardware" erfolgreich professionell einsetzen. Backblaze verwendet normale SATA-Disks und die ganzen Anbieter von "Root-Servern" bauen ihre Kisten selbst zusammen. Das geht aber nur, wenn man genug gross ist, um selbst für Ersatzteile zu sorgen, also immer genügend Ersatzgeräte an Lager zu halten.

Wie Du inzwischen selbst nachgelesen hast, kann der Hyper-V mittlerweile die vCPUs nacheinander "ausführen". Jede vCPU ist ein eigener Thread. Leider halten sich die (öffentlich zugänglichen) Informationen über den Scheduler in Grenzen, so dass ich nicht weiss, wann genau das eingeführt wurde. Das "Problem" bleibt, dass die VM nicht weiss, was der Hyper-V macht. Je nach Anwendung läuft eine Berechnung auf zwei Threads, die das Gastbetriebssystem auf zwei vCPUs verteilt und weil der eine Thread auf das Resultat des anderen angewiesen ist, dauert die Berechnung länger, als wenn sie nacheinander auf einer vCPU ausgeführt worden wäre. Wobei das in den meisten Fällen eher theoretische Überlegungen sind. Bei massiver CPU-Überbuchung habe ich schon Probleme in der Praxis gesehen. Terminalserver waren so langsam, dass sogar Eingaben verzögert erschienen sind. Dabei hat der Task Manager nur wenige Prozent Auslastung angezeigt. In der Panik wurden denn noch mehr vCPUs zugeteilt...

Bei den vCPUs gilt "so wenig wie möglich, so viel wie nötig". Ich konnte mich aber nie dazu durchringen, eine VM mit nur einem Core zu betreiben. Wenn die Maus während Windows Updates ruckelt, bekommt man ein ungutes Gefühl. Zudem platziert der Core-Scheduler, der seit Server 2019 standardmässig aktiv ist, keine vCPUs unterschiedlicher VMs auf dem gleichen Core. Dies zur Verhinderung von Spekulations-Angriffen. Deshalb wohl auch die Empfehlung, immer eine gerade Zahl zu verwenden. DCs bekommen bei mir deshalb zwei vCPUs. Zwar müssen nicht mehr alle vCPUs gleichzeitig laufen, aber der Scheduling-Overhead wächst mit deren Anzahl. Zudem stösst man irgendwann an die NUMA-Grenze. Ist man zu grosszügig, überschreitet man je nach Umgebung die Empfehlungen zum Overcommit. Da schreibt Microsoft von 4:1 als empfohlen und bis 8:1 unterstützt, wobei das natürlich keine fixe Grenze ist. Bei Kunden habe ich mehrmals gesehen, dass jede VM so viele vCPUs hatte wie der Host Cores. Das ist gut gemeint, aber kontraproduktiv. Man sollte keine Angst vor CPU-Auslastung haben, schliesslich soll die CPU arbeiten. Wenn ein Datenbankserver im Tagesmaximum zu 80 % ausgelastet ist, ist das gut und kein Warnsignal für "der braucht viermal mehr Cores".

Das wusste ich noch nicht. Ich bin davon ausgegangen, dass Veeam nur auf denselben Hypervisor restoren kann. So ist es noch einfacher und geht ohne Umweg über Agents in den VMs. Habe eine kurze Demo gefunden:

Mit Starwind habe ich schon viele Migrationen erfolgreich erledigt. Aber V2V ist nichts, was man im Stress nach einem Hardwareausfall machen will. Jedenfalls nicht, wenn man es sauber machen will: VMware Tools vorgängig deinstallieren, nicht mehr vorhandene virtuelle Hardware entfernen etc. Die IP-Adressen muss man neu setzen und es gibt Software, die danach eine neue Aktivierung über die Hotline des Herstellers verlangt. Falls es nur wenige VMs sind und das Szenario sich nicht ändern lässt, würde ich eher noch in jeder VM den Veeam Agent installieren und aus dem laufenden OS heraus sichern. Solche Sicherungen sollten sich auch auf Hyper-V wiederherstellen lassen. Dann sparst Du Dir die Konvertierung.