Windows: Automount abschalten

Es gibt Szenarien, da muß ein Windows system Zugriff auf VMFS Volumes bekommen. Z.B. bei SAN basiertem Backup mit Veeam. Bevor man aber einen Windows Server an eine Storage mit VMFS Volumes heran läßt, muß man ihm unbedingt die Automount Funktion neuer Datenträger verbieten.

Man verwendet unter Windows das DISKPART Tool.

Kommandozeile öffnen (unter Server2008 die Adminkonsole) und DISKPART eingeben.

DISKPART> automount disable
DISKPART> automount scrub
DISKPART> exit

Kontrolle  durch Eingabe von Aoutomount ohne Parameter

DISKPART> automount

Reboot

Server neu starten (wichtig!).

Ab jetzt wird das System nicht mehr ungefragt Signaturen schreiben, außer man fordert es aktiv dazu auf.

Was man tun kann, wenn man den Schritt oben vergessen hatte und Windows netterweise die VMFS Volumes auf der Storage mit einer Signatur versehen hat, ist bei Yellow-Bricks zu lesen. Besser man unterbindet das im Vorfeld. 😉

 

WP7.5: Eigene Klingeltöne

Okay, das ist etwas OT, aber ich fand die Info dennoch wichtig genug, um sie festzuhalten. 😉

Nach dem erfolgreichen Update von WindowsPhone 7 auf WindowsPhone 7.5 (Codename Mango) kann man jetzt (endlich) eigene Klingeltöne erstellen und verwenden. Was für ein Fortschritt für die Menschheit! (Das konnte mein altes WindowsMobile 6.1 auch schon)
Aber da es insgesamt ein schönes, flüssiges System ist und kein angenagtes Obst enthält, mag ich nicht meckern.

Eine schöne Anleitung zum Import findet sich im WindowsBlog.

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.

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