• jajko 2.6.24.5 (domyslne smp ze Slacka 12.1) działało mi od dwóch lat na kilkunastu routerach bez kernel panic
• było ono zmontowane z domyślnego konfiga ze Slacka oraz połatane imq, esfq i layer7
• działało również pod Debianem bez żadnego "ale" (co w sumie oczywistym jest)

Na warsztat poszedł domyślny konfig jajeczka 2.6.34. Zaciągnięte zostały też vaniliowe źródła z kernel.org oraz patche Dj Gregora z linuxbox.pl. Swoją drogą z tego co zauważyłem Dj jest fanem Slackware (podobnie jak ja kiedyś) więc dziwne by było gdyby nie popełnił patchów dla domyślnego jądra tego systemu. Szacun. Kolejność ataku była następująca:

• patchowanie
• make menuconfig
• zapis konfigu i wyjście
• make menuconfig
• zaznaczenie odpowiednich modułów (IMQ Target, esfq, layer7)
• włączenie do jajka modułu Virtio Block Device, Virtio PCI i Virtio Baloon
• zapis konfiga
• make bzImage modules modules_install
• procedura tworzenia paczki (długa historia) z jądrem
• kompilacja i paczkowanie iptables, iproute, l7-protocols

Efekty - paczki do pobrania: [i386] [amd64]

Muszę przyznać, że powoli straciłem wiarę w moc i możliwości Proxmoxa jako narzędzia do wirtualizacji z serii Open-Source. Znalazło się jednak troszkę czasu aby przetestować to na sprzęcie Intela. W obroty poszedł quadzik Q9400 2.66GHz na rdzeniu, płyta Gigabyte GA-EG45M-DS2H z 8GB ramu 4 x KVR800D2N5K2/2G. Na tym sprzęcie do tej pory trzymany był zwirtualizowany hosting firmowy oraz kilka innych wirtualek znajomych, które były kontrolowane przez KVM. Zrobiliśmy test, który wydawał się być najgłupszym pod księżycem (btw. dziś ładny rogalik na niebie świeci :P). Zostawiliśmy odpalone te wszystkie maszyny - w sumie 8 sztuk. Następnie dołożyliśmy jeszcze jedną wirtualkę KVM z routerem moim starym postawionym na archaicznym już Slacku 11-tym. Przy okazji znów wielkie pokłony w stronę Kadzbiego, który to pokazał mi jak przez ssh skopiować działający żywy system na inną maszynę i jeszcze odpalić to hehe. Załatwia to linijka:

tar -pcf - ./ | ssh remoteuser@remotehost tar -C /path/to/remote/dir -pxf -

która pakuje fizyczny system, w locie przesyła go na zdalną maszynę i na niej rozpakowuje w wybrany katalog. Wystarczyło więc odpalić wirtualną maszynę, zbootować ją np z Gentoo Minimal, przypisać adres IP, odpalić serwer ssh (/etc/init.d/sshd start) a następnie zmienić hasło na użytkownika root i skopiować. Wcześniej przygotowano odpowiednią partycję, sformatowano i zamontowano w /path/to/remote/dir z powyższego ciągu znaczków. Później wydano 4 magiczne polecenia:

mount -o bind /dev /path/to/remote/dir/dev

mount -t proc /proc /path/to/remote/dir/proc

chroot /path/to/remote/dir/

lilo

które przeteleportowały nas w chrootowane środowisko naszego routera i zaaktualizowały lilo w MBR. Po reboocie ku naszemu zdziwieniu wszystko od razu zadziałało. Sieć śmiga przecudnie przy podobnej ilości użytkowników i transferach przez router rzędu 20Mbps (bo takie łącze mamy). Na razie obserwujemy. Proxmox ani router i inne wirtualki nie dają żądnych negatywnych znaków. Warto dodać w celach informacyjnych, że do maszyny z mamusią zostały dołożone dwie fizyczne karty sieciowe Intel PRO Fast Ethernet, z których utworzyliśmy dwa potrzebne bridże.

Zauważmy również, że zostało tu zamontowane podstawowe jądro 2.6.24.5 ze Slackware 12.1 delikatnie połatane. Jądro to nie obsługuje VIRTIO zatem wirtualka też. Jestem gotów wysnuć pewną hipotezę. Niemożliwe było osiągnięcie celu, który założyliśmy na tanim gównianym sprzęcie firmy AMD. Intel w tym wypadku przeszedł nasze oczekiwania (ostrożna hipoteza). W ramach argumentacji dopowiedzmy, że moduł KVM jądra matki, który odpowiada za kontrolę nad wirtualnym routerem jest inny dla Intel i inny dla AMD. Według mnie ten dla Intela jest "lepszy" bo działa.

Tworząc maszynę wirtualną wybieramy typ dysku VIRTIO (nie ATA, nie SCSI) oraz typ karty sieciowej VIRTIO. Opcje te dostępne są w Proxmoxie o wersji wyższej niż 1.3. Instalujemy na tym np. Debian Lenny w wersji netinstall. Instalka ładnie wykryje nam dysk o nazwie /dev/vda i cała reszta tu już to, co znacie z życia codziennego.

Po odpaleniu systemu na dzieciaku wydajemy polecenie lsmod i zobaczymy wśród podładowanych modułów między innymi:

• virtio_pci
• virtio_net
• virtio_blk

Następnie klepiemy polecenie lspci i powinniśmy zobaczyć coś koło tego:

• 00:03.0 Ethernet controller: Qumranet, Inc. Device 1000
• 00:04.0 Mass storage controller: Qumranet, Inc. Device 1001
• 00:05.0 RAM memory: Qumranet, Inc. Device 1002

Dla świętego spokoju dajmy jeszcze df -h i być powinno tam gdzieś na przykład:

/dev/vda1

Na sieci znalazłem info, że za pomocą VIRTIO można nawet 11-krotnie przyspieszyć wirtualny dysk. Aby jednak osiągnąć to, należy zmienić algorytm IO-Schedulera z [cfq] na [deadline] przez rekompilację jądra systemu (na dobre) lub "w locie" za pomocą polecenia:

echo deadline > /sys/block/sda/queue/scheduler

gdzie sda to nasz dysk. Nie testowałem tego jeszcze.

Na razie testowa konfiguracja chodzi u kolegi, który ma około 150 klientów przez to przepuszczonych. Kolejne problemy jakie spotkaliśmy to kompilacja jądra ze wszystkim odpowiednimi dla routera opcjami. Zaznaczam od razu, że paczki rabbit nie działają na maszyna z dyskiem VIRTIO ponieważ nie zostało to jeszcze wkompilowane a initrd nie używam. To będzie wyzwanie na kilka najbliższych jesiennych szarych wieczorów.

PS. dzięki kadzbi za pomoc.

Instalkę Proxmoxa ściągnąć można z sieci jako obraz iso, z  którym wiadomo co się robi. Sam proces instalacji jest dokładnie opisany na oficjalnej stronie www i jest bajecznie prosty. Warto tylko dodać, że dystrybucja nie posiada wsparcia dla sotfwarowego raida a partycje instaluje jako LVM2 więc przed przystąpieniem do montażu Proxmoxa odwiedź najpierw wujka googla i sprawdź co to jest "Logical Volume Management". Swoją drogą jakiś czas temu uparłem się i postawiłem Proxa na softowym raid1 ale proces ten był mocno skomplikowany i w czasie testów na "żywym organizmie" stwierdziłem, że działa to wszystko strasznie powoli.

Apropos tematu postu. Proxmox umożliwia pracę w dwóch trybach wirtualizacji:

• Containers (OpenVZ)  czyli dziecko korzysta z jaja mamy
• Fully Virtualized (KVM, Qemu) czyli dziecko ma swój własny emulowany sprzęt, do tego potrzeba dzieciakowi Intel-VT lub AMD-V

Pierwsza opcja moim zdaniem nadaje się perfekcyjnie jako baza dla serwerów hostingowych, pocztowych, dns itd ponieważ z poziomu mamusi można przeglądać bezpośrednio system plików dziecka. Jest to nieocenione w przypadku systemów backupowych (backup danych). W przypadku OpenVZ mamy jednak bardzo ograniczone możliwości korzystania z iptables czyli tworzenia firewalla. Obsługa sieci dla OpenVZ odbywa się na poziomie warstwy trzeciej przy użyciu routingu poprzez wirtualne interfejsy lub na poziomie warstwy drugiej (bridż). Wszystkie procesy uruchamiane przez dzieci są widzialne pod:

ps ax

wykonane u mamusi. Daje nam to dodatkową kontrolę nad nimi (np kill -9 hehe). Dodatkowo z poziomu mamy można przejść bezpośrednio na # konsoli wirtualnej maszyny bez znajomości hasła superusera prostym poleceniem:

vzctl enter id_maszyny

Wirtualizacja na poziomie systemu operacyjnego, którą jest OpenVZ umożliwia pracę jedynie w środowisku linux pod ograniczoną ilością dystrybucji. Oficjalne i nieoficjalne templatki VZ można znaleźć bez problemu w sieci.

Druga opcja (Qemu, KVM) przeznaczona jest bardziej dla routerów, które muszą mieć pełny dostęp do iptables oraz dla systemów operacyjnych != linux-kernel. Nic nie stoi na przeszkodzie aby zainstalować sobie WindeXP, Viste (ugh) albo inne cuda na czymś takim. Pytanie tylko po co Pełna wirtualizacja zabiera nam jednak możliwość dostępu do drzewa katalogów dzieci z poziomu matki. Nie ma również możliwości logowania do dziecka bez autoryzacji. Obsługa sieci jest możliwa tylko na poziomie warstwy drugiej (bridż).

Całością zarządzać można na dwa sposoby:

• poprzez konsolę
• poprzez gui ssl-owe przez przeglądarkę

Praca z Proxmoxem jest dość intuicyjna. Jeśli znasz podstawy sieci (warstwa 2 i 3) to odpalenie wirtualizacji zajmie Ci max godzinę zegarową. Jeśli nie - zapytaj kogoś kto zna - będzie szybciej

Kolega Fair jest w trakcie tworzenia panelu dla klienta dla Proxmox, który Wam polecam. Kliknij tu po więcej szczegółów.