02/12/14

vSAN – Simple Shared Storage!

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.

02/11/14

PowerCLI – einfacher Leben!

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

 

02/8/14

WebClient VM Console – Verbindung fehlgeschlagen vcenter:7331

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!

09/10/13

Unable to connect to MKS:902

Versucht man die Konsole einer VM zu öffnen und erhält obengenannte Fehlermeldung, muss es sich nicht unbedingt um eine Fehlkonfiguration in der Firewall handeln.

Es kann auch an einem fehlenden DNS Eintrag liegen. Das liegt daran das die VM Konsole eine direkte Verbindung zum ESXi host aufbauen möchte und dies versucht er anhand des DNS Namens im vCenter.

05/14/12

SSH access on vMA

The access with SSH to the vMA is very comfortable.

The SSH daemon runs by default, but the access is blocked from the TCP Wrapper to the sshd. If you want to access the vMA with SSH you can edit the /etc/hosts.allow file with this option:

sshd: ALL: ALLOW

 

05/8/12

Reporting Tab with ERROR

I would like to see the Reporting tab for the vRAM usage, but If I click on the Reporting Tab under Home > Administration > Licensing I get this error message:

An internal System Error was occured

 

Solution

Connect to the vCenter Appliance over SSH

and type

#/usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh unregister https://<hostname>:9443/vsphere-client localhost root "Password"
#/usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh register https://<hostname>:9443/vsphere-client localhost root "Password"

and make sure that the Flash Player is installed.

 

Now the Reporting Tab should work.

04/19/12

Change the Keyboard Layout on the vMA

The default Layout is US, but if you use a german Keyboard and have very complex passwords you run into a problem.

If you want change your Layout here are the steps:

# vi /etc/sysconfig/keyboard
change the line with KEYTABLE="us.map.gz"  to KEYTABLE="de-latin1"

 

Thats it!

04/19/12

Enable SNMP on ESXi with vMA

To enable SNMP on your host over the vMA you work with the command vicfg-snmp.

#vicfg-snmp --server "IP" -e -c "Community Name"

the e option enabled snmp and the c option set a community name.

 

To test your config you can work with snmpwalk, like:

snmpwalk -c "Community Name" -v "IP"