• 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]

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.