HP Server Storage erweitern, wo ESXi Server drauf liegt
Hallo ITler,
ich habe auf der HP Ebene mein vorhandenes Array erweitert.
Und zwar habe ich die HDDs reingesteckt und über die Konsole vom ESXi erweitert.
Per SSH auf ESXi verbunden.
Verzeichnis gewechselt
mit diesen Befehl habe ich mir die Übersicht angesehen.
mit diesen Befehl habe ich die zwei neuen HDDs dem vorhandenen Logischen Laufwerk hinzugefügt.
Slot=0 = auf welchen Slot der RAID Controller hängt
ld 1 = Logical Drive 1
add drives=2I:6:5,2I:6:6 = hinzufügen von den zweien Disks
Mit folgenden Befehl den Status des Rebuilds geprüft
Als es vollständig fertig war,
habe ich mit dem Befehl das Laufwerk erweitert
Anschließend gewartet, bis am ESXi Server unter Datastore
bei "Kapazität erhöhen" ein Speicher auftaucht.
Beim Versuch zu vergrößern, kam die Fehlermeldung:
Fehler beim Erweitern des VMFS-Datenspeichers ..... Die Hostkonfiguration kann nicht geändert werden.
Jetzt habe ich herausgefunden, das man den Speicher nicht erweitern kann,
wo das ESXi OS liegt.
Jetzt wäre mein weiteres vorgehen folgendes:
Backup erstellen von allen VMs
VMs herunterfahren
ESXi herunterfahren
ESXi über CD/USB neu installieren und denn ESXi auf ein anderes Speichermedium installieren
ESXi hochfahren und IP vergeben (selbe wie vorhin, für die Dokumentation etc.)
die Datastores einhängen
Dann auf "VM Registrieren" klicken und die VMs neu anlegen.
VMs starten
Testen ob alles geht
Hatte von euch schon mal das selbe Problem ?
Findet Ihr denn Ablauf richtig oder habt Ihr eine bessere Idee ?
Lg K
ich habe auf der HP Ebene mein vorhandenes Array erweitert.
Und zwar habe ich die HDDs reingesteckt und über die Konsole vom ESXi erweitert.
Per SSH auf ESXi verbunden.
Verzeichnis gewechselt
cd /opt/smartstorageadmin/ssacli/bin/
mit diesen Befehl habe ich mir die Übersicht angesehen.
./ssacli ctrl all show config
mit diesen Befehl habe ich die zwei neuen HDDs dem vorhandenen Logischen Laufwerk hinzugefügt.
./ssacli ctrl slot=0 ld 1 add drives=2I:6:5,2I:6:6
Slot=0 = auf welchen Slot der RAID Controller hängt
ld 1 = Logical Drive 1
add drives=2I:6:5,2I:6:6 = hinzufügen von den zweien Disks
Mit folgenden Befehl den Status des Rebuilds geprüft
./ssacli ctrl all show config
Als es vollständig fertig war,
habe ich mit dem Befehl das Laufwerk erweitert
./ssacli ctrl slot=0 ld 1 modify size=max forced
Anschließend gewartet, bis am ESXi Server unter Datastore
bei "Kapazität erhöhen" ein Speicher auftaucht.
Beim Versuch zu vergrößern, kam die Fehlermeldung:
Fehler beim Erweitern des VMFS-Datenspeichers ..... Die Hostkonfiguration kann nicht geändert werden.
Jetzt habe ich herausgefunden, das man den Speicher nicht erweitern kann,
wo das ESXi OS liegt.
Jetzt wäre mein weiteres vorgehen folgendes:
Backup erstellen von allen VMs
VMs herunterfahren
ESXi herunterfahren
ESXi über CD/USB neu installieren und denn ESXi auf ein anderes Speichermedium installieren
ESXi hochfahren und IP vergeben (selbe wie vorhin, für die Dokumentation etc.)
die Datastores einhängen
Dann auf "VM Registrieren" klicken und die VMs neu anlegen.
VMs starten
Testen ob alles geht
Hatte von euch schon mal das selbe Problem ?
Findet Ihr denn Ablauf richtig oder habt Ihr eine bessere Idee ?
Lg K
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 482566
Url: https://administrator.de/forum/hp-server-storage-erweitern-wo-esxi-server-drauf-liegt-482566.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
10 Kommentare
Neuester Kommentar
also grundsätzlich geht das schon... es ist nur sehr ungeschickt, ein ESX auf einem Storage für VMs bzw. VMDKs als Bootmedium zu installieren.
Was natürlch (nicht nur als Alternative) geht ist eine Zweitinstallation auf einem USB-Stick zu machen oder über PXE zu booten, halt jedem das Seine aber der zentrale Punkt deines Problems ist ist daß die GUI hinter dem Storage halt freien Speicherplatz erkennt, aber nicht erweitern will.
Auf Dateisystemebene dürfte deine Konfiguration wohl ungefähr so aussehen:
- Bootpartition
- swap
- OS Partition des ESX
- Datenpartition 1
- Datenpartition 2... n
listet man die Partitionen auf, dann dürften die alle auf demsleben Datenträgerliegen
/dev/sda1
/dev/sda2
/dev/sda3
/dev/sda4...
die GUI kann das nur wenn du von /sda bootest und /sdb eine bis viele Daten partitionen enthält. Bei dir dürfte alles auf /dev/sda liegen, die Zahlen dahinter sind nur Kennzeichner der Partionen.
Entweder du kreierst eine weitere Datenpartition und mountst die... dann wird aber der bestehende Storage nicht erweitert oder es ist Handarbeit angesagt.
Wie man genau dabei vorgeht wird hier erklärt:
kb.vmware.com/s/article/2002461
Dafür muß man sich im ESX die SSH shell freischalten, und das per Kommandozeile erledigen. Die Gui spielt da nicht mit...
Was natürlch (nicht nur als Alternative) geht ist eine Zweitinstallation auf einem USB-Stick zu machen oder über PXE zu booten, halt jedem das Seine aber der zentrale Punkt deines Problems ist ist daß die GUI hinter dem Storage halt freien Speicherplatz erkennt, aber nicht erweitern will.
Auf Dateisystemebene dürfte deine Konfiguration wohl ungefähr so aussehen:
- Bootpartition
- swap
- OS Partition des ESX
- Datenpartition 1
- Datenpartition 2... n
listet man die Partitionen auf, dann dürften die alle auf demsleben Datenträgerliegen
/dev/sda1
/dev/sda2
/dev/sda3
/dev/sda4...
die GUI kann das nur wenn du von /sda bootest und /sdb eine bis viele Daten partitionen enthält. Bei dir dürfte alles auf /dev/sda liegen, die Zahlen dahinter sind nur Kennzeichner der Partionen.
Entweder du kreierst eine weitere Datenpartition und mountst die... dann wird aber der bestehende Storage nicht erweitert oder es ist Handarbeit angesagt.
Wie man genau dabei vorgeht wird hier erklärt:
kb.vmware.com/s/article/2002461
Dafür muß man sich im ESX die SSH shell freischalten, und das per Kommandozeile erledigen. Die Gui spielt da nicht mit...
Die Frage ist, was gewinnt man damit? Wenn ich das richtig verstehe, bootet der ESXi z.B. per iSCSI aus dem SAN sein Betriebssystem von einem iSCSI-Volume. Scheinbar liegen in dem Volume auch VMs? Die sind zwar auf dem SAN, aber aus ESXi-Sicht doch auf einem Server-lokalen Volume. Das heißt doch, das mal eben auf einen anderen Host live zu migrieren ist immer mit einer Storage-Migration verbunden. Da kann man das mit dem Storage-System doch auch gleich lassen und in den ESXI lokal Platten oder SSD einbauen...? HA oder gar FT (wenn man die große Lizenz hat) kann man so vergessen.
Besser wäre IMHO das ganze Konstrukt noch mal einzureißen, entweder das ESXi - wenn es denn unbedingt sein muss - aus einem kleinen SAN-Volume (8GB sind nach meiner Erfahrung ausreichend, jedenfalls reichen so kleine USB-Sticks locker) zu booten, oder gleich von einem USB-Stick, und sich das iSCSI-Geboote zu sparen. ESXi macht im Betrieb sowieso nur selten Zugriff auf Betriebssystemdateien, da reicht ein Stick. Und das SAN dafür verwenden, wofür es vorgesehen ist, als Shared-Storage für die VMs, die bei einer Host-Migration nur vom RAM des einen Hosts in das RAM des anderen Hosts kopiert werden.
Oder sieht das jemand anders?
Besser wäre IMHO das ganze Konstrukt noch mal einzureißen, entweder das ESXi - wenn es denn unbedingt sein muss - aus einem kleinen SAN-Volume (8GB sind nach meiner Erfahrung ausreichend, jedenfalls reichen so kleine USB-Sticks locker) zu booten, oder gleich von einem USB-Stick, und sich das iSCSI-Geboote zu sparen. ESXi macht im Betrieb sowieso nur selten Zugriff auf Betriebssystemdateien, da reicht ein Stick. Und das SAN dafür verwenden, wofür es vorgesehen ist, als Shared-Storage für die VMs, die bei einer Host-Migration nur vom RAM des einen Hosts in das RAM des anderen Hosts kopiert werden.
Oder sieht das jemand anders?
Du hast recht, da habe ich irgendwas reingelesen, was nicht ist. Aber auch für deinen Fall gillt, man trennt normalerweise das Boot-Volume von den VMs. Boot meinetwegen von einem RAID 1, da kann dann nichts kaputt gehen, wenn eine Platte versagt, und den Rest auf weiteren Platten, die per RAID 5/6 ggf. mit Hotspare angelegt wurden. Nur sind halt heutige Platten von der Kapazität her viel zu schade, um nur ESXi drauf zu installieren - daher der Vorschlag mit dem USB-Stick.
Was den Defekt des USB-Sticks aneght, den könnte man clonen und sicher verwahren. Wenn man ein SAN und ein VCenter hat, bräuchte man das nicht, dann ist ein auf diesem Wege verloren gegangener ESXi kein Drama, der ist schnell neu aufgesetzt und wieder in den Cluster integriert (oder sogar aus einer Vorlage deployt).
Was den Defekt des USB-Sticks aneght, den könnte man clonen und sicher verwahren. Wenn man ein SAN und ein VCenter hat, bräuchte man das nicht, dann ist ein auf diesem Wege verloren gegangener ESXi kein Drama, der ist schnell neu aufgesetzt und wieder in den Cluster integriert (oder sogar aus einer Vorlage deployt).
den Stick kann man klonen und dann besser schlafen. um einem Datendisaster vorzubeugen würd ich mir mal ne 2 TB SATA Platte holen und ne Komplettsicherung machen bevor du der Partitionstabelle an die Gurgel gehst.
Wenn der Stick kaputt is dann isntallierst du ein neues ESXI auf nem neuen Stick, hängst deine 7 VMs wieder ein (der VMware Client hat eine Option dafür) und kannst locker weiterarbeiten.
Außerdem wäre der Stick sogar ein Notnagel falls deine Bootpartition mal kaputtgeht... Raid hin oder her, eine Platte fällt selten alleine aus, im Raid laufen die alle genau gleaich lang - und Kunden vun uns hatten das schon daß ihr vermeintlich sicheres Raid 5 mitten in einem Rebuild nach dem Tausch einer von 4 Platten eine weitere Platte verloren hatte. Dagegen hilft nur ein Raid 5 mit 2 spares
Wenn der Stick kaputt is dann isntallierst du ein neues ESXI auf nem neuen Stick, hängst deine 7 VMs wieder ein (der VMware Client hat eine Option dafür) und kannst locker weiterarbeiten.
Außerdem wäre der Stick sogar ein Notnagel falls deine Bootpartition mal kaputtgeht... Raid hin oder her, eine Platte fällt selten alleine aus, im Raid laufen die alle genau gleaich lang - und Kunden vun uns hatten das schon daß ihr vermeintlich sicheres Raid 5 mitten in einem Rebuild nach dem Tausch einer von 4 Platten eine weitere Platte verloren hatte. Dagegen hilft nur ein Raid 5 mit 2 spares
Hallo Zusammen,
ich halte es für die beste Variante die VMs zu backupen und den ESXi einfach auf einer SD-Karte neu zu installieren. Die Partition zu erweitern ist meiner Meinung nach mehr "gebastelt" und wäre mir persönlich zu unsicher. Mir ist bis jetzt noch keine SD-Karte von einem ESXi kaputt gegangen und selbst wenn die SD-Karte kaputt geht läuft der ESXi einfach weiter auch wenn er keine SD-Karte mehr erkennt. Alles wichtige läuft im RAM und die HDD/SD ist nur der "Config-Speicher". Nur eben rebooten kann man die Kiste nicht mehr. Die neuen Gen10 Server haben mittlerweile auch einen M.2 Slot, was vielleicht eine alternative wäre wenn einem die SD-Karte tatsächlich zu unsicher ist. Aber ein ESXi ist im Zweifel auch wieder schnell installiert.
@K-ist-K
Deine Anleitung passt trotzdem würde ich vorher ein Backup machen.
@GrueneSosseMitSpeck
Beim Ausfall von 2 Platten bringen dir die zwei Spares auch nichts nur ein RAID6 kann sowas abdecken. ;) RAID ersetzt aber auf keine Fall ein vernünftiges Backup.
ich halte es für die beste Variante die VMs zu backupen und den ESXi einfach auf einer SD-Karte neu zu installieren. Die Partition zu erweitern ist meiner Meinung nach mehr "gebastelt" und wäre mir persönlich zu unsicher. Mir ist bis jetzt noch keine SD-Karte von einem ESXi kaputt gegangen und selbst wenn die SD-Karte kaputt geht läuft der ESXi einfach weiter auch wenn er keine SD-Karte mehr erkennt. Alles wichtige läuft im RAM und die HDD/SD ist nur der "Config-Speicher". Nur eben rebooten kann man die Kiste nicht mehr. Die neuen Gen10 Server haben mittlerweile auch einen M.2 Slot, was vielleicht eine alternative wäre wenn einem die SD-Karte tatsächlich zu unsicher ist. Aber ein ESXi ist im Zweifel auch wieder schnell installiert.
@K-ist-K
Deine Anleitung passt trotzdem würde ich vorher ein Backup machen.
@GrueneSosseMitSpeck
Beim Ausfall von 2 Platten bringen dir die zwei Spares auch nichts nur ein RAID6 kann sowas abdecken. ;) RAID ersetzt aber auf keine Fall ein vernünftiges Backup.