Umzug von 6.7 nach 7.02 - nur kleine VMs möglich

[pcbastler]

Hallo zusammen,
aktuell läuft bei mir ein Dell T20 mit LSI2018er Controller mit ESXI 6.7 sehr zuverlässig. Jetzt möchte ich langfristig auf ESXi7 umsteigen und habe mit daher einen Dell T30 mit Perc H330 zugelegt. Beim Kopieren der VMs mittels scp (ssh auf dem T20, scp *.* root@neueIP:vmfs/volumes/Daten/meineVM/) gibt es eine kleine Auffälligkeit.
VMs mit kleinen Platten (<250GB) lassen sich problemlos kopieren, bei VMs mit 500GB HDD meldet sich der T30 komplett vom Netzwerk ab und friert ein (Bedienung über Tastatur auch nicht mehr möglich, Bildschirm zeigt aber noch den VMWare-Bildschirm). Eine separate Netzwerkkarte brauchte keine Besserung.
Auch der Import einer OVA mit 500GB HDD bricht mit identischem Fehler ab.
Als letzten Ausweg hab ich dann 6.7 auf dem T30 installiert, damit läuft das Kopieren perfekt durch. Nun stelle ich mir natürlich die Frage: Update oder nicht?
Kennt das jemand und eine Idee?
Vielen Dank im Voraus für alle hilfreichen Tips!

[~thc]

Die "kleinen" Dell-Server sind hier im Forum ja des öfteren Thema - daher habe ich beim Suchen erfahren, dass der T30 praktisch identisch mit dem offiziell auf der VMWare HCL stehenden T130 ist und auch genau so gut läuft.

Der T130 wiederum ist aber nur bis maximal 6.7 von VMWare freigegeben. Ich würde ihn also mit 6.7 betreiben.

Generell hilft es, sich ESXi als eine Art "Firmware" für eine Auswahl spezieller Hardware vorzustellen und nicht als "normales" OS, das man dann mal auf den letzten Stand bringt.

[Dayworker]

Mit jeder neuen ESXi-Version hat sich immer auch die unterstützte Alt-HW verringert. Einfach mal einen Server zu kaufen und dann darauf zu hoffen, daß dieser auch noch unter vSphere7 mitspielt, kann sich daher als kompletter Fehlschlag erweisen.
Mein H200 unterscheidet sich von deinem H330 nur in 2 Dingen, sein Flash ist etwas grösser und die Queue ist länger, ansonsten beruhen beide auf demselben uralten LSI/SAS2008-Chip. Mit vSphere7 hat sich VMware vom alten Treibermodell verabschiedet und unterstützt nur noch nativ Driver. Mangels entsprechender Treiber fallen damit alle SAS2008-Chipsätze von LSI/Broadcome raus. Dein Gedanke mit dem T130 und H330 ist bei normaler Config also ein Showstopper unter vSphere7. Einzigste Möglichkeit wäre, den Controller auf IT-Firmware umzuflashen und diesen an eine VM per PCI-Passthru als PCI-Gerät durchzureichen. Dann könnte man den darin verwalteten Speicherplatz als Storage-as-a-Service wieder an den ESXi per NFS (iSCSI geht auch, ist dann aber nicht so problemlos lauffähig wie NFS) zurückreichen. Das ist aber eine zusätzliche Ebene dazwischen, die nicht jeder haben will...

Von der Warte ist "~thc" nur zuzustimmen und solltest dich auf 6.7 beschränken. Alternativ käme der Kauf eines PE-T140 in Betracht. Damit ist vSphere7 offiziell freigegeben.

[pcbastler]

Hier muss ich leider widersprechen der Perc H330 basiert auf dem LSI 3008 und läuft unter 7.0 sofort mit dem lsi_mr3 Treiber (siehe auch https://www.vmware.com/resources/compat ... ctid=38057). Das konfigurierte RAID5 steht auch unter 7.0 mit voller Kapazität zur Verfügung. "Kleine" VMs lassen sich kopieren und starten auf der neuen Hardware ohne Probleme. Solange keine großen Kopieraktionen stattfinden läuft die Maschine ohne Auffälligkeiten.

[Dayworker]

Danke für den Hinweis zum H330 hinsichtlich LSI/SAS3008, war mir irgendwie wieder mal entfallen. Das ändert leider am Ende nicht sehr viel, weil weder der H200 noch der H330 als Einstieg-HW-Controller einen Schreib-Cache mitbringen. Das der H330 sogar Raid5 unterstützt, ist ja schön und ergibt einen Haken mehr in der Feature-Liste gegenüber dem älteren H200, aber ohne Schreib-Cache bricht die Schreibperformance trotzdem komplett zusammen. Du mußt auch keine Kopieraktionen auf dem Host starten, es reicht wenn eine VM ganz normal ihre Arbeit macht und ihre zahlreichen Log-Dateien befüllt. Bei mehreren laufenden VMs wird die Lage also immer nerviger, weil das Gast-OS nur stockend reagiert, bis die IO-Transaktion abgeschlossen ist...
Du hast in meinen Augen zwei Möglichkeiten, das zu ändern. Entweder den Plattencache hinterrücks wieder reaktivieren und den H330 als HW-Controller ohne ECC-gesicherten Write-Cache sowie ohne BBU zu betreiben oder du flashst den H330 zum HBA, reichst diesen per Passthru in eine VM durch und das Gast-OS sorgt mit seinem Dateisystem-Cache für mehr Performance. Alternativ kannst du auch einen höherwertigen Controller mit Write-Cache und BBU zum entsprechenden Preispunkt erwerben. Das bei Raid-Einsatz automatisch auch eine USV vorhanden ist, setze ich dabei mal voraus.

[pcbastler]

Meine endgültige Konfiguration sollte so aussehen: VMs auf einer SSD (die liegt aber noch beim Händler) am normalen SATA-Anschluss, auf dem RAID liegen dann nur die (in die VM eingebundenen) Datenplatten (da herscht zu 95% Lesebetrieb) und das Backup (per rsync also auch nicht die Masse), daher könnte ich mit der mangelhaften Performance (ca. 40MB/s) gut leben.
Das erklärt allerdings das Ausgangsproblem nicht wirklich Alternativ könnte ich jetzt den Migrationsprozess auf eine einzelne HDD am SATA starten und dann lokal die VMDKs kopieren. ist zwar nochmal Aufwand, aber das Ergebnis wäre interessant.

Kurz zum Hintergrund warum ich zu Hause überhaupt ESX verwende; Ich hab etwas Uralt-Software, dafür werkelt noch ein WinXP, dazu eine VM fürs Smarthome (debian), ein Webserver für Nextcloud und eine VM als Backup-NAS. Daher ist maximale Performance nicht unbedingt das Hauptkriterium.
Blöd wäre allerdings, wenn das 7.0 beim Kopieren großer Datenmengen (z.B. Plattenimage meines PC) auf eine VM genauso stehenbleibt wie beim Kopieren per scp.

[Dayworker]

Keine Ahnung wie es inzwischen bei SSDs aussieht, aber eigentlich will der ESXi kein SATA sondern eher SAS haben oder man setzt dem ESXi einen Raidcontroller vor. Dann fallen sämtliche Datenträgerverwaltungsaufgaben an diesen. Bei Desktop-SSDs kommt noch hinzu, daß ihre unstete Schreib-Varianz für wenig Freude sorgt und der ESXi meines Wissens bisher im Gegensatz zu TRIM keinen Idle-Mode kennt. Damit gibt es für eine SSD eher keinerlei Erholung sondern dauerhafte Schreib-IOs und damit muß man für ausreichende Kühlung der SSD sorgen. SSD-technisch wirst du um eine USV auch eher nicht herumkommen, selbst wenn deine SSD hoffentlich eine Powerless-Protection mitbringt. Das Problem ist, daß du ein Gast-Dateisystem (NTFS) in einem Datastore mit einem anderen Host-Dateisystem (VMFS) liegen hast. Ein Dateisystemfehler auf dem ESXi kann dann für weiteren Ärger in den Gästen sorgen.

Warum du den ESXi verwendest, spielt keine Rolle, solange du nicht MacOS auf Wintel-HW ausführen willst. Letzteres kollidiert mit Apple und auch im offfiziellen VMTN werden derartige Thread direkt geschlossen.

Auch wenn es dir nicht auf maximale Performance ankommt, fürfte dein Problem der Einstieg-HW-Controller sein. Bis der ohne Schreib-Cache reihum seine Daten ins Raid5 weggeschrieben hat, dauert es vermutlich einfach zu lange. Was für Platten hast du denn eigentlich genau im Einsatz, hoffentlich solche mit CMR und nicht die für den Raid-Einsatz untauglichen SMR-Versionen. Die wurden auch bei vielen NAS-Anbietern inzwischen als untauglich markiert.

[pcbastler]

Plattten sind WD Red plus (also CMR) eine APC-USV hängt dran und die VMs werden bei Stromausfall über Script runtergefahren (wobei das seit 1,5 Jahen nicht mehr sein müsste, die USV muss nur noch die 30s überbrücken bis die PV in den Inselbetrieb geht). Als Bootmedium werkelt im T20 eine WD green-SSD. Single-SSD am SATA sind für ESXi kein Problem (daher das Backup auf HDD), nur RAID sollte man damit nicht fahren (insbesondere RAID 5/6 schrotten SSDs durch die permanenten Schreibzugriffe quasi schon nach Tagen).
PS: Das aktuelle System läuft ohne Probleme seit 5 Jahren, der Umzug sollte nur wegen EOL des 6.7 stattfinden.

[Dayworker]

Zumindest bis 2023-11-15 läuft noch die Technische Unterstützung vom 6.7er. Danke übrigens für's Anschieben, damit ich mir https://lifecycle.vmware.com mal wieder anschaue. Mein 6.5er wird jetzt doch wieder mit denselben Zeiträume wie der 6.7er aufgeführt...

Wenn die Platten jetzt schon gute 5 Jahre im Raidbetrieb dauerlaufen, würde ich mir um ESXi-Supportzeiträume eher weniger Sorgen machen und mir mal die von den RED-plus gemeldeten Laufzeiten und Fehlerwerte per SMART anschauen. Die RED-plus haben zumindest als Retail eigentlich 5 Jahre Garantie, laufen aber natürlich auch deutlich länger ohne Probleme. Falls der gemeldete Wert für "Reallocated Sector Count" inzwischen grösser Null sein sollte, würde ich die Platten in diesem Fall mit dem WD-Festplattentool überprüfen, eventuell Lowlevel-Formatieren (falls der Controller vorschnell einen Fehler moniert hatte) und dann ggf die Platte(n) austauschen.

[pcbastler]

Genau wegen des Alters wollte ich auf ein komplett neues System setzen und den Umzug stressfrei langfristig realisieren. Jetzt kann ich einige VMs nicht auf den 7.0 kopieren weil da irgendetwas nicht funktioniert Ist das jetzt ein Limit des 7.0 oder muss ich wirklich zertifizierte Hardware erwerben?

[Dayworker]

Dein Problem dürfte mit grosser Sicherheit der fehlende Write-Cache sein. Der ESXi kennt nur sein VMFS-Dateisystem und sonst garnix. Da er keine weiteren Dateisysteme kennt und daher sein Caching auch komplett kontraproduktiv sein könnte, bringt er keinerlei Dateisystem-Cache mit und überläßt alles einem performanten Datenträgersystem.


[edit]
Hattest du das VMFS unter 6.7 eigentlich neu aufgesetzt oder hattest du das noch vom 5.5er weitergeführt?
Weil das VMFS hat sich ja stetig weiterentwickelt und könnte noch Altlasten mitschleppen.

[pcbastler]

Der T20 (Altsystem) ist mit 6.5 aufgesetzt und auf 6.7 hochgezogen. Der T30 wurde mit 7.0 aufgesetzt und aus Mangel an Alternativen dann mit 6.7 neu installiert. Da mit 6.7 auf dem T30 alles reibungslos funktioniert würde ich ein Hardwareproblem wirklich ausschließen.

[Dayworker]

Der 7er schreibt aber anscheinend deutlich mehr, wie alle vorherigen Versionen. Daher sind die früher häufig eingesetzten USB-Sticks inzwischen keine stabile Grundlage mehr.
Das könnte deine Beobachtung erklären.

[pcbastler]

Beide System booten von einer SSD, USB-Sticks sind nicht im Einsatz. Der Fehler tritt beim Kopieren vom HDD-RAID-Datastore des T20 (ESXi 6.7) auf den (ebenfalls HDD-RAID-basierten) Datastore des T30 auf (allerdings nur unter 7.0). Selbst eine komplette Auslastung des RAID beim Schreiben dürfte das Abschalten des Netzwerkes nicht erlären.

[Dayworker]

Ich hatte dir mit dem USB-Stick nur verdeutlichen wollen, daß der 7er deutlich mehr darauf schreibt als ältere Versionen. Das kann muß aber nichts bedeuten, ist jedoch ein Indikator.
Auf der anderen Seite ist der T30 nicht offiziell für den 7er freigegeben und wir können jetzt noch tagelang darüber lamentieren. Das eine HW nicht offiziell supportet wird, kann aber auch wiederum nichts bedeuten. Denn der Eintrag in die HCL kostet sicherlich nicht wenig Geld und das wird bei älterer HW kein Hersteller für eine Zertifizierung bezahlen wollen. Schau dich dazu in der VMware-HCL um, ob andere Hersteller für die beim T30 verbaute HW auch Support für den 7er anbieten. Aus eigener Erfahrung mit meinem Server in der Sig kann ich dir sagen, daß dieser von Dell offiziell nur bis 5.5 unterstützt wird und mit der gleichen CPU+Chipsatz dagegen bei HP/HPE auch mit 6.5 gelistet ist.

Da VMware bei seinen letzten Updates weniger Glück hatte und nach offensichtlichen Bugs sogar viele Updates zurückgezogen wurden, könnte eine ältere 7er Version vielleicht problemlos laufen. Falls es wirklich nur die Netzwerkkarte ist, aktuelle Logs zum Zeitpunkt des Kopierens liegen bisher nicht vor, würde eine schnellere Testmöglichkeit in einer zusätzlichen NIC bestehen.

[pcbastler]

Zusätzliche NIC habe ich schon probiert: gleiches Ergebnis. installiert habe ich VMware-VMvisor-Installer-7.0U2a-17867351.x86_64.iso (und später die beiden Updates). Da die Maschine nur noch durch ein Hard-Reset wiederbelebt werden kann, ist die Beschaffung von passenden Logfiles eher schwierig
PS: Auf jeden Fall ein dickes DANKE für deinen Einsatz!

Edit: ich hab jetzt den 6.7 auf 7.0.2 aktualisiert und eine einzelne Platte am onBoard-SATA für den Transfer eingebaut.
Einzige Auffälligkeit im Kernel-Log:

Code: Alles auswählen

2022-01-11T17:45:59.859Z cpu3:524725)ScsiDeviceIO: 4298: Cmd(0x4558c11c62c0) 0x1a, CmdSN 0x119e from world 0 to dev "naa.62cea7f074ebfd0029673031064a968d" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0

weiterhin fiel mir auf:
Während des scp-Transfers kommt das Pärchen ekeyed outbound cipher/rekeyed inbound cipher unter 6.7 alle 64GB, unter 7.0 alle 1GB

[Dayworker]

Lade dir mal die GA vom 7er herunter und probiere damit. Falls es damit dieselben Probleme gibt, mag der 7er wirklich irgendetwas an der HW nicht.
Das könnte unter Umständen auch in weiterer Grund für den fehlenden Eintrag in der HCL sein...

[~thc]

Während des scp-Transfers kommt das Pärchen ekeyed outbound cipher/rekeyed inbound cipher unter 6.7 alle 64GB, unter 7.0 alle 1GB

Das ist mir auch schon so aufgefallen - da wurde am SSH-Protokoll gedreht.

[pcbastler]

jetzt wird es spannend, ich habe auf dem T30 den 6.7 mit VMware-VMvisor-Installer-7.0.0.update02-18538813.x86_64-DellEMC_Customized-A07.iso aktualisiert und eine einzelne Platte am onBoard-Controller zusätzlich eingebaut. Der Transfer einer VM auf die Platte läuft mit ca. 40MB/s und ist jetzt bei 70% (350 GB). Wenn das erfolgreich durchläuft teste ich das morgen auf das RAID-Volume.
Ich weiss, mehrere Änderungen (Update + HDD) auf einmal sind für die Fehlersuche nicht wirklich hilfreich

Das kopieren über LAN auf die einzelne Platte klappt, das lokale kopieren auf das RAID lässt die Maschine sterben. Fehler eingegrenzt!

[Dayworker]

Mit einer Einzelplatte sollten eigentlich etwas mehr wie 40MB/s drin sein. Paßt aber wiederum sowohl zu den niedrigen, im Web vermeldeten Werten zum H200 als auch meinen eigenen Messungen dazu. Irgendwo hier im Forum müßten dazu die Werte rumfliegen, falls die Verlinkung noch paßt.
Da sich H200 und H330 nur minimal unterscheiden, würde ich schreibtechnisch mangels Schreib-Cache und ohne reaktiverten Platten-Cache im Raid5 nichts grösseres erwarten. Der Durchsatz im Raid5 müßte dann sogar noch niedriger liegen.

[pcbastler]

Ich glaube, die Lösung war so einfach und naheliegend das keiner drauf kommt
Ich hab die HCL noch mal ganz genau gelesen und festgestellt, dass mein Controller eine FW 25.5.6 hat. Also hab ich den angegeben OEM-Treiber (lsi_mr3 version 7.705.10.00-1OEM) installiert und die Kiste läuft Ich mach jetzt noch ein paar Tage Stresstest aber ich habe ein gutes Gefühl
Mist, zu früh gefreut. Bei gleichzeitigen lokalem kopiern und transfer per scp schmiert die Kiste wieder ab

[pcbastler]

ok, die Lösung das RAID als ESXi-Datastore unter 7.0 zu betreiben kann ich wohl begraben
Das Update auf 7.0 möchte ich wegen der unterstützten Client-OS (Debian 11, Win 11) aber irgendwie durchziehen. Wäre der Umweg über eine NAS-VM (OMV, Freenas, ...) mit durchgereichtem Controller und NFS-Freigabe eine sinnvolle Lösung? Platz für die NAS-VM wäre auf der Boot-SSD noch vorhanden.

[~thc]

Sinnvoll? Eher die letzte Möglichkeit. Du umgehst den ESXi-RAID-Treiber und hoffst, dass die restliche Hardware 7.0 kompatibel ist.

Ich betreibe übrigens produktiv einige Debian 11 Server unter ESXi 6.5. Da die Tools ohnehin aus dem Repository von Debian kommen, stört mich die alte Bezeichnung für das "OS" nicht wirklich. Und Windows 11 läuft so auch unter 6.7.

[pcbastler]

da ich ohnehin eine Debian-VM als Datengrab verwende habe ich jetzt mal den Weg des durchgereichten HBA (im BIOS des H330 auf HBA-Modus umgeschalten) beschritten.
Dann eine VM mit OMV6 und ZFS aufgesetzt und die Platten als ZFS-RAID-Pool hinzugefügt
Beim Kopieren der VMs vom alten System liegt die Transferrate bei 90MB/s, das ist schon mal eine andere Hausnummer
Dann wird es wohl jetzt ein Mischbetrieb, das Datengrab darf neben dem Home-Backup auch noch die VMs halten.

[pcbastler]

Leider hat auch das Software-RAID beim massiven Schreiben Fehler gebracht. Glücklicherweise hat der Händler ein Einsehen gehabt und den Controller getauscht. Mit dem neuen läufts jetzts perfekt.