Schlagwort: VM

Veröffentlicht am

Storage DRS default affinity

Mit Einführung von vSphere5 kam Storage-DRS als eine neue Funktionalität hinzu. Ähnlich dem herkömmlichen DRS, welches die VM Lastverteilung bezüglich Arbeitsspeicher und CPU zwischen den ESXi Knoten regelt, ermöglicht Storage-DRS eine automatische Lastverteilung in Bezug auf Speicherplatz und I/O.

In der Praxis beobachtet man jedoch häufiger, daß VMs oder einzelne ihrer vDisks nicht migriert werden, obwohl erhöhte Last über einen längeren Zeitraum auftritt. Die Ursache, warum Storage-DRS beispielsweise nicht die vDisk einer VM verschiebt, welche die stark beanspruchte Datenbank enthält, fand ich durch einen Blogartikel von Duncan Epping auf Yellow-Bricks.

Die Standard Einstellung eines jeden Storage Clusters ist “VMDKs zusammenhalten” bzw. “keep VMDK’s together”. Eine Default Einstellung, die sicherlich dem Admin entgegenkommen soll, damit er nicht alle Disks seiner VM auf mehrere LUNs verteilt suchen muß. Der Preis für diese “Ordnung” ist allerdings, daß die Dateien einer VM nur komplett oder gar nicht verschoben werden. In der Praxis bedeutet dies, daß z.B. eine VM mit 5 vDisks von je über 100 GB nur unter extremsten Bedingungen auf eine andere LUN wandern würde. Wünschenswert wäre jedoch, daß beispielsweise nur eine einzelne VMDK Datei verschoben wird, da diese gerade unter erhöhten I/O Druck geraten ist.

Die nett gemeinte, aber etwas unflexible Standardeinstellung dieses Verhaltens läßt sich leicht ändern:

  •  Ansicht Datenspeicher und Datenspeicher Cluster
  • Kontextmenü von Datenspeicher-Cluster öffnen und “Einstellungen bearbeiten” wählen
  • Einstellungen der VM
  • Haken bei “VMDKs zusammenhalten” entfernen. Entweder für einzelne VMs oder global für den gesamten Storage-Cluster.

Weiterführende Literatur

Frank Denneman zum Thema impact of intra vm affinity rules on storage drs.

Veröffentlicht am

vSphere5: Zombie VM mit PowerCLI abschiessen

Gelegentlich kommt es vor: Eine VM läßt sich werder beenden, hart abschalten, noch neu starten. Ein sogenannter Zombie.

Unter vSphere5 funktionieren PowerCLI und ESXCLI etwas anders als unter vSphere 4.x.

Methode1: (Soft)

> $VM = Get-VM.<VM-Name>
> $esxcli = Get-EsxCli -vmhost ($VM.Host)
> $WorldID = ($esxcli.vm.process.list() | Where { $_.DisplayName -eq $VM.Name}).WorldID
> $result = $esxcli.vm.process.kill("soft", $WorldID)
> $result

Methode2: (Hard)

…und bist Du nicht willig….. 🙂

> $VM = Get-VM.<VM-Name>
> $esxcli = Get-EsxCli -vmhost ($VM.Host)
> $WorldID = ($esxcli.vm.process.list() | Where { $_.DisplayName -eq $VM.Name}).WorldID
> $result = $esxcli.vm.process.kill("hard", $WorldID)
> $result

Auch Wildcards lassen sich hier einsetzen (Achtung!):

> $VM = Get-VM.<VM-Namepart>*

Schiesst alle VMs ab, die mit dem Teilamen beginnen. Weitere Informationen zum Thema finden sich im Originalpost bei Virtu-Al. Dort befindet sich auch eine PS Funktion, die obige Befehle vereinfacht. Die Syntax ist dann reduziert auf:

Get-VM <VM-Name> | Kill-VM

Eine alternative Methode bedient sich der esxcli cmdlets

Dies ist eine moderne Abwandlung (vSphere 5) einer Methode, die ich in einem älteren Artikel unter vSphere 4.x beschrieben hatte.

connect-viserver esx1.mydomain.com

Alle aktiven VM Prozesse auflisten.

$esxcli = get-esxcli
$esxcli.vm.process.list()

Hier muss man die WorldID der Zombie-VM notieren.

Klar zum Abschuss!

$esxcli.vm.process.kill("hard", <WorldID>)

Hier ist <WorldID> durch 3867 zu ersetzen.

Veröffentlicht am

vSphere5: Probleme mit Veeam 5.0.2

Wir erlebten kürzlich in einer brandneuen vSphere 5.0.0 Umgebung eine Überraschung mit Veeam (5.0.2). Zunächst lief alles rund und auch die Sicherungsjobs konnten erfolgreich abgeschlossen werden. Als ordentliche Dienstleister testet man natürlich die Wiederherstellung aus dem Backup. Zunächst den File-Level Restore. Dieser funktionierte ohne Probleme. Danach testeten wir ein Full VM Restore. Beim Versuch bekamen wir jedoch folgende Meldung:

Das Filesystem auf dem Datastore ist VMFS5 (nativ, 1MB Blocksize), vCenter ist die VMware Appliance (5.0.0). Das ausführende Konto hat volle Rechte auf den Datastore. Eine Suche im Veeam-Forum brachte etwas Licht ins Dunkel (Link).

Wie man dennoch wiederherstellen kann:

„vSphere5: Probleme mit Veeam 5.0.2“ weiterlesen

Veröffentlicht am

vCenter: Entfernen von Snapshot scheitert (concurrent access)

Beim Versuch einen Snapshot zu entfernen wird folgende Fehlermeldung ausgeworfen:

Ein allgemeiner Systemfehler ist aufgetreten: concurrent access

bzw in englisch:

A general system error occurred: concurrent access

Der Fehler wird erzeugt, wenn zwei oder mehrere Prozesse gleichzeitig auf eine vDisk zugreifen wollen.

Abhilfe: Neustart der Management-Agents auf dem Host, welcher die Fehlermeldung ausgibt. Vgl VMware KB 1027078. Dazu auf der ESX Konsole anmelden, ins Menü “Troubleshooting Options” gehen und die Agenten neu starten.

Danach lassen sich die Snapshots i.d.R. wieder entfernen.