Archiv für die Kategorie » VMWare «

07 | 03 | 2017

Leider kein April-Scherz – neue VMware-Zertifizierungspreise

Geschrieben von um 22:46 Uhr

Ab dem 01. April wird VMware die Zertifizierungspreise „anpassen„. Und während man vielleicht die Erhöhung von $400 auf $450 (12,5%) für Advanced-Zertifizierungen noch verschmerzen kann, tun mir die besten der besten armen Schweine leid, die vorhatten, ihre VMware-Recognition mit einem VCDX-Titel zu krönen. Statt $1200 (300 Registrierung + 900 Verteidigung) müssen sie nun $3900 löhnen (900 Registrierung + 3000 Verteidigung). Das ist eine Erhöhung um 225%. Und dass man dafür von Duncan Epping persönlich zerlegt wird, lindert den Schmerz vermutlich nur marginal.

Einmal ausnahmsweise ist es ein gutes Gefühl, nicht zu den besten auf einem Gebiet zu gehören…

*seufz*

Tags » , , «

+

24 | 02 | 2017

Das war mal wieder soweit…

Geschrieben von um 15:14 Uhr

… und ich musste meinen VCP erneuern. Diesmal beschloss ich, dies im Wege eines Delta Exams zu tun. Das ging gut, aber ich denke, nächstes Mal mache ich mal wieder eine volle Prüfung. Der Aufwand ist derselbe und der Stressfaktr etwas weniger 😉

Tags » , , «

+

10 | 02 | 2017

Der beste Wandschmuck: ein PowerCLI 6.5R1-Poster

Geschrieben von um 22:58 Uhr

Für Leute mit Platz an der Wand und einem Großformatdrucker: https://blogs.vmware.com/PowerCLI/2017/02/powercli-65-poster.html

Tags » , , «

+

07 | 10 | 2016

MAP in einer Workgroup-Umgebung

Geschrieben von um 22:30 Uhr

Heute mal etwas leichtere Kost, eher als Reminder gedacht.

Das Microsoft Assesment & Planning Toolkit ist ja ein bewährtes Mittel zur systemübergreifenden Performance-Analyse. Zum Beispiel, um eine Konsolidierung von Servern von Physik und „wilder Virtualisierung“ auf geordnete virtuelle Plattformen oder in die Cloud zu modellieren. So auch heute. Die Herausforderung jedoch war, dass nur einer der zu betrachtenden Server tatsächlich Domänen-Mitglied ist – und zwar in einer Domäne, in die der MAP-Server natürlich nicht aufgenommen werden durfte! Alle anderen Server gehören keiner Domäne an, und die meisten von ihnen haben nur den Default-„Administrator“ an Konten eingerichtet. Das Kennwort von diesem Administrator ist zwar nicht überall unterschiedlich, aber auch nicht überall gleich – ca. die Hälfte der Server hatte „Kennwort1“, und der Rest teilte sich in etwa gleichmäßig in „Kennwort2“ und „Kennwort3“.

Landet man in einer solchen Situation, so muss man folgendes berücksichtigen:

  • „.\Administrator“ kann MAP nicht erfassen, nur „Administrator“ oder „<COMPUTER>\Administrator“
  • Jedes Account kann in der exakten Schreibweise nur einmal vorkommen, das Erfassen von „Administrator“ mit unteschiedlichen Passwörtern ist also nicht ohne weiteres möglich
  • Im Inventory-Teil kann man jedem Eintrag, wenn man ihn manuell eingibt, oder jeder Liste, wenn man sie aus Dateien einliest, ein eigenes Konto zuweisen.
  • Im Performance-Sammlungs-Teil gibt es diese Funktion aber nicht – da kann man NUR eine Liste von Accounts zum Durchprobieren erfassen!
  • Die Schreibweise „<COMPUTER>\Administrator“ wird im Performance-Sammlungs-Teil nur für den Computer akzeptiert, der auch tatsächlich da steht. Somit mussten wir die Durchprobier-Liste in Form „Administrator – Kennwort1″,“DomainUser – DomainKennwort“, „SERVER2A\Administrator – Kennwort2“, „SERVER2B\Administrator – Kennwort2″,…“SERVER2Z\Administrator – Kennwort2″,“SERVER3A\Administrator – Kennwort3“,… erfassen. Alles andere hat nicht funktioniert.
  • Im Inventory-Teil (WMI) wird hingegen auch ein „fremder“ Computername angenommen, wenn nur der Benutzername und das Kennwort passen.

Last but not least: Die eingegebenen Accounts werden bei Abmeldung „vergessen“ und stehen beim nächsten Aufruf von MAP nicht zur Auswahl.

In einer Domänen-Umgebung wäre das alles überhaupt kein Problem…

 

Tags » , , «

+

24 | 04 | 2015

VCP550-DCV Rezertifizierung

Geschrieben von um 16:31 Uhr

Ich hatte ja meine VCP-Zertifizierung schon verloren geglaubt… dann hat VMware aber bis 09.05.2015 verlängert, und ich konnte mich doch noch anmelden 🙂

Nun habe ich zwei Jahre Ruhe auf dieser Front, bin aber gespannt ob man die Complimentary Workstation License bei jeder Rezertifizierung auf dem aktuellen Versionsstand bekommt. Das wäre doch schön…

Tags » «

+

10 | 05 | 2014

Exchange DAG-Member und vMotion/Live Migration

Geschrieben von um 8:06 Uhr

Gestern Abend, in der Diskussionsrunde nach dem Treffen der Berliner Windows Server UG, fiel aus einem in der Szene sehr respektierten Mund der Satz (sinngemäß): „Man darf Exchange 2013-Server verschieben, aber nur mit LiveMigration, also nur auf Hyper-V“. Dies hörte sich nicht richtig an, also habe ich nachgelesen (Ausgangspunkt war dabei TechNet). Tatsächlich ist folgendes der Fall:

  • Man kann DAG-Member im Betrieb verschieben, allerdings nicht erst seit 2013, sondern bereits ab 2010SP1
  • Wichtig für den Support ist nicht der Hypervisor (solange er Teil der Virtualisierungsinitiative ist), sondern das Verfahren. Es darf nämlich kein Zustand der VM auf die Festplatte zwischengespeichert werden. Somit sind neben LiveMigration auch vMotion und XenMotion qualifiziert und vermutlich auch weitere Verfahren, nicht jedoch z.B. Quick Migration
  • Support für das Verfahren wird vom Hypervisor-Hersteller bereitgestellt. VMware pflegt dazu das Best Practices-Dokument https://www.vmware.com/files/pdf/Exchange_2013_on_VMware_Best_Practices_Guide.pdf . Sicherlich gibt es auch ein ähnliches Dokument von Citrix, wenn ich es finde, poste ich den Link hier. Wichtig dabei ist, dass die Elastizität des Clusters etwas erhöht wird, um Spontanfailover während einer vMotion/LiveMigration zu vermeiden.

Bleibt also noch die meistgehasste Frage, nämlich nach der Lizenzierung eines solchen Verfahrens. Hier gilt (s. offiziellen Guide) das Übliche:

  • VL mit SA = Mobilität innerhalb der Farm
  • VL ohne SA = 90-Tage-Bindung an die Hardware
  • Retail oder OEM = keine Mobilität

Die Sinnhaftigkeit der Virtualisierung von DAG-Membern ist freilich nicht Gegenstand der Diskussion 😉

Tags » «

+

15 | 01 | 2012

Kostenloses ESXi mit vCenter verwalten?

Geschrieben von um 13:45 Uhr

Das ist wohl eher ein Kuriosum als ein produktiv einsetzbares Merkmal. Dennoch möchte ich es nicht unerwähnt lassen:

Man kann einen auf kostenfreie Version lizentzierten ESXi 4 (in dem vorliegenden Beispiel 4.0.0 Build 208167) zu einem vCenter 5 (in dem vorliegenden Beispiel vCenter Appliance 5.0.0 Build 455964) hinzufügen.

Tags » , , , , «

+

05 | 01 | 2012

VCP5 Zertifizierung

Geschrieben von um 13:38 Uhr

Nach dem Kurs im Dezember und einiger Vorbereitung bin ich ab heute VCP auf vSphere 5. Yay!

Tags » , , «

+

20 | 11 | 2011

Die ESXi 5-Konsole auch per SSH

Geschrieben von um 13:32 Uhr

Manchmal hat man keine Lust auf lange Shell-Befehle und möchte einfach nur auf die Konsole seines Hosts – dieser steht aber weit weg, und iLO, iDRAC o.ä. ist entweder nicht da oder nicht ausreichend lizenziert. Bei ESXi 5 gibt es jetzt Abhilfe – vorausgesetzt, die Dienste „SSH“ und „ESXi Shell“ sind an und in der Firewall freigeschaltet (ja, auch der ESXi hat jetzt eine Firewall). Dies ist übrigens kein „UNSUPPORTED“-Modus mehr.

Nach der erfolgreichen SSH-Anmeldung gibt man am Prompt einfach

dcui

ein:

… und schon hat man, wenn auch in Schwarz/Weiß, die gewohnte Oberfläche:

mit allen Einstellungen, die man von der Konsole her kennt, mit Ausnahme des Tastatur-Layouts:

„DCUI“ steht übrigens für „Direct Connect User Interface“.

Enjoy!

Tags » , , , «

+

16 | 10 | 2011

vSphere Storage Appliance – Installation und erste Eindrücke

Geschrieben von um 19:57 Uhr

Ich hatte ja schon über die grundlegenden Eckdaten der VSA geschrieben (hier). Seither sind einige Wochen vergangen, in denen ich anderes zu tun hatte, aber nun möchte ich den VSA-Thread endlich fortführen.

Heute wollen wir die Installation der VSA live ausprobieren. VMWare verspricht eine Installation in 15 Minuten, was durchaus zutreffen kann, wenn die Voraussetzungen (über welche ich in dem o.g. früheren Beitrag schon ausführlich schrieb) geschaffen wurden – was freilich gut und gerne eine Stunde in Anspruch nehmen kann.

Als erstes wird auf dem vCenter Server die Installations-CD eingelegt. Ohne größere Abfragen oder bunte Splash-Screens startet der Installationsvorgang, der übrigens gleich die über das Netzwerk erreichbare vSphere-Infrastruktur inventarisiert. Sie muß in diesem Augenblick noch nicht vollständig stehen, aber es erleichtert die Sache.

Danach ist im vSphere Client (im Datacenter-Knoten) ein neuer Tab verfügbar: VSA Manager. Dieser benötigt Flash, im Gegensatz zu den anderen Komponenten des vSphere Clients. Es ist noch keine aktive VSA konfiguriert, daher erscheint beim Aufruf des Plug-Ins die Aufforderung, eine zu installieren:

Der Startbildschirm des VSA Installers

 

Wir wollen eine Neuinstallation riskieren und lassen die Auswahl daher bei „New Installation“. Es folgt ein kurzer Überblick darüber, was alles eingerichtet wird und warum es ganz toll ist:

Erklärungstecte des VSA Installers

 

Danach folgt die Auswahl und Untersuch des gewünschten Datacenters für den VSA Cluster. In dem „Essentials Plus + 3er VSA“ – Szenario, welches VMWare als DAS Einsatzszenario für die VSA anzusehen scheint, ist freilich nur ein Datacenter hier möglich. Implementiert man die VSA mit den „großen“ Produkten, können hier sicher auch weitere Datacenter erscheinen.

 

Hier sieht man die CPU-Kompatibilität der Hosts im zukünftigen Cluster. Bei diesen beiden handelt es sich um Maschinen unterschiedlicher Leistungsklassen – ein Athlon und ein Opteron, daher auch der recht bescheidene Grad an Übereinstimmung, wie man sieht:

 

Manchmal sind beim ersten Durchlauf ein oder mehrere Hosts im „Degraded“-Status. Einen Schritt zurück gehen und den Host rebooten hat ab und zu geholfen – immer unter der Annahme, daß die übrigen Voraussetzungen stimmen.

Nun wir das Netzwerk für den VSA-Cluster konfiguriert, sie muß im selben Subnetz liegen wie der VSA Cluster Manager-Rechner, in diesem Fall also der vCenter-Server.

 

Mit der Eingabe der beiden ersten IP-Adressen werden automatisch auch weitere Adressen auf die Hosts verteilt:

 

Das sieht dann so aus:

 

und für den zweiten Host:

 

Ein Wort der Warnung, was das Networking auf den Hosts angeht: Im Moment haben die Hosts noch ihre Management-Interfaces schön mit einer IP-Adresse versehen. Wenn es an die Konfiguration des Clusters geht, wird der Installer die Netzwerkschnittstellen neu mischen. Die Adressen bleiben zwar erhalten, es kann aber sein, daß sie plötzlich einer anderen Netzwerkkarte zugewiesen werden! Daher sollte die Kommunikation zwischen den 4 NICs in jedem Host und dem vCenter in diesem Augenblick noch „flach“ sein, d.h. jede Netzwerkkarte muß jede andere erreichen können. Später kann man sie dann trennen, sei es um den Traffic zu isolieren oder um Ausfallsicherheit gegenüber dem Defekt eines Switches zu erhöhen.

Nun die letzte Frage, bevor’s losgeht – jetzt oder später formatieren. Meine Erfahrung hier ist so:

  • formatiert man gleich, dauert es lange
  • formatiert man später, merkt man es gar nicht.

Daher rate ich, die Formatierung nicht als Teil der Installation vorzunehmen.

 

Jetzt noch mal die Konfiguration überprüfen…

 

…und schon wird einem der erschreckende Hinweis präsentiert, daß alle Daten gleich futsch sind:

 

Die Erfahrung zeigt, dem ist nicht so, jedenfalls nicht in diesem Release. Trotzdem ist es nicht gut, Daten im Datastore zu haben:

  1. da VMWare das offensichtlich so vorgesehen hat, wird es vermutlich in einem der späteren Releases umgesetzt
  2. eben weil die bestehenden Daten erhalten bleiben, reduzieren sie die Gesamtkapazität der VSA. Zur Erinnerung: alle von der VSA präsentierten Shares sind gleich groß, und zwar etwa halb so groß wie der kleinste verfügbare Platz auf einem der Hosts!

Nun aber wird tatsächlich installiert. Das sind die berühmten 15 Minuten:

 

… man sieht schon ein wenig vom Cluster:

 

… und die beiden Appliances (das wären bei 3 Hosts natürlich auch drei):

 

… nun ist der Cluster auch per TCP/IP zu erreichen:

… und fertig!

Jetzt zeigt der VSA Cluster Manager auch sinnvolle Daten zum Zustand des Clusters an:

Die VSA ist fertig und läuft. Herzlichen Glückwunsch!

Zwei Anmerkungen an dieser Stelle noch:

  1.  obwohl der VSA Installer recht tiefgreifende Einstellungen am vCenter vornimmt, stellt er an den physischen Datastores der Hosts (die ja dann durch die VMDKSs der VSA-Appliances ja richtig voll sind!) die Alarmaktionen nicht ab, die dann auch immer anschlagen. Allerdings ist es bei der HP-Appliance und bei manch anderen, die ich gesehen habe, auch nicht anders
  2. Will man die VSA wieder deinstallieren, so darf man nicht anfangen, den Cluster aufzulösen, die Appliance-VMs händisch zu entfernen usw. Dafür gibt es einen Skript, der mit der VSA zusammen installiert wird. Die Benutzung wird hier in der VMWare-KB beschrieben. In meinem Fall mußte im Unterschied zum KB-Artikel der Pfad zur Java-Umgebung manuell gesetzt werden (systemweite Umgebungsvariable).

Tags » , , , , , «

+