j-sys.de

Ich migriere so nach und nach alle VMs von VMWare ESXi nach Hyper-V 2008 R2 - heute abend ist der dritte Server ausgetauscht worden, derzeit laufen 21 VMs verteilt auf diesen drei Servern. In den nächsten Wochen kommt dann das Sahnestückchen: Das erste Failover-Cluster. ;-)

Bis Mitte des Jahres werden wir noch diverse Kundenserver migrieren bzw. gleich auf Hyper-V aufsetzen, u.a. auch produktive gespiegelte SQL- und Exchange-Server etc. Mein Blog wird sich also noch mit einigen Berichten zum Thema Hyper-V füllen. Da ich mir die wichtigen Infos recht mühsam via google zusammensuchen musste, werde ich versuchen, alle relevanten Informationen mit hübschen Screenshots hier zu sammeln und zu ordnen.

Ihr habt auch noch Infos zum Thema?
Dann immer her damit und rein in die Kommentare!

Eines meiner Projekte, die ich dann doch im letzten Jahr noch abschliessen konnte, war die Migration unserer VMs von VMWare ESXi 3.5 nach Microsoft Hyper-V 2008 R2. Ich hatte ganz schön zu kämpfen, so klappte bspw. die Verbindung zu den VMs via Hyper-V-Manager einfach nicht.

Schuld daran war (und ist) aber gar nicht Hyper-V selbst, sondern ein Problem mit der Integration von Windows Server 2008 in ein Windows 2003 basiertes Active Directory.

Seitdem diese Fehler beseitigt sind, läuft die Hyper-V-Geschichte absolut rund - und schnell. Einer der Gründe für die Migration war und ist die bessere Performance von Hyper-V gegenüber ESXi, insbesondere was die Plattenzugriffe angeht.

Den ganzen Eintrag lesen »

Wie ich vor einigen Minuten dem heise-Newsticker entnommen habe, stellt VMWare diverse Patches zum Stopfen offener Löcher in folgenden Anwendungen bereit:

VMware Workstation 6.5.1 and earlier,
VMware Player 2.5.1 and earlier,
VMware ACE 2.5.1 and earlier,
VMware Server 2.0,
VMware Server 1.0.8 and earlier,

VMware ESXi 3.5 without patches ESXe350-200811401-O-SG,
ESXe350-200903201-O-UG

VMware ESX 3.5 without patches ESX350-200811401-SG,
ESX350-200903201-UG

VMware ESX 3.0.3 without patch ESX303-200811401-BG

VMware ESX 3.0.2 without patch ESX-1006980

Ausführliche Infos gibt es im Original-Fehlerbericht direkt bei VMWare.

Ich betreibe hier diverse virtuelle Maschinen auf einem ESXi-Server, bei einigen fiel mir nun auf, das die Maus in der Console des VI-Clients nicht funktioniert, also kein Mauszeiger vorhanden, Bedienung per Tastatur aber einwandfrei.

Da ich die Maschinen normalerweise per RDP administriere, war mir das bisher nicht wirklich aufgefallen. Die Ursache war -nach Rücksprache mit einem Kollegen- aber schnell gefunden:
Einige der Maschinen wurden früher auf einem Microsoft Virtual Server betrieben und nur auf diesen Maschinen trat das Phänomen auf.

Seinerzeit wurden die Maschinen mit dem VMWare Converter nach ESXi portiert und dabei wurde augenscheinlich vergessen, die VirtualMachineAddOns -das Microsoft Pendant zu den VMWareTools- zu deinstallieren. Dummerweise klappt die De-Installation selbiger AddOns nicht, wenn die Maschine erstmal auf dem ESXi läuft. Was also tun?

Hilfe kam in diesem Fall per Mail -vielen Dank, Holger!-, wobei auch google die Ergebnisse liefert. Hier mal die Essenz aus dieser Mail:

The problem is that the old mousedriver is hooked to the mouse device class. To remove this dependency, go into the registry and navigate to the key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}

Remove the value msvmmouf from the UpperFilters Regvalue. ONLY THIS ONE VALUE, NOT THE COMPLETE KEY!!!

Reboot....tadaaa!!

Der Vollständigkeit halber sollte man nun noch "saubermachen":

If you wish you can take out the drivers completely by deleting these registry hives completely :
The driver:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msvmmouf

The Service:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VPCMap

The CopyHook Shell Extension: ( for folder access )
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{30C14BAC-122C-42ED-B319-1139DBF48EB8}\InProcServer32

HKEY_CLASSES_ROOT\Directory\shellex\CopyHookHandlers\VPCCopyHook

After a reboot you can delete the "Virtual Machine Additions" folder from program files...

Und wem das immer noch nicht ausreicht, der kann sich mal Gedanken darüber machen, wie man den Eintrag "VirtualMachineAddOns" aus Systemsteuerung\Software entfernt bekommt. ;-)

Ich hatte ja bereits einen Artikel verfasst, der das Einbinden eines MS Loopback Adapters beschreibt - ausgegangen bin ich seinerzeit von der Tatsache, das unter VMWare Server 1.0.x der Zugriff aus einer VM auf den Host über das installierte HostOnly-Network nur dann funktioniert, wenn die LAN-Schnittstelle aktiv ist. Zumindest konnte ich auf zwei Maschinen mit nicht aktiver LAN-Schnittstelle auch via HostOnly nicht zugreifen.

Auch wenn die Screenshots aus dem erwähnten Artikel aus Version 2 des VMWare Servers stammen, bezog sich der Artikel aber auf Version 1.0.x - da war ich wohl etwas voreilig, denn -oh Wunder- mit Version 2 funktioniert genau das -der Zugriff aus der VM via HostOnly-Network auf den Host- beinah stressfrei.

Entweder hat dieses Verhalten tatsächlich erst mit Version 2 Einzug gehalten oder ich bin seinerzeit an den Einstellungen unserer Firewall gescheitert. Anyway, einen Stolperstein gibt es trotzdem:
Sowohl die Rechner meiner Kollegen als logischerweise auch meiner sind Mitglieder einer Windows 2003 Domain. Versuche ich nun, aus der VM heraus (_KEIN_ Domain-Mitglied) ein Netzlaufwerk auf eine Freigabe des Hosts zu verbinden, werde ich erwartungsgemäss nach Anmeldedaten gefragt.

Den ganzen Eintrag lesen »

Wer VMWare installiert hat, findet nach der Installation zwei neue Einträge im Ordner Netzwerkverbindungen:

VMWare Netzwerkverbindungen

Sobald nun eine Firewall auf dem Rechner zum Einsatz kommt, macht es u.U. Sinn, diese beiden Netze
a) seinen Gegebenheiten anzupassen und
b) in den Firewalleinstellungen freizugeben

Den ganzen Eintrag lesen »