Vergrößern des Datastores? (16 TB-Grenze?)

[evolver]

Hallo zusammen,

bei mir läuft ein ESXi 6.5.0 (Build 4887370) mit einem großen Datastore. (Blockgröße 1 MB)
Es wurden vier 5 TB-Platten als RAID5 hinterlegt. In ESXi wurden bisher ~ 13,6 TB Gesamtkapazität angezeigt.

Jetzt wollte ich eine fünfte 5 TB-Platte hinzufügen. Leider zeigt mir das System nach dem Hinzufügen nur 16 TB Gesamtspeicher an. Gibt es da irgendwo eine Begrenzung? Ich hätte jetzt mit ~18 TB gerechnet. Zumindest der freie Speicher sollte jetzt bei knapp 5TB liegen und nicht bei 2,45 TB.

Zum Vergrößern bin ich wie folgt vorgegangen:
1. RAID über den RAID-Controller vergrößern.
2. Per SSH auf ESXi.
3. Nutzbare Größe herausfinden:

Code: Alles auswählen

[root@localhost:/dev/disks] partedUtil getUsableSectors "/vmfs/devices/disks/naa.60030057023593402059df7115196052"
[...]
34 39065747422


4. Partitionsdaten anzeigen:

Code: Alles auswählen

[root@localhost:/dev/disks] partedUtil get "/vmfs/devices/disks/naa.60030057023593402059df7115196052"
[...]
3 15472640 29299310558 0 0


5. Partition vergrößern:

Code: Alles auswählen

[root@localhost:/dev/disks] partedUtil resize "/vmfs/devices/disks/naa.60030057023593402059df7115196052" 3 15472640 39065747422


6. Reboot
7. VMFS vergrößern:

Code: Alles auswählen

[root@localhost:/dev/disks] vmkfstools --growfs "/vmfs/devices/disks/naa.60030057023593402059df7115196052:3" "/vmfs/devices/disks/naa.60030057023593402059df7115196052:3"


Die Daten der Partition:

Code: Alles auswählen

[root@localhost:/dev/disks] partedUtil getptbl "/vmfs/devices/disks/naa.60030057023593402059df7115196052"
gpt
2431730 255 63 39065747456
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 39065747422 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

[root@localhost:/dev/disks] vmkfstools -P "/vmfs/volumes/datastore1"
VMFS-6.81 (Raw Major Version: 24) file system spanning 1 partitions.
File system label (if any): datastore1
Mode: public
Capacity 17591917608960 (16776960 file blocks * 1048576), 2698730536960 (2573710 blocks) avail, max supported file size 70368744177664
UUID: 58c88c18-66c91226-64e5-50e54920a091
Partitions spanned (on "lvm"):
        naa.60030057023593402059df7115196052:3
Is Native Snapshot Capable: NO
[root@localhost:/dev/disks] df -m
Filesystem 1M-blocks     Used Available Use% Mounted on
VMFS-6      16776960 14203344   2573616  85% /vmfs/volumes/datastore1
vfat             249      151        98  61% /vmfs/volumes/7ac83470-e40c2d89-5138-94c92057ad54
vfat             249      151        98  61% /vmfs/volumes/32bb6975-20c33e9e-1d98-9f179d47b2d0
vfat             285      205        80  72% /vmfs/volumes/58c88c11-69b3b4d4-ba8a-50e54920a091
vfat            4094       43      4050   1% /vmfs/volumes/58c88c20-84c34c2b-ae73-50e54920a091


Ich finde immer nur eine Grenze von 64 TB ab VMFS-5. Somit sollte doch eigentlich nichts gegen eine Nutzung der ganzen 20 TB sprechen?
Ich wollte aber jetzt nicht einfach so rumprobieren. Dafür ist mir das Risiko, etwas falsch zu machen, dann doch zu groß.

Danke schonmal vorab für eure Hilfe!

[~thc]

Ein offensichtlicher Fehler ist für mich nicht zu erkennen. Meine Vermutung: Die Funktion "growfs" hat ein 16 TB Limit.

[rprengel]

Hallo zusammen,

bei mir läuft ein ESXi 6.5.0 (Build 4887370) mit einem großen Datastore. (Blockgröße 1 MB)
Es wurden vier 5 TB-Platten als RAID5 hinterlegt. In ESXi wurden bisher ~ 13,6 TB Gesamtkapazität angezeigt.

Jetzt wollte ich eine fünfte 5 TB-Platte hinzufügen. Leider zeigt mir das System nach dem Hinzufügen nur 16 TB Gesamtspeicher an. Gibt es da irgendwo eine Begrenzung? Ich hätte jetzt mit ~18 TB gerechnet. Zumindest der freie Speicher sollte jetzt bei knapp 5TB liegen und nicht bei 2,45 TB.

Zum Vergrößern bin ich wie folgt vorgegangen:
1. RAID über den RAID-Controller vergrößern.


Danke schonmal vorab für eure Hilfe!

Im Raidcontroller-Interafce wird die erwarte Grösse angezeigt ohne irgendwelche Meldungen angezeigt?
Das ESX Webinterface zeigt die gleichen Werte an?

Gruss

[evolver]

Im Raidcontroller-Interafce wird die erwarte Grösse angezeigt ohne irgendwelche Meldungen angezeigt?
Das ESX Webinterface zeigt die gleichen Werte an?

Im RAID-Controller sieht alles gut aus:


Im Webinterface wird es so angezeigt:




Auch von der Vergrößerung in der Shell passt das ja:
Vorher beanspruchte die Partition den Bereich von 15472640 bis 29299310558 (Blöcke?)
Jetzt von 15472640 bis 39065747422. Heißt so grob 10 Mrd. Blöcke pro nutzbarer Platte.

Im ersten ESXi-Screenshot zeigt der ja auch 18,18 TB an. Das ist die Partitionsansicht.
Also scheint die Partition groß genug zu sein, nur das Filesystem dadrauf ist zu klein, richtig?

[Supi]

Hallo zusammen,

bei mir läuft ein ESXi 6.5.0 (Build 4887370) mit einem großen Datastore. (Blockgröße 1 MB)
.......
Zum Vergrößern bin ich wie folgt vorgegangen:
1. RAID über den RAID-Controller vergrößern.

Zwei Fragen:
Wieso danach nicht alles über die GUI gemacht? Datatstore rescan, Kapazität erweitern und das wäre es gewesen?
Den ESXi zumindest mal auf 6.5 U1 oder ESXi 6.5 Express Patch 4 bringen?

[evolver]

Zwei Fragen:
Wieso danach nicht alles über die GUI gemacht? Datatstore rescan, Kapazität erweitern und das wäre es gewesen?
Den ESXi zumindest mal auf 6.5 U1 oder ESXi 6.5 Express Patch 4 bringen?

Ich hatte das damals (als ich von drei auf vier Platten erweitert habe) über das Webinterface versucht und keinen Weg gefunden. Dann hatte ich nach ein bisschen Suche den Weg über die Shell gefunden, was damals auch problemlos funktioniert hat.

Welchen Menüpunkt meinst Du mit "Datastore rescan"? Hatte damals mit "Kapazität erhöhen" probiert, was nicht funktionierte.

Wie führe ich am sichersten/einfachsten ein Update auf 6.5 U1 durch? Ich würde dann mal updaten und versuchen, ob growfs danach vielleicht noch mehr rausholt.

[Supi]

Hallo noch mal,

also zum Update ( ich gehe von Free ESXI ohne Vcenter aus):
https://esxi-patches.v-front.de/ESXi-6.5.0.html

esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-6.5.0-20171004001-standard \
-d https://hostupdate.vmware.com/software/ ... -index.xml
esxcli network firewall ruleset set -e false -r httpClient

Welchen Menüpunkt meinst Du mit "Datastore rescan"? Hatte damals mit "Kapazität erhöhen" probiert, was nicht funktionierte.

War ein Denkfehler von mir, da ich zumeinst nur mit SAN zu tun hatte. Beim Lokal Storage ist das größere Volume nach dem Server-Reboot ja schon "erkannt".


Aber:

ich würde es ggf erst mal dem Vshpere # Client probieren.
http://vsphereclient.vmware.com/vsphere ... 112508.exe

Keine Ahnung ob man damit beim 6.5 noch alles Administrieren kann. Seit 6.5 U1 jedenfalls nicht mehr.

Habe nur eben bei meiner ESXi 6.0 Spielwiese festgestellt, das der Host Client ja immer noch ne Gurke ist?!
Neuester Fling und neuester ESXi 6.0.
Locale HDD 20GB. ... diese um 2 GB vergrößert. ( ESXi als VM in der workstation, da kann man ja leicht die HDD vergrößern. )

im Host-Client klappt das nicht. Über den #Client schon?!. Muss man nicht verstehen.
Daher eventuell erst mal noch nicht updaten.

[evolver]

Hi Stefan,

danke für die Hinweise. Der vSpehre-Client läuft ja um Längen besser als das Webinterface. Das hätte mir viel Arbeit in der Vergangenheit erspart.

Habe jetzt unter Konfiguration => Speicher => Alle erneut prüfen geklickt. Er war recht schnell fertig, es hat sich jedoch nichts geändert.

So sieht das in vSphere aus:



Wenn ich das Dateisystem -warum auch immer- nicht auf die max. Größe bekomme, könnte ich doch eventuell ein zweites VMFS anlegen und datastore1 auf beide verteilen? Das wäre natürlich nur ein unschöner Workaround, aber das würde vermutlich doch gehen, oder?
Dafür müsste ich jedoch die Partition wieder verkleinern, richtig?

Die schönste Lösung wäre natürlich, wenn ich die 16 TB irgendwie auf die 18 TB bekomme.

Gruß
Christian

[Supi]

Hallo Christian,

was passiert denn beim klicken auf erhöhen?

Zum Host-Client-Bug siehe unten. Muss man nicht verstehen.

[evolver]

was passiert denn beim klicken auf erhöhen?

Dann soll ich ein LUN zum Erhöhen auswählen. Die Liste ist aber leer. Vermutlich, weil das einzige LUN (mit 18 TB) bereits belegt ist.

[Supi]

Hallo Christian,

ja dein Problem ist, das du auch den ESXi auf dem Raid bzw. Volume installiert hast. Sehr ungünstig. Gabs da keinen passenden USB Stick?

Da hilft wirklich nur die Console:

https://kb.vmware.com/s/article/2002461

Ohne reichlich Übung in der Shell und mit VMFS Tools würde ich da aber bei einem 16TB Datastore nicht rumfummeln.
Dann lieber wenn möglich alle VM'S sichern, den ESXI neu auf USB installieren und den Datastore frisch formatieren.

Aber einige der Punkt aus der KB hast du ja schon gemacht. Kurz überflogen fehlt der Punkt: partedUtil fixGpt "/vmfs/devices/disks/Device" .. oder?

und "EnterpriseDaddy" schreibt hier:
http://www.enterprisedaddy.com/2016/08/ ... mand-line/

partedUtil getUsableSectors ....
You would notice that the last sector shown is higher than the current one that we saw when we checked the partition information.
In the next step, we will have to resize the partition information to reflect the extended information.

Subtract 1 from the last usable sector and resize the partition information with the below command.

In deinem Befehl oben ist der eine Sektor nicht abgezogen.

[evolver]

Hi Stefan,

ich hatten den ESXi in der ersten Fassung auf einem USB-Stick. Das Board hat sogar einen USB-Port verlötet. Wäre sehr praktisch gewesen. Aber ich habe mich dann nicht getraut, da ich nicht wusste, wie lange so ein USB-Stick hält und was die Konsequenzen sind, wenn der kaputt geht.
Man lernt ja nie aus...

Leider kann ich die 13,5 TB Daten nicht mal grade woanders hinschieben, um alles neu aufzusetzen.

Aber wie Du schon sagst: Die meisten Punkte aus dem KB-Artikel habe ich bereits gemacht.
Die Partition scheint ja die richtige Größe zu haben. Also haben meine partedUtil-Befehle wohl funktioniert.
Nur das darauf befindliche Filesystem scheint die Partition nicht ganz zu nutzen. (vmkfstools -growfs)

Sonst werde ich wohl mal auf ESXi 6.5 U1 updaten und hoffen, dass das dann mit growfs funktioniert.

Habe das mit fixGpt und anschließendem growfs gerade auch noch ausprobiert. Leider ohne Erfolg:

Code: Alles auswählen

partedUtil fixGpt "/vmfs/devices/disks/naa.60030057023593402059df7115196052"

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
2431730 255 63 39065747456
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 39065747422 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

vmkfstools --growfs "/vmfs/devices/disks/naa.60030057023593402059df7115196052:3" "/vmfs/devices/disks/naa.60030057023593402059df7115196052:3"
Underlying device has no free space
Error: No space left on device

Danke!
Viele Grüße

Christian

[evolver]

partedUtil getUsableSectors ....
You would notice that the last sector shown is higher than the current one that we saw when we checked the partition information.
In the next step, we will have to resize the partition information to reflect the extended information.

Subtract 1 from the last usable sector and resize the partition information with the below command.

In deinem Befehl oben ist der eine Sektor nicht abgezogen.

Stimmt. Könnte sein, dass das mein Fahler war.

Leider kann ich das jetzt nicht mehr ändern:

Code: Alles auswählen

partedUtil resize "/vmfs/devices/disks/naa.60030057023593402059df7115196052" 3 15472640 39065747421
Error: Read-only file system during write on /dev/disks/naa.60030057023593402059df7115196052

Um das zu fixen, muss ich vermutlich eine neue Partitionstabelle schreiben:
https://kb.vmware.com/s/article/1036609#Creating%20a%20new%20partition%20table

Also mache ich eventuell damit alles kaputt oder komme ggf. auch nicht damit ans Ziel.

[Supi]

Alternativ mal Uli hier antriggern?
memberlist.php?mode=viewprofile&u=430

[evolver]

Alternativ mal Uli hier antriggern?
memberlist.php?mode=viewprofile&u=430

Ich habe Uli mal angeschrieben. Mal gespannt, was er dazu sagt.

Dann habe ich noch ein bisschen im Netz nach ähnlichen Problemen geschaut und bin noch auf diesen Thread aufmerksam geworden.
https://communities.vmware.com/thread/567069
Das sieht exakt nach meinem Problem aus und offensichtlich hat er dort auch schon mitgeholfen.

[evolver]

Ich würde gerne mal versuchen, die Partition um einen Sektor zu verkleinern, in der Hoffnung, dass das mein Problem ist.

Weiß jemand, wie ich das anstelle?

Habe es wie folgt versucht, was aber nicht funktioniert hat:

Code: Alles auswählen

partedUtil resize /vmfs/devices/disks/naa.60030057023593402059df7115196052 3 15472640 39065747421
Error: Read-only file system during write on /dev/disks/naa.60030057023593402059df7115196052

Vermutlich muss ich die ganze Partitionstabelle dafür neu schreiben?
Spontan würde ich sowas hier ausführen:

Code: Alles auswählen

partedUtil setptbl "/vmfs/devices/disks/naa.60030057023593402059df7115196052" "3 15472640 39065747421 AA31E02A400F11DB9590000C2911D1B8 0"

Aber wenn ich das richtig sehe, würde ich dadurch alle nicht aufgeführten Partitionen löschen?

Also müsste ich wohl eher sowas hier machen:

Code: Alles auswählen

partedUtil setptbl "/vmfs/devices/disks/naa.60030057023593402059df7115196052" "1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B 128" "5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 0" "6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 0" "7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 0" "8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 0" "9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 0" "2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 0" "3 15472640 39065747421 AA31E02A400F11DB9590000C2911D1B8 0"

Die Daten habe ich via getptbl bekommen:

Code: Alles auswählen

partedUtil getptbl /vmfs/devices/disks/naa.60030057023593402059df7115196052
gpt
2431730 255 63 39065747456
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 39065747422 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

Geht das so?

Danke für eure Hilfe!

[Supi]

Zu deinen PartedUtil Fragen kann ich nix sagen, nur einen anderen Denkanstoß geben:

https://www.amazon.de/Western-Digital-W ... B018C5EK8C

12 TB (R0) NAS kaufen, kommt bei Bestellung in 1h auch morgen an. Dann die VM's dort hin verschieben.
ESXI neu auf USB installieren und dann das RAID im ESXI neu formatieren, damit du alles nutzen kannst.

Bei Amazon kannst du aktuell die HW auch bis Ende Januar 2018 zurücksenden.
Nicht die ganz feine Art.... aber ggf. die pragmatischste?

[evolver]

Zu deinen PartedUtil Fragen kann ich nix sagen, nur einen anderen Denkanstoß geben:

https://www.amazon.de/Western-Digital-W ... B018C5EK8C

12 TB (R0) NAS kaufen, kommt bei Bestellung in 1h auch morgen an. Dann die VM's dort hin verschieben.
ESXI neu auf USB installieren und dann das RAID im ESXI neu formatieren, damit du alles nutzen kannst.

Bei Amazon kannst du aktuell die HW auch bis Ende Januar 2018 zurücksenden.
Nicht die ganz feine Art.... aber ggf. die pragmatischste?

Vermutlich hast Du Recht. Mich würde natürlich schon interessieren, warum das mit der Vergrößerung nicht funktioniert, aber dafür alle Daten auf's Spiel zu setzen ist vielleicht eine dumme Idee... (Habe von den wichtigsten Daten natürlich ein Backup, aber den Aufwand muss man ja nicht treiben, wenn's nicht notwendig ist)

Also ESXi auf einen USB-Stick. Größe und Geschwindigkeit sind dabei relativ egal, weil sowieso alles ins RAM geladen wird? Habe hier noch einen USB 2.0 8 GB Stick rumliegen. Den würde ich dann dafür nehmen.

In dem Server hängt noch eine 256 GB SSD, die momentan ungenutzt ist. ESXi hat da irgendwas mit SSD Caching, wenn ich mich richtig entsinne. Lohnt das? Ansonsten kommt die SSD demnächst in eBay.

Und dann am besten direkt ESXi 6.5 U1 nehmen - auch wenn ich dann kein vSphere mehr benutzen kann.

[rprengel]

.

In dem Server hängt noch eine 256 GB SSD, die momentan ungenutzt ist. ESXi hat da irgendwas mit SSD Caching, wenn ich mich richtig entsinne. Lohnt das? Ansonsten kommt die SSD demnächst in eBay.

Und dann am besten direkt ESXi 6.5 U1 nehmen - auch wenn ich dann kein vSphere mehr benutzen kann.

Hallo,

wenn intern ein sata-Anschluss frei ist nutz ein kleine Sata-Festplatte (2,5 Zoll). Ist auf Dauer stressfreier.
Gruss

Ralf

[JustMe]

Der USB-Stick sollte gehen; 4GB wuerden auch reichen. Aber Deine Einwaende hinsichtlich der "Standfestigkeit" sind trotzdem nicht von der Hand zu weisen. Nachdem ich kuerzlich in nicht allzu langer Zeit einen 128GB-Stick mit Video-Aufnahmen "zerschrieben" habe, vertraue ich den Dingern nicht mehr so sehr. OK, zugegeben, ist ein anderer Anwendungsfall.

Dein setptbl wird aber hoechstwahrscheinlich zu keinen Zeitpunkt funktionieren, solange Du von demselben Device den ESXi gebootet hast. Vielleicht ist das ja auch der Grund, warum die Vergroesserung des Datastores trotz korrekt vergroesserter Partition auf 16TB begrenzt blieb.

Um eine Komplettsicherung z.B. auf das von Supi angesprochene NAS wirst Du also vmtl. nicht drum herumkommen. Nochmal OK: Man koennte auch mit einem ESXi-Installationsmedium booten, um die Konfiguration damit auszufuehren, aber das Risiko bleibt natuerlich trotzdem bestehen.

Dann ist ja zu sehen, dass Dein Device eine "Local LSI Disk" ist. Der RAID-Controller kann doch bestimmt mehr als ein einzelnes VD anlegen, und dann koenntest Du ein "Boot-VD" mit z.B. 20GB (fuer ESXi, Logs, Dumps, etc.) anlegen, und den Rest des Arrays dann alleine dem VMFS-Datastore zuweisen. Die beiden Komponenten waeren somit fuer den ESXi unabhaengig voneinander.

Auch die SSD als Cache muesste doch vom LSI(Avago/Whatever-)-Controller selber verwaltet werden koennen. Der ESXi ist mit der SSD-Cache-Verwendung etwas eigen (Zweck/Verwendung, Lizenz, ...).

[evolver]

Hallo,

euch allen ein frohes neues Jahr.
Nach vielen Stunden kann ich nun zumindest einen Teilerfolg vermelden.
Ich schreibe mal einen etwas längeren Text, was ich alles gemacht habe. Vielleicht hilft das noch jemandem, der über das Forum stolpert oder ihr könnt daran sehen, wo mein Fehler liegt.

Neben meinem RAID mit 20 GB (~15 TB belegt) habe ich das Backup-RAID mit 16 TB laufen.

Zunächst hatte ich alle VMs beendet und über die ESXi-SSH-Shell die Verzeichnisse kopiert.
Das ist daran gescheitert, dass dadurch offensichtlich der komplette Speicherplatz bei Thin-VMDKs reserviert wird. Nach 16 TB meldete die Shell dann, dass die Platten voll sind.

Nach etwas Suche im Netz fand ich dann diese Seite und habe mir daraus folgende Script gebaut:

Code: Alles auswählen

mkdir "/vmfs/volumes/datastore_backup/$1"
find "/vmfs/volumes/datastore1/$1" -maxdepth 1 -type f | grep ".vmdk" | while read file; do fname=`basename "$file"`; vmkfstools -i "$file" -d thin "/vmfs/volumes/datastore_backup/$1/$fname"; done
find "/vmfs/volumes/datastore1/$1" -maxdepth 1 -type f | grep -v ".vmdk" | while read file; do cp "$file" "/vmfs/volumes/datastore_backup/$1"; done
find "/vmfs/volumes/datastore1/$1" -maxdepth 1 -type f | grep [0123456789][0123456789][0123456789][0123456789][0123456789][0123456789] | grep ".vmdk" | while read file; do cp "$file" "/vmfs/volumes/datastore_backup/$1"; done

Das Script habe ich dann für jede VM und die Datenplatte der NAS (liegt in eigenem Verzeichnis auf dem datastore) aufgerufen:

Code: Alles auswählen

./copy_vm "Windows 10"
./copy_vm "NAS"
./copy_vm "NAS_Data"
[...]

Danach habe ich mein RAID neu aufgesetzt. 20 GB extra für den ESXi. Die Konfiguration des ESXi habe ich wie hier beschrieben wiederhergestellt. Dann habe ich auf dem restlichen, freien Speicher der 20 GB ein datastore "datastore_esxi" eingerichtet. Im WebUI habe ich unter Verwalten => System => Auslagerung den Datenspeicher auf datastore_esxi geändert.

Anschließend habe ich mit dem selben Script wie oben die VMs zurück kopiert und die VMs registriert.

Dann sah zunächst alles gut aus, jedoch war der datastore nach etwa 200 GB Daten wieder voll.

Ich hatte dann zunächst vermutet, dass die Thin-VMDKs wieder den gesamten Speicher reserviert haben, aber mit

Code: Alles auswählen

vmkfstools -K

konnte ich keinen weiteren Speicher freigeben.
Jetzt ist mir jedoch aufgefallen, dass in den Verzeichnissen teilweise VMDKs liegen, die nicht mehr verwendet sind.
Ich habe noch VMs mit Snapshots - also scheint die Übernahme von Snapshots grundsätzlich funktioniert zu haben.

Bei einer VM beispielsweise habe ich eine Thin-Platte mit 500 GB und ohne Snapshots. Auf der VM existiert eine Partition mit 250 GB (der Rest ist noch unpartitioniert). Belegt sind letztendlich ca. 170 GB.
Diese VM hat insgesamt 5 VMDKs mit je 500 GB - also insgesamt 2,5 TB.

Im WebUI sieht man, dass die Festplatte die Endung 00005 hat. Alle anderen VMDKs habe ich nun gelöscht und die VM läuft immer noch. Heißt also, dass die überflüssig waren. Das Verzeichnis wurde dadurch von 2,5 TB auf 891 GB verkleinert. Aber so richtig gut ist das natürlich noch nicht bei effektiv ~170 GB verwendetem Speicher.

Gibt es eine Möglichkeit, die überflüssigen Dateien zu bereinigen?
Bei VMWare Workstation konnte man den Umweg über ein Clonen der VM gehen. Das scheint in ESXi nicht möglich zu sein.
Ich würde vermuten, dass ich jede VM einzeln bearbeiten muss. Alle Snapshots löschen und Festplatten konsolidieren. Danach im WebUI schauen, welche VMDK aktuell verwendet wird und die anderen löschen.

Zusätzlich würde ich auch

Code: Alles auswählen

vmkfstools -K

für alle VMDKs ausführen. Wenn ich das richtig verstanden habe, muss ich jedoch im Gast-VM zunächst den freien Speicher nullen, richtig?

Sorry für den langen Text und Danke für's Lesen. Ich weiß momentan nur nicht so recht, wie ich das am besten wieder grade gezogen bekomme.

Danke für eure Antworten!

[rprengel]

Sorry für den langen Text und Danke für's Lesen. Ich weiß momentan nur nicht so recht, wie ich das am besten wieder grade gezogen bekomme.

Danke für eure Antworten!

Hallo,

wenn ich das richtig lese hast du mehrere Baustellen.

1)
http://www.opvizor.com/orphaned-vm-snap ... ed-backup/
http://try.opvizor.com/snapwatcher/
Die Demo hilft dir ggf. einen Überblick zubekommen

https://communities.vmware.com/thread/553595
hilft vielleicht überflüssige Dateien zu identifizieren.
!! nicht selber getestet !!

2)
Zum verkleinern der Platten innerhalb der VMs gibt es hier im Forum einiges an Artikeln.
Ich hatte das Problem auch aber bei waren es immer nur zusätzliche Platten mit Daten die zu grosszügig konfiguriert waren.
Daher habe ich in diesen Fällen einfach eine neue leer Platte eingehängt, die Daten kopiert und dann nach Tests die zu grosse Platte abgebaut.

Gruss

[JustMe]

Aber die "groesste" Baustelle ist erst einmal Understanding VM snapshots in ESXi

Dann eine kleine Zusammenfassung hinterher, die moeglicherweise einleuchtet, sobald Du obiges verinnerlicht hast:
- Dein Skript funktioniert so nur sauber fuer VMs OHNE Snapshots. Und eigentlich nicht einmal da, weil es keine Unterscheidung zwischen Daten-vmdk und Deskriptor-vmdk macht.
- Snapshots sind eine verkettete Liste (bei mehreren Snaps EINER VM, selbstverstaendlich).
- vmkfstools -i "konsolidiert" bereits alle in der Kette vorhandenen Snapshots in die Zieldatei.
--> Somit hat das Skript fuer die VM mit z.B. 5 Snapshots beim 6-maligen (oder sogar 12x?) Aufruf von vmkfstools insgesamt 6 neue Basedisks (und nicht etwa Snapshot-Dateien) erstellt; mit jeweils unterschiedlichen Staenden.
--> Und dann hast Du nicht nur per vmkfstools kopiert/konsolidiert, sondern auch noch mit cp dieselben Dateien noch einmal hinterher kopiert.

Besser waere es vmtl. gewesen, sich die AKTUELLE(n) aktiven vmdk aus der .vmx auszulesen, und nur diese per vmkfstools zu kopieren.

[evolver]

Ja, da habe ich wohl im Eifer einen vermeintlichen Fehler auf der verlinkten Seite gefunden (dass nur das "Haupt-VMDK" konvertiert wird) und mir durch mein "Bugfix" dann erst wirklich Probleme verursacht.

Habe jetzt mit RVTools ein paar Dateien gefunden, die unnütz sind und sie entsprechend umbenannt. Die VMs laufen größtenteils ohne Probleme. Eine VM musste ich neu aufsetzen - aber das kann sein, dass die vorher schon ein Problem hatte.

Vielen Dank für die gute Unterstützung!

[Supi]

https://docs.vmware.com/en/VMware-vSphe ... notes.html

PR 1986020: ESXi VMFS5 and VMFS6 file systems might fail to expand
ESXi VMFS5 and VMFS6 file systems with certain volume sizes might fail to expand due to an issue with the logical volume manager (LVM). A VMFS6 volume fails to expand with a size greater than 16 TB.

This issue is resolved in this release.

Größerer Haken an der Sache, damit fällt aktuell der Support von Veeam als Backupsoftware aus.