Nach einem Upgrade von vSphere 4.1 auf 5 kann der datastore nicht erweitert werden

 

Führt man ein entsprechendes Update durch, und erweitert anschließend das Array des datastores um weitere HDDs, kann die Größe des datastores im vSphere Client nicht erhöht werden, obwohl die neue Größe korrekt angezeigt wird.

Hier hilft die gute alte SSH Konsole 🙂

SSH einschalten:

  • „F2“ an der lokalen Konsole: „Troubleshooting Options“

oder

  • vSphere Client: Host auswählen, „Konfiguration“, „Software“ – „Sicherheitsprofil“, „Dienste“ – „Eigenschaften“, „SSH“ => „Optionen

Nun verbindet man sich mit dem favorisierten SSH Client (z.B. PuTTY).

Nach dem root login helfen die folgenden Befehle (Pfade, etc. bitte anpassen):

  • vmkfstools -P "/vmfs/volumes/datastore"

    => Partiton span ermitteln (für partedUtil)

  • partedUtil get "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0"
  • Partition ermitteln (251=VMFS), ersten Sektor der Partition notieren
  • partedUtil getUsableSectors "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0"

    => Letzten Sektor notieren

  • partedUtil resize "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0" <partition> <startsektor> <endsektor>
    • z.B: partedUtil resize "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0" 2 10229760 213196319
  • vmkfstools --growfs "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0:<partition>" "/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0:<partition>"

    => GROWEN 😉

vmware: „Die Festplatten der virtuellen Maschine müssen konsolidiert werden“

Der vSphere Client hat Administratoren ja zu eine rleichen gelb-Allergie erzogen, und das ist auch gut so.

Im vSphere Client sieht man bei einer VM schon mal folgende Warnung:

Virtual machine disks consolidation is needed

oder in Landessprache:

Die Festplatten der Virtuellen Maschine müssen konsolidiert werden.

Normalerweise geht der nächste Click direkt in den Snapshot-Manager, aber dieser ist leer: Im Manager der VM wird kein einziger Snapshot angezeigt. Im Datastore hingegen sind durchaus ein bis mehrere -vtk.vmdk Dateien zu sehen.

Man wird die Snapshots über den vSphere-Client auch direkt wieder los: Snapshots -> Konsolidieren

Möglicherweise gibt es auch nach einigen Sekunden eine Warnmeldung, die Disk sei aber gelockt. In diesem Fall hat warscheinlich eine andere VM oder ein anderer Prozess die Snapshot Datei als Disk eingebunden oder geladen.

Das passiert schonmal bei Backups im Hot-Add Modus, z.B. von Veeam Backup im “Appliance” Modus. Dabei wird – technisch gesehen – ein Snapshot der zu sichernden VM generiert und direkt an den Veeam-Proxy angehängt.

Tipp: Welche VMs das Probelm haben ist in der VM-Übersicht schnell zu sehen, wenn man die Spalte „Konsolidierung erforderlich“ einblendet.

Exchange 2010 Verwaltungskonsole startet nicht: „Ausnahme beim Aufrufen von „GetSteppablePipeline“ …

Gestern ging es noch, heute startet die EMC (Exchange-Verwaltungskonsole) von Exchange 2010 nicht mehr:

„Ausnahme beim Aufrufen von „GetSteppablePipeline“ mit 1 Argument(en): „Die Datei C:Program FilesmicrosoftExchange ServerV14Remote ScriptsConsoleInitialize.ps1″ kann nicht geladen werden, die die Ausführung von scripts auf diesem System deaktiviert ist.“

Der Fehler tritt gerne auf, wenn man Sharepoint-Komponennten von einem Server deinstalliert, häufig beim SBS2011. Die Ursache ist, das das Sharepoint-Setup bei der Deinstallation die Ausführungsrichtlinie (ExecutionPolicy) auf „restricted“ setzt und damit praktisch jede Scriptausführung verhindert.

Den Status der der Policy zeigt:

get-executionpolicy

und den korrekten Zustand stellt das setzen der Policy wieder her:

set-ExecutionPolicy RemoteSigned

schon klappt die Konsole meistens wieder.

Manchmal bekommt man auch eine andere Fehlermeldung die so lautet:

Set-ExecutionPolicy : Access to the registry key ‚HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell‘ is denied.

At line:1 char:20

+ Set-ExecutionPolicy <<<< RemoteSigned

In diesem Fall half mir:

  • Reg://HKLMSOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell
  • Die Zeichenfolge „ExecutionPolicy“ mit dem Wert „RemoteSigned“ erstellen

und dann zur Sicherheit mit get-executionpolicy den Zustand noch einmal prüfen.

mod_fcgid: read data timeout in 120 seconds, referer: /nav-menus.php

In WordPress lassen sich Menüs nicht mehr bearbeiten? Du hast eine große Seite am Start mit vielen Pages und kann keine neuen Seiten mehr ins Menü aufnehmen? Das mag an deiner FastCGI-Limitierung liegen. WordPress (3.0 bis 3.x) nutz zur Menüverwaltung ein Ressourcenfressendes System das bei jedem Speichern ein gigantisches POST lostritt. Google hilft die passenden Diskussionen im WP-Bugtracker und den Foren zu finden. Wir wären aber schliesslich keine Admins, wenn wir keinen schnellen schmutzigen Fix zur Hand hätten:

fcgid.conf (Debian: /etc/apache2/mods-available/fcgid.conf)

IPCCommTimeout 240

Das Limit ist in Sekunden angegeben. Ob das generelle Erhöhen dieses Limits auf deinem Server allerdings eine gute Idee ist, liegt in deiner Verantwortung.