j-sys.de

Gestern musste ich gleich zweimal mit virtuellen Platten spielen, einmal auf nem VMWare ESXi-Host und einmal auf nem Hyper-V-Host. Auf dem ESXi laufen mehrere Windows Server 2003, auf einem davon musste ich "mal eben schnell" ein halbes Terrabyte Speicherkapazität zur Verfügung stellen.

Also via VMWare Infrastructure Client in die Settings der VM, Festplatte hinzufügen, 512GB als Grösse angeben und - denkste! Die maximal zulässige Plattengrösse beträgt 256GB. WTF?

Beim Anlegen des VMFS Datastore mit den Default-Einstellungen wird als Blocksize 1MB gewählt, was dann hinterher nur max. 256GB grosse virtuelle Platten zulässt. Ändern lässt sich die Blocksize im Nachhinein natürlich nicht mehr, dazu müsste der VMFS Datastore mit einer anderen Blocksize neu formatiert werden.

Den ganzen Eintrag lesen »

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 bereits im September mit Version 2 der Virtualisierungssoftware VMWare Server herumgespielt und in einem Anflug von Wahnsinn auch alle meine VMs auf die neue Version konvertiert. Aber von vorn:

Mit VMWare Server 2 hat eine webbasierte Verwaltung der VMs Einzug gehalten, die von Version 1 bekannte VMWare Server Console ist damit verschwunden (der Grund dafür, warum mein VBSkript nicht mehr funktioniert). Wer VMWare Server auf seinem Arbeitsplatz-Rechner|Laptop betreibt, wird sich über die Webverwaltung nicht wirklich freuen: RAM-Verbrauch und CPU-Last schießen dadurch unwahrscheinlich in die Höhe, für die Webverwaltung wird ein Gespann aus Apache|Tomcat eingesetzt, das nunmal seine Ressourcen fordert.

Den ganzen Eintrag lesen »