VMware-Forum

Hallo,

ich habe das Problem, dass sich mein lokaler Datenspeicher auf dem esxi 5.5 Vers. 2456374 (VMFS 5.58 ) nicht vergrößern lässt.

Wir haben ein raid 5 aus 3 x samsung 850 evo ssd 1TB mit einem fujitsu d3116 (lsi sas9266-8i) raid-controller. Als Gesamtkapazität werden mir 1,82 TB angezeigt und auf diese Größe müsste doch theoretisch auch der Datenspeicher zu vergrößern gehen?
Er lässt jedoch nicht vergrößern. Es werden nur 463 GB angezeigt. Der "Erhöhen" Button ist im vsphere-client ausgegraut.

Den Host habe ich in den Wartungsmodus versetzt um das Volume mit dem vspehre client zu vergrößern, aber ohne Erfolg. Das vcenter ist auch auf diesem host und auch auf diesem Datenspeicher installiert. Spielt das eventuell eine Rolle?

Theoretisch sollte doch der lokale Datenspeicher ohne weiteres bis zu seiner Kapazitätsgrenze zu vergrößern gehen oder gibt es dort etwas zu beachten?

Bin für jeden Tipp dankbar.

Thomas

Wenn man auf einem RAID5-Verbund im LSI ein Logical Volume mit 1,82 TB erzeugt und darauf den ESXi installiert, hat der Datastore automatisch die maximale Kapazität.

Wie kann es sein, dass dieser bei Euch nur 483 GB hat?
Ist das RAID5 nachträglich vergrößert worden?

Ja. Ursprünglich war das Raid so groß. Dann wurden nacheinander die ssd gegen größere ausgetauscht.

Ist auch die Virtuelle Disk vergroessert worden nachdem die Diskgroup sich geaendert hat? Hat die Diskgroup nur eine VD oder 2 gehabt?

Zeig uns mal en Screenshot von der GUI des Kontrollers und dann dazu ein vom ESXi.

Gruss
Joerg

Das müsste dann bedeuten, dass schon auf Controller-Ebene das Volume noch die alte Größe hat und der ESXi erst mal gar nichts tun kann (er sieht nach wie vor eine "Festplatte" mit 463 GB).

Nur ausgewählte Controller können ein RAID online vergrößern - du müsstest erst mal schauen, ob das dein Controller kann.

@~thc
Der esxi wurde auf einem usb-stick installiert.
Das Raid-5 Datastore dient nur als Speicher für die VMs.

@irix
Ich denke die virt. Disk habe ich in der GUI des Controllers vergrößert (ist aber schon ein paar Tage her...).
Es gibt 3 VD (1x Raid5, 1x JBOD, 1x Raid 1) auf dem Controller.

Anbei der Screenshot vom esxi:

~ # fdisk -l

***
*** The fdisk command is deprecated: fdisk does not handle GPT partitions. Plea se use partedUtil
***

Found valid GPT with protective MBR; using GPT

Disk /dev/disks/naa.600605b00492768019bc48852ffe06f7: 974608384 sectors, 929M
Logical sector size: 512
Disk identifier (GUID): 8264bc92-c89b-43f1-8b55-f421568d5784
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 974608350

Number Start (sector) End (sector) Size Code Name
1 2048 974608350 929M 0700
Found valid GPT with protective MBR; using GPT

Disk /dev/disks/mpx.vmhba32:C0:T0:L0: 62537728 sectors, 59.6M
Logical sector size: 512
Disk identifier (GUID): 474e8a86-81e4-4d1c-9a27-ce1bde8251dc
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 62537694

Number Start (sector) End (sector) Size Code Name
1 64 8191 8128 0700
5 8224 520191 499K 0700
6 520224 1032191 499K 0700
7 1032224 1257471 219K 0700
8 1257504 1843199 571K 0700
Found valid GPT with protective MBR; using GPT

Disk /dev/disks/naa.600605b0049276801aa3e378ba1cac7f: 3904294912 sectors, 3723M
Logical sector size: 512
Disk identifier (GUID): f936b609-b9d6-4e34-afa9-64ad7879a7f2
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3904294878

Number Start (sector) End (sector) Size Code Name
1 2048 3904294878 3723M 0700
Found valid GPT with protective MBR; using GPT

Disk /dev/disks/naa.600605b00492768019a32e94a0af1bdb: 3904897024 sectors, 3724M
Logical sector size: 512
Disk identifier (GUID): d760a9a4-d555-4731-90a8-e18002d6ab9b
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3904896990

Number Start (sector) End (sector) Size Code Name
1 2048 3904896990 3723M 0700
~ #

Hier der Screenshot vom Controller:

https://www.dropbox.com/s/1mhcxhbq16d3j ... r.png?dl=0

Danke
Thomas

Schau mal ob du mit partedUtil nen Listing hinbekommst weil das fdisk zeigt noch nicht eine Disk an oder?

Gruss
Joerg

Das sieht doch alles erst mal korrekt aus.

Von oben nach unten:
- 465 GB RAID 0
- 32 GB USB-Stick
- 1,81 TB RAID 5 oder RAID 1
- 1,81 TB RAID 5 oder RAID 1

@irix: ich weiß jetzt nicht, ob ich partedUtil richtig verwendet habe, aber folgendes spuckt es aus:

~ # partedUtil get /vmfs/volumes/52110709-26e4caa2-32ec-00262d004afa
Warning: Unable to open /vmfs/volumes/52110709-26e4caa2-32ec-00262d004afa read-write (Is a directory). /vmfs/volumes/52110709-26e4caa2-32ec-00262d004afa has been opened read-only.
Warning: Could not determine sector size for /vmfs/volumes/52110709-26e4caa2-32ec-00262d004afa: Inappropriate ioctl for device.
Using the default sector size (512).
A bug has been detected in GNU Parted. Refer to the web site of parted http://www.gnu.org/software/parted/parted.html for more informations of what could be useful for bug submitting! Please email a bug report to bug-parted@gnu.org containing at least the version (1.8.1) and the following message: Unable to determine the size of /vmfs/volumes/52110709-26e4caa2-32ec-00262d004afa (Inappropriate ioctl for device).
Unable to get device /vmfs/volumes/52110709-26e4caa2-32ec-00262d004afa

@thc: Meiner Meinung nach sollte laut Controller soviel Speicher vorhanden sein...

For ESXi/ESX 4.1 and later, run this command:

albiderbaer hat geschrieben:Unable to get device /vmfs/volumes/52110709-26e4caa2-32ec-00262d004afa

Sollte einem das jetzt zu denken geben, dass dieser Identifier in der obigen fdisk-Liste ueberhaupt nicht auftaucht?

Ansonsten faellt mir auf:
vCenter befindet sich auf LOKALEM Storage? Merkwuerdig...
Sind da vielleicht noch weitere Komponenten wie Replication, vSphere-Cluster, etc.pp. eingerichtet/beteiligt?
Wurde schon mal (nach der Vergroesserung) ein Rescan oder Reboot des Hosts durchgefuehrt?

Edit:
Umpf, ja, erst einmal zu Ende denken, und dann schreiben...
Wenn ich den Hinweis in KB1017662 richtig interpretiere, dann geht das mit dem GUI so einfach nur fuer NON_LOCAL Disks. Fuer LOCAL Disks muss man die Kommandozeile laut KB2002461 bemuehen.
Vielleicht ist genau dies das Problem:
- LUN (bzw. Virtual Disk wurde vergroessert)
- Partition wurde gewuenscht vergroessert
- GPT wurde noch nicht gefixt

JustMe hat geschrieben:Sollte einem das jetzt zu denken geben, dass dieser Identifier in der obigen fdisk-Liste ueberhaupt nicht auftaucht?t

Nö - das ist ein Datastore-Identifier und oben in der Liste sind die Disk-Identifier.

Danke für die Info mit den KBs. Das hatte ich überlesen.

Wenn ich entsprechend KB2002461 vorgehe, dann kommt folgende Meldung:

~ # partedUtil getUsableSectors /vmfs/devices/disks/naa.600605b00492768019a32e94
a0af1bdb:1
Unknown partition table on disk /vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1

Der ":1" duerfte ueberfluessig sein. Der verweist auf die erste Partition auf der LUN, und die Partition Table befindet sich ausserhalb der Partition.

@~thc: OK; ich dachte, die Identifier waeren in der Liste unter "Disk Identifier (GUID)" zu finden. Muss ich bei Gelegenheit mal genauer pruefen.

Beim letzten Schritt bleibe ich leider stecken...

vmkfstools --growfs /vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1 /vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1
Not found
Error: No such file or directory

Setz mal bitte die beiden Identifier in Anführungszeichen - so wie im KB.

Ich komme irgendwie nicht weiter...
Das "unknown" bei der Auflistung macht mich stutzig:

~ # esxcli storage core path list
unknown.vmhba2-unknown.2:2-naa.600605b00492768019bc48852ffe06f7
UID: unknown.vmhba2-unknown.2:2-naa.600605b00492768019bc48852ffe06f7
Runtime Name: vmhba2:C2:T2:L0
Device: naa.600605b00492768019bc48852ffe06f7
Device Display Name: Local LSI Disk (naa.600605b00492768019bc48852ffe06f7)
Adapter: vmhba2
Channel: 2
Target: 2
LUN: 0
Plugin: NMP
State: active
Transport: parallel
Adapter Identifier: unknown.vmhba2
Target Identifier: unknown.2:2
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 286720

usb.vmhba32-usb.0:0-mpx.vmhba32:C0:T0:L0
UID: usb.vmhba32-usb.0:0-mpx.vmhba32:C0:T0:L0
Runtime Name: vmhba32:C0:T0:L0
Device: mpx.vmhba32:C0:T0:L0
Device Display Name: Local USB Direct-Access (mpx.vmhba32:C0:T0:L0)
Adapter: vmhba32
Channel: 0
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: usb
Adapter Identifier: usb.vmhba32
Target Identifier: usb.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 122880

unknown.vmhba2-unknown.2:1-naa.600605b0049276801aa3e378ba1cac7f
UID: unknown.vmhba2-unknown.2:1-naa.600605b0049276801aa3e378ba1cac7f
Runtime Name: vmhba2:C2:T1:L0
Device: naa.600605b0049276801aa3e378ba1cac7f
Device Display Name: Local LSI Disk (naa.600605b0049276801aa3e378ba1cac7f)
Adapter: vmhba2
Channel: 2
Target: 1
LUN: 0
Plugin: NMP
State: active
Transport: parallel
Adapter Identifier: unknown.vmhba2
Target Identifier: unknown.2:1
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 286720

unknown.vmhba2-unknown.2:0-naa.600605b00492768019a32e94a0af1bdb
UID: unknown.vmhba2-unknown.2:0-naa.600605b00492768019a32e94a0af1bdb
Runtime Name: vmhba2:C2:T0:L0
Device: naa.600605b00492768019a32e94a0af1bdb
Device Display Name: Local LSI Disk (naa.600605b00492768019a32e94a0af1bdb)
Adapter: vmhba2
Channel: 2
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: parallel
Adapter Identifier: unknown.vmhba2
Target Identifier: unknown.2:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 286720

sata.vmhba34-sata.0:0-mpx.vmhba34:C0:T0:L0
UID: sata.vmhba34-sata.0:0-mpx.vmhba34:C0:T0:L0
Runtime Name: vmhba34:C0:T0:L0
Device: mpx.vmhba34:C0:T0:L0
Device Display Name: Local HL-DT-ST CD-ROM (mpx.vmhba34:C0:T0:L0)
Adapter: vmhba34
Channel: 0
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: sata
Adapter Identifier: sata.vmhba34
Target Identifier: sata.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 131072

Und wenn ich dann entsprechend KB2002461 vorgehe, dann bleibe ich bei growfs hängen:
vmkfstools --growfs "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1" "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1"
Not found
Error: No such file or directory

Vielleicht könnt ihr mir helfen.

Zumindest das "unknown" scheint normal zu sein - ist bei meinen LSIs auch so.

@albiderbaer:
Zeig' doch mal bitte die Ausgaben von




PS:
Die Tabellenausgaben auf der Kommandozeile bzw. in ssh/Putty kann man der besseren Lesbarkeit wegen in eine code-/code Umgebung packen (siehe oben).

Ich gehe aber davon aus, dass die vorherigen Punkte aus dem KB-Artikel (also 1- insbesondere 12) alle erfolgreich und mit sinnvollen Ergebnissen abgeschlossen wurden. Oder gab es irgendwo was Unerwartetes?

@JustMe:
hier die Ausgabe:
~ # ls -lah /vmfs/devices/disks
total 8815987568
drwxr-xr-x 1 root root 512 Jun 2 09:11 .
drwxr-xr-x 1 root root 512 Jun 2 09:11 ..
-rw------- 1 root root 29.8G Jun 2 09:11 mpx.vmhba32:C0:T0:L0
-rw------- 1 root root 4.0M Jun 2 09:11 mpx.vmhba32:C0:T0:L0:1
-rw------- 1 root root 250.0M Jun 2 09:11 mpx.vmhba32:C0:T0:L0:5
-rw------- 1 root root 250.0M Jun 2 09:11 mpx.vmhba32:C0:T0:L0:6
-rw------- 1 root root 110.0M Jun 2 09:11 mpx.vmhba32:C0:T0:L0:7
-rw------- 1 root root 286.0M Jun 2 09:11 mpx.vmhba32:C0:T0:L0:8
-rw------- 1 root root 1.8T Jun 2 09:11 naa.600605b00492768019a32e94a0af1bdb
-rw------- 1 root root 1.8T Jun 2 09:11 naa.600605b00492768019a32e94a0af1bdb:1
-rw------- 1 root root 464.7G Jun 2 09:11 naa.600605b00492768019bc48852ffe06f7
-rw------- 1 root root 464.7G Jun 2 09:11 naa.600605b00492768019bc48852ffe06f7:1
-rw------- 1 root root 1.8T Jun 2 09:11 naa.600605b0049276801aa3e378ba1cac7f
-rw------- 1 root root 1.8T Jun 2 09:11 naa.600605b0049276801aa3e378ba1cac7f:1
lrwxrwxrwx 1 root root 20 Jun 2 09:11 vml.0000000000766d68626133323a303a30 -> mpx.vmhba32:C0:T0:L0
lrwxrwxrwx 1 root root 22 Jun 2 09:11 vml.0000000000766d68626133323a303a30:1 -> mpx.vmhba32:C0:T0:L0:1
lrwxrwxrwx 1 root root 22 Jun 2 09:11 vml.0000000000766d68626133323a303a30:5 -> mpx.vmhba32:C0:T0:L0:5
lrwxrwxrwx 1 root root 22 Jun 2 09:11 vml.0000000000766d68626133323a303a30:6 -> mpx.vmhba32:C0:T0:L0:6
lrwxrwxrwx 1 root root 22 Jun 2 09:11 vml.0000000000766d68626133323a303a30:7 -> mpx.vmhba32:C0:T0:L0:7
lrwxrwxrwx 1 root root 22 Jun 2 09:11 vml.0000000000766d68626133323a303a30:8 -> mpx.vmhba32:C0:T0:L0:8
lrwxrwxrwx 1 root root 36 Jun 2 09:11 vml.0200000000600605b00492768019a32e94a0af1bdb4d5220534153 -> naa.600605b00492768019a32e94a0af1bdb
lrwxrwxrwx 1 root root 38 Jun 2 09:11 vml.0200000000600605b00492768019a32e94a0af1bdb4d5220534153:1 -> naa.600605b00492768019a32e94a0af1bdb:1
lrwxrwxrwx 1 root root 36 Jun 2 09:11 vml.0200000000600605b00492768019bc48852ffe06f74d5220534153 -> naa.600605b00492768019bc48852ffe06f7
lrwxrwxrwx 1 root root 38 Jun 2 09:11 vml.0200000000600605b00492768019bc48852ffe06f74d5220534153:1 -> naa.600605b00492768019bc48852ffe06f7:1
lrwxrwxrwx 1 root root 36 Jun 2 09:11 vml.0200000000600605b0049276801aa3e378ba1cac7f4d5220534153 -> naa.600605b0049276801aa3e378ba1cac7f
lrwxrwxrwx 1 root root 38 Jun 2 09:11 vml.0200000000600605b0049276801aa3e378ba1cac7f4d5220534153:1 -> naa.600605b0049276801aa3e378ba1cac7f:1


und hier die Ausgaben in Tabellenform:


~ # hexdump -C /vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb -n 512
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 1d 9a 00 00 |................|
000001c0 01 00 ee fe ff ff 01 00 00 00 ff ff bf e8 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200


bzw.


~ # hexdump -C /vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1 -n 512
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
~ #



Entsprechend KB1017662 bin ich die 12 Punkte auch durchgegangen. Ohne Erfolg.
Nur beim 2. Punkt bin ich mir nicht ganz sicher, darf denn nun auf dem Speicher noch eine VM laufen oder nicht?
Müssen vielleicht doch erst alle VMs auf einen anderen Datenstore migriert werden?

Ich meinte eigentlich die 12 Punkte von dem zuletzt erwaehnten KB2002461...
...wo dann der Aufruf mit growfs als dreizehnter Punkt kommt, und die Ausgabe erscheint, dass das Device naa...bdb:1 nicht gefunden wuerde. Von daher kam meine Nachfrage zum Listing und dem Zugriff hexdump, der aber offenbar sauber klappt.

Warum dann der vmkfstools-Aufruf einen solchen Fehler ausgibt: Sorry, bin mit meinem Latein am Ende.

PS:
Wenn man den Datastore vorher leerraeumt, kann man ihn auch gleich neu anlegen
Sollte diese Option bestehen, waere es als pragmatische Loesung vielleicht vorzuziehen.

@JustMe:
Sorry,
also ich habe jetzt nochmal meine Schritte mit entsprechenden Ausgaben nach KB2002461 aufgelistet:

~ # vmkfstools -P "vmfs/volumes/SSD-Raid"
VMFS-5.58 file system spanning 1 partitions.
File system label (if any): SSD-Raid
Mode: public
Capacity 497947770880 (474880 file blocks * 1048576), 101244207104 (96554 blocks) avail, max file size 692015868149 76
UUID: 52110709-26e4caa2-32ec-00262d004afa
Partitions spanned (on "lvm"):
naa.600605b00492768019a32e94a0af1bdb:1
Is Native Snapshot Capable: YES
~ # partedUtil get "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb"
243068 255 63 3904897024
1 2048 3904896990 0 0
~ # partedUtil getUsableSectors "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb"
34 3904896990
~ # partedUtil resize "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb" 1 2048 3904896990
~ # partedUtil fixGpt
Usage:
Get Partitions : get <diskName>
Set Partitions : set <diskName> ["partNum startSector endSector type attr"]*
Delete Partition : delete <diskName> <partNum>
Resize Partition : resize <diskName> <partNum> <start> <end>
Get Partitions : getptbl <diskName>
Set Partitions : setptbl <diskName> <label> ["partNum startSector endSector type/guid attr"]*
Fix Partition Table : fix <diskName>
Create New Label (all existing data will be lost): mklabel <diskName> <label>
Show commonly used partition type guids : showGuids
Get usable first and last sectors : getUsableSectors <diskName>
Fix GPT Table interactively : fixGpt <diskName>

~ # partedUtil fixGpt "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb"

FixGpt tries to fix any problems detected in GPT table.
Please ensure that you don't run this on any RDM (Raw Device Mapping) disk.
Are you sure you want to continue (Y/N): y
gpt
243068 255 63 3904897024
1 2048 3904896990 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
~ # vmkfstools -V
~ # vmkfstools --growfs "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1" "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb:1"
Not found
Error: No such file or directory
~ #


Hilfe, ich komme einfach nicht weiter.

Vielleicht bleibt da wirklich nur noch die Rueckfrage bei VMware selbst...

Sieht eigentlich alles gut aus. Zwar wird der Partition Type beim get als "0" ausgegeben, aber das ist bei den VMFS5-Partitions hier bei mir auch so.
Nach den ausgegebenen Daten sind jedenfalls die Punkte bis eben zum growfs alle korrekt (und waren das schon, bevor Du die Ausgabe aufgezeichnet hast).

Mir blieben nur noch zwei Punkte:
- Wie lange hast Du zwischen "vmkfstools -V" und "vmkfstools --growfs..." gewartet? Oder vielleicht sogar mal den Host dazwischen rebootet?
- Hast Du die Anzeige in Deinem vSphere Client aktualisiert?

- Und in letzter Verzeiflung kannst Du auch mal schauen, ob ein geringfuegig niedriger gewaehlter Endsektor fuer die Partition helfen wuerde, z.B. 3904890000 statt 3904896990 (dann wuerden knapp 3.5G ungenutzt bleiben).

Sorry...

Ich hab' das jetzt mal "rasch" mit einem virtuellen ESXi nachgestellt. Leider hat alles voellig problemlos funktioniert, so wie im Artikel beschrieben (bis auf den Fehler, den Du ja auch bemerkt hast: Im Punkt 9 gehoert zum fixGpt auch noch die Device-Kennung).

Der growfs-Befehl geht ohne Ausgaben durch, und das VMFS wird nach einem Refresh im WebClient auch korrekt angezeigt.

Warum dieser Befehl bei Dir auf einmal die Partition nicht mehr findet, die vorher noch angezeigt wurde, kann ich leider nicht sagen.

Geht nach dem vmkfstools -V noch ein partedUtil get "/vmfs/devices/disks/naa.600605b00492768019a32e94a0af1bdb" ? Falls ja, wie ist die Ausgabe?