Alternatywa dla VirtualBox – AQEMU.

Zachciało mi się zmiany kernela z 3.2 na 3.5. Inspiracją był znajomy, który zaobserwował spadek zużycia prądu na laptopie przy zmianie z kernela 3.2 do 3.4 z 28W do 19W (pomiar wg powertop). VirtualBox po zmianie kernela oczywiście przestał działać. Nic nowego i nawet pisałem o tym, że debianowa paczka dla VirtualBox jest pod konkretny kernel robiona. Pisałem też, jak uruchomić VirutalBox na Debianie z własnym kernelem.

Co prawda u mnie kernel 3.5 nic nie daje w kwestii zużycia energii, ale skoro już pojawił się temat, to trzeba go pociągnąć. Mogłem użyć poprzednio opisanego sposobu z uruchomieniem VirutalBox na Debianie z własnym kernelem, ale jakoś nie uśmiechała mi się zmiana VirtualBox na wersję z repozytorium Oracle (poza tym, kiedyś różniły się licencją – w Debianie było OSE, nie żeby miało to jakiekolwiek znaczenie w tym przypadku), ściąganie plików nagłówkowych i kompilacja kernela, więc postanowiłem się rozejrzeć za alternatywami dla VirtualBox.

Ludzie podszepnęli KVM, który jak najbardziej znam i używam, ale w innym, serwerowym zastosowaniu. Okazuje się, że KVM ma także, obok narzędzi do zarządzania CLI i webowych, także narzędzia desktopowe, czyli GUI. Na stronie z listą frontendów dla KVM znaleźć można trzy frontendy typu desktop: AQEMU, virt-manager oraz GKVM. W pierwszym podejściu przeoczyłem virt-managera i wziąłem się za AQEMU. Już miałem orzec, że bootowanie z obrazu iso płyty CD nie działa, ale dogrzebałem się do ustawienia, które pozwala wybrać medium (i które nie jest zapamiętywane, bug zgłoszony).

Po tym było już z górki. Wirtualizacja desktopu z użyciem KVM generalnie po prostu działa. Nie testowałem jakoś specjalnie mocno, bo służy mi to głównie do zabaw z różnymi systemami liveCD, ale sieć działa, bootowanie z CD-ROM działa, przeglądarka działa. Zarządzanie, wygląd i dostęp do opcji też wygląda też sensownie, co można zobaczyć na screenshocie poniżej.

AQEMU screenshot

Źródło: strona projektu AQEMU

Zrobiłem, po przebootowaniu do 3.2, rzecz jasna, krótki benchmark, a w zasadzie namiastkę benchmarku, dla AQEMU i VirtualBox, w postaci zmierzenia czasu uruchamiania systemu z liveCD (padło na T(A)ILS – akurat nowe wydanie jest; 1GB RAM dla wirtualki, 1 CPU, parę uruchomień, ustawienia zbliżone do domyślnych). Dla AQEMU bootowanie (do momentu pierwszej interaktywności) trwało zwykle 44,9 sekundy, dla VirtualBox – 45,2 sekundy. Różnica pomijalna. Co ciekawe, dołożenie drugiego procesora nie wpływa na wynik i to w żadnym z przypadków.

Przy okazji, gdyby ktoś się brzydził frontendami i był hardcore’owym użytkownikiem wiersza poleceń, to do uruchomienia liveCD z w pliku o nazwie plik.iso użyciem KVM wystarczy:

kvm -m 1024 -vga vmware -boot d -cdrom plik.iso

Chwilowo to wszystko nt. wirtualizacji na desktopie. Szybki wniosek VirtualBox nie jest jedynym rozwiązaniem, AQEMU daje radę i wygląda na rozwiązanie wygodniejsze, jeśli ktoś używa Debiana niekoniecznie z dystrybucyjnym kernelem, lub kernelem z innej wersji. Nie będę testował GKVM – projekt wygląda na porzucony. Prawdopodobnie niebawem szansę dostanie virt-manager – na razie nie uruchomił się OOTB i krzyczy o niemożności dostania się do libvirtd. Nie miałem czasu bliżej się przyjrzeć sprawie. Jak uruchomię, to nie omieszkam opisać. Stay tuned.

Benchmark jądra BSD i Linux.

Dawno temu pisałem o porównaniu Linuksa i FreeBSD i FUDzie/mitologizacji zwolenników *BSD przy okazji benchmarku tych systemów, który to wątek wyższości *BSD ciągnie się odkąd pamiętam. Wtedy badano wersje 32 bitowe, a teraz, z okazji zamrożenia Debiana Wheezy pojawiła się nowa wersja benchmarku, dla systemów 64 bitowych. Nie ma zaskoczenia – Debian z jądrem Linuksa jest zawsze szybszy od wersji kFreeBSD. Często różnice są znaczące i wersja z jądrem Linuksa jest szybsza o 20-30%. Pomijam zupełnie ekstremalne przypadki, gdzie różnica jest o wiele większa.

Także w typowo serwerowych zastosowaniach widać różnicę na korzyść Linuksa – serwowanie statycznego contentu przy pomocy Apache to 10% różnicy. PC-BSD, które było poddane paru testom pokazuje, że słaby wynik Debian/kFreeBSD to nie przypadek. Z argumentów za korzystaniem z *BSD pozostał już chyba tylko ZFS. Moja motywacja do instalacji Debiana/kFreeBSD jest coraz mniejsza.

Źródło: Benchmark Debiana z jądrem Linux i kFreeBSD by Phoronix.

Raspbian, czyli Linux dla Raspberry Pi

Niedawno pojawiła się dystrybucja, będąca pochodną Debiana, która wypełnia „dziurę” między debianowymi architekturami armel oraz armhf. Jej celem jest wykorzystanie w pełni możliwości procesora Raspberry Pi. O różnicach w architekturach więcej pisałem we wpisie dlaczego nie kupię Raspberry Pi. Raspbian, bo tak nazywa się dystrybucja, oferuje architekturę armhf (inną niż w Debianie). Dzięki temu system, a szczególnie multimedia, mogą działać szybciej, niż w przypadku zwykłego Debiana. Przyspieszenie w działaniu zależy od aplikacji i typowo wynosi 10-20%. Dokładny benchmark Raspbiana tutaj.

Projekt jest rozłączny z Debianem, mieszanie pakietów Raspbiana zarówno z debianową architekturą armel, jak i armhf nie jest możliwe (a przynajmniej jest mocno odradzane).