Prezentacja User-Mode Linux Katarzyna Rempoła, Jakub Tomiczek, Adam Warski

Spis treści:

• Wstęp
• Zastosowania
• Kompilacja i instalacja
• Instalacja z RPM-a
• Kompilacja jądra UML-a
• Kompilacja i instalacja modułów do jądra
• Instalacja modułów
• Ładowanie modułów do jądra i kompilacja własnych modułów
• Kompilacja i instalowanie narzędzi UML-a
• Uruchomienie i logowanie
• Łącza szeregowe i konsole
• Urządzenia
• Kanały
• Systemy plików
• Tworzenie nowych systemów plików
• Rozszerzanie istniejących systemów plików
• Dostęp do systemu plików komputera bazowego (hosta)
• Współdzielenie systemów plików
• Tworzenie nowego bazowego systemu plików
• Konsola zarządzania
• Instalacja i uruchamianie konsoli
• Dostępne komendy
• Dostęp do sieci
• ethertap i TUN/TAP
• multicast i demon switch
• slip
• slirp
• pcap
• Do czego może się przydać
• SKAS
• Debugowanie jądra
• Debugowanie jądra w tt mode
• Przykład
• Debugowanie w skas mode
• Debugowanie modułów
• Linki
• Autorzy

Wstęp

Historia

User-Mode Linux to system operacyjny Linux zagnieżdżony w zewnętrznym systemie operacyjnym (Linux). Koncepcja jego stworzenia zrodziła się na początku 1999 roku, a jej autorem jest Jeff Dike. UML zaczął powstawać jako łatka do jądra 2.0. Oryginalnie był projektowany jako narzędzie develpoerów, które miało przyspieszyć rozwijanie oprogramowania i zredukować wpływ wymagań sprzętowych. Pierwsza wersja ukazała się wiosną 2000 roku. Od tego czasu UML jest w ciągłym rozwoju i do każdej nowej wersji jądra Linuxa powstaje odpowiednia łatka.

Konkurencja

Idea zagnieżdżania systemów operacyjnych bardzo się rozpowszechniła i obecnie User-Mode Linux nie jest jedynym projektem tego typu. Konkurencyjne projekty to między innymi: Linux on Linux, Windows on Linux, Linux on Windows.

UML nie jest najszybszym do uruchomienia i najłatwiejszym w obsłudze spośród nich. Ma jednak wiele istotnych przewag, które wynikają z towarzyszącej mu i ściśle przestrzeganej ideologii.

Zasady działania

W przeciwieństwie do normalnego jądra systemu operacyjnego Linux, UML nie komunikuje się ze sprzętem. Jest od niego oddzielony warstwą macierzystego systemu - hosta. Zamiast z interfejsu hardware'u, korzysta z interfejsu funkcji systemowych udostępnianych przez hosta. Z punktu widzenia hosta jest więc zwykłym procesem działającym w przestrzeni użytkownika: nie ma dostępu do pamięci systemu macierzystego. Za to z punktu widzenia uruchomionych w nim aplikacji jest jądrem: z własną pamięcią wirtualną, schedulerem (planistą) oraz dostępem do zasobów. Procesy nie mają dostępu do jego przestrzeni adresowej.

User-Mode Linux umożliwia uruchomienie wielu wirtualnych komputerów pracujących pod kontrolą systemu Linux, które są odizolowane zarówno od siebie, jak i od systemu macierzystego (wraz z kontrolowanym przez niego sprzętem).

Ideologia i zalety

W odróżnieniu od konkurencyjnych projektów, twórcy UML-a dbają o to, aby w jak największym stopniu pozostał on zwykłym programem. Wynikają z tego następujące zalety:

• Działa szybko. UML jest kompilowany do kodu maszynowego i uruchamiany dokładnie tak jak dowolna inna aplikacja na hoście. (Inne schematy wirtualizacji zakładają np. implementację całej architektury sprzętowej i to bardzo je spowalnia). Ciężar dostosowania się do sprzętu bierze na siebie system macierzysty. Statystycznie aplikacje działają w UML-u ok. 20% wolniej niż na systemie macierzystym.
• UML korzysta na wszystkich usprawnieniach i ulepszeniach wprowadzanych do Linuxa, tak samo jak korzystają na nich inne linuksowe aplikacje.
• Elastyczność zastosowań: Można go używać jako dzielonej biblioteki, z której mogą korzystać inne programy. Może być podpowłoką istniejącej aplikacji. Może używać standardowego wejścia / wyjścia jak dowolny inny program (można te deskryptory przekierowywać)
• Przenośność (przynajmniej w planach)
• Dojrzałość: Ponieważ UML jest rozwijany od wielu lat (od 1999 roku), jest już bardzo dopracowany. Dowód: UML można uruchomić w UML-u.
• Dostępność: Jako część jądra Linuxa, jest na licencji GPL, więc jest produktem darmowym.

Zastosowania

Niektóre zastosowania UML-a zaskoczyły samego autora, Jeffa Dike'a. Oto niektóre z nich:

• "UML Hosting" - użycie UML-a w celu utworzenia wirtualnych serwerów dedykowanych zamiast stawiania prawdziwego, samodzielnego komputera.
• Można w nim bezpiecznie uruchamiać serwisy sieciowe (np. www). O ile nie będzie wkompilowane wsparcie dla hostfs - dostępu do głównego systemu plików hosta, żadne włamanie nie będzie groźne dla systemu macierzystego.
• Testowanie nowych wersji jądra, narzędzi i dystrubucji: umożliwia sprawne debugowanie jądra: uruchomienie jądra, które normalnie wymaga restartu komputera, w przypadku UML-a sprowadza się do włączenia aplikacji. Można również używać narzędzi do debugowania: gprof, gcov, gdb. Można debugować programy ustawiając pułapki (breakpointy) na wywołaniach systemowych. Pozwala to jednoznacznie, w przeciwieństwie do ERRNO, ustalić miejsce i przyczynę wystąpienia błędu.
  Można na różnych instancjach UML-a uruchamiać jednocześnie różne dystrybucje Linuxa, bez konieczności wydzielania osobnej partycji na każdą - wystarczy jeden plik
  Można tworzyć różne środowiska kompilacji programów (różne kompilatory, biblioteki, wersje jądra etc.)
• Można w nim bezpiecznie (ze względu na macierzysty system operacyjny i dane) testować niepewne / niebezpieczne programy. To zastosowanie nazywa się sandbox (piaskownica). Ponieważ UML jest zwykłą aplikacją, najgorsze co się może stać to zniszczenie jego systemu plików. O ile używaliśmy plików COW, odtworzenie systemu plików jest trywialne (wystarczy utworzyć nowy COW). W przeciwnym przypadku trzeba ściągnąć lub zrobić nowy system plików. W żadnym przypadku nie wymaga to instalacji nowego UML-a ani nawet potrzeby restartu systemu.
• Poprzez pełną obsługę sieci wbudowaną w UML, możliwe jest wirtualne konfigurowanie sieci - dużo łatwiej i bezpieczniej jest najpierw sprawdzić nowe ustawienia routingu, tunelowania czy filtrowania na sieci wirtualnej niż fizycznej. Wirtualne maszyny mogą być w sieci z innymi wirtualnymi maszynami, z hostem, a także z innymi fizycznymi maszynami.
• Zwiększenie bezpieczeństwa i funkcjonalności serwisów oferujących dostęp do shella - utworzenie dla każdego użytkownika maszyny wirtualnej powoduje, że ma on do niej prawa roota oraz nie może dokonać zniszczeń na serwerze bazowym.
• "honeypot" - są to maszyny udostępniane w internecie, których zadaniem jest zwabienie włamywaczy. Cele tego mogą być różne - badania nad nowymi zabezpieczeniami, odwrócenie uwagi od prawdziwych serwerów lub też łapanie przestępców.
• Można emulować sprzęt, którego fizycznie nie ma. Wirtualną maszynę można skonfigurować tak, jakby miała większą pamięć, więcej urządzeń, a wkrótce zostanie dodana możliwość emulacji wieloprocesorowości.

Kompilacja i instalacja

Instalacja z RPM-a

Najłatwiej uzyskać User-Mode Linux ściągając RPM-a, gdzie będzie skompilowane jądro, dokumentacja i narzędzia (uml_moo, mkcow, mconsole...). Dodatkowo trzeba ściągnąć specjalnie przygotowany pod UML-a system plików.
Po zainstalowaniu za pomocą wywołania

[host]$ rpm -ivh nazwa_pakietu

można już uruchomić UML-a wywołując

[host]$ /usr/bin/linux (lub linux)

Kompilacja jądra UML-a

Przebiega jak zwykła kompilacja jądra.

1. Ściągnąć najnowszą łatkę. Z nazewnictwem jest inaczej niż w przypadku jądra Linuxa - numer łatki odpowiada numerowi jądra, na które powinna być nałożona.
2. Ściągnąć pasujące jądro (Chodzi tu o normalne Linuxowe jądro - łatka przystosuje je do UML-a)
3. Stworzyć katalog (np. ~/uml) i rozpakować w nim jądro:

   [host]$ mkdir ~/uml
   [host]$ cd ~/uml
   [host]$ tar -xjvf linux-2.4.27.tar.bz2

4. Nałożyć łatkę:

   [host]$ cd ~/uml/linux
   [host]$ bzcat uml-patch-2.4.27.bz2 | patch -p1

5. Uruchomić standardowy program do konfiguracji jądra, np. wywołać make menuconfig lub make xconfig. Ważna zmiana: trzeba w linii wywołania dopisać ARCH=um, np.:

   [host]$ make menuconfig ARCH=um

   Uwaga: to działa tylko na systemach z podziałem przestrzeni adresowej 3G/1G; dla tych skonfigurowanych na 2G/2G trzeba pobrać specjalną łatkę.
6. Uruchomić

   [host]$ make linux ARCH=um

   W wyniku powstanie plik linux w katalogu, w którym były źródła. UML jest już gotowy do uruchomienia.

Uwaga: rozmiar jądra, które powstało może być niepokojąco duży. To cecha charakterystyczna UML-a i modułów dla UML-a, że powstające binaria zajmują więcej miejsca niż analogiczne binaria hosta. W rzeczywistości są to w dużej części informacje debugowe, a faktyczna wielkość kodu wykonywalnego jest normalna. Rezczywisty rozmiar można zobaczyć robiąc na hoście strip linux

Uwaga: nie budować UML-a w /usr/source/linux ze względu na dowiązania symboliczne istniejące w katalogu /usr/include

Uwaga: bootowanie na większości systemów plików wymaga devfs (wirtualnego systemu plików) wkompilowanego do jądra i montowanego w czasie bootowania. Wyjątkiem jest system plików tomsrtbt. Można też zmodyfikować system plików, aby nie wymagał devfs. Aby to osiągnąć, należy:

• skopiować skądś katalog /dev
• stworzyć kilka urządzeń /dev/ubd:

for i in 0 1 2 3 4 5 6 7; do mknod ubd$i b 98 $[ $i * 16 ]; done

• zmienić /etc/fstab i /etc/inittab, aby nie odwoływały się do urządzeń devfs

Uwaga: ubd0 jest domyślnym urządzeniem filesystemu UML-a. ubd reprezentuje skonfigurowane urządzenia blokowe. Jest to oznaczenie przyjęte w UML-u dla hd, fd, cdrom, scd, itd. Urządzenia ubd są bardzo elastyczne. Mogą być mapowane na partycje, katalogi, volume managers, jak również fizyczne urządzenia. Urządzenia mogą być ładowane i usuwane z uruchomionego UML-a za pomocą konsoli zarządzania (management console, mconsole).

Kompilacja i instalacja modułów do jądra

Ta procedura wygląda analogicznie jak ze zwykłym jądrem, z dokładnością do tego, że trzeba, jak zwykle, dopisać do polecenia "ARCH=um":

[host]$ make modules ARCH=um

Moduły, jakich ma używać uml-kernel muszą być zbudowane w tym samym katalogu, gdzie kompilowaliśmy kernel ("user-mode pool"); moduły z macierzystego jądra nie działają dla UML-a.

Uwaga: znowu binaria są większe niż można by przypuszczać, ale wiadomo, o co chodzi.

Instalacja modułów

Istnieje kilka sposobów, aby zainstalować moduły:

• Ręczna instalacja: należy skopiować moduły na wirtualną maszynę i umieścić w /lib/modules/`uname -r`.
• Automatyczna instalacja za pomocą polecenia make:

  Gdy UML jest wyłączony (jest to konieczne, aby nie modyfikować jego systemu plików w czasie, gdy on to robi), montujemy jego system plików na hoście np. w /mnt/root_fs z opcją -o loop:

  [host]$ mount /opt/uml/root_fs /mnt/root_fs -o loop

  i w katalogu, w którym budowaliśmy moduły uruchamiamy

  [host]$ make modules_install INSTALL_MOD_PATH=/mnt/root_fs ARCH=um

  Następnie odmontowujemy fs

  [host]$ umount /mnt/root_fs

• Gdy nie możemy zamontować systemu plików na hoście (np. dlatego, że jest to plik COW), możemy: w uruchomionym UML-u zamontować katalog źródeł:

  [uml]$ mount -t hostfs none jakis_katalog -o sciezka_do_katalogu_ze_zrodlami // wejść do zamontowanego katalogu
  [uml]$ cd jakis_katalog
  [uml]$ make modules_install // zainstalować moduły - bez dopisku ARCH=um!

Ładowanie modułów do jądra i kompilacja własnych modułów

Funkcje obsługujące ładowanie modułów są standardowe: depmod może zgłaszać problemy, ale dośwadczenie wskazuje, że nie należy się tym przejmować, ponieważ insmod, modprobe działają poprawnie.

Standardowym problemem przy kompilowaniu własnych modułów dla UML-a na hoście jest dobór właściwych flag kompilatora (CFLAGS). Gdy są one niepoprawne, moduł może nie działać, nawet jeśli się skompiluje. Bezpieczne jest ustawienie dokładnie tych CFLAGS, których są użyte w Makefile do budowania jądra. Aby je poznać, można do tego użyć tego właśnie pliku Makefile i jego reguły script:
Po wejściu do katalogu źródeł UML-a, następujące polecenie powinno wypisać CFLAGS:

make script 'SCRIPT=@echo $(CFLAGS)' ARCH=um

We własnym skrypcie można zdefiniować zmimenną CFLAGS następującym poleceniem:

CFLAGS=`cd katalog_ze_źródłami; make script 'SCRIPT=@echo $(CFLAGS)' ARCH=um

We własnym Makefile można zdefiniować zmienną CFLAGS następująco:

CFLAGS=$(shell cd katalog_ze_źródłami; make script 'SCRIPT=@echo $$(CFLAGS)' ARCH=um)

Kompilacja i instalowanie narzędzi UML-a

Realizacja niektórych funkcji jądra jest wspomagana przez programy przestrzeni użytkownika. Odpowiednie programy znajdują się w pakiecie uml_utilities, rozprowadzanym niezależnie od łatki na jądro. Istnieje jednak ścisła zależność między wersją łatki a wersją pakietu.

Kompilacja pakietu uml_utilities (w katalogu ze źródłami na hoście)

[host]$ make && make install

Przykładowe narzędzia

• port-helper - używany przez konsole, łączące się z xterm-ami lub portami hosta
• tunctl - narzędzie konfiguracjyne do tworzenia i usuwania urządzeń tap
• uml_net - narzędzie automatycznej konfiguracji urządzeń tap

Uruchomienie i logowanie

User-Mode Linux uruchamia się poleceniem linux. Jeśli nie podamy parametru ubd0, UML będzie próbował zamontować plik o nazwie root_fs z bieżącego katalogu jako swój root filesystem. Jeśli chcemy wskazać inny filesystem, uruchamiamy:

[uml]$ linux ubd0=nasz_filesystem

UML uruchamia się i prosi o zalogowanie. UML-owe systemy plików początkowo zawierają 2 konta: root z hasłem root i user z hasłem user. Podajemy wybrany login i hasło i już jesteśmy zalogowani na wirtualną maszynę.

Inne metody logowania

• wirtualna konsola (o ile uruchamiamy linux będąc w X-ach i system plików jest odpowiednio skonfigurowany, żeby uruchamiać wirtualne konsole)
• łącze szeregowe
• poprzez sieć (np. ssh) (o ile jest skonfigurowana między hostem i UML-em i na UML-u jest uruchomiona usługa ssh)

Łącza szeregowe i konsole

Możliwe jest podłączenie UML-a do wielu typów kanałów wejścia/ wyjścia komputera bazowego. Umożliwia to między innymi: podłączenie konsoli UML-a do nieużywanej konsoli komputera bazowego podłączenie konsoli UML-a do portu, przez co możliwy jest dostęp do maszyny wirtualnej przez sieć połączenie dwóch maszyn wirtualnych Ogólny format - w linii poleceń dajemy jedną lub więcej opcji postaci: urządzenie=kanał Jeżeli chcemy osobno okreslić kanał wejściowy i wyjściowy, należy użyć opcji: urządzenie=kanał_wejściowy,kanał_wyjściowy

Urządzenia

Dostępne urządzenia są dwa: konsola - con oraz łącze szeregowe - ssl. Użycie jako nazwy urządzenia po prostu "con" albo "ssl" oznacza przypisanie kanału wszystkim urządzeniom. Jeżeli chcemy podłączyć kanał do konkrentego urządzenia, po nazwie urządzenia dodajemy numer, np. "con5", "ssl9". Ustawienia dla konkretnych urządzeń przesłaniają ustawienia ogólne.

Kanały

• urządzenie=pts lub urządzenie=pty

  UML przydzieli urządzeniu wolny pseudo-terminal na komputerze bazowym. Jaki konkretnie terminal został przydzielony można sprawdzić w logach startowych sytemu (np. poleceniem dmesg). Następnie z komputera bazowego można uzyskać dostęp do przydzielonego w ten sposób terminala poleceniem screen (lub: minicom, kermit). Np. screen /dev/pts/x; screen /dev/ttyxx.

• urządzenie=tty:urządzenie_tty

  Podłączy urządzenie do niewykorzystywanego terminala komputera bazowego, urządzenie_tty to np. /dev/tty5.

• urządzenie=xterm

  Spowoduje utworzenie nowego xterm-a i przyłączenie do niego podanego urządzenia.

• urządzenie=fd:a,fd:b

  Podłączenie wejścia i wyjścia urządzenia do istniejących (otwartych) deskryptorów a i b. Np. polecenie con0=fd:0,fd:1 spowoduje podłączenie głównej konsoli do konsoli, z której został UML uruchomiony. Można też podać na przykład wcześniej przygotowane deskryptory.

• urządzenie=port:numer

  Spowoduje podłączenie danego urządzenia do podanego portu na komputerze bazowym. Dostęp do UML-a można wtedy uzyskać poprzez telnet. Podanie jako urządzenia ssl spowoduje, że każdy klient dostanie jedno łącze szeregowe, aż do ich wyczerpania (nowi klienci będą usypiani). Umożliwia to zalogowanie się do UML-a bez znajomości konkretnych urządzeń, do jakich zostały podłączone kanały - jak to było w przypadku pseudo-terminali. W ten sposób też można udostępnić logowanie do UML-a przez sieć, bez konieczności konfigurowania obsługi sieci w maszynie wirtualnej.

• urządzenie=none

  Urządzenie nie jest widoczne w systemie, tzn. nie można go otworzyć.

• urządzenie=null

  Urządzenie jest widoczne, można je otworzyć, ale próba odczytu spowoduje zablokuje proces, a wszystkie zapisy idą w "czarną dziurę".

Np., aby pozbyć się dwóch dodatkowych konsol otwierających się podczas startu systemu, należy dodać do linii poleceń opcje:

con=pty con0=fd:0,fd:1

Systemy plików

Tworzenie nowych systemów plików

Na początku musimy utworzyć plik, w którym będziemy przechowywać nowy system plików. Robimy to korzystając z polecenia dd, którym tworzymy plik rzadki (tzn. plik który fizyczne zajmuje mniej miejsca niż wynosi jego rozmiar):

[host]$ dd if=/dev/zero of=nowy_fs seek=100M count=1 bs=1

W ten sposób plik "nowy_fs" będzie miał wielkość 100MB, ale na dysku zajmie dużo mniej (można to sprawdzić poleceniem ls -ls - plik zajmuje 12 bloków).

Następnie uruchamiamy UML-a, dodając w linii poleceń opcję:

ubdx=nowy_fs

gdzie x jest numerem wolnego urządzenia blokowego.
Można utworzyć tylko system plików, którego obsługa jest wbudowana w jądro lub załadowana jako moduł jądra. Aby utworzyć system plików wydajemy polecenie:

[uml]$ mke2fs /dev/ubd/x

gdzie x jest poprzednio wybranym numerem. Polecenie to stworzy system plików ext2, ale można też tworzyć inne, poleceniami: mkreiserfs, mkdosfs itd.. Jakie systemy plików możemy stworzyć zależy od tego, jakie systemy plików obsługuje jądro (ich lista znajduje się w /proc/filesystems) oraz od zainstalowanych narzędzi w systemie. W przypadku ich braku, możemy ściągnąć je z sieci lub bazowego komputera.
Na koniec trzeba zamontować system plików:

[uml]$ mount /dev/ubd/x /mnt/nowy_fs_katalog

Rozszerzanie istniejących systemów plików

Często systemy plików ściagnięte z sieci jako nie mają prawie wolnego miejsca, przez co praca z nimi jest bardzo utrudniona. Jednak w łatwy sposób można istniejący system plików powiększyć. W tym celu trzeba wyjść z UML-a i wydać polecenia (dla systemu plików ext2):

[host]$ e2fsck -f nazwa_pliku
[host]$ dd if=/dev/zero of=nazwa_pliku bs=1 count=1 seek=nowy_rozmiar conv=notrunc
[host]$ resize2fs -p nazwa_pliku
[host]$ e2fsck -f nazwa_pliku

Po kolei: sprawdzamy system plików, zmieniamy rozmiar pliku (jako nowy_rozmiar możemy podać np. 100M lub 2GB), zmieniamy rozmiar systemu plików i na koniec dla pewności ponownie sprawdzamy czy cała operacja przebiegła pomyślnie.

Dostęp do systemu plików komputera bazowego (hosta)

Często zachodzi potrzeba skopiowania jakichś plików z komputera na którym jest uruchomiony UML do systemu plików UML-a. Można to zrobić na parę sposobów: zamontować system plików hosta przez nfs, wyłączyć UML-a, zamontować jego system plików na komputerze bazowym, poleceniem:

[host]$ mount system_plików katalog -o loop

albo skorzystać z wbudowanego w UML-a systemu plików hostfs. Aby z niego skorzystać, system plików musi być dostępny w systemie (wkompilowany w jądro albo załadowany jako moduł). Najprostszym sposobem na jego wykorzystanie jest wydanie polecenia:

[uml]$ mount none /mnt/host -t hostfs

W ten sposób przez katalog /mnt/host będziemy mieli dostęp do całego systemu plików hosta. Dodanie opcji -o katalog spowoduje zamontowanie tylko podanego katalogu (np. -o /home).
Możliwe jest też uruchomienie UML-a z katalogu na komputerze bazowym, zamiast z zawartego w pliku systemu plików. W tym celu najpierw musimy mieć odpowiedni katalog (jeżeli mamy system plików w pliku, możemy to zrobić poleceniem mount system_plików katalog -o loop). Następnie w pliku etc/fstab zamontowanego systemu plików zmieniamy rodzaj systemu plików dla katalogu głównego / na:

none / hostfs defaults 1 1

Po czym zmienimy właściciela wszystkich plików, których właścicielem był root na nas:

[host]$ find . -uid 0 -exec chown użytkownik {} \

Na koniec uruchamiamy UML-a z następującymi opcjami:

root=/dev/root rootflags=/ścieżka/do/katalogu/z/systemem/plików rootfstype=hostfs

Można też ograniczyć działanie hostfs-a przez podanie opcji w linii poleceń:

hostfs=katalog,[append]

gdzie katalog jest nazwą katalogu, który będzie można standardowo zamontować (przy podaniu np. /home niemożliwe jest uzystkanie dostępu do katalogu /etc; katalog ten można pominąć, jeżeli nie chcemy ograniczać dostępu). Opcja append oznacza, że nie będziemy mogli kasować plików z komputera bazowego (otwarcie pliku do zapisu spowoduje otwarcie go w trybie dopisywania).

Współdzielenie systemów plików

Mogłoby się wydawać, że gdy chcemy naraz uruchomić więcej niż jednego UML-a, to dla każdego musimy mieć osobny plik z głównym systemem plików (root_fs). (Próba uruchomienia dwóch UML-i z tym samym plikiem jak root_fs skończy się uszkodzeniem systemu plików!) Jednak takie rozwiązanie jest bardzo pamięciożerne, gdyż systemy plików zajmują na ogół dużo miejsca. Dlatego UML oferuje mechanizm dostępu do systemów plików COW (copy-on-write, kopiowanie przy zapisie). Każda kopia UML-a posiada jedynie własny plik COW, w którym zapisywane są zmiany w stosunku do oryginalnego systemu plików. Uruchomienie UML-a z systemem plików COW jest bardzo proste, w linii poleceń przy uruchamianiu UML-a dodajemy opcję: ubd0=nazwa_pliku_cow,nazwa_root_fs

Spowoduje to utworzenie pliku nazwa_pliku_cow, jeżeli jeszcze nie istniał, albo skorzystanie z już istniejącego. Gdy plik COW już istnieje, możemy uruchamiać UML-a z opcją:

ubd0=nazwa_pliku_cow

Rozmiar pliku COW będzie dużo większy niż faktyczna ilość zajętego na dysku miejsca. Dlatego aby go sprawdzić należy wydać polecenie ls -ls. Gdy raz skorzystamy z pliku nazwa_root_fs jako pliku bazowego dla pliku COW, nie należy go modyfikować, czyli uruchamiać UML-a bezpośrednio z niego. Spowoduje to, że wszystkie pliki COW powiązane z tym systemem plików najprawdopodobniej przestaną działać.
Możliwe jest też scalenie pliku COW z systemem plików. W tym celu wydajemy polecenie:

[host]$ uml_moo nazwa_pliku_COW nowy_root_fs

Spowoduje to utworzenie nowego pliku z systemem plików, który będzie połączonym oryginalnym systemem plików z zmianami zawartymi w pliku COW. Można też dokonać scalenia bez tworzenia nowego pliku:

[host]$ uml_moo -d nazwa_pliku_COW

Jednak spowoduje to że inne pliki COW powiązane z oryginalnym systemem plików przestaną działać.
Aby utworzyć nowy plik COW bez uruchamiana UML-a, należy wydać polecenie:

[host]$ uml_mkcow [-f] plik_COW plik_root_fs

Opcja -f powoduje nadpisanie starego pliku COW. Narzędzie uml_moo i uml_mkcow są częścią pakietu UML Utilites.

Tworzenie nowego bazowego systemu plików

Do tworzenia nowych bazowych systemów plików (root_fs) zostało stworzonych kilka narzędzi:

• UML Builder - prosty w obsłudze, z graficznym interfejsem użytkownika.
• gBootRoot - bardziej zaawansowany, tworzenie systemów plików dla UML-a jest tylko jedną z jego opcji.

Więcej informacji o tych i innych narzędziach można znaleźć na stronie UML-a.

Konsola zarządzania

Instalacja i uruchamianie konsoli

Konsolę zarządzania możemy pobrać z repozytorium CVS projektu UML: (dostepna w postaci pliku źródłowego), nastepnie kompilujemy ją dostarczonym makefile`m. Przy uruchamianiu UML-a wystarczy teraz tylko dopisać CONFIG_MCONSOLE, spowoduje to utworzenie w katalogu .uml w podkatalogu z nazwą maszyny wirtualnej instancji UML-a gniazda umożliwiającego komunikację konsoli zarządzania z UML-em. Nazwa katalogu maszyny wirtualnej jest dość losowa więc dla wygody uruchamiania konsoli możemy w linii poleceń przy startowaniu UML-a wpisać umid=nazwa

[root@localhost linux-2.4.26]$ ./linux ubd0=../root_fs_toms1.7.205 CONFIG_MCONSOLE umid=nazwa

Podczas uruchamiania UML-a powinniśmy zobaczyć coś podobnego do:

mconsole (version 2) initialized on /root/.uml/nazwa/mconsole

Teraz możemy uruchomić uml_mconsole w następujący sposób:

uml_mconsole nazwa

Dostępne komendy

1. version

OK Linux tomsrtbt 2.4.26 #1 nie lis 28 03:09:16 CEST 2004 i686

2. halt i reboot

3. config

config ubd0

OK ../root_fs_toms1.7.205

config ubd3=/root/user-mode/root_fs_slack8.1

4. remove

remove ubd3

5. help

6. sysrq