modified on 2 gru 2009 at 10:16 ••• 14 372 views

Xen

Z MikroTik Wiki

Spis treści

Wstęp do wirtualizacji Xen

Technologie wirtualizacji umożliwiają wykorzystanie jednego interfejsu fizycznego przez wiele różnych systemów operacyjnych. Wparcie wirtualizacji w RouterOS pozwala na uruchomienie wielu kopi RouterOS lub innych wspieranych systemów operacyjnych. Wsparcie wirtualizacji zależy od architektury systemu. Nie wszystkie architektury wspierane przez RouterOS pozwalają na wirtualizację.

Możliwość uruchomienia oprogramowania innego niż RouterOS pozwala użytkownikom uruchamiać aplikację, które nie są zawarte w RouterOS.

Xen jest systemem wirtualizacji dla maszyn X86. Xen oparty jest o Wirtualną maszynę Xen dla Linuksa.

Wsparcie wirtualizacji x86

Wsparcie wirtualizacji systemów z architekturą x86 jest zaimplementowane przez Xen (http://www.xen.org). Umożliwia RouterOSowi uruchamianie innych systemów operacyjnych wspierających parawirtualizację Xen w "wirtualnych maszynach" (goście), kontrolowanych przez oprogramowanie RouterOS (host).

Wsparcie wirtualizacja systemów x86 dołączone jest do RouterOS od wersji 3.11. Musi być zainstalowany pakiet "xen"

Host RouterOS zestawia wirtualne maszyny, aby mogły używać pliku jako obrazu dysku. Dodatkowo host RouterOS może zestawić wirtualną sieć ethernetową pomiędzy sobą a wirtualnymi maszynami. Umożliwia to uczestniczenie gości w sieci pod kontrolą hosta RouterOS.

Aby uruchomić system operacyjny w wirtualnej maszynie musisz mieć:

  • Jądro OS wspierające parawirtualizację Xen
  • Obraz dysku OS
  • (opcjonalnie) inicjujący ram dysk używany podczas botowanie OS w wirtualnej maszynie

Jeśli do botowania VM używany jest obraz RouterOS, jądro i inicjujący ram dysk nie są wymaganie - potrzebne jest jedynie określenie obraz dysku. Obrazy RouterOS używane w VM można utworzyć na dwa sposoby:

  • zrobienie obrazu z gotowej instalacji RouterOS x86 wspierającej wirtualizację (wersja >= 3.11)
  • przez użyciu specjalnej funkcji RouterOS tworzącej obraz używany w VM (te funkcje nie tworza obrazu RouterOS, który może być skopiowany i uruchamiany na fizycznych maszynach!).

Drugi sposób jest bardziej elastyczny ponieważ pozwala użytkownikowi określić rozmiar obrazu dysku.

Aby uruchomić inny system operacyjny w VM, potrzebujesz kernela Linuksa, obrazu dysku i inicjującego ram dysku (jeśli potrzebny).

Jeden obraz dysku może być na raz używany tylko przez jedną maszynę wirtualną.

Tworzenie obrazu RouterOS do VM

Aby utworzyć obraz RouterOS dla VM użyj polecenia "/xen make-routeros-image":

[admin@MikroTik] /xen> make-routeros-image file-name=ros1.img file-size=32

[admin@MikroTik] /xen> /file print
 # NAME             TYPE            SIZE       CREATION-TIME
 0 ros1.img         .img file       33554432   jun/06/2008 14:47:23

Zostanie utworzony 32 MB obraz RouterOS, który od razu może być użyty w VM. Nowy obraz RouterOS oparty jest o system hosta i zawiera wszystkie pakiety, które są zainstalowane na hoście ale nie zawiera ustawień hosta.

Dodatkowo, "make-routeros-image" ma parametr "configuration-script", który może być użyty do dodania skryptu konfiguracyjnego w momencie inicjalizacji VM. Skrypt zostanie uruchomiony podczas pierwszego uruchamiania obrazu systemu.

Konfiguracja VM

Wszystkie funkcje wirtualizacji związane z architekturą x86 dostępne są w menu "/xen".

Dostępna pamięć dla hostowego RouterOS

Domyślnie cała pamięć dostępna jest dla systemu hosta, na przykład dla systemu z 1 GB pamięci:

[admin@MikroTik] > /system resource print
                   uptime: 2m4s
                  version: "3.9"
              free-memory: 934116kB
             total-memory: 963780kB
                      cpu: "Intel(R)"
                cpu-count: 2
            cpu-frequency: 2813MHz
                 cpu-load: 0
           free-hdd-space: 77728884kB
          total-hdd-space: 79134596kB
  write-sect-since-reboot: 989
         write-sect-total: 989
        architecture-name: "x86"
               board-name: "x86"
[admin@MikroTik] > /xen global-settings print
  memory-for-main: unlimited

W niektórych przypadkach możesz ograniczyć możliwość alokacji potrzebnej pamięci dla systemów VM, ponieważ host może używać pamięci, do np. celów cashowania systemu plików. Dlatego zaleca się ustawienie limitu pamięci dostępnej dla hosta (wartość limitu zależy od programów uruchomionych na hoście, ogólnie obowiązują te same reguły co dla określania ilości fizycznej pamięci dla normalnej instalacji RouterOS):

[admin@MikroTik] > /system resource print
                   uptime: 2m4s
                  version: "3.9"
              free-memory: 934116kB
             total-memory: 963780kB
                      cpu: "Intel(R)"
                cpu-count: 2
            cpu-frequency: 2813MHz
                 cpu-load: 0
           free-hdd-space: 77728884kB
          total-hdd-space: 79134596kB
  write-sect-since-reboot: 989
         write-sect-total: 989
        architecture-name: "x86"
               board-name: "x86"
[admin@MikroTik] > /xen global-settings print
  memory-for-main: unlimited
[admin@MikroTik] > /xen global-settings set memory-for-main=128
[admin@MikroTik] > /system reboot
Reboot, yes? [y/N]:
y
system will reboot shortly

 ....

[admin@MikroTik] > /system resource print
                   uptime: 1m5s
                  version: "3.11"
              free-memory: 114440kB
             total-memory: 131272kB
                      cpu: "Intel(R)"
                cpu-count: 2
            cpu-frequency: 2813MHz
                 cpu-load: 0
           free-hdd-space: 77728884kB
          total-hdd-space: 79134596kB
  write-sect-since-reboot: 794
         write-sect-total: 794
        architecture-name: "x86"
               board-name: "x86"

Tworzenie RouterOS VM

Załóżmy, że mamy już obraz RouterOS "ros1.img", utwórzmy VM dla RouterOS:

[admin@MikroTik] /xen> add name=ros1 disk-images=hda:ros1.img memory=64 console-telnet-port=64000
[admin@MikroTik] /xen> print detail
Flags: X - disabled, C - configuration-changed
 0 X name="ros1" disk-images="hda:ros1.img" initrd="" kernel="" kernel-cmdline="" cpu-count=1 memory=64 weight=256
     console-telnet-port=64000 state=disabled

Poniższe parametry pominięto przy poleceniu "add":

  • disk-images=hda:ros1.img - parametry określają, czy plik "ros1.img" będzie używany jako dysk "hda" (IDE Primary Master) na systemie gościa;
  • memory=64 - określa ilość pamięci dla VM;
  • console-telnet-port=64000 - system hosta nasłuchuje na porcie 64000 i po uruchomieniu telnetu, forwarduje wyjście konsoli klienta do klienta telnetu i akceptuje wejście konsoli do telnetu klienta.

Pozostałe ustawienia:

  • kernel & initrd - pliki jądra i ram dysku, jak wspomniano wcześniej, wskazanie plików nie jest konieczne do uruchomienia obrazu RouterOS;
  • kernel-cmdline - polecenia podane do jądra Linuksa
  • cpu-count - jak wiele CPU będzie dostępnych w VM;
  • weight - proporcjonalna "ważność" VM podczas uruchamiania wielu VM. Parametr weight określa proporcjonalny przydział CPU, gdy wiele VM próbują uzyskać dostęp do zasobu procesora. Waga systemu hosta wynosi 256. Na przykład, jeśli VM ma również wagę 256 i obydwa systemy będą chciały wykorzystać 100% procesora, obydwa dostaną połowę czasu procesora. Jeśli gość będzie mieć wagę 128, dostanie tylko 1/3 czasu CPU.

Uruchamianie, zatrzymywanie i łączenie z RouterOS VM

Aby uruchomić VM, włącz ją:

[admin@MikroTik] /xen> enable ros1
[admin@MikroTik] /xen> print
Flags: X - disabled, C - configuration-changed
 #   NAME                                                                             MEMORY     WEIGHT STATE
 0   ros1                                                                             64         256    running

Są dwa (wykluczające się, ponieważ tylko jedna wirtualna konsola jest dostępna dla wszystkich VM) sposoby połączenia z konsolą w uruchomionym VM:

  • przez użycie polecenia "/xen console <VM name>"
  • przez użycie programu telnet i połączenia z portem określonym przez parametr "console-telnet-port".

Jest kilka sposobów zatrzymania VM:

  • najlepszym sposobem jest wyłączenie systemu gościa VM (tzn. przez połączenie z systemem gościa, zalogowanie się i wpisanie polecenia "/system shutdown").
  • przez wymuszenie wyłączenia przez hosta poleceniem "/xen shutdown <VM name>";
  • przez wyłączenie wpisu VM w menu "/xen", jest to najbardziej niebezpieczny sposób wyłączenia VM, ponieważ może zostać uszkodzony system plików gościa (wyłączenie wpisu jest równoznaczne z wyjęciem kabla zasilającego w urządzeniu fizycznym).

Stan VM można sprawdzić w menu "/xen":

[admin@MikroTik] /xen> shutdown ros1

[admin@MikroTik] /xen> print
Flags: X - disabled, C - configuration-changed
 #   NAME                                                                                          MEMORY     WEIGHT STATE
 0   ros1                                                                                          64         256    shutdown

W celu uruchomienia wyłączonego VM musisz wyłączyć lub włączyć wpis VM w menu "/xen" lub użyć polecenia "/xen start <nazwa VM>".

Można również użyć polecenia "/xen reboot <nazwa VM> używanego do restartu włączonego VM, ale użycie polecenia może być niebezpieczne - ponieważ wymusza restart systemu gościa, w większości przypadków nie zostaje poprawnie zamknięty system plików.

Jeśli zostaną zmienione ustawienia dotyczące VM w menu "/xen", podczas gdy system gościa jest włączony, ustawienia nie zostaną zastosowane natychmiastowo (ponieważ doprowadziłoby do restarty VM). Zamiast tego, VM zostaje oznaczony "configuration-changed" a nowe ustawienia zostaną zastosowane przy najbliższym restarcie. Na przykład:

[admin@MikroTik] /xen> print
Flags: X - disabled, C - configuration-changed
 #   NAME                                                                                           MEMORY     WEIGHT STATE
 0   ros1                                                                                           64         256    running
[admin@MikroTik] /xen> set ros1 memory=32
[admin@MikroTik] /xen> print
Flags: X - disabled, C - configuration-changed
 #   NAME                                                                                           MEMORY     WEIGHT STATE
 0 C ros1                                                                                           32         256    running
[admin@MikroTik] /xen> shutdown ros1

[admin@MikroTik] /xen> print
Flags: X - disabled, C - configuration-changed
 #   NAME                                                                                           MEMORY     WEIGHT STATE
 0   ros1                                                                                           32         256    shutdown
[admin@MikroTik] /xen> start ros1

[admin@MikroTik] /xen> print
Flags: X - disabled, C - configuration-changed
 #   NAME                                                                                           MEMORY     WEIGHT STATE
 0   ros1                                                                                           32         256    running

Po tej sekwencji poleceń rozmiar pamięci gościa wynosi 32 MB.

Rekonfiguracja Obrazu RouterOS VM

Za pomocą polecenia /xen reconfigure-routeros-image" zostaje wyczyszczona konfiguracja z obrazu RouterOS i nałożony zostaje nowy skrypt konfiguracyjny (skrypt zostanie uruchomiony podczas następnego uruchomienia VM):

[admin@MikroTik] /xen> reconfigure-routeros-image file-name=ros1.img configuration-script=script.file

Konfiguracja sieci w VM

Aby VM mógł być widoczny w sieci, muszą zostać utworzone wirtualne interfejsy łączące VM z hostem. Wirtualne połączenie z gościem może odbywać się przez połączenie ethernetowe punkt-punkt, widoczne w VM jako typ "/interface ethernet", a po stronie hosta jako "/interface virtual-etherne. Poprzez konfigurację forwardowania pakietów (przez routing lub mostkowanie) do/z wirtualnego interfejsu na systemie hosta.

Konfiguracja Interfejsów sieciowych w VM

Interfejsy sieciowe wyświetlane na wirtualnej maszynie jako interfejsy ethernetowe są konfigurowane w menu "/xen interface":

[admin@MikroTik] /xen interface> add virtual-machine=ros1 type=dynamic
[admin@MikroTik] /xen interface> print detail
Flags: X - disabled, A - active
 0   virtual-machine=ros1 vm-mac-addr=02:1C:AE:C1:B4:B2 type=dynamic static-interface=none
    dynamic-mac-addr=02:38:19:0C:F3:98 dynamic-bridge=none

Powyższe polecenie tworzy interfejs dla VM o nazwie "ros1" typu "dynamic".

Są dwa typy interfejsów:

  • dynamiczne - punkt końcowy połączenia wirtualnej sieci po stronie hosta ("/interface virtual-ethernet") zostanie utworzony dynamicznie gdy uruchomiona zostaje wirtualna maszyna. Poprzez użycie tego typu interfejsu użytkownik nie musi ręcznie tworzyć interfejsu na hoście, kosztem ograniczonej elastyczności połączenia (np. nie ma możliwości przydzielenia na stałe adresu IP do dynamicznie tworzonego interfejsu). W tej chwili, adres można dodać automatycznie do mostka poprzez parametr "dynamic-bridge". Jest to podobne do dynamicznych interfejsów WDS dla bezprzewodowych łączy WDS.
  • statyczne - punkt końcowy połączenia wirtualnej sieci po stronie hosta ("/interface virtual-ethernet" musi być utworzony ręcznie. Pozwala to na zmaksymalizowanie elastyczności, ponieważ z góry określane są parametry interfejsu służącego do łączenia się z VM (można przydzielić adres, mogą być stosowane reguły filtra, itp.), jednak należy ręcznie utworzyć "/interface virtual-ethernet".

Interfejsy VM posiadają poniższe parametry:

  • virtual-machine - do którego VM należy interfejs;
  • vm-mac-addr - adres MAC interfejsu ethernetowego w systemie gościa;
  • type - typ interfejsu
  • static-interface - gdy "type=static", ten parametr określa który interfejs wirtualny na hoście będzie służył do łączenia się z gościem;
  • dynamic-mac-addr - gdy "type=dynamic", parametr przechowuje adres MAC automatycznie utworzonego interfejsu wirtualnego po stronie hosta;
  • dynamic-bridge - gdy "type=dynamic", to dynamicznie utworzony wirtualny interfejs zostanie automatycznie dodany do mostka.

Konfiguracja dynamicznych interfejsów

Aby utworzyć wirtualne połączenie mające automatycznie utworzony punkt końcowy po stronie hosta, użyj poniższego polecenia:

[admin@MikroTik] /xen interface> add virtual-machine=ros1 type=dynamic
[admin@MikroTik] /xen interface> print detail
Flags: X - disabled, A - active
 0   virtual-machine=ros1 vm-mac-addr=02:1C:AE:C1:B4:B2 type=dynamic static-interface=none dynamic-mac-addr=02:38:19:0C:F3:98 dynamic-bridge=none

Po włączeniu "ros1", możesz sprawdzić, czy został utworzony interfejs wirtualny z dynamicznym adresem MAC:

[admin@MikroTik] /xen> /interface virtual-ethernet print
Flags: X - disabled, R - running
 #    NAME                                                                                                     MTU   ARP        MAC-ADDRESS
 0  R vif1                                                                                                     1500  enabled    02:38:19:0C:F3:98

Po stronie gościa interfejs ethernetowy jest dostępny z podanym vm-mac-addr:

[admin@Guest] > int ethernet print
Flags: X - disabled, R - running, S - slave
 #    NAME                                                                                                     MTU   MAC-ADDRESS       ARP
 0 R  ether1                                                                                                   1500  02:1C:AE:C1:B4:B2 enabled

Przez edycję parametru "dynamic-bridge", interfejs wirtualny może być automatycznie dodany jako koniec mostka w połączeniu mostkowym w systemie hosta. Na przykład, jeśli zachodzi potrzeba forwardowania ruchu pomiędzy interfejsem "ether1" na hoście i interfejsem "ros1" na VM, należy wykonać:

Utwórz mostek na systemie hosta i dodaj "ether1" jako punkt końcowy mostka:

[admin@MikroTik] > /interface bridge add name=to-ros1
[admin@MikroTik] > /interface bridge port add bridge=to-ros1 interface=ether1

Następnie określ, że wirtualny interfejs powinien być automatycznie dodany jako drugi punkt końcowy:

[admin@MikroTik] /xen interface> print detail
Flags: X - disabled, A - active
 0 A virtual-machine=ros1 vm-mac-addr=02:1C:AE:C1:B4:B2 type=dynamic static-interface=none dynamic-mac-addr=02:38:19:0C:F3:98 dynamic-bridge=none
[admin@MikroTik] /xen interface> set 0 dynamic-bridge=to-ros1

Aby sprawdzić, czy interfejs wirtualny został dodany jako punkt końcowy:

[admin@MikroTik] /xen interface> /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic
 #    INTERFACE                                               BRIDGE                                               PRIORITY PATH-COST  HORIZON
 0    ether1                                                  to-ros1                                              0x80     10         none
 1  D vif1                                                    to-ros1                                              0x80     10         none

Używając podobnej procedury, użytkownik może, na przykład, "tunelować" cały ruch przez VM - jeśli host posiada dwa fizyczne interfejsy, użytkownik może utworzyć 2 mostki i kierować cały ruch przez gościa (zakładając, że system operacyjny gościa jest konfigurowany, aby pakiety były forwardowane pomiędzy dwoma interfejsami).

Konfiguracja statycznych interfejsów

Aby stworzyć wirtualne połączenie, którego punkt końcowy w systemie hosta będzie statycznym interfejsem. Na początku utwórz statyczny wirtualny interejs:

[admin@MikroTik] /interface virtual-ethernet> add name=static-to-ros1 disabled=no
[admin@MikroTik] /interface virtual-ethernet> print
Flags: X - disabled, R - running
 #    NAME                                                                                                     MTU   ARP        MAC-ADDRESS
 0  R vif1                                                                                                     1500  enabled    02:38:19:0C:F3:98
 1    static-to-ros1                                                                                           1500  enabled    02:3A:1B:DB:FC:CF

Następnie, utwórz interfejs dla gościa:

[admin@MikroTik] /xen interface> add virtual-machine=ros1 type=static static-interface=static-to-ros1
[admin@MikroTik] /xen interface> print
Flags: X - disabled, A - active
 #   VIRTUAL-MACHINE                                                                                                    TYPE    VM-MAC-ADDR
 0 A ros1                                                                                                               dynamic 02:1C:AE:C1:B4:B2
 1 A ros1                                                                                                               static  02:DF:66:CD:E9:74

Teraz sprawdźmy, czy wirtualny interfejs jest aktywny:

[admin@MikroTik] /xen interface> /interface virtual-ethernet print
Flags: X - disabled, R - running
 #    NAME                                                                                                     MTU   ARP        MAC-ADDRESS
 0  R static-to-ros1                                                                                           1500  enabled    02:3A:1B:DB:FC:CF
 1  R vif1                                                                                                     1500  enabled    02:38:19:0C:F3:98

Na systemie gościa:

[admin@Guest] > /interface ethernet print
Flags: X - disabled, R - running, S - slave
 #    NAME                                                                                                     MTU   MAC-ADDRESS       ARP
 0 R  ether1                                                                                                   1500  02:1C:AE:C1:B4:B2 enabled
 1 R  ether2                                                                                                   1500  02:DF:66:CD:E9:74 enabled

Posiadanie statycznego interfejsu na systemie hosta pozwala na użycie interfejsu w konfiguracji, jaka tylko będzie potrzebna, np dodanie adresu IP:

[admin@MikroTik] > ip address add interface=static-to-ros1 address=1.1.1.1/24

W podobny sposób dodamy adres IP do odpowiedniego interfejsu na systemie gościa i sprawdźmy, czy działa routing:

[admin@Guest] > /ip address add interface=ether2 address=1.1.1.2/24
[admin@Guest] > /ping 1.1.1.1
1.1.1.1 64 byte ping: ttl=64 time=5 ms
1.1.1.1 64 byte ping: ttl=64 time<1 ms
1.1.1.1 64 byte ping: ttl=64 time<1 ms
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0/1.6/5 ms

Uruchamianie systemów innych niż RouterOS na VM

Wirtualizacja oparta o Hypervisior Xen dla architektur x86 może być używana w RouterOS aby umożliwić uruchamianie innych systemów operacyjnych używających jądro Linuksa mające wsparcie trybu gościa Xen (wsparcie DomU w terminologii Xen).

Aby uruchomić inny system jako gości na hoście RouterOS musisz mieć:

  • plik obrazu OS
  • plik z jądrem Linuksa
  • opcjonalnie plik z ram dyskiem inicjującym

Jest kilka sposobów przygotowanie potrzebnych plików:

  • używając przygotowane wcześniej, gotowe do uruchomienia obrazy (najprostszy sposób);
  • zainstalować system operacyjny z potrzebnymi pakietami wirtualizacyjnymi i użycie obrazu z zainstalowanego systemu (średnio trudne);
  • zainstalować system operacyjny, zrobienie obrazu, rekompilacja jądra, dostosowanie sytemu bo uruchomienia w Xen (najtrudniejsze).

Użycie obrazu Ready to Boot

Jeśli masz system oparty na Debianie GNU/Linux z zainstalowanym Xenem, możesz użyć skryptów xen-tool (http://www.xen-tools.org) aby utworzyć/zainstalować obrazy i użycie jądra Xen oraz initrd z Twojej dystrybucji linuksa. Innym sposobem jest użycie przygotowanych obrazów dostępnych do pobrania, na przykład z http://jailtime.org. Obrazy nie zawierają jądra i dlatego te obrazy mogą być użyte dopiero po pobraniu odpowiedniego jądra i pliku initrd z normalnej dystrybucji.

Dodatkowo, sami udostępniamy zestaw plików gotowych do użycia w VM.

Obraz ClarkConnect 4.2 Community Edition SP1

Obraz został przygotowany z obrazu płyty instalacyjnej (ftp://ftp.clarkconnect.com/4.2/iso/community-4.2.SP1.iso) i dodatkowego pakietu jądra Xen (ftp://ftp.clarkconnect.com/4.2/other/kernel xen-2.6.18-8.1.14.3.cc.i686.rpm). Zainstalowane jest minimum aplikacji.

Archiwum zawiera poniższe pliki:

  • jądro: vmlinuz-2.6.18-8.1.14.3.ccxen
  • inicjujący RAM disk: clark.initrd.rgz, clark.otherinitrd.rgz (either one can be used)
  • obraz dysku: clark.img

Aby użyć tego obrazu w VM pon RouterOS (pamiętaj, że musisz wgrać pliki z archiwum do hosta RouterOS), użyj poniższego polecenia:

[admin@MikroTik] /xen> add disk=hda disk-image=clark.img initrd=clark.otherinitrd.rgz kernel=vmlinuz-2.6.18-8.1.14.3.ccxen kernel-cmdline="root=/dev/hda1" memory=128 name=clark

Hasło dla roota: rootroot.


Archiwum można pobrać stąd: http://www.mikrotik.com/download/clark.tar.bz2

Obraz CentOS 5.1

Obraz został przygotowany przy użyciu netinstall ISO (ISO file: CentOS-5.1-i386-netinstall.iso, dostępny na mirrorach wymienionych w http://isoredirect.centos.org/centos/5/isos/i386/) i instalacji opartej o sieć. Image is prepared using netinstall ISO (ISO file: CentOS-5.1-i386-netinstall.iso, available from mirrors listed at http://isoredirect.centos.org/centos/5/isos/i386/) and network based installation. Minimum software is installed. Zainstalowane jest minimum aplikacji.

Archiwum zawiera poniższe pliki:

  • jądro: vmlinuz-2.6.18-53.el5xen
  • inicjujący RAM disk: centos.initrd.rgz
  • obraz dysku: centos.img

Aby użyć tego obrazu w VM pon RouterOS (pamiętaj, że musisz wgrać pliki z archiwum do hosta RouterOS), użyj poniższego polecenia:

[admin@MikroTik] /xen> add disk=hda disk-image=centos.img initrd=centos.initrd.rgz kernel=vmlinuz-2.6.18-53.el5xen kernel-cmdline="ro root=/dev/hda1" memory=512 name=centos

Hasło dla roota: rootroot.

Archiwum można pobrać stąd: http://www.mikrotik.com/download/centos.tar.bz2

Instalowanie systemu z obsługą wirtualizacji

Jednym ze sposobów uproszczenia instalacji OS jest zainstalowanie go w pliku obrazu przy użyciu aplikacji do pełnej wirtualizacji, jak VMWare lub QEMU. Pozwala to na utworzenie gotowego do użycia pliku obrazu bez potrzeby dodatkowego sprzętu.

Przykład: Tworzenie obrazu ClarkConnect Community Edition 4.2 SP1

Poniżej podana jest instrukcja jak uzyskać ClarkConnect 4.2 Community Edition działający jako gość na VM. Instalacja ClarkConnect domyślnie nie zapewnia wsparcia dla wirtualizacji i potrzebne są drobne modyfikacje.


Instalacja ClarkConnect

Najpierw, utwórz obraz, na którym zostanie zainstalowany ClarkConnect:

~/xen$ qemu-img create clark.img 1Gb
Formatting 'clark.img', fmt=raw, size=1048576 kB

Następnie uruchom instalację z obrazu płyty instalacyjnej ClarkConnect:

~/xen$ sudo qemu -hda clark.img -cdrom community-4.2.SP1.iso -net nic,vlan=0,macaddr=00:01:02:03:04:aa -net tap,vlan=0,ifname=tap0 -m 128 -boot d

Podczas procesu instalacji utwórz jedną partycję główna i (opcjonalnie) dysk wymiany. Weź pod uwagę rozmiar dysku podczas wybierania pakietów do instalacji. W tym przykładzie dysk został podzielony na 800 MB partycję główną, a reszta przeznaczona została na swap. QEMU emuluje kartę ethernetową, podczas instalacji karta ma przydzielony adres IP 10.0.0.23/24.

Instalacja ClarkConnekt domyślnie nie zapewnia obsługi wirtualizacji i trzeba ją dodać ręcznie. ClarkConnect dostarcza pakiet z jądrem z obsługą Xen dostepny pod adresem: ftp://ftp.clarkconnect.com/4.2/other/kernel-xen-2.6.18-8.1.14.3.cc.i686.rpm

Aby zainstalować ten pakiet musisz umieścić go w nowo utworzonym obrazie dysku. Uruchom obraz dysku:

~/xen$ sudo qemu -hda clark.img -net nic,vlan=0,macaddr=00:01:02:03:04:aa -net tap,vlan=0,ifname=tap0 -m 128

Zakładając, że sieć pomiedzy hostem a wirtualną maszyną QEMU jest poprawnie skonfigurowana, możemy użyć SCP aby wgrać plik z pakietem:

~/xen$ scp ./kernel-xen-2.6.18-8.1.14.3.cc.i686.rpm root@10.0.0.23:/
The authenticity of host '10.0.0.23 (10.0.0.23)' can't be established.
RSA key fingerprint is 70:84:b8:c5:6d:62:37:d1:1e:96:29:d0:77:46:6a:0c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.23' (RSA) to the list of known hosts.
root@10.0.0.23's password:
kernel-xen-2.6.18-8.1.14.3.cc.i686.rpm                                                                             100%   16MB   2.0MB/s   00:08

Następnie, podłącz się z ClarkConnectem i zainstaluj pakiet z jądrem. Pakiet nie jest całkowicie kompatybilny z systemem ClarkConnect 4.2 SP1 i nie uda się zainstalować go poprawnie, ale pamiętaj, że jedynym celem instalacji pakietu jest otrzymanie jądra z obsługą Xen i sterowników. Wymuszona instalacja nie jest zła, poza tym, że moduł z zależnościami musisz utworzyć ręcznie:

~/xen$ ssh root@10.0.0.23
root@10.0.0.23's password:
Last login: Tue Jun 10 07:20:34 2008
[root@server ~]# cd /
[root@server /]# rpm -i kernel-xen-2.6.18-8.1.14.3.cc.i686.rpm --force --nodeps
Usage: new-kernel-pkg [-v] [--mkinitrd] [--rminitrd]
       [--initrdfile=<initrd-image>] [--depmod] [--rmmoddep]
       [--kernel-args=<args>] [--banner=<banner>]
       [--make-default] <--install | --remove> <kernel-version>
       (ex: new-kernel-pkg --mkinitrd --depmod --install 2.4.7-2)
error: %post(kernel-xen-2.6.18-8.1.14.3.cc.i686) scriptlet failed, exit status 1
[root@server /]# ls /boot
config-2.6.18-53.1.13.2.cc    initrd-2.6.18-53.1.13.2.cc.img  symvers-2.6.18-8.1.14.3.ccxen.gz  vmlinuz-2.6.18-53.1.13.2.cc    xen-syms-2.6.18-8.1.14.3.cc
config-2.6.18-8.1.14.3.ccxen  memtest86+-1.26                 System.map-2.6.18-53.1.13.2.cc    vmlinuz-2.6.18-8.1.14.3.ccxen
grub                          symvers-2.6.18-53.1.13.2.cc.gz  System.map-2.6.18-8.1.14.3.ccxen  xen.gz-2.6.18-8.1.14.3.cc
[root@server /]# depmod -v 2.6.18-8.1.14.3.ccxen -F /boot/System.map-2.6.18-8.1.14.3.ccxen
 ....

Następnie, skopiuj niektóre pliki z zainstalowanego systemu:

  • Xen enabled kernel (/boot/vmlinuz-2.6.18-8.1.14.3.ccxen)
  • initial ram disk (/boot/initrd-2.6.18-53.1.13.2.cc.img)
~/xen$ scp root@10.0.0.23:/boot/vmlinuz-2.6.18-8.1.14.3.ccxen ./
root@10.0.0.23's password:
vmlinuz-2.6.18-8.1.14.3.ccxen                                                                                   100% 2049KB   2.0MB/s   00:01
~/xen$ scp root@10.0.0.23:/boot/initrd-2.6.18-53.1.13.2.cc.img ./
root@10.0.0.23's password:
initrd-2.6.18-53.1.13.2.cc.img                                                                                  100%  434KB 433.8KB/s   00:00

Domyślna instalacja ClarkConnekt nie wykonuje procesu logowania na wirtualnej konsoli Xen. Aby możliwe było logowanie przez wirtualną konsolę z RouterOS za pomocą polecenia "/xen console <VM name>", urządzenie wirtualnej konsoli powinno być utworzone wewnątrz obrazu dysku (mknod /dev/xvc0 c 204 191).

Domyślny ram dysk ClarkConnect nie wspiera bootowania z wirtualnego dysku Xen ponieważ nie zawiera sterownika wirtualnego dysku. Aby ominąć ten problem, należy zaktualizować ram dysk.

Ręczna aktualizacja initrd

Jednym sposobem stworzenia ram dysku obsługującego bootowanie z wirtualnego dysku jest ręczne dodanie sterownika wirtualnego dysku do initrd i aktualizację go aby załadowywał ten moduł.

Najpierw wypakujmy zawartość ram dysku skopiowanego z obrazu ClarkConnect:

~/xen$ file initrd-2.6.18-53.1.13.2.cc.img
initrd-2.6.18-53.1.13.2.cc.img: gzip compressed data, from Unix, last modified: Tue Jun 10 14:01:27 2008, max compression
~/xen$ mv initrd-2.6.18-53.1.13.2.cc.img clarkinitrd.gz
~/xen$ gunzip clarkinitrd.gz
~/xen$ file clarkinitrd
clarkinitrd: ASCII cpio archive (SVR4 with no CRC)
~/xen$ mkdir initrd
~/xen$ cd initrd/
~/xen/initrd$ sudo cpio -idv --no-absolute-filenames < ../clarkinitrd
.
etc
bin
bin/insmod
bin/nash
bin/modprobe
sysroot
sys
lib
lib/sd_mod.ko
lib/libata.ko
lib/scsi_mod.ko
lib/ata_piix.ko
lib/ext3.ko
lib/jbd.ko
sbin
dev
dev/console
dev/systty
dev/tty3
dev/tty2
dev/tty4
dev/ram
dev/tty1
dev/null
init
loopfs
proc
1990 blocks
~/xen/initrd$ cat init
#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs none /sys
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading libata.ko module"
insmod /lib/libata.ko
echo "Loading ata_piix.ko module"
insmod /lib/ata_piix.ko
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
umount /sys
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
echo Switching to new root
switchroot /sysroot

Z powyższego listingu możemy zauważyć, że skrypt inicjujący w obrazie initrd ładuje sterowniki do dysków SCSI i ATA jak i moduły systemu plików EXT3. Aby ClarkConnect bootował się wewnątrz Xen musimy zamieniać sterowniki sprzętu ze sterownikami wirtualnego dysku Xen a moduły systemu plików EXT3 odpowiednimi modułami z jądra Xen. Pobierz moduły z zainstalowanego systemu ClarkConnect:

~/xen/initrd$ cd lib/
~/xen/initrd/lib$ ls
ata_piix.ko  ext3.ko  jbd.ko  libata.ko  scsi_mod.ko  sd_mod.ko
~/xen/initrd/lib$ sudo rm ata_piix.ko libata.ko scsi_mod.ko sd_mod.k
~/xen/initrd/lib$ scp root@10.0.0.23:/lib/modules/2.6.18-8.1.14.3.ccxen/kernel/fs/jbd/jbd.ko ./
root@10.0.0.23's password:
jbd.ko                                                                                                                                                                               100%   70KB  69.8KB/s
00:00
~/xen/initrd/lib$ sudo scp root@10.0.0.23:/lib/modules/2.6.18-8.1.14.3.ccxen/kernel/fs/ext3/ext3.ko ./
root@10.0.0.23's password:
ext3.ko                                                                                                                                                                              100%  141KB 141.5KB/s
00:00
~/xen/initrd/lib$ sudo scp root@10.0.0.23:/lib/modules/2.6.18-8.1.14.3.ccxen/kernel/drivers/xen/blkfront/xenblk.ko ./
root@10.0.0.23's password:
xenblk.ko                                                                                                                                                                            100%   22KB  22.0KB/s
00:00


Następnie, zaktualizuj skrypt inicjujący aby ładował sterownik wirtualnego dysku. Końcowy skrypt inicjujący powinien wyglądać tak:

~/xen/initrd$ cat init
#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs none /sys
echo "Loading xenblk.ko module"
insmod /lib/xenblk.ko
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
umount /sys
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
echo Switching to new root
switchroot /sysroot

Utwórz plik initrd z katalogu z modyfikacjami;

~/xen/initrd$ find * | cpio -o -H newc -O ../clarkinitrd.new
~/xen/initrd$ find . -depth | cpio -ov --format=newc > ../clark.initrd
~/xen/initrd$ cd ../
~/xen$ gzip -c -9 < clark.initrd > clark.initrd.rgz
Używanie Narzędzia mkinitrd

Zamiast ręcznie tworzyć ram dysk sposobem opisanym powyżej, możliwe jest użycie narzędzia mkinitrd dostępnego w dystrybucji ClarkConnect. Po zainstalowaniu pakietu z jądrem Xen opisanym powyżej, inicjujący ram dysk może być utworzony za pomocą polecenia (polecenie musi być wykonane w ClarkConnect, tzn wewnątrz VM QEMU):

[root@server /]# mkinitrd clark.otherinitrd.rgz 2.6.18-8.1.14.3.ccxen --omit-scsi-modules --omit-raid-modules --omit-lvm-modules --with=xenblk

Na koniec, nowo utworzony clark.otherinitrd.rgz musi być skopiowany z obrazu ClarkConnect.

dodawanie ClarkConnect VM do RouterOS

Wgraj pliki (za zapomnij wyłączyć QEMU korzystającego z obrazu) do RouterOS hosta i utwórz wpis gościa VM:

[admin@MikroTik] /xen> print detail
Flags: X - disabled
 1 X name="clark" disk=hda disk-image="clark.img" initrd="clark.otherinitrd.rgz" kernel="vmlinuz-2.6.18-8.1.14.3.ccxen"
     kernel-cmdline="root=/dev/hda1" cpu-count=1 memory=128 weight=256 console-telnet-port=64000 state=disabled

VM jest skonfigurowany do użycia plików, które utworzyliśmy wg wcześniejszych kroków. Zwróć także uwagę na parametr "kernel-cmdline". Informuje on ClarkConnect gdzie znajduje się główny system plików - ponieważ udostępniamy obraz dysku z "disk=hda", a podczas instalacji system plików został utworzony jako pierwsza partycja na obrazie dysku, główny system plików znajduje się na urządzeniu /dev/hda1.

Uruchom ClarkConnect. Wykryje on zmiany sprzętu i umożliwi logowanie się przez urządzenie wirtualnej konsoli.


Przykład: Przygotowywanie Obrazu Centos 5.1

CentOS jest dystrybucją opartą o RedHat. Dystrybucja zwiera potrzebne pakiety do wsparcia wirtualizacji, więc instalacja obrazu CentOS ze wsparciem wirtualizacje jest w miarę proste.

Instalacja CentOS 5.1

W celu otworzenia przykładowego obrazu CentOS, używamy QEMU do zainstalowania CentOS w taki sam sposób jak instalowaliśmy ClarkConnect.

Utwórz plik obrazu i uruchom QEMU z obrazem CentOS netinstall ISO:

~/xen$ qemu-img create centos.img 2Gb
Formatting 'centos.img', fmt=raw, size=2097152 kB
~/xen$ sudo qemu -hda centos.img -cdrom=CentOS-5.1-i386-netinstall.iso -net nic,vlan=0,macaddr=00:01:02:03:04:aa -net tap,vlan=0,ifname=tap0 -m 256

Pamiętaj, że używamy obrazu ISO netinstall - pakiety zostaną pobrane przez sieć. Oznacza to, że musi być skonfigurowana sieć w QEMU.

Podczas instalacji utwórz partycję jak w poprzednim przykładzie. Przykładowy obraz został utworzony ze schematem partycji jak na obrazku:

Image:Centos_partitioning.png

Podczas instalacji wybierz zestaw oprogramowania "Virtualization":

Image:Centos_packages.png

Po zakończeniu instalacji, obraz CentOS nie będzie się bootował w emulatorze QEMU ponieważ nie wspiera hypervisora Xen. Nie ma to znaczenia, ponieważ wszystkie potrzebne programy do uruchomienia w VM zostały zainstalowane na obrazie dysku. Jednak wymusza to innego podejścia do wypakowania potrzebnych plików z obrazu (w ClarkConnect robiliśmy to poprzez łączenie się z VM i skopiowanie plików przez sieć wirtualną).

Przygotowywanie Inicjującego Ram-Dysku

Aby pobrać jądro Xen z obrazu CentOS i przygotować initrd (zawierający sterownik do wirtualnego dysku):

Zamontuj partycję root z obrazu przy użyciu urządzenia loopback (pierwsza partycja na obrazie zaczyna się do sektora 63, dlatego używamy offsetu w pliku obrazu aby wskazać początek partycji):

# mount centos.img /mnt -o loop,offset=$[512*63]

Skopiuj plik jądra:

# cp /mnt/boot/vmlinuz-2.6.18-53.el5xen ./

Użyjmy narzędzia mkinitrd aby utworzyć plik initrd. Aby można było to zrobić w zamontowanym obrazie, użyj polecenia chroot:

# chroot /mnt /bin/sh
sh-3.1# mkinitrd centos.initrd.rgz 2.6.18-53.el5xen --omit-scsi-modules --omit-raid-modules --omit-lvm-modules --with=xenblk
sh-3.1# exit
dodawanie CentOS VM do RouterOS

Teraz pliku używane do uruchomienia gościa na VM (jądro, nowo utworzony initrd i obraz dysku) muszą być umieszczone na RouterOS i należy utworzyć odpowiedni wpis VM:

[admin@MikroTik] /xen> print detail
Flags: X - disabled
 0 X name="centos" disk=hda disk-image="centos.img" initrd="centos.initrd.rgz" kernel="vmlinuz-2.6.18-53.el5xen"
     kernel-cmdline="ro root=/dev/hda1" cpu-count=1 memory=256 weight=256 console-telnet-port=64000 state=disabled

Jądro CentOS również potrzebuje parametrów wskazujących, którą partycję ma użyć jako główny system plików, podobnie jak ClarkConnect.

Dodawanie wsparcia wirtualizacji do systemu operacyjnego z Twoim Ulubionym Linuksem

Aby można było uruchomić Twój ulubiony system operacyjny/dystrybucję jako gość na VM, musi on wspierać Xen DomU, więc uruchomienie wsparcia Xen pociągnie za sobą rekompilację jądra. Dysk i wirtualny interfejs sieciowy muszą być dostępne przez sterowniki Xen netfront i blockfront, więc upewnij się, że te sterowniki znajdują się w Twoim systemie, bezpośrednio w jądrze lub jako moduły. Jądro musi być skompilowane z obsługą PAE.

W zależności od jądra Linuksa, które używa Twoja dystrybucja, istnieje możliwość, że źródła jądra nie mają obsługi Xen. Może to oznaczać, że zachodzi potrzeba łatania jądra. W takich przypadkach odnieś się do dystrybucji używających podobnej wersji jądra i łatek z obsługą Xen.