Schlagwort-Archive: vmware

VMWare vCenter Server Appliance mit Proxy aktualisieren

Die Aktualisierung einer VCSA ist eigentlich ja recht einfach: Man geht über den Port 5480 auf das Appliance-Management (aka MUI, VAMI), klickt auf Update und das drunterliegende Linux wird samt aller Programme auf den aktuellen Release aktualisiert. Die Programme kommen dabei direkt von den Updateservern – zumindest wenn man eine direkte Internetverbindung hat. Steht das System in einem Netz, welches keinen direkten Zugang bietet und nicht über einen transparenten Proxy verfügt, lässt die UI die nötige Konfiguration einfach erscheinen: Unter Netzwerk -> Verwalten findet sich ein Menüpunkt “Proxy-Einstellungen”, welcher die direkte Eingabe ermöglicht. Theoretisch.

Die Praxis sieht leider anders aus: Dieses GUI-Element setzt lediglich die Umgebungsvariable http_proxy, welche ausschließlich für unverschlüsselte Verbindungen gültig ist. Da der Update-Download inzwischen per HTTPS läuft wird der Proxy praktisch ignoriert und der Download-Versuch läuft ins Leere. Dieses Problem tritt mindestens zwischen der Version 6.0 und der aktuellen 6.5U1 auf.

Zur Abhilfe muss man selbst Hand anlegen: In der Datei /etc/sysconfig/proxy findet sich neben der, von der GUI bereits gesetzten, Variable HTTP_PROXY auch ein passendes HTTPS_PROXY. Füllt man dies manuell aus ist der Update-Download fehlerfrei möglich. Wer vSAN einsetzt, sollte hier auch gleich noch die lokalen Server als Ausnahme definieren um den VMWare-Bug #2150523 zu umgehen.

Es zeigt sich wie so oft: Der Texteditor ist mächter als die Maus.

Danke an Andrew Richardson/VirtualSlices für das Aufklären des ursprünglichen Fehlers.

VMWare RDM: ESXi-Boot wird minutenlang verzögert

Schlecht. Ein ESXi-Host sollte zwecks Update “mal schnell” neu gestartet werden, doch nun sind mehr als 30 Minuten vergangen und es gibt noch immer kein Lebenszeichen. Selbst für Server etwas ungewöhnlich und lange genug um den VMWare-Updater in einen Timeout laufen zu lassen. Nach einiger Zeit war das System zwar wieder korrekt gebootet und zeigte keine weiteren Auffälligkeiten, eine solche Wartezeit wäre bei Störungen jedoch sehr hinderlich, also gehen wir mal auf Quellensuche.

Im Log finden sich mehrere Einträge, welche durch die Zeitstempel massive Wartezeiten erkennen lassen:

Das Ganze wiederholt sich dann mehrfach. Also ein SCSI-Timeout? Der Host ist per FibreChannel an diverse Storage-Systeme angebunden, sollte jedoch auch nur die für ihn relevanten LUNs sehen. Zumal nach dem langem boot auch alle Datastores verfügbar und VMs ohne Fehler online waren.

Nach einigem Suchen dann die Erkenntnis: Die angekreideten LUNs gehören zu einem Windows-Cluster und sind als RDM vorgesehen. ESXi versucht nun beim Booten diese LUNs zu scannen, was jedoch nicht gelingt da der Cluster auf einem anderen Host aktiv und die Partition somit dauerhaft gesperrt ist. Zur Abhilfe muss man diesen Scan beim Boot explizit für die betroffenen LUNs auf jedem Host deaktivieren:

https://kb.vmware.com/kb/1016106

VMWare vSphere-Client per SSH-Tunnel

vmlistUgh – eine VM hängt und ich habe kein VPN ins zugehörige Netz. Aber jetzt extra hinfahren? Auch unschön. Glücklicherweise gibt es noch einen SSH-Zugang, den ich hier nutzen kann. Also schnell Tunneln – doch welche Ports? Nunja, nehmen wir für den “alten” vSphere-Client folgende:

  • 443
  • 992
  • 993

Wer jedoch versucht mit 127.0.0.1 oder localhost zu verbinden wird auf Probleme stoßen – bei mir lief der Client auf diesen IPs keinen Connect zu. Ein kurzer Griff in die IPv6-Kiste mit dem guten, alten [::1] half und ließ die Verbindung zu.

VMWare vMotion auf VMA per CLI auslösen

Kleines Script zwischendurch: Über dieses Perl-Konstrukt kann man auf einem vSphere Management Assistant eine vMotion auf der Konsole auslösen. So lassen sich recht einfach eventgesteuerte vMotion-Aktionen umsetzen. Ich nutze es z.B. um zeitgesteuert VMs an Standorte mit höherer erwarteter Hitrate zu verlegen oder bei Störungen kritische VMs automatisiert auf “sicherere” Hosts zu migrieren. Das Original stammt von William Lam, ich habe einige Punkte etwas umgebaut um Storage-vMotion auszuklammern. Üblicher Disclaimer: Proof of concept, keine Garantie, nicht-Programmierer-versucht-sich-an Perl, Works for me.

Aufruf:

BitNotice #102 – Windows Server für’s Klonen vorbereiten (SYSPREP)

Spätestens wenn man einen Haufen Server benötigt und eine Virtualisierung einsetzt möchte man nicht dutzende male das Windows-Setup durchführen und seine wichtigsten Tools per Hand installieren. Einfach die Festplatte zu kopieren ist aber auch keine wirkliche Lösung, denn Windows hat intern IDs, welche im lokalen Netzwerk besser nicht mehrmals vorkommen sollten. Über das Tool “Sysprep”, welches praktischerweise in der der Standardinstallation schon dabei ist, kann man eine Windows-Installation schnell von eindeutigen Merkmalen befreien und so für das Klonen vorzubereiten. Das Tool steht in allen aktuellen Versionen zur Verfügung.

Bitte beachtet, dass je nach Windows-Lizenz nur eine gewisse Anzahl, Art und Hostkonfiguration abgedeckt ist, ein genauer Blick in die Lizenzvereinbarung ist entsprechend Pflicht.

Ergänzungen:

  • 2:14 – …159265… (SCNR)
  • 3:27 – Neu im Sinne von Windows-Einstellungen wurden zurückgesetzt, installierte Programme, Updates, etc bleiben erhalten

BitBastelei #195 – Windows 2012R2 Failovercluster mit VMware

Wieder mal eine Runde “Serverzeugs”: Windows Server 2012 R2 kann über “Failoverclustering” eine Hochverfügbarkeit bereitstellen. Hierzu müssen alle Clusterknoten auf einen gemeinsamen Speicher direkt zugreifen können. Kommt eine Virtualisierungsinfrastruktur wie VMWare hinzu muss man etwas basteln um eine stabile Funktion zu erreichen.

VMWare KB1037959: Microsoft Clustering on VMware vSphere: Guidelines for supported configurations

VMWare ESXi 5.x – SSH aktivieren

VMWare ESXi basiert intern auf einem Unix-artigen System, entsprechend kann ab und an ein kleiner Schubs auf der Konsole recht hilfreich wirken. Zwar ist im System von Haus aus ein SSH-Server vorhanden, jedoch üblicherweise deaktiviert.

Um einen SSH-Zugang zu aktivieren klickt man im vSphere-Manager den Host an und wählt rechts den Tab “Konfiguration” aus. In der linken Seite befindet sich unter “Software” der Menüpunkt “Sicherheitsprofil”. Unter Dienste ist SSH bereits geführt, jedoch nicht gestartet – dies kann man über den kleinen Link “Einstellungen” an der rechten Seite ändern. Unter SSH->Optionen lässt sich der Dienst dauerhaft aktivieren oder auch nur für einen kurzen Eingriff manuell starten.

SSH @ ESXi 5.x

Der zugehörige Artikel bei VMware wäre 2004746

Nativer Client für VMWare ESXi unter Linux

VMWare ESXi bzw. VMWare ESX ist nahezu der “de facto Standard” für die professionelle Virtualisierung. Die Verwaltung erfolgt dabei über den VMware Infrastructure Client – eine .NET-Software, welche aber momenten nicht für Linux vorhanden ist und auch unter wine nur bedingt funktioniert. Zwar gibt es mit Kodiak einen 3rd-Party-Client, welcher die komplette Verwaltung ermöglichen soll und dank Adobe AIR auch unter Linux laufen sollte, allerdings ist dieser derzeit in geschlossener Beta und steht noch nicht zum Download.Was viele nicht wissen: Es gibt einen einfachen Client direkt von VMWare. OK, nicht offiziell:

VMWares einfachere Variante “VMware Server” nutzt in der aktuellen Version zur Verwaltung den Webbrowser. Der Konsolenzugriff wird dabei über ein Plugin ermöglicht, welches auch für Firefox unter Linux zur Verfügung steht. Mit einem kleinen trick kann man dieses Plugin dafür nutzen eine Verbindung zu ESX(i) aufzubauen und so immerhin die Konsolen anzuzeigen:

  1. Zuerst muss natürlich das Plugin installiert sein. Hierzu muss man seinen Browser auf einen installierten VMWare-Server verbinden und dort die Konsole öffnen. Da der VMWare-Server kostenlos ist sollte auch eine temporäre Installation machbar sein. Da das Plugin eine XPI ist lässt sie sich auch einmalig auslesen und (technisch gesehen) auf eine unbegrenzte Anzahl von Rechnern verteilen. Ob das Plugin installiert ist kann man bei Firefox 3.5 unter Extras -> Add-Ons -> Plugins prüfen:
    FF-Pluginliste: VMWare
  2. Nun gilt es das Plugin zu lokalisieren. Üblicherweise sollte es sich ein einem Ordner dieses Formates befinden:
    /home/username/.mozilla/firefox/****.default/extensions/VMwareVMRC@vmware.com/plugins
  3. Hier findet sich die Binärdatei des Plugins, welche auch ohne Browser gestartet werden kann. Mit
    ./vmware-vmrc -h
    startet eine GUI und fragt nach Server, Nutzer und Kennwort. Darauf folgt eine Liste mit VMs.
    VMWare Plugin - Login
    VMWare Plugin: VM-Liste

Achtung: Wählt man eine ausgeschaltete VM wird diese automatisch gestartet.

Das einbinden von CD-ISOs sowie Restart und Shutdown funktionieren Problemlos, USB-Geräte und Netzeinstellungen lassen sich nicht anpassen. Im VMWare-Forum findet sich eine Liste mit weiteren Optionen des Plugins.

Update: Offenbar funktioniert der Trick auch mit dem VMWare-Player:
vmplayer -h 1.2.3.4