Snapvault Lagtime mittels Powershell abfragen

Die Lagtime einer Snapvault-Relationship lässt sich mittels Powershell wie folgt abfragen:
>Get-NaSnapvaultSecStatus

Um alle Relationships anzeigen zu können, welche mehr als einen Tag nicht mehr aktualisiert worden sind, kann man folgende Bedingung setzen:
>Get-NaSnapvaultSecStatus | Where-Object {$_.LagTime -gt 86400}

Das Feld LagTime ist im Standardoutput nicht sichtbar. Es enthält das Lag-Delta in Sekunden.

VMWare Workstation "drag and drop" Problem

Nach dem Upgrade von VMWare Worksation 6.x auf 6.5 und dem aktualisieren der VMWare-Tools auf die neuste Version funktionierte plötzlich die gewohnte "drag and drop"-Funktionalität zwischen Hostsystem und VM nicht mehr richtig. Alle gängigen Ratschläge wie das Neuinstallieren der VMWare-Tools fruchteten nicht und das Problem trieb mich fast in den Wahnsinn, funktionierte es doch vorher immer. Files die per drag and drop ausgetauscht werden, landen immer zunächst im Tempfolder des Zielsystems. Ich konnte sogar beobachten, dass dies mittels einem temporären Verzeichnis initialisiert wurde, jedoch landeten die Dateien anschliessend nicht darin.
Die Lösung war erschreckend einfach. Ich musste lediglich auf den VMs die Anzeigeoptionen anpassen und die Farbtiefe von 16 Bit auf 32 Bit erhöhen. Das wars.

GUI für Storage VMotion

Mit ESX 3.5 und VC 2.5 wird der Traum eines jeden Admins wahr. Virtuelle Maschinen können nun im laufenden Betrieb auf einen anderen VMFS-Store migriert werden. Leider funktioniert das derzeit aber nicht via VC, sonder nur über das neue Remote CLI.

Koen Warson stellt auf seiner Webseite jedoch ein cooles GUI dafür zur Verfügung. Ein weiteres Feature des Tools ist die Möglichkeit, auf mehreren ESX Hosts gleichzeitig einen Rescan der HBAs durchzuführen

http://www.svmotion.com/

HA-Probleme nach Upgrade auf VC 2.5

Nach dem Update von Virtual Center auf Version 2.5 liess sich HA auf den Hosts unserer beiden Cluster nicht mehr konfigurieren. Auch die Option "Reconfigure for VMware HA" brachte keinen Erfolgt. Die Lösung war dann ganz einfach HA auf Clusterebene zu deaktivieren und nach der Neukonfiguration aller Hosts wieder zu aktivieren.

VM aus ESX exportieren

Wenn man eine VM aus einer ESX-Plattform nach VMWare Workstation zügeln will stösst man auf das Problem, dass Windows nicht mit dem VMFS-Format der ESX-Diskfiles umgehen kann. Mittels vmkfstools lassen sich die Disks aber konvertieren. Das gleiche Verfahren funktioniert auch in die andere Richtung.

Folgender Befehl konvertiert ein ESX-Diskfile in eine für Windows lesbare Form:
vmkfstools -i ./vmserver1.vmdk -d 2gbsparse ./vmserver1.vmdk

Dieser Artikel hier beschreibt sämtliche Optionen im Detail:
http://decipherinfosys.wordpress.com/2007/02/25/exporting-and-importing-virtual-machines-using-vmkfstools/

Geniales SQL Tutorial

Auf folgendes geniale Tutorial bin ich heute zufällig gestossen. Auf den ersten Blick sieht es zwar eher auf Anfänger ausgerichtet aus, auf den zweiten geht es aber schön in die Tiefe und erklärt auch komplexere Statements anhand von guten Beispielen. Daumen hoch.

http://www.sql-und-xml.de/sql-tutorial/index.html

Netapp Aggregat down wegen einzelnem Diskfehler

Mein neustes Leiden geht in die Kategorie der Fehler die man niemals erwarten kann. Auf unserer Netapp 3040 spukte heute eine Disk, welche dafür sorgte, dass das ganze Aggregat, bestehend aus 31 Disks, einen massiven Performanceeinbruch erlitt. Vermutlich war zwar nur die darunter liegende Raidgruppe beeinträchtigt, aber die Auswirkungen waren dennoch massiv. So verloren die daran gemounteten SAN-LUNs teilweise die Verbindung zur Storage und switchten mehrmals über alle Pfade. Was das für Exchangeserver bedeutet kann sich jeder ausdenken.
Bei der Fehleranalyse konnten wir ausschliessen dass das Problem generell mit dem Filer zu tun hatte, da andere Server mit LUNs auf dem gleichen Head keine Probleme hatten. Auch die FC-Fabrics und das Zoning waren in Ordnung und schieden somit aus. Der einzige gemeinsame Nenner der Exchangeserver, das Aggregat in welchem die LUNs lagen, an erbot sich jedoch nicht als Fehlerquelle. Doch genau hier lag der Hund begraben. Nach etwa einer halben Stunde tauchte zum ersten mal im \etc\messages folgender Eintrag auf:
scsi.path.excessiveErrors:error]: Excessive errors encountered by adapter 0c on disk device 0c.#.
Leider wurde die Disk aber nicht als fehlerhaft markiert und konnte somit das System weiter stören. Nach einer weiteren Analyse und einem manuellen deaktivieren der Disk erholte sich das Aggregat dann aber schlagartig wieder. Der alles rettende Zauberbefehl lautete diesmal wie folgt. Der -o Switch erzwingt ein sofortiges abschalten der Disk, da die Storage ansonsten zuerst noch versucht die fehlerhafte Disk auf eine Spare zu synchronisieren.
disk fail -o <diskid>
Eine redundante Storage, redundate FC-Fabrics, redundante HBAs und ein fleissige Snapdrive das brav versucht seine LUNs am Leben zu halten auf der einen Seite unterliegen einer fehlerhaften Disk auf der anderen Seite - und das alles an einem Freitag. Ich bin schon mal gespannt auf die Analyse von Netapp. Zum Glück ist jetzt Freitag Abend. :-)

Kixstart Scripts verifizieren

Kixtart ist eine weit verbreitete Umgebung für Logonscripts. So kann man z.B. ganz einfach nach AD-Gruppen basierte Laufwerkmappings vornehmen. Bei grösseren Umgebungen werden solche Scripts aber schnell mal unübersichtlich und schwer zu warten. Mit dem Tool KiXStrip lassen sich Scripts einfach verifizieren. Der Syntax dazu lautet wie folgt:

kixstrip inputput.kix output.kix /block_check

Ade dasBlog und willkommen auf Subtext

Der Umzug meines Blogs auf meinen eigenen Server ist endlich vollbracht. Die momentane Adresse wird nun wohl eine Weile in Betrieb bleiben, vermutlich ändert aber die Domain gelegentlich noch.

Der Umzug von dasBlog auf SubText war leider eine regelrechte Tortur bei der mich aber Alex super unterstützt hat. Ohne ihn hätte ich es wohl nie geschafft den XML-Müll von dasBlog in sauberes BlogML zu konvertieren. Nochmals vielen Dank an dieser Stelle.

Tool der Woche: SQLRecon

Alle Jahre wird in grösseren Firmen das unbeliebte "Such-die-Lizenz" Spiel durchgeführt, bei welchem gegenüber dem Management, aufgeführt werden muss wieviele SQL-Instanzen welchen Kalibers auf wievielen Prozessoren sich gegenwärtig im Betrieb befinden. Natürlich ist die Ausgangslage für den verantwortlichen SQL-Fuzzi ebenfalls wiederkehrend die selbe: obwohl man fleissig Buch führt stimmt die Liste nie. Da ein paar Testserver die immer noch laufen, dort ein paar Leichen und dann noch die ganzen virtualisierten Servern mit neuer CPU-Bestückung...
Was also tun?

Per Zufall bin ich auf folgendes Juwel gestossen, welches einen Netzbereich durchforsten kann und sauber alle SQL Instanzen inkl. Patchlevel etc. identifiziert. Ihm gehört das "wow" der Woche:

http://www.specialopssecurity.com/labs/sqlrecon/

Und ja... das Blog lebt noch. Ich gelobe Besserung. :-)