iSCSI Port Binding is the function that you use to bind multiple vmkernel Interfaces to the iSCSI Initiator to use Multipathing. But sometimes you don’t need iSCSI Port Binding.

If you have a single subnet for communication to the SAN you should use iSCSI Port Binding. Because the ESXi Host can only use one physical NIC to communicate with the SAN if you have multiple NICS.
So we have only a single connection. With iSCSI Port Binding the ESXi take both vmkernel to communicate.

But if you have multiple vmkernel Interfaces in different Subnet and the Storage SPs are in different Subnets you don’t need iSCSI Port Binding and you shouldn’t use it. The vmkernel make multiple Connection for each Subnet and there no longer is a need for Port Binding.

Here the KB Site kb2038869

Immer häufiger treten Probleme beim Kunden bzgl. vCenter Dienst auf. Nicht selten ist es der Fall, dass es einfach eine volle DB ist, die von ihrer größer her (aufgrund der Lizenzierung) beschränkt ist.
Installiert man die vCenter DB als Embedded auf einem Windows OS, dann ist dies bei eine Microsoft SQL Express DB, die bei SQL 2005 auf 4 GB und bei SQL 2008 auf 10 GB beschränkt ist. Ist die Größe der DB erreicht, so bleibt entweder der Dienst stehen, oder es treten kuriose Fehler auf, wie z.B. Snaphshots ergeben Verbindungsabbrüche am vCenter. Der Grund liegt darin, dass alles was wir an Events und Tasks am vCenter durchführen in die DB geschrieben wird. Es werden auch die Performance Statistiken dort reingeschrieben, ist diese voll können solche Fehler auftreten.
Abhilfe schafft zum einen das Purging der DB und zum anderen Einstellungsänderungen, damit wir die Größe der DB ein wenig beschränken können, z.B. nur Task und Events der letzten 180 Tage.
Im Event Viewer von Microsoft, wird auch darauf hingewiesen, dass es ein Lizenz Problem ist!

Zuerst die Retention Policy ändern, dazu auf die vCenter Setting gehen:

Und dann für die Task und Events die Tage definieren wie lange sie beibehalten werden sollen:

Danach wird auf Basis der definierten Tage die DB entrümpelt. Hierbei auf die vCenter DB gehen (VIM_VCDB) > Programability > Stored Procedures > Rechts Klick auf dbo.cleanup_events_tasks_porc und dann auf Execute Stored Procedure.. klicken und abwarten, dies kann basierend auf der DB Größe ein wenig dauern.

To change the language for the WebClient you can add a string to the URL, so you don’t need to change the language for the whole Browser:

https://client-ip-hostname:9443/vsphere-client/?locale=en_US

Mögliche Optionen wären:
English = /?locale=en_US
German = /?locale=de_DE
French = /?locale=fr_FR
Japanese = /?locale=ja_JP
Korean = /?locale=ko_KR
Chinese = /?locale=zh_CN

Monitoring! Da ich jetzt schon mehrmals darauf angesprochen wurden, wie man die VMware Infrastruktur Monitoren kann, ist hier ein kleiner Blog Eintrag darüber. Und zwar geht es um den vCenter Operations Manager von VMware und das Monitoren des Guest OS über den Hyperic Server von VMware.
Die Kombination ist ab der vCenter Operations Manager Advanced lizenziert. ()

Pre-Installation … Was gibt es an Ressourcen Bedarf:

Nachdem der Ressourcen Bedarf abgedeckt ist (denkt an Best Practice Thick Provisioning), kann mit der Installation begonnen werden:

1. Download vCenter Operations Manager vApp
2. Configure IP Pool on Datacenter
3. Deploy vCOPS vAPP
4. Post-Configuration vCOPS
5. Lizenzierung vCOPS
6. Installation VMware Hyperic Server
7. Installation VMware Infrastructure Navigator
8. WebClient Config

Download vCenter Operation Manager

Configure IP Pool
Auf die Datacenter Ebene gehen und links den IP Pool Tab auswählen, dann auf Add und die Netzwerkinformationen angeben, den IP Pool NICHT aktivieren. Dann auf den Association Tab gehen und dort die Portgruppe auswählen, die oben genannte Netzwerkinformation enthält und wodrauf vCOPS laufen soll.

Deploy vCOPS vAPP
Rechtsklick auf das Datacenter und Deploy OVF Template, dann die VMware-vcops-5.8.2.0-1885282-vapp.ova Datei auswählen.

Informationen zur vApp:

Auf Basis der Umgebungsgröße die entsprechende Option wählen:

Denn Datastore auswählen. Beste Performance bei Thick Eager Zeroed Provisioning (Best Practice):

Die Portgruppe auswählen, die ihr vorher auch für den IP Pool verwendet habt:

Die Statischen IPs vergeben (eine für die UI und eine für die Analytics):

Und dann warten bis die vAPP deployed wurde:

Wichtig ist dabei, dass der vApp Status auf Available steht!

Post-Configuration vCOPS
Auf https://vcops ip oder FQDN/admin
Standard Passwort für den Admin Bereich ist BN:admin PW:admin.

Nachdem erfolgreichem Login startet sofort der Konfigurations-Wizard:

Standard Passwort für den User root ist vmware.

vCenter Daten angeben, wollte ihr das der Collector nur bestimmte Metriken sammelten, dann erstellt dafür einen eigenen User, der nur auf die Metriken Zugriff hat. (Collector User (optional). Ansonsten einfach einen Administrator angeben und den Rest “Blank” lassen.

Lizenzierung vCOPS

Die Lizenz wird über den vSphere Client / Web Client eingespielt:

Installation VMware Hyperic Server
Auf der VMware Seite die entsprechende Datei herunterladen, ich habe mich für die einfache Bereitstellung entschieden (Appliance). VMware Site

Deploy OVF und Datei auswählen:

vApp Informationen (Hyperic Server und vPostgress DB):

Option an den Umgebungsanforderungen anpassen:

Und zum Schluss noch Usernamen, Passwörter und IP Adressen setzen:

Fertig ist das Deployment des Hyperic Servers:

Installation VMware Infrastructure Navigator
Der Infrastructure Navigator ist für die Abstraktion von Applications Beziehungen nützlich. Abgefragt wird dies über die VMware Tools und einem einfach netstat Befehl.;) Seit der Version 5.8 bringt er zudem die Möglichkeit Hyperic Agents zentral auf die VMs zu deployen. (CMDLETS for Powershell)

Auch hier die Appliance von der VMware Site laden und deployen:

File auswählen:

Informationen zur Appliance:

Zum Schluss noch Netzwerk und User Informationen setzen:

Navigator im Einsatz:

Damit ist die Bereitstellung aller Komponenten komplett, allerdings fehlt noch die Konfiguration.

WebClient Config
Damit die Hyperic Agent zentrale auf die VMs deployed werden können, muss noch ein Profile erstellt werden:

Jetzt können die VMs über den WebClient mit einem Hyperic Agent versehen werden um somit die Service und Auslastung zu überwachen:

Und über den Hyperic Server überwachen:

Viel Erfolg!!!!

Mir ist heute aufgefallen das ich bei der aktuellen vMA 5.5 kein resxtop aufrufen kann. Leider gab es auch keine Fehlermeldung, sondern reine Stille. 😉

Version meiner vMA ist:

Abhilfe schaffte mir das verschieben eines Folders:

sudo mv /usr/lib/vmware-rcli/lib/ /usr/lib/vmware

Und schon klappts!

Thanks William (http://www.virtuallyghetto.com/2013/11/heads-up-workaround-required-for.html)

VMware hat vor kurzem einen Client für IOS Geräte zur bereitgestellt, der den Remote Zugriff erlaubt um die VMware Infrastruktur zu Monitoren.  Dabei wird eine sogenannte Watchlist erstellt um VMs zu gruppieren.

Voraussetzung ist die VMware vSphere Mobile Watchlist App here und eine Umgebung mit mindestens vSphere 5.0.

Features:

• Power Options
• VM Status überprüfen
• Wachtlist erstellen
• Anzeigen und analysieren von Alerts

Nachdem das Thema vSAN in bei Kunden und Teilnehmer immer interessanter wird und ich in meinem vorherigen Post ein wenig darüber berichtet habe, schauen wir uns mal die Installation/Konfiguration an. Voraussetzungen für die Bereitstellung: (Sorry für den deutschen WebClient, ich finde ihn auch fürchterlich);)

• 3 ESXi Systeme
• Mindestens 1 SSD und 1 HDD per Host
• vmkernel für vSAN Traffic (Kommunikationsverkehr)
• vSphere Umgebung 5.5 (ESXi, vCenter (Windows/Appliance))
• WebClient (C# Client is not supported)

Ich benutzte für die Testumgebung 3 nested ESXi Systeme, die nach folgenden Prinzip deployed werden:

• 3 VMDKs je ESXi (2 GB ESXi Installation, 5 GB SSD, 10 GB HDD)
• ESXi Software Build 1439689 (Build 1331820 kann zu Fehler führen “Network Misconfiguration”)

Nach der Installation wird noch die vmx angepasst um die 5GB VMDK als SSD zu taggen! (scsi0:1.virtualSSD = 1)

Continue reading →

Immer mehr Kunden interessieren sich für das Thema vSAN von VMware, was mich zu diesem Post getrieben hat. Also was ist eigentlich vSAN? Wie wird es bereitgestellt und auf was muss ich achten?

Warum machen die Virtualisierer das? Um zum einem die Abhängigkeiten von Herstellern zu reduzieren (Storage Hersteller) und somit den kompletten Virtualisierungsbereich (Ressourcen (RAM, CPU), Netzwerk, Storage) selbst abdecken zu können. Alles aus eigener HAND!

Natürlich bringt vSAN nicht nur dem Softwarehersteller Vorteile, sondern uns als Administratoren auch:

• Simple Management (zentral über WebClient)
• Flexible (Einfache Storage Erweiterung)
• Integration mit VMware (vCenter, vSphere)
• Skalierbarkeit (Performance, Kapazität)
• SSD Caching (Performance
• SPBM Feature (Verfügbarkeit per VM)
• Lower TCO
• Features vMotion, HA, DRS

Wie macht VMware das? Ganz einfach, indem es die lokalen Festplatten als Shared Datastore zur Verfügung stellt!

vSAN ist nicht der erste Versuch von VMware mit lokalen Storage ein SAN bereitzustellen. Vorher hieß die Funktionalität VSA und war sehr unflexible, unperformant und setzte Voraus das auf allen ESXi Systemen (min. 2;max. 3) eine VSA Appliance bereitgestellt werden musste.

Einsatzgebiete wären unteranderem VDI und Testumgebungen.

Ich werde immer wieder in Projekten und Schulungen gefragt, wozu man die PowerCLI den verwenden kann. Die Antwort fällt dabei nicht gerade kurz.

Die PowerCLI ist ein “mächtiges” Tool das dabei helfen kann,  zu automatisieren, inventarisieren, Monitoren oder Workarounds in der VMware Umgebung bereitzustellen. Die Abfrage kann, ESXi Hosts, Datastores, VMs, Networks und auch Cluster Objekte beinhalten.

Zudem bringt die PowerCLI SnapIns für den Image Builder, AutoDeploy und Update Manager mit.

Um euch mal ein Gefühl dafür zu geben, hier mal ein  Beispiel:

Bevor Ihr startet müsst ihr die Execution Policy noch Anpassen:

# Get-Executionpolicy

(unrestricted/remotesigned/Allsinged/restricted) (Weitere Infos hier Microsoft )

Wir brauchen für unsere PowerCLI z.B. remotesigned

# Set-Executionpolicy remotesigned

Dann die PowerCLI neustarten und wir können uns mit einem vCenter/ESXi Host verbinden:

# Connect-VIServer vc.home.com

Und nun zur eigentlichen Abfrage, z.B. auf welchen Datastores unsere VMs zu finden sind. (DRS (vMotion), HA, Performance, Availability)

# get-vms | Select Name, @{Label="Datastore";Expression={Get-Datastore -VM $_}}

Wir geben in der ersten Spalte den Namen der VMs aus und in der zweite den jeweiligen Datastore/Datastores mit $_ frage ich jede Zeile (also jede VM von get-vm ab)

Viel Spaß beim ausprobieren!

Beispiel Scripte und eine sehr gute Unterstützung für den Start mit der PowerCLI gibt es auf folgender Seite www.virtu-al.net

Die Verbindung per Launche Console auf eine VM  funktioniert nicht. Der Tab der normalerweise als Console dient zeigt die Fehlermeldung “Verbindung fehlgeschlagen – vcenter:7331”.

Nach ein paar Minuten Recherche habe ich den passenden Artikel gefunden, und zwar muss eine JAVA Umgebungsvariable ergänzt werden. Dafür verbindet man sich per SSH mit der Appliance und passt folgende Datei an:

# vi /usr/lib/vmware-vsphere-client/server/wrapper/conf/wrapper.conf

Und fügt folgende Zeile hinzu:

set.default.VMWARE_JAVA_HOME=/usr/java/jre-vmware

Dann wird nur noch der vsphere-Client neugestartet (WebClient Server) mit:

#/etc/init.d/vsphere-client restart

Und siehe da die VM Console funktioniert wieder einwandfrei!