Ich hatte das Problem in einer Umgebung ohne vCenter (ja sowas gibts) mehrere Windows Sever 2012 installieren zu müssen. Normaler weiße mit einem vCenter kein Problem – man macht eine Vorlage und stellt über diese die Server bereit. Ich habe also einen Server installiert und dann mit sysprep vorbereitet. Dann habe ich die Server in VMWare angelegt – ohne Festplatten. Danach habe ich die Festplatte meines „Vorlagen-Servers“ auf dem Datastore in jeden angelegten Server kopiert. Wegen der Optik muss aber die vmdk noch umbenannt werden:

Mit SSH auf dem ESXi anmelden.

dann in das entsprechende Verzeichnis gehen

cd /vmfs/volumes/NAME-DES-DATASTORES/NAME-DES-SERVERS/

dann umbenennen

vmkfstools -E alter-name.vmdk neuer-name.vmdk

Achtung: nur die .vmdk-Datei umbennen – die name-flat.vmdk-Datei wird automatisch mit umbennant.

Jetzt kann in die Festplatte in die VMs hinzugefügt werden.

Quelle: VMWare

Man muss ja öfters mal auf einen VMWare ESXi 5.x per SSH zugreifen. Standardmäßig ist dieser Dienst jedoch aus gutem Grund deaktiviert. Aktivieren lässt sich der Dienst direkt an der Konsole des Server – oder ganz einfach über den VMWare vSphere Client.

Den Dienst kann man im vShpere Client unter Konfiguration – Sicherheitsprofil – Dienste finden. Dort dann rechts oben auf Eigenschaften klicken. Dort kann man dann den Dienst aufwählen (in unserem Fall SSH) und starten – und natürlich auch wieder beenden

ssh-esxi

Ganz ohne zum Server gehen zu müssen 🙂

Ich hatte das Problem, dass bei einem Update der VMWare Tools die Installation mit dem „internen Fehler 2203“ bzw. “internal error 2203″ abbricht. Die Deinstallation der Tools funktionierte – aber auch eine Neuinstallation der Tools scheiterte mit dem Fehler 2203 – der Windows Installer lief bei mir bei der Produktregistrierung nach den Audio-Treibern in den Fehler.

Den Fehler verursachten die Benutzervariablen TEMP und TMP. Diese beiden hab ich auf c:\temp gesetzt:

vmware-tools-umgebungsvariablen

Danach funktioniert die Installation 🙂

Ich hatte das Problem, dass Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 auf SMB bzw. CIFS-Freigaben eines NetApp-Filers nicht zugreifen konnten.

Microsoft beschreibt unter KB2686098 das Problem:

This behavior may be due to the “Secure Negotiate” feature added to SMB 3.0 for Windows Server 2012 and for Windows 8, which relies on the correct signing of error responses by all SMB 2 servers (including those supporting only protocol versions 2.0 and 2.1). Some third-party file servers do not respond with a signed error response causing the connection to fail.

Es stehen auch zwei Lösungen zu Auswahl:

Ausschalten des „Sicheren Aushandeln“ – der Secure Negotiaten – auf den Windows-Systemen (meine Empfehlung):

Per Powershell (als Administrator)

Set-ItemProperty -Path „HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters“ RequireSecureNegotiate -Value 0 -Force

Kein Neustart nötig – Die Freigaben waren sofort erreichbar.

Oder alternativ das einschalten des Signing auf der NetApp:

options cifs.smb2.signing.required on

Danach sollte der Zugriff auch wieder möglich sein.

Auf einem Linux-Server möchte man ab und an mal einen Speedtest machen. Am schönsten wäre natürlich über Speedtest.net. Nur haben Server seltenst ja eine GUI oder noch dazu einen Browser. Dafür gibt es jetzt die speedtest-cli

Zuerst holen wir uns von Github das Scipt

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py

Danach muss man das Script ausführbar machen

chmod +x speedtest-cli

Danach kann man es starten

./speedtest-cli

und sogar mit mit Result-Bildchen

./speedtest-cli –share

Dann sieht das so aus:


root@vps:/# ./speedtest-cli --share
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Nobis Technology Group, LLC (23.105.138.107)...
Selecting best server based on ping...
Hosted by Interserver, inc (Secaucus, NJ) [7.01 km]: 17.007 ms
Testing download speed........................................
Download: 77.93 Mbit/s
Testing upload speed..................................................
Upload: 48.40 Mbit/s
Share results: http://www.speedtest.net/result/3225015203.png

null

Quelle: vpstip.com

Ich hatte das Problem das sich in einer Umgebung mit VMWare View der vCenter-Server geändert hat. Ich habe versucht eine Anleitung für einen Umzug zu finden – leider ohne großen Erfolg. Hier wie ich es trotzdem hinbekommen habe:

Ausgangslage: VMWare View 5.1 auf eigenem Server intalliert. Desktop-Pools sind keine Linked-Clones. Neuer vCenter-Server installiert,die ESXi-Host verbunden und konfiguriert.

Problem: VMWare View kann zwar mehrere vCenter verwalten – aber die Desktop-Pools können nur einem vCenter zugeordnet sein – und das lässt sich nicht ändern. Also muss man hier ein wenig nachhelfen.

Dazu führt man auf dem View-Server folgende Schritte durch:

1) vCenter in View Manager eintragen

Als erstes muss der neue vCenter im View Manager eingetragen werden. Dazu navigiert man zu
View Konfiguration -> Server -> vCenter Server und fügt über Hinzufügen
mit Hilfe des Assistenten den neuen Server hinzu.

Dadurch wird im View LDAP das Objekt für den neuen vCenter angelegt.

2) Export der Einstellungen

Auch die ganzen Pool-Einstellungen stehen in diesem LDAP. Wir öffnen die VMWare PowerCLI Powershell und machen einen Export

vdmexport -v -f c:\view-export.ldif

3) Anpassen der Einstellungen

Als erstes rate ich dazu ein Backup der Datei zu erstellen. Danach können wir durch ersetzen der alten vCenter-ID durch die neue vCenter-ID die Konfiguration der Desktop-Pools anpassen.

Dazu öffnen wir die Datei in einem Editor – ich empfehle Notepad oder Notepad++.

Zuerst muss man die vCenter-Definitionen in der Datei suchen. Sie sehen so aus:

Der alte vCenter:

dn: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: abcd1234-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://alter-vCenter.test.local:443/sdk

Der neue vCenter

dn: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: efgh5678-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://neuer-vCenter.test.local:443/sdk

Der dn-Wert ist die ID des vCenters – in diesem Fall von unserem neuen Server also efgh5678-49cb-4fce-ae39-5dbcba9120d1.

Jetzt sucht man nach dem pae-VCDN-Wert der Desktop-Pools. Dafür sucht man mit der alten ID nach

pae-VCDN: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1

Hier müsste man die einzelnen Desktop-Pools finden. Jetzt kann man die ID einfach ersetzten.

Suchen nach:
pae-VCDN: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
Ersetzten durch:
pae-VCDN: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int

Ich empfehle hier keine „Alle Erstzen“ des Editors zu machen, sonder schön einzeln und manuell.

Danach speichern wir die Datei am besten unter c:\view-import.ldif ab.

4) Import der Einstellungen

Wir öffnen wieder die VMWare PowerCLI Powershell und machen den Import

vdmimport -f c:\view-import.ldif

Der Import ändern normalerweise nur Werte die geändert worden sind.

Danach im VMWare View Manager die Pools überprüfen – nach einem Browser-Refresh müssten die Pools den neuen vCenter-Server anzeigen.

Falls möglich jetzt noch den alten vCenter (wenn nicht eh schon) beenden und testen. Bei mir traten keine Probleme auf.

Das wars 🙂

Quelle: Link

Ich benutzte einen meiner Server um dort ein VPN zu betreiben. Dabei verwende ich die Kombination aus L2TP und IPSec. So ein IPSec/L2TP-VPN hat gegenüber z.B. OpenVPN den Vorteil, dass man keine Clientsoftware benötigt und es eigentlich auf allen meinen Betriebssystemen out of the Box läuft. Mac OS, iOS, Android und Windows können ohne Zusatzsoftware eine Verbindung mit dem VPN aufbauen. Implementiert habe ich das auf einem Debian-Linux mit Hilfe von Openswan (IPSec-Implementierung) und xl2tpd (L2TP-Implementierung).

weiterlesen