Michael Schroeder - ElasticSky

2. Februar 20132. Februar 2013

Nexus 7 Neustart nach Absturz

Ein Asus Nexus 7 (Android 4.2.1) hatte sich nach einem Absturz in einer endlosen Bootschleife festgefahren. Alle Versuche, durch längeres Drücken der Starttaste das Gerät neu zu starten scheiterten. Zuerst kam das Google Logo und dann nur noch flackernde Pixel auf einem schwarzen Hintergrund. Manchmal auch ein leerer Hintergrund in schwarz (Beleuchtung aktiv) oder in pink.
Anders als bei einem Smartphone kann man beim Nexus nicht einfach den Akku entfernen (es geht schon, erfordert aber Eingriffe in das Gehäuse).

Der Akku hatte sicher noch über 50% verbleibende Kapazität. Beim Anschluss an das Ladekabel erschien jedoch nicht das übliche weisse Batterie Logo.

Prozedur

Ladekabel verbinden. Falls zuvor die Batterie entladen war, sollte zunächst einige Zeit geladen werden.
Man muss in den Debug Modus gelangen. Dazu drückt man die Volume [-] Taste und den Hauptschalter gleichzeitig für mehrere Sekunden bis sich das Debugmenü öffnet.

Dort kann man mit Hilfe der Lautstärke Wippe die möglichen Aktionen wechseln bis dort “Power off” zu sehen ist. Mit der Starttaste (on/off) führt man die Aktion aus.

Nach der Abschaltung die Stromversorgung lösen.
Stromversorgung wieder einstecken. Jetzt sollte das Batteriesymbol erscheinen.
Nexus laden lassen bis der Akku voll ist (optional)

Das Tablet funktioniert wieder einwandfrei. 🙂

blogged somewhere in time…

1. Februar 201321. August 2013

Cluster Migration – EVC Modus

Dies ist ein häufig vorkommendes Szenario: Die ESXi Server eines bestehenden ESX-Clusters sollen durch neue Server ersetzt werden. Dank Techniken wie vMotion ist dies prinzipiell im laufenden Betrieb möglich.

EVC Modus

Der Enhanced vMotion Compatibility (EVC) Mode ermöglicht vMotion Vorgänge zwischen ESXi Hosts mit unterschiedlichen CPU Generationen. Dabei werden Funktionen der moderneren CPU maskiert, um eine einheitliche Basis aller Server im Cluster zu gewährleisten.

Das Szenario

ESXi mit intel Generation Penryn, die abzulösen sind
ESXi mit intel Ivy Bridge als neue Server
EVC im Cluster nicht aktiviert
VM Downtime schwierig

Was aber tun, wenn im bestehenden Cluster kein EVC aktiviert ist? Ein Beitritt eines neuen ESXi ist zwar möglich, aber vMotion von den alten ESXi zum neuen wird verweigert wegen CPU Differenzen. Das ist zunächst erstaunlich, den die neue CPU sollte alle Funktionen der alten CPU bieten. Eine Aktivierung des EVC Modus im bestehenden Cluster war nicht möglich, da sich laufende VMs darin befanden. Welche Optionen hat man nun?

Kalte Migration

Eine Möglichkeit die immer besteht, ist die kalte Migration. Das heisst: alle VMs abschalten und dann den EVC Modus aktivieren auf Basis der ältesten CPU im Cluster. Wenn man so weit ist, kann man auch gleich die Server kalt ersetzen und benötigt keinen EVC Modus. In Produktivumgebungen besteht diese Möglichkeit in der Regel nicht.

Live Migration

Die Live Migration ist das Mittel der Wahl in etwa 99% aller Szenarien. Genau an diesem Punkt scheitert man aber, wenn der EVC Modus nicht aktiviert war. Die Lösung ist die Erzeugung eines zweiten Clusters. Diesem treten die neuen Server bei und der EVC Modus wird auf den aktuellen Stand der neuen Server gesetzt (hier: Ivy Bridge i7). Nun kann man die VMs aus dem alten Cluster in den neuen migrieren. Regeln für HA und DRS müssen manuell angepasst werden.

Pro: keine Downtime
Contra: Clustereinstellungen und Regeln (DRS, HA) gehen verloren

Dabei ist zu beachten, daß alle mit vMotion migrierten VMs weiterhin mit ihren alten CPU Einstellungen laufen. Dies ändern sie erst bei einem Kaltstart (kein Reboot!).

Es ist empfehlenswert alle VMs im neuen Cluster zum nächstmöglichen Zeitpunkt zu beenden und danach neu zu starten. Ein Warmstart (reboot) genügt nicht! Erst dann nutzen die VMs die erweiterten Funktionen der neuen CPU des Hosts.

Der EVC Modus des Clusters sollte auch dann aktiv bleiben, wenn alle Hosts identisch sind. Wenn zu späterem Zeitpunkt ein Host der nächsten Generation zugefügt werden soll, ist das durch direkten Clusterbeitritt möglich.

23. Januar 201324. Januar 2013

NTFS Sicherheit: Ersteller Besitzer Objekt

Ein Verzeichnis soll für zwei Benutzergruppen zugänglich sein. Gruppe “Edit” soll lesen, schreiben und verändern dürfen. Die zweite Gruppe “Public” soll nur lesen dürfen, aber keine Daten verändern. Klingt einfach – und ist es eigentlich auch. Dennoch zeigt der Ordner ein eigenwilliges Verhalten: Jeder in der Gruppe Public konnte Dateien erstellen und diese auch ändern. Ursache war, daß es neben den Gruppen Public und Edit noch die Gruppe “Ersteller Besitzer” gab.

Die Gruppe “Ersteller Besitzer” kann problemlos entfernt werden. Sobald dies erfolgt ist, greifen die Zugriffsrechte wie oben geplant.

vSphere5.1: IODM mit esxcli

I/O Device Management (IODM)

Mit vSphere 5.1 kamen neue Funktionen zum Monitoring von Storage Adaptern zur esxcli hinzu. Der Namespace storage san hilft bei der Überwachung von iSCSI, FC, FCoE und SAS Protokollen. Der namespace

Verbindung zum Server

Zunächst muss dem Befehl eine Verbindungsinformation übergeben werden. Nach absenden des Befehls fragt der ESXi nach Nutzer und Kennwort. Diese können wahlweise auch direkt übergeben werden.

–username=<myuser> | -u=<myuser>
–password=<mypassword> | -p=<mypassword>

esxcli --server <ESXi Hostname> storage san <protocol> <cmd> <options>

Mit Übergabe der Zugangsdaten:

esxcli --server myESX.domain.com --user=root --password=mypassword storage san FC list

protocol: [FC | iSCSI | FCoE | SAS]
cmd: list, stats get, events get, reset
options: [–adapter | -A] vmhba<nummer>

Zeige Adapter

esxcli --server myESX.domain.com storage san FC list

Selektive Auswahl nur eines speziellen Adapters:

esxcli --server myESX.domain.com storage san FC list --adapter vmhba4

Zeige Adapter Statistiken

esxcli --server myESX.domain.com storage san FC stats get

Auch hier lässt sich die Auswahl mit der (–adapter) Option wieder auf einen speziellen vmhba begrenzen.

Autor: Michael Schroeder