mit VMware und Microsoft

  Tipps, Tricks und HOWTOs
Virtualisierung für Profis und Einsteiger
Server-Konsolidierung, Desktop-Virtualisierung, Testumgebungen
Home/Aktuell

Tipps&Tricks
Download
Links zum Thema
Artikelarchiv


über mich
Kontakt
Impressum
 
Tipps

In loser Reihenfolge werden hier Tipps und Tricks für die tägliche Arbeit veröffentlicht.


Netscaler Gateway in Double Hop DMZ - Callback-URL in Storefront
(Aktuell!: Seit Storefront 3.5 kann die Callback-URL einfach frei gelassen werden, es erfolgt keine Fehlermeldung. Damit hat sich das leidliche Problem erledigt!

In der Storefront Konfiguration muss eine Callback-URL angegeben werden, über die der Storefront Server den NetScaler Gateway Authentication Service erreichen kann. Damit prüft Storefront, ob die Zugriffe vom richtigen Netscaler kommen. Normalerweise ist das die öffentliche Adresse des Netscalers. In manchen stark abgesicherten Netzwerken hat aber der Storefront Server keinen Internetzugang und kann daher die Callback-URL nicht erreichen. Dadurch können Clients keinerlei Verbindungen über den Netscaler aufbauen.

Hier hilft etwas zusätzliche Konfiguration am Netscaler:
Erstellen Sie einen weiteren virtuellen Gateway Server mit einer DMZ-internen IP-Adresse (VIP)
Diese VIP muss der Storefront Server auf Port 443 erreichen können
Weisen Sie diesem vServer das gleiche SSL-Zertifikat zu, wie dem vServer mit der öffentlichen IP-Adresse
Dieser neue vServer benötigt keine weitere Konfiguration, er dient nur als Callback Ziel!
Erstellen Sie am Storefront Server einen Hosts-Eintrag mit dem öffentlichen FQDN des Netscalers (FQDN wie im Zertifikat!)
Geben Sie diesem Hosts-Eintrag die IP des oben erstellten vServers in der DMZ Jetzt können Sie diese FQDN als Callback-URL hinterlegen.


VMware Data Protection (VDP) überlastete Speicher, abgebrochene Jobs, hängende Snaphots
Sicherungen mit VMware Data Protection (VDP) haben immer wieder Probleme mit abgebrochene Backups, nicht entfernte Snapshots und in der VDP-Appliance hängen gebliebene Sicherungsplatten.
Im vmkernel.log der ESXi-Hosts finden sich häufig Fehlermeldungen zur Speicheranbindung, z.B.: Device naa.5000c5000b36354b performance has deteriorated. I/O latency increased from average value of 1832 microseconds to 19403 microsecond
Der Grund liegt in der parallelen Abarbeitung von standardmäßig acht gleichzeitigen Backup-Jobs. Vor allem wenn die VMs auf dem gleichen Storage liegen, kann das zu einer Überlastung des Speichergerätes führen.
Abhilfe schafft hier eine Begrenzung der parallelen Backups auf zwei. In älteren Versionen erfolgte dies über Konfigurationsdateien in der VDP-Appliance. In den aktuellen VDP-Versionen muss man die Einstellungen in der Web-GUI suchen:
https://vdpappliance:8543/vdp-configure/
VDP-Appliance > Einstellungen (das kleine Zahnrad oben rechts) > Proxydurchsatz managen
Schieberegler "Anzahl der gleichzeitig ausgeführten Backup..."


Citrix XenApp 6.5 Multimonitor Benutzersitzungen spiegeln Error 120, 7044
(Aktuell!: Seit XenDesktop 7 existiert im Desktop Director eine komfortablere Variante, über die MS Remoteunterstützung Benutzersitzungen zu spiegeln! )

Seit Windows 2008 R2 (und damit seit XenApp 6.5) weigert sich die integrierte Spiegelungs-Funktion von Citrix mit Nutzersitzungen zu arbeiten, in denen mehrere Monitore angeschlossen sind. In heutigen Umgebungen ist das oftmals ein echtes Problem! Abhilfe schafft hier nur die Verwendung der "Microsoft Remoteunterstützung". Diese ist wie folgt einzurichten:

auf allen RD-Hosts in der Farm:
das Feature Remoteunterstützung (Remote Assistance) installieren
Server neu starten
in der Kommandozeile den Befehl "winrm quickconfig" ausführen
Fragen mit "Y" beantworten

In den Gruppenrichtlinien (gpmc.msc):
Computerkonfig\Richtlinien\Administrative Vorlagen\System\Remoteunterstützung\
Remoteunterstützung anbieten > aktivieren
Helfer dürfen den Computer remote steuern > berechtigte Gruppe eintragen
gpupdate.exe auf jedem Server

Jetzt kann folgendes Kommando als PubApp für die spiegelnden Admins veröffentlicht werden:
C:\Windows\System32\msra.exe" /offerra

Einziges Problem: Ganz so komfortabel wie mit Citrix-Mitteln geht es nicht - auf welchem Host die Benutzersitzung läuft, muss man vorher in der Delivery Console heraussuchen.


Windows-VM verliert nach "Revert Snapshot" die Verbindung zur Domäne
Vor allem Test-VMs, aber auch Muster-VMs oder TerminalServer-Templates verlieren nach dem Revert eines Snapshots die Verbindung zur Domäne. Warum?

Zur Authentifizierung zwischen PC und Server (Domäne) wird eine sogenanntes Maschinenkonto-Kennwort verwendet. Dieses ändert sich aus Sicherheitsgründen zyklisch (30 Tage). Wenn die VM mittels Revert auf einen älteren Stand zurückgesetzt wird, stimmt das Maschinenkonto-Kennwort von Windows nicht mehr mit dem der Domäne überein.

Mit folgendem Registry-Key schaltet man das automatische Wechseln dieses Kennwortes in jeder VM ab:
HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters DisablePasswordChange REG_DWORD 1

Oder folgende GPO verwenden:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
"Disable machine account password changes" = Enabled

Ist das Kennwort einmal abgelaufen, hilft ein kurzes Entfernen der VM aus der Domäne und nach dem Neustart ein erneutes Aufnehmen in die Domäne! Dann gleich den obigen Registry-Key ändern und einen neuen Snapshot machen!


Die Netzkarte zeigt in der VM nur 10Mbit
Keine Sorge, die AMD-PCNET-Karte in einer VM zeigt niemals eine höhere Geschwindigkeit als 10MBit an! Trotzdem ist die Geschwindigkeit (je nach Host-Anbindung) wesentlich höher. Man kann mit ca. 50% der Hostleistung rechnen. Das bedeuted, dauert der Transfer einer 500MB großen Datei vom Host auf ein anderes System im 1GBit-Netz ca. 10-15 Sekunden, so dauert der gleiche Transfer aus der VM heraus bis zu 30 Sekunden. Trotzdem werden nur 10Mbit in der VM angezeigt! (Der Transfer müsste dann mindestens 1500 Sekunden dauern!) Mit dem neueren vmxnet-Treiber ist die Anzeige korrekt!


Ein paar VMX-Hacks für Kenner:
Die hier gezeigten Einträge in der VMX-Konfigurationsdatei der Workstationvariante sind etwas für erfahrene VMware-Nutzer! Ohne große Erklärung - viel Spaß beim Ausprobieren! ACHTUNG! Immer aktuelle VMware-Tools installieren!!!

Schnelle Netzkarte:
ethernet0.virtualDev= "vlance" / "vmxnet"

vierte Netzkarte:
ethernet4.present = "TRUE"
ethernet4.connectionType = "hostonly"/"bridget"/"nat"
ethernet4.addressType = "generated"
ethernet4.generatedAddress = "00:0c:29:e1:da:a2"
ethernet4.generatedAddressOffset = "0"

SCSI-Controller Buslogic oder LSIlogic:
scsi0.virtualDev = "buslogic" / "lsilogic"

zweiter SCI-Controller (mit Platte):
scsi1.present = "TRUE"
scsi1:0.present = "TRUE"
scsi1:0.fileName = "scsi10.vmdk"
scsi1:0.mode = "undoable"


Viel Zeit sparen - keine Gast-Installation oder Defrag mit Snapshot
Vor der Neu-Installation eines OS in einer VM oder vor einem sauberen Defrag der Grundinstallation sollten Sie noch keinen Snapshot setzen. Sonst installieren Sie komplett in die Redo-Logs der virtuellen Platte und müssen am Ende erst ein langwieriges Synchronisieren (Commit) über sich ergehen lassen. Erst nach erfolgter Grundinstallation, abgeschlossenen Kopiervorgängen und einer Defragmentierung ist es Zeit, den sauberen Grundzustand mit einem Snapshot zu sichern.


virtuelle ESX Server unter VMware Workstation 6 laufen lassen
Aktualisierung 21.05.2010: Seit Version 7 unterstützt Workstation das völlig ohne Trickserei!

Einige Einträge in der vmx-Datei einer VM schalten die hardwareunterstützte Virtualisierung ein. Der Trick funktioniert allerdings nur auf CPUs mit Intel-VT (Vanderpool) oder AMD-V (Pacifica). Hier die Trickserei mit Workstation 6.x direkt in der vmx-Datei:

- alte Syntax für Workstation 6:

für Intel Prozessoren:
monitor_control.vt32 = "TRUE"
für AMD Prozessoren:
monitor_control.enable_svm = "TRUE"
zusätzlich für alle CPU Typen (in jedem Falle notwendig):
monitor_control.restrict_backdoor = "TRUE"

- neue Syntax für Workstation 6.5:

für Intel und AMD Prozessoren gleichermassen:
monitor.virtual_exec = "hardware"
monitor_control.restrict_backdoor = "TRUE"


ISDN-Karte in VM verwenden
Häufig wird die Frage gestellt, ob ISDN-Karten in einer VM verwendet werden können. Das ist z.B. nötig bei der Virtualisierung eines Exchange-Servers mit angebundenem Fax-Gateway. Meist befindet sich eine aktive ISDN-Karte im Server, welche den Fax-Versand erledigt. Was wird nun in der VM? ISDN-Karten werden definitiv nicht unterstützt!
Einzige sinnvolle Lösung ist der Einsatz eines virtuellen CAPI. Zu empfehlen ist z.B. ein ELSA-LANCOM Router mit aktivierter FAX-Option. Die Fax-Option ist hier besonders wichtig, da viele virtuelle CAPI kein Fax Gruppe 4 unterstützen. Das wird aber von einigen Fax-Server-Lösungen vorausgesetzt!





Mein Buch zum Thema
3. Auflage:
--> Inhalt, Leseproben, Ausblick

Buchvorstellung



Newsletterabo
garantiert keine Werbung!

Tipps, HOWTOs,
Tests und Bugs.

Aktuell:
P2V - physical to virtual
Wie migriere ich eine physische Maschine in eine VM? Vorgehensweise, Bluescreens, Treiber...

Und: Netzwerk mit VMware
Wie bringe ich eine VM ins Netz? Bridged oder NAT? Virtuelle Netzwerke als Testumgebung?

Hier gibt es die Details!


eMail: