Kategorie-Archiv: Allgemein

Linux root Partition im laufenden Betrieb vergrößern

Veröffentlicht am von — Keine Kommentare ↓

Heute Morgen ist eine root-Partition auf einem Debian Server vollgelaufen. Da es unter Linux leider keine so komfortablen Werkzeuge zur Volumenverwaltung wie unter Windows gibt, hier die etwas umständliche, aber ebenso vollständige Anleitung in Schritten.

Die Platte in diesem Beispiel ist /dev/sda und die vergrößerte Version hat 80GiB.

/dev/sda
   +--- /dev/sda1  --> / (Linux boot)   bisher 30GiB
   +--- /dev/sda2  --> Swap             bisher 5iB

In diesem Fall gab s auf dem Boot-Volumen auch noch eine Swap-Partition, die in diesem Zuge kurzerhand auf ein zusätzliches Volumen verschoben wurde. Glücklicherweise ist beides im laufenden Betrieb möglich.

Lösung

Neue Disk-Größe einlesen

Nachdem die „Festplatte“ vergrößert wurde, erkennt Linux auch das nach einem rescan des SCSI-Busses. Je nach System mussm an das * durch das/die echte/n Gerät/e-Pfade ersetzen.

echo "- - -" > /sys/class/scsi_host/*/scan
echo 1 > /sys/class/scsi_device/*/device/rescan

Partitionen und Layout ansehen

Dann kann man sich das aktuelle Partitionslayout und die größere Disk mit fdisk ansehen.

root@raumstation:~# fdisk /dev/sda

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sda: 80 GiB, 85899345920 bytes, 167772160 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x739a8a99

Device     Boot Start       End   Sectors Size Id Type
/dev/sda1  *     2048 167772126 167770079  80G 83 Linux

Command (m for help):q

root@raumstation:~#

Swap-Partition abschalten und entfernen

Die Linux-Swap Partiton schaltet man ab mit swapoff. Der Parameter -a entfernt alle Swap-Partitionen des Kernels. Wenn man aktuell mehrere nutzt, muss man natürlich nur die „falsche“ außer Betrieb nehmen.

root@raumstation:~# swapoff -a

Dann kann man die Partitionen bis zur Volumengrenze löschen.

root@raumstation:~# fdisk /dev/sda

<d> für "delete"
<2> Nummer für die Partitionsnummer (fdisk schlägt die höchste vor)
<w> für "Write"
<q> für "Auit"Quit"

Linux Boot Partition vergrößern

Die einfachste Möglichkeit ist das growpart Werkzeug. Das ist sehr klein und schnell installiert.

root@raumstation:~# apt-get install cloud-guest-utils

Dann gibt es den Befehl, der die Partition automatisch so groß wie möglich macht:

growpart /dev/sda 1

Linux Dateisystem vergrößern

Wenn die Partition vergrößert wurde, muss nun das Dateisystem darüber informiert werden. Das geht zum Glück ebenso schnell.

resize2fs /dev/sda1

Neues Swap-Volumen anlegen und einbinden

In diesem Fall haben wir ein zusätzliches Swap-Volumen angebunden (/dev/sde), mit einem rescan (siehe oben) im System sichtbar gemacht und darauf mit fdisk eine Partition angelegt.

Bei der Größe der Swap-Partition halten wir uns gerne an die steinalte Admin-Weisheit „Immer die Hälfte vom Arbeitsspeicher, mindestens aber 4 und nie mehr als 32g.“

Wenn das geschehen ist, erstellt man das Swap-System mit mkswap …

mkswap /dev/sde1

… und schaltet das swapping wieder ein:

swapon /dev/sde1

Migrationsoptionen („Migrieren“) für eine virtuelle Maschine sind ausgegraut

Veröffentlicht am von — Keine Kommentare ↓

Manchmal kommt es vor, dass eine VM „überraschend“ nicht mehr migriert werden will. Die VM wurde aber schon mal migriert, vMotion ist lizenziert (meint: korrekt eingerichtet), andere VMs migrieren auch, nur diese eine hat die Option im Menü grau („ausgegraut„). Es laufen auch keine Jobs mehr, die die Migration verhindern können. Also keine andere (Storage/vmotion-) Migration, kein Backup oder andere Replikationsaufgaben.

Wie passiert das?

Das Problem kann auftreten, wenn eine Sicherungs- oder Storage-Motion-Vorgang einer VM zwar abgeschlossen ist, aber und die Einträge in der (PostgreSQL-) Tabelle aus dem vCenter Server nicht entfernt wurden. Das kann auch mal passieren, wenn Backup-Ende und vCenter-Reboot unglücklich zusammenfallen.

Wer das genau warum gewesen ist und wer noch betroffen ist, kann man in der Datenbank zum Glück schnell nachschauen. Auf der Shell des vCenter Servers gibt dieses Statement die entsprechende Liste für alle Objekte aus:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres -c "select * from vpx_disabled_methods;"

Lösung

Wie bekommt man jetzt die Migrieren-Funktion zurück?

1. Man besorge sich die MO-ID („Managed Object“) ID der VM. Entweder aus dem MOB-Browser (https://VCENTER.EXAMPLE.COM/mob) oder direkt aus der URL vom vCenter GUI. Die URL enthält die MO-ID, wenn man im vCenter zu dem betreffenden Objekt navigiert und den Parameter „VirtualMachine:vm-1234568“ kopiert.

2. Man öffne das VM Ops Manager Interface unter:

https://VCENTER.EXAMPLE.COM/mob/?moid=AuthorizationManager&method=enableMethods

3. In selbigen fügt man oben („entity“) für „MOID“ die MO-ID (aus Schritt 1) ein und in der Mitte („method“) die Methode zum reversen des Feldes für „RelocateVM_Task“. Also genau dieses XML:

Oben („entity“)

<!-- array start -->
<entity type="ManagedEntity" xsi:type="ManagedObjectReference">vm-12345678</entity>
<!-- array end -->

Mitte („method“)

<Methode>RelocateVM_Task</Methode>

4. Unten rechts „Invoke Method“ führt die Methode aus und setzt die Felder zurück.

Der Erfolgsbericht folgt auch sofort, in maschinenlesbarer Form. Ein „Refresh“ im vCenter danach offenbart auch sofort die vermisste „Migrieren“ Funktion wieder.

HPE Alletra 5000/6000 (ehem. NimbleStorage) in GreenLake hinzufügen

Veröffentlicht am von — 1 Kommentar ↓

Möchte man heute ein HPE Alletra Array der 5 oder 6000er Serie in Betrieb nehmen, muss man es zunächst in HPE GreenLake hinzufügen und mit der Data Services Cloud Console (DSCC) verbinden. Das geht leider nicht (mehr) ganz wie in sämtlichen Dokumentationen beschrieben, daher hier einmal kurz zusammengefasst:

  1. HPE Account erstellen (sofern noch nicht erfolgt) und die Subscription aktivieren (Aktivierungslink und Details sollten bei Array-Bestellung per Mail kommen)
  2. GreenLake Workspace erstellen
  3. Storage -> Data Services in dem GreenLake Workspace „provisionieren“
  4. Oben links im Menü neben dem GreenLake Logo unter Manage Users dem Benutzer via …-Menü Assign Role die Administrator Rolle für Data Services zuweisen
  5. Dann oben unter Devices im Inventory Add Device klicken, Storage Devices als Device Type auswählen, Purchase or Lease auswählen, die AF-XXXXXX Seriennummer als Serial Number und die Modellbezeichnung (z.B. 5010 für eine Alletra 5010) als Product Number verwenden und den Assistenten zuende Klicken.
  6. Unter Device Subscriptions kann man dann in gleicher Art mit dem Subscription Key die Subscription hinzufügen.
  7. Jetzt kann man den Setup-Assistenten des Arrays (aus dem Nimble Setup Manager) zu ende klicken und via Data Services -> Setup Service das Array konfigurieren.

HPE Alletra (Nimble) NCM auf ESXi Hosts installieren/aktualisieren

Veröffentlicht am von — Keine Kommentare ↓

Das Alletra Multipath-IO (MPIO) braucht den „Nimble Connection Manager“ (NCM) für vSphere. Das ist ein kleines VIB auf dem ESXi Host.

⚠️ Die Installation des selbigen erfordert zwei (!) reboots des Host.

Das VIB kann man aber zum Glück auch ohne offline-Zauberei, Download aus dem Infosight-Support-Center und so weiter installieren. Noch nicht alle Teile von HPE wurden vom Greenlake-Virus zerstört 🙂

Lösung

Den NCM an der Konsole installieren oder aktualisieren:

esxcli software component apply -d https://update.nimblestorage.com/esx8.0/ncm

Dazu muss der ESXi Hosts selbstverständlich (temporär) ins Internet dürfen. Obwohl die Installation nach dem Abschluss behauptet Reboot Required: false ist dieser notwendig, sonst greifen die MPIO-Policies nicht.

FSLogix automatisch aktualisieren (FSLogix autp Update) [UPDATE]

Veröffentlicht am von — Keine Kommentare ↓

Update: Im FSLogix-Paket haben sich Pfade geändert, die unnötige Fehlermeldung zu Beginn ist entfernt und die Pfade sind angepasst.

Leider ist FSLogix nicht in Windows-Update(s) enthalten. Der Admin einer RDS-Farm muss also selbstständig für seine Updates sorgen.

Da es aber in der Tat häufiger mal Updates für FSLogix gibt (Siehe Hotfix-Liste), die beispielsweise Fehler mit der Microsoft Office 365 Aktivierung beheben, lohnt es sich diese auch wirklich zu installieren. Man kann das Setup in derselben Version auch mehrfach ausführen, es wird nur installiert, wenn wirklich etwas Neues dabei ist.

Der Vorgang ist prinzipiell einfach: Neue Version herunterladen, ZIP-Datei auspacken, App-Installer ausführen und Server neu starten. Wäre das nicht toll, wenn das auch automatisch geht?

Lösung

Bei dem letzten Einsatz, der das Problem „Leeres Microsoft 365 Anmeldefenster“ behebt, ist ein PowerShell Script das selbiges tut entstanden. Einsatz auf eigene Gefahr ☺️

# Update FSLogix to "latest"
# [email protected]
#
# Achtung: BOOTET bei Erfolg den Server neu, ohne Rueckfrage!

# Aktuelle FSLogix-Version liegt hier
$FslogixUrl= "https://aka.ms/fslogix_download"

# Download landet hier
if ( Test-Path "C:\Windows\Temp\fslogix\install" ) { Remove-Item "C:\Windows\Temp\fslogix\install" -Force -Recurse }
mkdir "C:\Windows\Temp\fslogix\install" -Force | Out-Null
Write-Host "Download von" $FslogixUrl "... (180Mbyte)"
# Ausblenden der ProgressBar macht den Download 5x schneller
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $FslogixUrl -OutFile "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -UseBasicParsing

# Auspacken
Write-Host "Auspacken von C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip ..."
Expand-Archive -LiteralPath "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -DestinationPath "C:\Windows\Temp\fslogix\install" -Force -Verbose
Set-Location "C:\Windows\Temp\fslogix\install\x64\release"

# Installieren + Neustart
Start-Process "FSLogixAppsSetup.exe" -ArgumentList "/install /quiet" -Wait -Passthru