… jak to było?

Od zawsze interesowałem się wirtualizacją, jak tylko o niej usłyszałem od razu zaprzęgnąłem ją do pracy instalując jakieś dziwne systemy na domowym komputerze. Wirtualizacją jest dla mnie po prostu genialna (nie tylko ze względu oszczędności powstałe przez mniejsze zużycie prądu).

Było to też zajęcie raczej hobbistyczne niż zawodowe. Początkowo była to jakaś pierwsza wersja VMware, później kolejne wersje tego programu, pracowałem trochę też Virtual PC dla Power PC Mac OSX (działa okropnie wolno), DosBox (jest ok na każdym systemie), używałem też trochę Xen i różnych emulatorów Atari ST, czy Amigi. W ostatnim czasie w IT sporo dzieje się w tym temacie. Firmy jak drożdże wydają swoje wersje wirtualnych systemów lub ogłaszają “strategiczne wsparcie” dla jakiegoś rozwiązania, że wspomnę tylko te najbardziej mnie interesujące: Redhat (Xen), SUN xVM (Xen), Oracle VM (Xen). Kilka dni temu SUN zakupił firmę produkującą Virtualbox - także w miarę popularny program do wirtualizacji. Ostatnio czytałem też, że Ubuntu zdecydowało się na wspieranie KVM jako narzędzia do wirtualizacji. Ba nawet popularny Dilbert w tym tygodniu mówi tylko o wirtualizacji Wygląda zatem, że wirtualizacja jest obecnie jednym z wiodących tematów w IT. Ostatecznie zachęcony małą wiadomością na www.linuxnews.pl postanowiłem sprawdzić jeden z nie znanych mi w ogóle systemów do wirtualizacji VirtualBox i dobrze znany mi VMware Serwer.

Systemy porównałem w ten sam sposób - poprzez program Sisoftware Sandra w wersji 1312 na Windowsie XP. Hmm… i u mnie wygrało VMware. VMware (1.0.4) wyraźnie wygrywa z VirtualBox (1.5.4) . Gospodarzem był zwykły desktop PC z Fedorą 8 oraz procesorem AMD X2 4200+.

Generalnie do 1MB obie maszyny idą łeb w łeb, ale niestety dla większych bloków pamięci VMware oscyluje cały czas w granicach ~160 , a VirtualBox ~200. Jest to prawie 12,5% różnicy w wydajności na korzyść VMware! W blogu który mnie zainspirował wartości były całkowicie inne VMware ~100-360, a VirtualBox ~75, czyli do 400% różnicy na korzyść VirtualBox. Ale oto zrzuty ekranu, one przecież nie kłamią:

Wyniki dla VMware:

Wyniki dla VirtualBox:

Jak to jest zatem możliwe?

Było zabawnie…
dap

* A teraz na poważnie, ten wpis ma pokazać, że wyciąganie ogólnych wniosków w oparciu o tylko jeden test jest raczej mało miarodajne. Można o tym oczywiście pogadać z kumplami przy piwie, że u mnie jest tak i tak a jak u Ciebie, ale robienie z tego wiadomości na główną stronę w miarę popularnego portalu jest przesadzone. Oczywiście sam temat wart jest głębszego zbadania, gdyż wydajność wirtualnych maszyn jest bardzo ważna, ale nie poprzez dwa testy i dwa zrzuty ekranu. W miarę możliwości i pomysłów być może zrobię bardziej szczegółowe testy. Zatem moje porównanie proszę zignorować jako dowód na cokolwiek, a w szczególności na wyższość jednego programu nad drugim. U mnie po prostu tak to dziś było - ot taki fenomen

Po instalacji najnowszego jądra Xen udało mi się stworzyć wirtualny komputer, który przeżywa nawet restart, używa wirtualnych opcji procesora i działa w pełnej wirtualizacji. Niestety z tego co udało mi się przeczytać nie ma możliwości by Xen i VMware działały równocześnie. Nie jest to duży problem, ale zobaczmy…

dap

Wirtualizacja - małe przygody (konfiguracja AMD-V + Xen @ Linux)

Wirtualna maszyna ORACLE bazuje na technologii Xen dlatego postanowiłem ją wypróbować na Linuksie. Uprzedzę jednak zakończenie - e niestety nie udało się uruchomić żadnej wirtualnej maszyny w pełnej wirtualizacji, ale i tak zabawa była przednia. Zatem po kolei…

Jako posiadacz procesora AMD sprawdziłem najpierw czy mój procesor wspiera sprzętowo wirtualizacje:

$ cat /proc/cpuinfo | grep svm
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc


Zatem wspiera - czyli wszytko OK?

Niestety nie. Wszelkie próby uruchomienia systemu kończą się komunikatami o tym, że opcja wirtualizacji nie jest włączona w BIOS-ie. W BIOS-ie naturalnie nie ma żadnej opcji związanej z wirtualizacją procesora.

Hmm… czyżby to problem wersji BIOS-u? Na pewno - zatem robimy aktualizację. Moja płyta główna to GA-M59SLI-S5. Ostatnia aktualizacja BIOS-u była chyba u producenta, ja w każdym razie nic na niej nie zmieniałem Szybkie sprawdzenie wersji - i rzeczywiście na niemieckiej stroniejest GIGABYTE nowa wersja F8H, ale na polskiej jest jeszcze nowsza F8L. W żadnej z poprawek nie ma informacji o wsparciu wirtualizacji w procesorach, ale być może zostało to po prostu przeoczone. W każdym razie decyduje się na update BIOS-a. Z racji wygody wybieram aktualizację przez internet za pomocą programu @BIOS. Wszystko jest ok, ale na wszystkich serwerach jest tylko wersja F8H. No cóż, spróbujemy tę aktualizację. BIOS został ściągnięty i zainstalowany, komputer zresetowany, wszystko działa poprawnie. Ale opcji włączanie wsparcia dla wirtualizacji nie ma.

Hmm… zatem może wersja z tego roku F8L ja posiada? Tym razem ściągam BIOS na dysk i dokonuję aktualizacji lokalnie. Wszystko wygląda ok. Uruchamiam ponownie komputer i … nic, ale to kompletnie nic się na ekranie monitora nie pokazuję Komputer jest włączony, wiatraczki pracują, a na monitorze nic nie widać! Taaa… Zatem doigrałem się. Życiowa mądrość, że lepsze jest wrogiem dobrego ponownie się potwierdziła . Miałem komputer z teoretyczną działającą wirtualizacją, a teraz - po ulepszeniu - mam komputer, który praktycznie całkiem nie działa. Nawet super opcja DualBIOS (TM) jest niedostępna gdyż nic się na ekranie monitora nie pojawia. Teraz stało się jasne dlaczego wersja F8L nie była dostępna przez internetową aktualizację. Nerwowe przeglądanie instrukcji obsługi dla płyty nie przynosi żadnych efektów - nigdzie nie widzę zworki odpowiedzialnej za ew. przywrócenie BIOS-u z kopii zapasowej. Super…

… zatem goooglam, goglam i goglam, być może ktoś inny miał podobny problem. Po chwili jest rozwiązanie, należy zresetować CMOS. A teraz dużymi literami: AFTER BIOS UPDATE ALWAYS RESET CMOS! Zwieram zworkę odpowiednią za kasację i komputer się włącza. Uff… udało się.

Niestety w BIOS-ie w dalszym ciągu nie ma opcji odpowiedzialnej za wirtualizację, ale w czasie czytania instrukcji wpada mi w oko mała podpowiedź. Zaawansowane opcje w BIOS-ie stają się widoczne po naciśnięciu Ctrl-F1. Genialnie, podwójne zabezpieczenie, którego kompletnie nie rozumiem - szczególnie w kontekście opcji wirtualizacji. Ale cóż grunt, że opcja została włączona i działa… teoretycznie. Znaczy także praktycznie, gdyż komunikat o błędzie już się nie pojawia, ale za to nie można uruchomić poprawnie Xen. Oczywiście Xen działa, tylko nie da się zrobić działającego wirtualnego systemu.

Problemy leży prawdopodobnie w APIC tej wspaniałej płyty głównej, gdyż poprzedni kernel startował tylko z opcja noapic. Kernel z opcją Xen nie startował z tą opcją (po kilku sekundach zawieszał się), ale właśnie startował po jej wyłączeniu. Na tak uruchomionym systemie można było utworzyć wirtualny system, który niestety nie przeżywał restartu.

… i w tym właśnie momencie stwierdziłem że VMware Serwer nie był zły. Oczywiście jest zamknięte, oczywiście nie jest tak wydajne jak Xen, oczywiście nie zostało wybrane przez ORACLE, ale przy stosunkowo niewielkim nakładzie pracy działa (i to zarówno na Windowsie jak i na Linuksie).

Szybko się przeprosiłem z VMware, ściągnąłem aktualną wersję (1.0.4) VMware Serwer, patch (update115) dla Linuksa i proszę mam wreszcie wirtualne maszyny, które działają nawet po restarcie

Oczywiście wirtualizacji Xen nie odpuszczę ale jak na razie cześć prac wykonam na VMware - tym bardziej, że bardzo interesuje mnie porównanie wydajności obu tych systemów.

Było zabawnie…

dap

PS. W ramkach jest pokazana schematyczna architektura obu systemów. VMware Serwer w wersji 2.0 ma wspierać także parawirtualizację, lecz na razie jest to wersja Beta.