Dyski w virtualboxie: vdi - domyślny format virtual boxa vmdk - otwarty format dysku wirtualnego - kompatybilny z vmware vhd - dysk używany przez microsoft hdd - dysk używany uzywany do równoległych stacji roboczych - parallel desktops qed - asynchroniczny dla urządzeń wejścia wyjścia qcow - nie alokuje dysku aż będzie potrzebne jego użycie - optymalizacja ta jest przydatna, gdy wiele zadań korzysta z tego samego pliku nie wykonywana jest wówczas kopia dla każdego z tych zadań tylko w sposób niejawny dane są współdzielone - dostarczając wskaźniki do dysku Instalacja XENa: sudo apt-get install xen-hypervisor-4.1-amd64 cd /etc/grub.d/ sudo mv 20_linux_xen 08_linux_xen sudo update-grup sudo reboot Instalacja nowej maszyny wirtualnej: sudo xl list sudo apt-get install xen-tools lsb_release -a sudo xen-create-image --dir=/home/xen --dhcp --hostname wsi1 --vcpus 1 --pygrub --dist trusty root password:.. sudo brctl addbr xenbr0 Uruchamianie maszyny: sudo xl create /etc/xen/wsi1.cfg
Sprawdzenie, czy działa: sudo xl list sudo xl console wsi1 sudo xl list -l wsi1 Zarządzanie pamięcią masową: dd if=/dev/zero of=extra.img bs=1024 count=$((1024 * 1024)) mkfs.ext4./extra.img Wyświetlanie informacji na temat pamięci masowej podłączonej do hosta: sudo xl block-list wsi1 Dodawanie pamięci masowej do wsi: sudo xl block-attach wsi file:///home/chris/extra.img xvdb1 w sudo xl block-list wsi1 na WSI1: ls -l /dev/xvdb1 mkdir extradisk mount /dev/xvdb./extradisk df -h cd extradisk touch test.txt echo "Hello world!" > test.txt cd.. umount./extradisk
na gospodarzu: sudo xl block-detach wsi1 xvdb1 gospodarz możne podpiąć dysk sam sobie: sudo xl block-attach 0 file:///home/chris/extra.img xvdb1 w sudo xl block-detach 0 xvdb1 Dysk możemy powiększyć: dd if=/dev/zero bs=1024 count=$((1024 * 512)) >> extra.img /sbin/e2fsck -f extra.img /sbin/resize2fs extra.img --- Sieć --- Konfiguracja sieci: brctl show sudo xl list ifconfig sudo mcedit /etc/network/interfaces auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 iface eth0 inet manual sudo ifup eth0 sudo ifup xenbr0
na wsi1: sudo ifdown eth0 sudo ifup eth0 Sprawdzić czy po przelogowaniu działa internet w wsi1 Każdy startowany system DomU ma tworzone interfejsy o nazwie: vif<id domeny>.<id interfejsu> Nazwę tę można zmienić podając parametr vifname w tablicy konfigurującej interfejsu w pliku konfiguracyjnym domeny: wsi.cfg. W ten sposób: vif = ['vifname=wsi1'] Te interfejsy są dołączane do przełącznika programowego w Dom0: vif = ['bridge=xenbr0'] Możemy też podać adres MAC interfejsu sieciowego w ten sposób: vif = ['mac="00:16:3e:00:00:00"'] Prefix "00:16:3e" należy do Xena. Ręczne dodawanie interfejsów: xl network-list <domain name or ID> xl network-detach <domain name or ID> <index> xl network-attach <domain name or ID> <opcje, jak dla vif> xl network-list <domain name or ID>
--- cpu --- Parametr vcpus = x w pliku konfiguracyjnym określa liczbę procesorów dostępnych dla systemu wirtualnego. Można także określić, na którym procesorze fizycznym ma się wykonywać procesor wirtualny. Możemy to zrobić w pliku konfiguracyjnym dla, na przykład, dwóch procesorów: wyłączyć maszynę wirtualną zmienić w wirtualboxie na 3 cpu cat /proc/cpuinfo ustawić parametr: cpus = [ '0, 2' ] Czyli wirtualny procesor #0 wykona się na procesorze fizycznym #0, a wirtualny procesor #1 wykona się na procesorze fizycznym #2. Możemy zobaczyć obciążenie procesorów wirtualnych: sudo xl vcpu-list wsi1 Możemy też ręcznie, chwilowo, określić wykonywanie procesorów wirtualnych na procesorach fizycznych: sudo xl vcpu-pin wsi1 x y Definiowanie procesorów jest przydatne, jeżeli chcemy, aby np. procesor Dom0 miał zawsze dostępny jeden procesor fizyczny. cat /proc/cpuinfo
Quota na procesor: Dostęp do procesora dla domeny wirtualnej możemy regulować przez zdefiniowanie dwóch parametrów: weight i cap. Wartość obu parametrów możemy sprawdzić przez: sudo xl sched-credit -d wsi1 Parametry możemy zmieniać tak: sudo xl sched-credit -d wsi1 -w 512 Im wyższy "weight", tym większy priorytet domeny dostępu do procesora. Parametr ten ma sens w porównaniu do wartości weight innych systemów. Domyślną wartością jest 256. Czas fizycznego procesora przydzielony systemowi wirtualnemu jest proporcjonalny do wartości weight. xm sched-credit -d wsi -c 50 Wartość "cap" określa maksymalną liczbę setnych sekund fizycznego procesora, która może być przydzielona systemowi na sekundę. Liczba ta może przekroczyć 100, jeżeli fizycznych procesorów jest więcej niż jeden. Wartość 0 oznacza brak ograniczenia. priorytet do procesów: ionice -p pid -c <class> -n <priority> Klasa 1 oznacz klasę czasu rzeczywistego, 2 oznacza klasę best-effort, a 3 oznacza klasę "idle", która może coś wykonać, jeżeli użycie dysku jest bardzo małe. Domyślnie procesy używają klasy 2. Priorytet to liczba od 0 do 7. Liczba 0 oznacza najwyższy priorytet.
--- framebuffer --- na wsi i na gospodarzu: sudo apt-get update Framebuffer: Aby system miał dostęp do trybu graficznego, czyli do emulacji karty graficznej, to definiujemy "framebuffer" w pliku konfiguracyjnym: vfb = ['type=vnc'] Wyświetlanie jest realizowane przez VNC - virtual network computing. Emulator karty wirtualnej jest serwerem VNC, a klient podłącza się przez klienta VNC. Domyślnie serwer VNC Xena słucha tylko na localhost, ale można to zmienić. Na Dom0 instalujemy klienta VNC: apt-get instal install vncviewer Na wsi: adduser student passwd -d student apt-get install lightdm Na gospodarzu: xl vncviewer wsi1
--- Backup danych: --- Zatrzymujemy maszynę przez: sudo xl save ID state-file potem kopiujemy plik z dysku, a potem wykonujemy: sudo xl restore state-file sudo xl console wsi1 LAN tylko dla systemów wirtualnych ---------------------------------- sudo xen-create-image --dir=/home/xen --dhcp --hostname wsi2 --vcpus 1 --pygrub --dist trusty sudo xl create /etc/xen/wsi2.cfg sudo xl list sudo xl console wsi2 Tworzymy "ręcznie" dodatkową sieć LAN tylko dla systemów wirtualnych: sudo brctl addbr xenbr1 sudo ifconfig xenbr1 up możemy dodać IP dla interfejsu xenbr1, który będzie adresem IP dla Dom0: sudo ifconfig xenbr1 192.168.0.1 netmask 255.255.255.0 sudo xl create /etc/xen/wsi1.cfg sudo xl create /etc/xen/wsi2.cfg
sudo xl console wsi1 sudo xl console wsi2 sudo xl network-attach wsi1 bridge=xenbr1 sudo xl network-attach wsi2 bridge=xenbr1 w wsi1: ifconfig eth1 192.168.0.2 netmask 255.255.255.0 up w wsi2: ifconfig eth1 192.168.0.3 netmask 255.255.255.0 up * możemy popingować w wsi1 i wsi2: adduser student login student w wsi1: echo "Hello from wsi1" > hello.txt scp hello.txt student@192.168.0.3:/home/student w wsi2: ls cat hello.txt echo "Hello from wsi2" >> hello.txt scp hello.txt student@192.168.0.2:/home/student --- limity na transfer danych --- Token bucket filter: Token bucket filter (TBF) kolejkuje pakiety, aby ograniczyć prędkość przesyłanych danych. Kolejkowanie (ang. queueing) jest procesem przechowywania pakietów w buforze w takiej kolejności w jakiej nadeszły. Przesłanie jednego pakietu pochłania tyle żetonów, ile jest bitów w tym pakiecie.
Żetony są dodawane do wiadra w stałym tempie wyrażonym w bitach na sekundę jako parametr "rate". Wiadro ma określoną głębokość wyrażoną w bitach (np. 100kbit) lub bajtach (50kb), którą definiujemy przez parametr "burst". Jeżeli liczba żetonów w pakiecie jest zbyt mała, aby wysłać pakiet, to pakiet jest buforowany do momentu zgromadzenia odpowiedniej liczby żetonów. Buforowanie pakietów można ograniczyć na jeden ze dwóch sposobów: * używając parametru "limit" możemy podać wielkość bufora wyrażoną w bitach lub bajtach, * używając parametru "latency" możemy podać maksymalne opóźnienie, jakie może pakiet doznać w kolejce. Tak więc obowiązkowymi parametrami TBF są "rate" i "burst". Trzeba dodatkowo "limit" albo "latency". Ograniczymy ruch przychodzący do sieci prywatnej po interfejsie xenbr0: sudo tc qdisc add dev xenbr0 root tbf rate 10kbit burst 50kbit limit 100kbit scp będzie działać wolno sudo tc qdisc add dev eth0 root tbf rate 10kbit burst 50kbit limit 100kbit wget będzie działać wolno sudo tc qdisc change dev xenbr0 root tbf rate 20kbit burst 100kbit limit 200kbit sudo tc qdisc change dev eth0 root tbf rate 20kbit burst 100kbit limit 200kbit Mały bufor, np. "limit 20 kbit", będzie potrafił pomieścić tylko jeden pakiet IP (około 1500 B), co przełoży się na duże straty pakietów i częste żądania retransmisji. Można dodać te komendy do pliku /etc/xen/scripts/vif-bridge
Usuwanie kolejki: sudo tc qdisc del dev xenbr0 root sudo tc qdisc del dev eth0 root Ograniczenie na gwałtowny przesył danych: sudo tc qdisc add dev xenbr0 root handle 1:0 tbf rate 10kbit burst 20kbit limit 20kbit sudo tc qdisc add dev xenbr0 parent 1:0 handle 2:0 tbf rate 10kbit burst 50kbit limit 100kbit lub: tc qdisc add dev xenbr0 root tbf rate 10kbit burst 50kbit limit 100kbit peakrate 200kbit mtu 1500 sudo tc qdisc del dev xenbr0 root Maximum Transmission Unit (MTU) rozmiar największego datagramu (bloku danych pakietowych) (w bajtach), który można przekazać przez warstwę protokołu komunikacyjnego. Narzędzie do automatycznego tworzenia kolejek: apt-get install wondershaper wondershaper [network interface] [download speed] [uploads peed] jednostką są kbit wondershaper clear [network interface] --- Profiling --- sudo apt-get install make sudo apt-get install netperf
sudo apt-get install bonnie++ sudo apt-get install gcc Operacje na plikach + instrukcje procesora: instalacja UnixBench pobierz unixbench ze strony make./run przejrzeć USAGE, README cat./results/... Dysk: echo $UID zalogować na roota bonnie++ -u 1000 bonnie++ -s 1024 -n 100 100*1024 plików utworzy echo "[RESULTS]" bon_csv2html > [OUTPUT] Sieć: w wsi1 i gospodarzu uruchomić netserver wywołać netperf w gospodarzu i wsi1 wywołać netperf -H [numer IP]