HP Microserver Gen8 + WD RED 3TB Problem

[ichweissesnicht]

hey,

ich hab ein HP Gen8 MS mit aktueller Firmware, mit einer Hitachi 320GB Festplatte in Slot 1 und einer WD RED 3TB in Slot 2. Die Platten laufen im AHCI Mode.

Installiert ist die aktuelle HP Version von ESXI 6.0. https://my.vmware.com/web/vmware/detail ... ductId=491

Ich habe nun folgendes Problem: Ich kann die WD RED problemlos als Storage hinzufügen und wird mir auch korrekt angezeigt. Ich kann ebenfalls eine VM erstellen und dieser die gesamten 2,7 TB der Platte zuordnen. Allerdings ist es dann nicht möglich Ubuntu Server 16.04 auf dieser VM zu installieren.

Entweder bleibt er hängen wenn es darum geht die Festplatten auszuwählen auf der das System installiert werden soll oder ich kann die Festplatten auswählen bekomme aber ein Lesefehler/Schreibfehler im Anschluss.

Das gleiche passiert auch wenn ich dem System z.B. nur 200GB zuteile.

Die WD Red ist neu, somit ist ein hardware defekt ausgeschlossen.

Installiere ich Ubuntu allerdings auf der alten 320 Hitachi Platte, funktioniert das ganze ohne Probleme.

Vielen Dank für die Hilfe!

[~thc]

Laut heise.de ist die WD eine Platte mit 4K-Sektoren (mit Emulation (512e)).

Das wird von ESXi nicht unterstützt:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2091600

[ichweissesnicht]

danke für den Hinweis.

wenn ich die mit einer anderen 3TB platte in einen RAID packe, funktioniert es dann?

Welche Platten kann ich benutzen?

vielen Dank.

[~thc]

Benutze einfach Platten mit 512 Byte Sektoren.

Ein RAID würde nur etwas an einem echten RAID-Controller nützen, dessen eigene Logik die 4K-Sektoren vor ESXi "versteckt".

[JustMe]

Hm, ja, "not supported" heisst nicht automatisch "geht nicht"...

Grundsaetzlich gehen die 512e-Platten schon, aber man muss mit Performance-Problemen rechnen, weil (noch) nicht alle Operationen des ESXi auf 4K "aligned" sind.

Ich vermute hier eher mal, dass der ESXi mit der GPT auf der Platte nicht zurecht kommt.

Kannst Du die VM, die auf der 320er erstellt wurde, auf die WD kopieren?
Lassen sich dort ueberhaupt "groessere" Dateien hinkopieren?
Kannst Du rein testhalber die WD mal mit einem MBR versehen (dann werden aber selbstverstaendlich nur noch 2TB verwendet), und es dann erneut probieren?

Ich kenne die HP jetzt nicht so genau, aber ich vermute mal, dass der Chipsatz-Controller in RAID-Konfiguration vom ESXi sowieso nicht unterstuetzt wird.

[ichweissesnicht]

der Microserver hat ja einen echten Raid oder ist das keiner?

HPE
Dynamic Smart Array B120i Controller

http://www8.hp.com/h20195/v2/GetPDF.aspx/c04123182.pdf

ich kann das nachher mal mit MBR testen, wäre es da möglich 2 Datastore Platten einzufügen oder geht dann wirklich nur die 2TB?

Kopieren geht leider auch nicht, da stürzt er ab.

[ichweissesnicht]

als alternative könnte ich noch den SAS/SATA PCI-Express Card IBM M1015 als Raid Controller verbauen, der wird laut google auch öfters verwendent, allerdings wenn es mit dem internen gehen würde, wäre mir das lieber

[PBecker]

Haben wir auch im Microserver Gen8.
Das einzige Problem ist, dass der aktuelle Treiber einen Schlag hat und man downgraden muss.

Siehe auch http://h20564.www2.hpe.com/hpsc/doc/pub ... =c05026755

[JustMe]

Tja, wenn man HPE fragt, ist das ganz sicher ein "echter" RAID-Controller. Leider einer mit einer aeusserst eingeschraenkten Treiber-Unterstuetzung (Windows ). Deshalb werden die auch gerne als FakeRAID-Controller bezeichnet. Auf der VMware-Compatibility List taucht er jedenfalls nicht auf.

Der M1015 dagegen vermutlich schon (wenn's ein weiterer verkappter LSI-Controller ist).

Nein, man kann nicht mehr als eine (i.W.: EINE) vmfs-Partition (aka Datastore) auf einer einzelnen LUN haben.

Die 2TB-Begrenzung ruehrt vom MBR her; damit koennen nur die ersten 2TB der Platte adressiert werden (OK: mit mehr als einer Partition wuerde auch bei MBR mehr gehen, aber einer so partitionierten Platte wuerde ICH meine Daten bei real existierenden Betriebssystemen nicht anvertrauen).

[ichweissesnicht]

hey,

erstmal vielen dank für die Zahlreichen antworten. Das mit der MBR ist mir bekannt das dann Partiotionen von max 2TB möglich sind

ok, dann muss ich mal schauen wie ich das Regel. Dann bleibt wohl nur der Raid Controller oder ist schon abzusehen wann VMWare 4K Sektoren unterstützt?

[PBecker]

Nochmal meine Antwort, falls du es überlesen hast:

Keine Probleme mit der 3TB Red. Haben wir auch im Microserver Gen8.
Das einzige Problem ist, dass der aktuelle Treiber einen Schlag hat und man downgraden muss.

Siehe auch http://h20564.www2.hpe.com/hpsc/doc/pub ... =c05026755

[ichweissesnicht]

hey,

oh sorry, dachte das bezog sich auf den Raid Treiber.

wenn ich den Treiber downgrade müsste es auch mit GPT klappen?

[PBecker]

hey,

oh sorry, dachte das bezog sich auf den Raid Treiber.

wenn ich den Treiber downgrade müsste es auch mit GPT klappen?

Kann ich dir nicht sagen. Wir booten den Gen8 von USB und haben ein Raid1 als Datastore auf 2 RED. Der vermurkste Treiber sorgt auf jeden Fall für unterirdische Performance und Abbrüche.

[ichweissesnicht]

aber ihr benutzt den internen raid controller oder hast du zusätzllich einen verbaut?

[continuum]

Ich vermute hier eher mal, dass der ESXi mit der GPT auf der Platte nicht zurecht kommt.

Das denke ich eher nicht - für eine 2700 GB Platte würde der ESXi selber auf jeden Fall einen GPT-table anlegen.

Mann kann übrigens mehr als ein VMFS-volume pro Platte/LUN anlegen - im Prinzip soviele wie man will - nur muss man alle Volumes nachdem ersten von Hand erstellen - per partedUtil und vmkfstools.
Es wird aber strikt davon abgeraten mehr als eines zu verwenden - weil der ESXi nur mit einem Volume per LUN rechnet.

Ein paar Fragen zur VM:
wird EFI oder normale Firmware verwendet ?
Verstehe ich das richtig dass die Ubuntu VM eine 2700 GB VMDK bekommt ?

Der Ubuntu1604-Installer verwendet bei einer 2700 GB VMDK auf jeden Fall GPT - ob mit EFI-firmware oder nicht.

[PBecker]

aber ihr benutzt den internen raid controller oder hast du zusätzllich einen verbaut?

Den internen B120i.

[ichweissesnicht]

ich hab ubunutu auch mal mit einer 200 GB Platte probiert aufzusetzen, allerdings mit dem gleichen Ergebnis.

Aber wenn es bei PBecker mit dem downgrade vom Treiber funktioniert, dürfte das bei mir ja auch klappen.

Was genau meinst du mit EFI bzw. normale Firmware? Gibt es da eine Option beim erstellen der VMWare?

[JustMe]

"...beim Erstellen der VMWare..."
Da rollen sich ja saemtliche Fussnaegel
"VMware" ist der Name einer Firma, eines Unternehmens.
Von denen gibt es ein Produkt namens "vSphere/ESXi".
Das, was man damit betreiben (und dazu auch erstellen) kann, nennt sich "Virtuelle Maschine (VM)".
In den Eigenschaften einer solchen VM laesst sich auch einstellen, ob man ein BIOS oder EFI verwenden moechte (haengt ggfs. auch von dem gewaehlten Gast-OS ab).

Wegen des Controllers solltest Du mal schauen, welcher Treiber denn ueberhaupt verwendet wird (esxcli storage core adapter list). Wenn (z.B. wegen der AHCI-Einstellung) ueberhaupt nicht der hpvsa-Treiber verwendet werden sollte, dann laufen die Vorschlaege von PBecker (bzw. dem verlinkten HP-Beitrag) in's Leere.

Auf jeden Fall aber laesst dieser Artikel den Schluss zu, dass einem ein HP-Support-Mitarbeiter die richtigen Einstellungen nennen koennen sollte. Warum VMware's HCL den B120 nicht listet, steht dann auf einem ganz anderen Blatt. Vielleicht muss man da kreativ ein paar Leerzeichen einstreuen, oder so...
Ein lspci -vv wuerde auf jeden Fall auch noch ein paar IDs liefern, mit denen man die HCL drangsalieren koennte.

Ansonsten, @continuum:
Ist schon klar, dass man sich problemlos ungueltige (oder zumindest fragwuerdige) GPTs zusammenstellen kann. Aber wie Du schon selbst schriebst: Sinn macht das im Allgemeinen nicht.
Und im Prinzip gibst Du mir ja damit eigentlich auch recht: Es gibt nicht "die eine richtige" GPT fuer einen bestimmten Datentraeger, sondern das was "einer" da drauf geschrieben hat, muss z.B. von ESXi noch lange nicht richtig interpretiert (und fortgeschrieben) werden. Das ist bei MBR (insbesondere wenn nur mit primaeren Partitions gearbeitet wird) sehr viel eindeutiger.

[continuum]

Es gibt nicht "die eine richtige" GPT fuer einen bestimmten Datentraeger, sondern das was "einer" da drauf geschrieben hat, muss z.B. von ESXi noch lange nicht richtig interpretiert (und fortgeschrieben) werden. Das ist bei MBR (insbesondere wenn nur mit primaeren Partitions gearbeitet wird) sehr viel eindeutiger.

GPT ist eindeutig die bessere Konstruktion.
Eine GPT-tabelle ist eindeutig oder invalid. Bei DOS-partitionstabellen war das lange nicht so streng formuliert.
Wenn man mit partedUtils und vmkfstools eine 2te VMFS-partition anlegt dann ist auch diese ganz klar definiert und benutzbar.
Das Problem entsteht erst durch die vSphere-Oberflächen. Diese sind alle so ausgelegt dass nur eine VMFS-partition angelegt wird pro disk/LUN.
Dieses ist aber in keiner Weise zwingend. Der ESXi-teil der unter der Oberfläche arbeitet, hat keine Probleme mit 5 VMFS-volumes pro LUN.
Die GUI-tools suchen aber nur nach der ersten und können evtl vorhandene weitere Volumes nicht sinnvoll darstellen.

... es gibt keine eine richtige GPT ....

Doch - der allgemein akzeptierte Standard erwartet folgendes:

1. Festplatten kleiner als 2TB:
MBR oder GPT ist erlaubt.
Falls GPT verwendet wird sollen die Betriebssysteme bitte die Tabelle so angelegt werden, dass auch ein ProtectiveMBR mit angelegt wird.
Dieser sorgt dann dafür dass der GPT nicht von veralteten Tools vermurkst wird.

2. Festplatten grösser als 2TB
GPT zwingend erforderlich - ansonsten verschwendet man wegen der Addressbereich-Limitierung von 2TB bei DOS-tables den kompletten Diskplatz jenseits 2TB.

GPT ist sicherer, denn es wird von allen brauchbaren Tools eine GPT-backupkopie am Ende der Platte angelegt.
GPT macht ausserdem Schluss mit dem Murks von prim. und erweiterten Partitionen.
Ein GPT-table kann daher viel mehr Partitionen enthalten als ein DOS-table.


Der Ubuntu-installer hält sich daran: eine 2700 Gb VMDK bekommt eine GPT-tabelle.
Der ESXi oder Windows-10 Installer machen dass genauso.

[Dayworker]

2. Festplatten grösser als 2TB
GPT zwingend erforderlich - ansonsten verschwendet man wegen der Addressbereich-Limitierung von 2TB bei DOS-tables den kompletten Diskplatz jenseits 2TB.

Unter Linux ist GPT nicht zwingend erforderlich, solange die Platte 4TB (die Grösse könnte dem damaligen Umstand geschuldet sein, daß es keine grösseren HDDs gab) nicht überschreitet. Linux ist im Gegensatz zu Windows in der Lage, auch den Bereich über 2 TB per MBR anzusprechen, wenn man es entsprechend zu 2TB für Windows plus 2TB für Linux partitioniert. Das klappt aber wirklich nur dann, wenn Linux als zweites System auf demselben Datenträger installiert wird und man den Linux-Bootmanager nutzt. Unter Windows klappt dieser Trick nicht. Er wurde aber in der Anfangszeit von Platten über 2TB häufiger eingesetzt, damit man die Unfähigkeit einiger Windows-Versionen, als Bootmedium mit 4KB-Sektorgrösse umgehen zu können, umschiffen und trotz 512Byte Sektorgrösse die HDD vollständig nutzen konnte. Von Asus oder war es WD gab es sogar eine Windows-SW, die über einen Treiber nichts anderes machte, als den Bereich über 2TB als weiteres Laufwerk einzublenden. Dieser Bereich war dann wirklich nur über diesen Treiber ansprechbar, wenn man keinen Datensalat riskieren wollte.

[JustMe]

Wie oben schon mal (wenn auch teilweise widersprochen) nebenbei erwaehnt, ergeben sich die 4TB daraus, dass im MBR der Startblock und Groesse in Bloecken fuer eine Partition hinterlegt ist. Da in den jeweils 4 Bytes nur Platz zur Adressierung von eben 2^32 Bloecken ist, ergibt sich eine maximale Partitiongroesse von 2TB bei 512Byte Blockgroesse, und wenn man den Startblock der zweiten Partition ganz am Ende des adressierbaren Bereiches liegen laesst, dann reicht diese zweite Partition eben bis kurz vor 4TB.

Wer immer seine Daten einer so partitionierten Platte unter Windows (oder plattennahen Tools unter Linux et.al.) anvertraute, bezahlte diesen Leichtsinn eher frueher als spaeter mit einem Totalverlust derselben. Ich denke, das DIES eher der Grund dafuer war, den Bloedsinn zu lassen, zumal ja, wie voellig korrekt erwaehnt, die funktionsfaehige Alternative namens GPT nur noch der (vollstaendigen) Implementierung durch M$ (und einige BIOS-Implementierer) harrte, und zu viele "Anwender" die Welt bevoelkern, die den Standpunkt kultivieren "Ich weiss nicht was ich tue; aber ich will, dass es funktioniert". /Misanthrop off

[ichweissesnicht]

hey,

hat geklappt mit RAID 1 und dem alten Treiber. Läuft jetzt problemlos