OMNI-OS Fehlermeldung: Zu wenig Speicherplatz für OmniOS.vmdk

[Traviso]

Hallo,

ich bekomme seit kurzem unter ESXi die Fehlermeldung "Es steht nicht genügend Speicherplatz für die virtuelle Festplatte „OmniOS.vmdk“ zur Verfügung. Sie können die Sitzung möglicherweise fortsetzen, indem Sie Speicherplatz auf dem betreffenden Volume freigeben und auf Wiederholen klicken." für meine OMNI-OS VM.

Da aber die OMNI OS VM bereits den ganzen Speicherplatz der SSD verwendet (minus der vServer VM), bin ich mir nicht sicher, was ich machen soll.

Hat jemand einen Tipp für mich ?

 

[gea]

Die Bootplatte (vmdk) von OmniOS ist wohl voll.
Wie groß ist die denn und wieviel ist frei?

Dann erstmal schauen ob es Bootenvironments (frühere Betriebssystemstände, Menü Snapshots > Bootenvironments) gibt, die man nicht mehr braucht. Falls man Snapshots auf dem rpool hat, kann man die auch löschen. Als nächstes kann man auf schauen ob es Crash Images gibt (auf oberster Ebene der Bootplatte) oder in /var/crash

Am Einfachsten nutzt man WinSCP oder mc (midnight commander) auf der Konsole um die Bootplatte zu durchsuchen/ Dateien zu löschen/ editieren.

 

[Traviso]

Vielen Dank für deine schnelle Rückmeldung!

Die Bootplatte (vmdk) von OmniOS ist wohl voll.
Wie groß ist die denn und wieviel ist frei?

Die Platte ist eine 240 GB SSD. In ESXi wird angezeigt, dass die OMNI OS Platte ca. 242 GB groß ist. Das passt eigentlich nicht so Ganz, da ja auch noch die vServer Appliance ca. 64 GB dieser SSD verwendet. Aber so ist es aus ESXi ersichtlich und so war es schon seitdem ich die VM installiert habe.
Die vServer VM war zuerst installiert, danach die OMNI OS VM.

Mit df -hl bekomme ich folgendes angezeigt:

Filesystem Size Used Available Capacity Mounted on
rpool/ROOT/omnios-r151034e 38.3G 904M 34.8G 3% /
/devices 0 0 0 0% /devices
/dev 0 0 0 0% /dev
ctfs 0 0 0 0% /system/contract
proc 0 0 0 0% /proc
mnttab 0 0 0 0% /etc/mnttab
swap 4.92G 332K 4.92G 1% /etc/svc/volatile
objfs 0 0 0 0% /system/object
bootfs 0 0 0 0% /system/boot
sharefs 0 0 0 0% /etc/dfs/sharetab
/usr/lib/libc/libc_hwcap1.so.1 35.7G 904M 34.8G 3% /lib/libc.so.1
fd 0 0 0 0% /dev/fd
swap 4.92G 8K 4.92G 1% /tmp
swap 4.92G 148K 4.92G 1% /var/run

Dann erstmal schauen ob es Bootenvironments (frühere Betriebssystemstände, Menü Snapshots > Bootenvironments) gibt, die man nicht mehr braucht.

Dort war <1MB an Dateien, die ich aber jetzt gelöscht habe.

Falls man Snapshots auf dem rpool hat, kann man die auch löschen.

Unter "Snapshots" tauchen keine Schnappschüsse auf rpool auf.

Als nächstes kann man auf schauen ob es Crash Images gibt (auf oberster Ebene der Bootplatte) oder in /var/crash

/var/crash ist leer.

 

[gea]

Ich vermute dass die vdisks "thin provisioned" angelegt wurden. Damit kann man den tatsächlichen Platz überbuchen, muss aber halt aufpassen, dass man nicht mehr nutzt als da ist, https://www.storage-insider.de/was-ist-thin-provisioning-a-862633/

Man könnte jetzt eine VM löschen und neu anlegen oder als Template sichern und neu bereitstellen (thick provisioned). Wenn die Installation komplexer ist, dann das aktuelle BE per ZFS Replikation auf den Datenpool sichern, eine Minimalinstallation von OmniOS z.B. auf einer thick provisioned 80GB Platte anlegen und dann das gesicherte BE zurückspielen, aktivieren und booten (Disaster Backup/Recovery eines laufenden Systems für OmniOS)

 

[Traviso]

Ich vermute dass die vdisks "thin provisioned" angelegt wurden. Damit kann man den tatsächlichen Platz überbuchen, muss aber halt aufpassen, dass man nicht mehr nutzt als da ist, https://www.storage-insider.de/was-ist-thin-provisioning-a-862633/

Ja, das könnte sein, dass ich damals thin provisioned gewählt hatte.

Man könnte jetzt eine VM löschen und neu anlegen oder als Template sichern und neu bereitstellen (thick provisioned). Wenn die Installation komplexer ist, dann das aktuelle BE per ZFS Replikation auf den Datenpool sichern, eine Minimalinstallation von OmniOS z.B. auf einer thick provisioned 80GB Platte anlegen und dann das gesicherte BE zurückspielen, aktivieren und booten (Disaster Backup/Recovery eines laufenden Systems für
OmniOS)

Vielen Dank für die Tipps. Da werde ich mich morgen einmal dran machen.

 

[Traviso]

Jetzt habe ich OmniOS und Napp-IT neu installiert. Weiterhin habe ich die ersten beiden Pools importiert. Leider hatte der zweite Pool beim Import den Namen des noch nicht importierten dritten Pools bekommen. Wie kann ich denn den Namen des Pools nachträglich ändern ? Irgendwie habe ich nichts gefunden.

 

[gea]

Beim ZFS Import kann man den Namen ändern/angeben.
Also Export, dann Import mit neuem Namen.

 

[Traviso]

Beim ZFS Import kann man den Namen ändern/angeben.
Also Export, dann Import mit neuem Namen.

Super, vielen Dank!