VirtualBox - messze vagyunk még... sajnos :(

Az hamar kiderült, hogy nem úszom meg a GPL berkein belül, hiszen szerver környezetben nyilván headless kell futtatnom a guesteket, akkor pedig (V)RDP-re van szükségem. Na sebaj, most épp így jártunk.

Létrehoztam négy virtuális gépet. Mivel a guest-eknek itt-ott szükségük volt némi CPU-kraftra, ezért guestenként 2-4 processzormagot osztottam ki, 1-2-4 giga memória, egy virtuális LSI SCSI vezérlő, és Intel Pro/1000 ethernet társaságában.

Megkezdtem az első guest telepítését: 32 bites, Windows Server 2003 Standard formájában. Már a telepítés során jöttek érdekességek: intenzívebb I/O műveleteknél a guest néha meg-megakadt, sőt, egyszer mintha teljesen le is fagyott volna. Ekkor játszottam a VM beállításaival, kikapcsoltam a virtuális SCSI vezérlőnél a "host cache" opciót, és aztán - most vagy ennek köszönhetően, vagy véletlen egybeesés - végigment a telepítés, és első blikkre minden jónak is látszódott.

Az első napokban a guesteket néha újra kellett indítanunk különböző szoftverek telepítése miatt. Ekkor általános tapasztalattá vált, hogy az esetek nagy részében a guest OS nem tudott szabályosan leállni, hanem a poweroff előtti utolsó(?) fázisban megakadt, és ilyenkor már VBoxManage segítségével sem lehetett a virtuális gépet kikapcsolni/resetelni, hanem "kill -9" kellett a VM processznek.

További tapasztalat volt, hogy óriási az overhead - amikor a négy guest az idle loopon kívül nem csinált semmit, akkor is összesen több, mint egy processzormagnyi system time ment a levesbe. Ekkor a host gép kernelében átállítottam a CONFIG_HZ értékét 1000-re, és látványosan javult a dolog.

Még csemege, hogy az 1-nél több processzormaggal rendelkező VM-ek esetében, a Windows guest-ek órája össze-vissza járt. Hiába volt ntp kliens, egyik pillanatról a másikra nagyokat ugrált az óra - hogy összességében sietett 20 perc alatt fél napot :) - az még hagyján, de hogy visszafelé is ment az idő, az néhány guest-ben futó programot kiakasztott. Azon már csak mosolyogtunk, amikor az éjjel 03:00:00-ra beállított backup nem futott le - mert a guest egyszerűen átugrotta ezt az időpontot :) Ezen a host kernel commandline-ba illesztett "divider=10 clocksource=acpi_pm" opció segített, de teljesen tökéletes sosem lett a dolog.

Egyszer szóltak a fejlesztők, hogy valamit köhög a guest-be telepített SQL Server 2005, és hibásak egyes adattáblák. Megnéztem, masszívan sérült volt alatta az NTFS fájlrendszer. Hümm. Megjavítottam, majd a későbbiekben még egyszer előfordult fájlrendszer korrupció. Ekkor - jobb ötlet híján - átállítottam a virtuális LSI SCSI vezérlőt egy "mezei" PIIX4 ATA vezérlőre, hátha ott a probléma - mivel ezt kínálja alapból a VirtualBox is, gondoltam, lehet, hogy csak én vagyok olyan barom, hogy a default helyett mást választok, és esetleg nincs tesztelve megfelelően az LSI SCSI emuláció.

Hogy ez segített-e valamit, az már nem fogjuk megtudni. Meguntuk ugyanis, hogy összességében a rendszer állandó meglepetésekkel szolgált. Az volt az utolsó csepp a pohárban, hogy nagyobb I/O műveleteknél néha olyan szinten belassult a VM-ben minden, hogy pl. egy 3GB-os ZIP kicsomagolásakor a VM még pingre sem válaszolt.

Csalódott vagyok, és szurkolok a fejlesztőknek, hogy rövidesen a VirtualBox valóban olyan "Enterprise" termék legyen, mint ahogy az a weboldalának kezdőlapján kiírva szerepel.

A pórul járt VM-eket pedig addig is betoltuk vCenter-be.
Brühühü :(