#Broadcom versucht bei #VMWare echt den Laden schneller gegen die Wand zu fahren als es X geschafft hat, oder? Allen Partnern kündigen, Mitarbeiterstamm ausdünnen, Lizenzen deutlich verteuern und nur noch mietbar machen und jetzt allen Cloud-Partnern den Hahn abdrehen. Die haben es geschafft den Laden in Kürze von "kann man nutzen, ist stabil und hat guten Support" in "mach nen Bogen drum" zu verwandeln. Das ist ja schlimmer als Oracle oder sowas.
Schlagwort-Archive: vmware
adlerweb // BitBastelei 2023-12-04 18:20:25
Kann das nur unterschreiben. #VMWare hatte eine der angenehmsten Supportabteilungen mit denen ich bisher so zu tun hatte. Aber ist ja leider häufig so – irgendwann wird aufgekauft und dann steht Profit über Kundenzufriedenheit.
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.
Bild: https://www.adlerweb.info/blog/wp-content/uploads/2018/01/vcsa.png
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:
***T09:53:18.467Z cpu1:***)vmw_psp_mru: psp_mruSelectPathToActivateInt:346: Changing active path from NONE to vmhba0:xx:xx:xx for device "Unregistered Device". ***T09:53:18.467Z cpu1:***)StorageApdHandler: xxx: APD Handle Created with lock[StorageApd-0xxxx] ***T09:53:18.467Z cpu1:***)ScsiEvents: 501: Event Subsystem: Device Events, Created! ***T09:53:18.467Z cpu1:***)VMWARE SCSI Id: Id for vmhba1:xx:xx:xx xxxxx ***T09:53:18.467Z cpu1:***)VMWARE SCSI Id: Id for vmhba0:xx:xx:xx xxxxx ***T09:53:58.506Z cpu2:***)ScsiDeviceIO: xxx: Cmd(0xxxx) 0x1a, CmdSN 0x1 from world 0 to dev "naa.xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. ***T09:53:58.506Z cpu1:***)ScsiDeviceIO: xxx: Could not detect setting of QErr for device naa.xxx. Error Timeout. ***T09:54:08.631Z cpu19:***)NMP: nmp_ResetDeviceLogThrottling:3343: Error status H:0x0 D:0x18 P:0x0 Sense Data: 0x0 0x0 0x0 from dev "naa.xxx" occurred 989 times(of 989 commands) ***T09:54:38.524Z cpu2:***)ScsiDeviceIO: xxx: Cmd(0xxxx) 0x1a, CmdSN 0x2 from world 0 to dev "naa.xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. ***T09:54:38.524Z cpu1:***)ScsiDeviceIO: xxx: Could not detect setting of sitpua for device naa.xxx. Error Timeout.
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:
esxcli storage core device setconfig -d naa.xxxx --perennially-reserved=true
VMWare vSphere-Client per SSH-Tunnel
Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/07/vmlist-300×205.pngUgh – 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.
#!/usr/bin/perl -w # Reworked for standard vmotion: Florian Knodt - https://www.adlerweb.info # Original for distinct storage: William Lam - http://blogs.vmware.com/vsphere/automation use strict; use warnings; use VMware::VILib; use VMware::VIRuntime; use Data::Dumper; my %opts = ( vmname => { type => "=s", help => "Name of Virtual Machine to migrate", required => 1, }, vihost => { type => "=s", help => "Name of ESXi host to migrate to", required => 1, }, priority => { type => "=s", help => "Migration priority [high|low]", required => 0, default => 'high', }, ); Opts::add_options(%opts); Opts::parse(); Opts::validate(); Util::connect(); my $vmname = Opts::get_option('vmname'); my $vihost = Opts::get_option('vihost'); my $priority = Opts::get_option('priority'); if(Vim::get_service_content()->about->apiVersion lt "5.1") { &seeya("Script requires vCenter Server >5.1\n"); } # define priority enums my %priorityConstants = ('high' => 'highPriority', 'low' => 'lowPriority'); # retrieve VM my $vm_view = Vim::find_entity_view(view_type => 'VirtualMachine', filter => {'name' => $vmname}, properties => ['name']); if(!defined($vm_view)) { &seeya("Unable to find VM: " . $vmname . "\n") } # retrieve host my $host_view = Vim::find_entity_view(view_type => 'HostSystem', filter => {'name' => $vihost}, properties => ['name']); if(!defined($host_view)) { my $test = Vim::find_entity_view(view_type => 'HostSystem', properties => ['name']); print Dumper($test); &seeya("Unable to find ESXi host: " . $vihost . "\n"); } # in case bad input if($priority ne "low" || $priority ne "high") { $priority = "high"; } $priority .= "Priority"; my ($task,$message); eval { # call migrate API print "Migrating " . $vmname . " to ESXi Host: " . $vihost . "...\n"; $task = $vm_view->MigrateVM_Task(host => $host_view, priority => VirtualMachineMovePriority->new($priority)); $message = "Successfully migrated " . $vmname . "!\n"; &getStatus($task,$message); }; if($@) { print "Error: " . $@ . "\n"; } Util::disconnect(); sub getStatus { my ($taskRef,$message) = @_; my $task_view = Vim::get_view(mo_ref => $taskRef); my $taskinfo = $task_view->info->state->val; my $continue = 1; while ($continue) { my $info = $task_view->info; if ($info->state->val eq 'success') { print $message,"\n"; return $info->result; $continue = 0; } elsif ($info->state->val eq 'error') { my $soap_fault = SoapFault->new; $soap_fault->name($info->error->fault); $soap_fault->detail($info->error->fault); $soap_fault->fault_string($info->error->localizedMessage); die "$soap_fault\n"; } sleep 5; $task_view->ViewBase::update_view_data(); } } sub seeya { my ($message) = @_; print $message; Util::disconnect(); exit 1; }
Aufruf:
./scriptname.pl --server vcenter.domain.local --username admin --password admin --vmname MyVM --vihost esxihost2.domain.local
BitNotice #102 – Windows Server für’s Klonen vorbereiten (SYSPREP)
(5 MB) 00:04:15
2016-07-19 19:34 🛈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
(42 MB) 00:26:35
2016-05-01 10:00 🛈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.
Bild: https://adlerweb.info/blog/wp-content/uploads/2014/07/vm1-300×196.png
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:
- 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:
Bild: https://www.adlerweb.info/blog/wp-content/uploads/2009/11/Bildschirmfoto-3-300×98.png - 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 - 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.
Bild: https://www.adlerweb.info/blog/wp-content/uploads/2009/11/Bildschirmfoto-4-300×220.png
Bild: https://www.adlerweb.info/blog/wp-content/uploads/2009/11/Bildschirmfoto-5-300×230.png
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