mbrowarski

xen linux dom0 opensolaris domU

Mając już zainstalowanego Linuksa na serwerze, czemu nie pokusić się o doinstalowanie tam następnego systemu, równolegle działającego ?
Przecież taką możliwość daje Nam wirtualizacja!!!
A jak nie mamy procesora x64 z możliwością sprzętowej wirtualizacji, a chcielibyśmy aby system był wydajny ?
Użyjmy Parawirtualizacji :)
Jak zacząć? Oto krótki przepis: Serwer posiadający procesor Intel 64bitowy dual Core, 2 Gb RAMu oraz trochę wolnego miejsca na dysku twardym i OpenSolarisa,którego można ściągnąć z tej strony.
Mountujemy obraz i przegrywamy z niego dwa pliki (jądro i plik startowy) na dysk twardy:
bash# cp /cdrom/boot/platform/i86xpv/kernel/amd64/unix /usr/src/xen/
bash# cp /cdrom/boot/amd64/x86.miniroot /usr/src/xen/
Następnie trzeba stworzyć plik, który będzie robił za cały dysk dla naszego systemu (np. 5GB):
bash# dd if=/dev/zero of=/usr/src/xen/disk.raw bs=1024k seek=5k count=1
Potem tworzymy plik konfiguracyjny config.py:
name = 'solaris-pv'
memory = '1024'
vcpus = 1
# for installation
disk = [ 'file:/iso/sol-nv-b75a-x86-dvd.iso,6:cdrom,r' , 'file:/usr/src/xen/disk.raw,0,w' ]
vif = [ '' ]
on_shutdown = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
kernel = '/usr/src/xen/unix'
ramdisk = '/usr/src/xen/x86.miniroot'
extra = '/platform/i86xpv/kernel/amd64/unix -B - nowin -B install_media=cdrom'

I już możemy uruchamiać proces instalacji:
bash# xm create -c config.py
SunOS Release 5.11 Version snv_75 64-bit
Copyright 1983-2007 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
WARNING: Found xen v3.1.0 but need xen v3.0.4-1-xvm
WARNING: The kernel may not function correctly

Ten błąd można zignorować, bo wszystko działa poprawnie. :)
I dalsza instalacja przebiega standardowo.
Także, życzę miłej zabawy z OpenSolarisem, Linuksem i XENem.

Posted at 04:47PM lis 06, 2007 by Maciej Browarski in Wirtualizacja - PL  |  Comments[0]

SUN Fire T2000 Solaris LDOMS test sieć net

Po wczorajszych testach SUN Fire T2000 został mi niedosyt związany z wydajnością sieciową.
Idąc tym tropem połączyłem bezpośrednio kablem drugi serwer T2000, aby uzyskać jak największą prędkość.
Jedna maszyna robiła za serwer WWW, a druga maszyna za klienta WWW. Na obydwóch maszynach zainstalowany system Solaris 10 update 4.
Zrobiłem dwa testy.
Pierwszy polegał na przesłaniu równoległe 16 x 43 MB (dokładnie 45107615 bajtów) plików i nie zapisywaniu danych na dysk.
Drugi na ściągnięciu tych samych danych, ale z zapisem na dysk.
Oba testy wykonałem na domenie kontrolnej jak i domenie logicznej.
Oto wyniki testów:
Dla domeny kontrolnej:
Bez zapisu na dysk: 9 sekund
Z zapisem na dysk: 20 sekund
Dla domeny logicznej:
Bez zapisu na dysk: 10 sekund
Z zapisem na dysk: 21 sekund

Przy uruchomieniu równolegle testów na domenie kontrolnej i domenie logicznej uzyskałem podobne czasy dla testu z zapisem na dysk i bez zapisu na dysk czyli:
21 sekund domena kontrolna, 31 sekund domena logiczna.
Podkreślam, że wyniki są orientacyjne i mają pokazać pewną tendencje i nie powinny służyć jako wyrocznia. Jeżeli ktoś wykona podobne testy i wyjdą inne wyniki, to nie wiń mnie za to.
Prędkość jaką uzyskałem bez zapisu na dysk to:
45107615 bajtów * 16 / 9 sekund = 80 191 315 bajtów / s = 641 530 520 bit/s
Prędkość jaką uzyskałem z zapisem na dysk to:
5107615 bajtów * 16 / 20 sekund = 36 086 092 bajtów / s = 288 688 736 bit/s
Wydaje się dobrym wynikiem :).
Najważniejszą rzeczą w tych testach jest to, że domena logiczna nie odbiega wydajnością od domeny kontrolnej.
Także tylko testować i cieszyć się z wydajnej wirtualizacji :).

Posted at 04:07PM paź 18, 2007 by Maciej Browarski in SUN Solaris  |  Comments[0]

SUN Fire T2000 solaris ldoms test

Jak miałem na testach maszynę X4100 wykonałem na niej testy.
Aktualnie mam SunFire T2000 i pozwoliłem sobie wykonać podobne testy, których krótki opis to:
1. Uruchomienie zadania zabierającego 100% procesora,
2. Uruchomienie równolegle 16 zadań zabierających 100% procesora,
3. Pobranie 40MB pliku i zapisanie go na dysk,
4. Pobranie równolegle 16 plików o wielkości 40MB i zapisanie na dysk.

Przyznam się szczerze, że wyniki testów mnie zaskoczyły!! Oczywiście są one orientacyjne, bardziej chodzi o wykrycie odpowiednich zachowań, tendencji.
Oto wyniki z domeny kontrolnej (4 wątki - 1 core, 1GB RAM):
1. 2 minuty 30 sekund
2. 31 minut 13 sekund
3. 4 sekundy
4. 1 minuta 1 sekunda

Oto wyniki z domeny logicznej (16 wątków - 4 core, 1 GB RAM):
1. 2 minuty 30 sekund
2. 7 minut 48 sekund
3. 4 sekundy
4. 1 minuta 3 sekundy
Jak widać z wyników T2000 nie jest demonem obliczeń (jeden fizyczny procesor, 6 core'owy 24 wątki, zegar 1,2GHz), ale pazurki wyciąga w przesyłaniu danych :) (średnio 10MBajtów/s = 80megabitów/s,a więcej pewnie sieć nie chciała dać).
Więc jeżeli mamy aplikację korzystającą mocno z sieci i dysków to ten serwer jest pod to przeznaczony. :)
Podział na logiczne domeny też nie sprawił, że operacje I/O spadły, także wirtualizacja jako Logical Domains (LDOMS) firmy SUN też jest udanym pomysłem.

Posted at 03:45PM paź 17, 2007 by Maciej Browarski in Wirtualizacja - PL  |  Comments[0]

Sieć w domenach logicznych (LDOMS)

Ostatnio pisałem o instalacji logicznej domeny kontrolanej przez Sun Solaris 10 na Sun Fire T2000.
Teraz chciałbym opisać, w jaki sposób jest rozwiązana sprawa kart sieciowych.
Jak wiemy z tego dokumentu karta sieciowa fizycznie jest widoczna tylko w domenie kontrolującej, a dalej jest udostępniana jako wirtualna karta.
Jak to się robi ?
W domenie kontrolującej wydaliśmy polecenie:
bash# ldm add-vsw net-dev=e1000g0 primary-vsw0 primary

Mówiące o tym, że tworzymy _virtualny_ switch o nazwie primary-vsw0 przypięty do fizycznej karty e1000g0. Tym samym wirtualne karty sieciowe są na zewnątrz widoczne tak jak nasza karta fizyczna.
Tworząc logiczną domenę, wydaliśmy taką komendę:
bash# ldm add-vnet vnet1 primary-vsw0 tdomena

Spowodowała ona, że w domenie logicznej pojawi się wirtualna karta logiczna, która jest przypięta do wirtualnego switcha primary-vsw0. MAC address karty logicznej zostanie automatycznie dobrany (będzie to nowy MAC address, a nie wspólny z fizyczna kartą e1000g0).
W domenie logicznej możemy zacząć manipulować kartą używając urządzenie vlan0, tj.:
-bash-3.00# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vnet0: flags=1004843 mtu 1500 index 2
inet x.x.x.x netmask ffffff00 broadcast x.x.x.255
ether 0:14:4f:f9:92:b4

Natomiast w domenie kontrolującej sytuacja wygląda tak:
-bash-3.00# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=1004843 mtu 1500 index 2
inet x.x.x.x netmask ffffff00 broadcast x.x.x.255
ether 0:14:4f:1d:e1:0
vsw0: flags=1000843 mtu 1500 index 3
inet x.x.x.x netmask ffffff00 broadcast x.x.x.255
ether 0:14:4f:fa:c6:5c

Aby był możliwy kontakt domeny kotrolującej z logiczną domeną, należy przydzielić interfejsowi vsw0 adres IP należący do tej samej sieci co adres w domenie logicznej
Bardzo pomocny jest ten artykuł.

Posted at 01:49PM paź 16, 2007 by Maciej Browarski in Wirtualizacja - PL  |  Comments[0]

Dance with OpenSolaris and XEN (part #3)

Last time I installed Linux on DomU, now I try to install on XEN OpenSolaris in PV mode.
Installation of OpenSolaris in PV mode is very easy (more easiest than Linux :)) because CD-ROM with OpenSolaris is prepare to install in this mode.
My config file for install looks:
name = 'solaris-pv'
memory = '1024'
vcpus = 4
# for installation
disk = [ 'file:/opt/iso/sol-nv-b75-x86-dvd.iso,6:cdrom,r' , 'file:/opt/xen/disk/solaris.raw,0,w' ]
vif = [ 'mac=00:0e:0c:3e:18:ee' ]
on_shutdown = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
Remember, in Linux systems we use hda to describe disk, in Solaris we must use 0, which means /dev/rdsk/c0t0d0s0.
And we can just type:
xm create solaris-pv.py -c
and we can start install OpenSolaris
After installation we must change line:
disk = [ 'file:/opt/iso/sol-nv-b75-x86-dvd.iso,6:cdrom,r' , 'file:/opt/xen/disk/solaris.raw,0,w' ]
to
disk = ['file:/opt/xen/disk/solaris.raw,0,w' ]
because, we don't want to reinstall systems.

Very helpful are this links.

Posted at 03:50PM paź 05, 2007 by Maciej Browarski in virtualization - EN  |  Comments[0]

Nowe linki XEN

Miejsca, które są warte odwiedzenia w tematyce XEN:
Instalacja OpenSolaris jako DomU
Instalcja Oracle 10 na OpenSolaris DomU, ktory jest na Linux (64 bit)
Instalacja Xen 3.1 Solaris DomU (64 bit) na Debian Etch Dom0 (64 bit)
Solaris and Xen - dużo porad
XEN Tools

Posted at 12:24PM paź 05, 2007 by Maciej Browarski in Linki  |  Comments[0]

Dance with OpenSolaris and XEN (part #2)

Last time I installed Linux on OpenSolaris in XEN using SUN X4100 with VT processor.
Now I'm going to install Linux on this same machine but our virtual machine will be in PV (paravirtualization) mode.
How we can do this ? Let's start :).
First, we need file disk.raw (whole disk for Virtual Machine) from previous installation, because Debian Linux distribution isn't ready to install in PV mode (but we can find kernel image for XEN, more detail below).
Second, we create new config file named linux-pv.py:
name = 'linux-pv'
memory = '1024'
vcpus = 2
boot='c'
kernel = "/opt/xen/kernel/vmlinuz-2.6.18-xenU"
root = "console=xvc0 root=/dev/hda1"
disk = [ 'file:/opt/xen/disk/disk-pv.img,hda,w' ]
vif = [ '' ]
on_shutdown = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'

This config file is smaller than previous, but we've 2 new parameters: kernel (where is kernel) and root (parameter for kernel command line).
You can download kernel image for debian from this link (this is for our server AMD64).
Or we can compile kernel :).
How we can do that ?
We need machine with Linux OS (or we can use Linux from previous installation) and download source code of XEN 3.1.0 from this link.
So now, we unpack and untar and we enter in xen-3.1.0-src directory and type there:
make kernels
This command compiling kernel with defaults settings and also download kernel source code version 2.6.18 from www.kernel.org site.
After that we can configuring our kernel domU:
make linux-2.6-xenU-config CONFIGMODE=menuconfig
So now, we can configure our XenU kernel (don't forget enable XEN->xen version compatibility 3.0.4, because OpenSolaris using XEN version 3.0.4-1).
After configuration is time to compile:
make dist KERNELS=linux-2.6-xenU



And after a good compilation, we can find binary kernel in dist/install/boot directory (file: vmlinuz-2.6.18-xenu) and modules for this kernel are in dist/install/lib directory.
Now we copy Linux kernel to /opt/xen/kernel directory onto our OpenSolaris systems and correct kernel parameter in config file linux-pv.py.
So, it's time to run PV systems. We do that by typing on OpenSolaris:
xm create linux-pv.py -c
Don't forget about '-c' parameter because now output from virtual systems will not be in separated window but in our xterm window.
When we can login as a root to linux, we must copy modules from compilation to /lib/modules directory.



So, now we can play PV Linux on our OpenSolaris system :).

Posted at 03:29PM paź 02, 2007 by Maciej Browarski in virtualization - EN  |  Comments[0]

Dance with OpenSolaris and XEN

On SUN hardware X4100 (with Intel Processor VT technology) I install OpenSolaris and above it, with new technology XEN, Linux.
Installation of Operating System goes smoothly (with default settings and some free place for virtual disk, I think, 10GB is enough). After reboot, in bootloader GRUB, I have chosen Solaris xVM (second on list menu).
Next I downloaded new Debian distribution net version AMD64 from here (This distro is very small and powerful) and put it on server directory /opt/iso/.
For better understood of configuration this website is very helpful.
Now let's start configuration.
All files I put on /opt/ directory.
On /opt/xen/disk I put file disk.raw which emulate whole disk for virtual machine (I make this file by typing: dd if=/dev/zero of=disk.raw bs=1024k seek=4k count=1 from command line).
And after that I create config file (/opt/xen/config/linux.py), which look like:

name = 'linux'
memory = '1024'
# number of virtual CPU
vcpus = 2
# For normal work change it to boot='c'
boot='d'
#
# virtual devices
# disk, cdrom and network
disk = [ 'file:/opt/iso/debian-40r1-amd64-netinst.iso,hdb:cdrom,r', 'file:/opt/xen/disk/disk.img,hda,w' ]
vif = [ 'type=ioemu, mac=00:0e:0c:3e:18:cd' ]
on_shutdown = 'destroy'
#
# we use destroy on reboot, because after installation we'd like to switch boot='d' to boot='c'
#
on_reboot = 'destroy'
on_crash = 'destroy'
#
# For full hardware virtualization we need this 4 lines
#
kernel = "/usr/lib/xen/boot/hvmloader"
device_model= "/usr/lib/xen/bin/amd64/qemu-dm"
builder='hvm'
sdl = 1

I make whole configuration from my laptop. So now I need to switch output from server console to my X window laptop. We need set up 2 things:
1. Our X server, on laptop, must have opened TCP port 6000 and
2. From root account we must type 'xhost +' to allow open window from remote server.
So, after that, next step is to run virtual machine :).
xm create /xen/opt/config/linux.py
On laptop, I can see new window from virtual machine :).

But, if we've a trouble ?
First thing is to read what error it is. But when we can't find solution, below is my emergency procedure:
1. check that xend is running.
We type a command:
svcs -a | grep xend
It should be running, if not, we try to switch it to online (sometimes reboot is good solution, if not, we try to find error in log file, why xend can't running).
2. Check that our laptop receive connection for X window.
Type:
netstat -na | grep 6000
Return line should contain *.6000 LISTEN, if not, we try configure process called ./X without option -nolisten.
3. Type 'xhost +' from laptop root account to allow remote connection for X.

Posted at 03:40PM paź 01, 2007 by Maciej Browarski in virtualization - EN  |  Comments[2]

Sięganie do źródeł OpenSolaris

Jak wiemy, BrandZ jest technologią, która pozwala na uruchomienie kodu skompilowanego pod Linuksem w środowisku Solaris i OpenSolaris.
Polega ona na uruchamianiu programów Linuksowych w normalny sposób, ponieważ ich kod binarny jest normalnie przetwarzany i działa on bez problemów (w końcu instrukcje procesora INTEL/AMD są takie same, bez względu na to jaki system operacyjny jest na nim uruchomiony). Jedyną różnicą są odwołania do funkcji systemowych jądra systemu operacyjnego.
Dlatego tajemnica technologii BrandZ tkwi w przechwyceniu wywołań funkcji systemowych Linuksa i albo wykonaniu ich bezpośrednio na Solarisie(np. funkcje open, write, close są takie same dla obydwóch systemów) albo wykonaniu ich w emulacji. Dokładnie o tym można poczytać tutaj.
Aby zobaczyć, które funkcje są przekazywane dalej do OpenSolarisa, a które emulowane, można podejrzeć w pliku źródłowym w strukturze sysents.
Gorąco polecam!!

Posted at 02:45PM wrz 27, 2007 by Maciej Browarski in OpenSolaris  |  Comments[0]

Podglądanie BrandZ

Gdybyśmy chcieli się bardziej wgłębiać w to co się dzieje w BrandZ to polecam (oprócz oczywiście kodu źródłowego) wykonanie w taki jak poniżej sposób poleceń w zonie lx:
linux# LX_DEBUG=1 LX_DEBUG_FILE=/tmp/output.lx polecenie
Powoduje to, że dane polecenie zostanie uruchomione pod kontrolą odpluskwiacza (debuger).
W pliku /tmp/output.lx w zonie znajdziemy zapis systemowy co i jak zostało uruchomione.
Pozwala to na poznanie lepiej technologii BrandZ.

Posted at 05:06PM wrz 21, 2007 by Maciej Browarski in SUN Solaris  |  Comments[0]

BrandZ linux

Aby zwiększyć wydajność Zone'y Solarisowych wynaleziono brandZ.
Jest to możliwość uruchamiania programów Linuksowych natywnie pod Solarisem, dzięki czemu uzyskujemy wirtualny system operacyjny!!
Wcześniej należy jednak zapoznać się z informacjami nt. ograniczeń. Głównie chodzi o aplikacje, które zależą bezpośrednio od jądra Linuksa (np. iproute, tcpdump).
Reszta aplikacji powinna działa poprawnie.
Jak to się instaluje ?
1. Najpierw tworzymy Zone wydając komendę:
# zonecfg -z linux
>create -B SUNWlx - dla OpenSolarisa, create -t SUNWlx dla Solarisa
>set zonepath=zonedir
>add net
net>set address=x.x.x.x/x
net>set physical=nge0
net>end
>exit
2. Instalujemy Zone w systemie:
# zonecfg -z linux install -d /tmp/lx-brandz-base.tar (plik można pobrać z tej strony)
3. Należy teraz przegrać wszystkie pliki z dystrybucji do katalogu zonedir/root/. (niestety musimy wcześniej zainstalować system, aby uzyskać te pliki)
4. Poprawa pliku /etc/inittab poleceniem:
perl -pi -e "s,tty1,console,; s,^([23456]),#\1," etc/inittab
5. Uruchamiamy zone:
# zoneadm -z linux boot
6. Można się teraz zalogować
# zlogin linux i już działamy w systemie Linux!!

Należy pamiętać, że BrandZ działa tylko na Solaris 10u4 platforma Intel. Aktualnie wspierane są tylko 32bitowe instalacje Linuksa, a pracę nad 64bitowych są w trakcie. Wersja dla SPARC też jest w opracowaniu.
Gorąco polecam, bo wirtualizacja z BrandZ nabiera nowego znaczenia:)

Posted at 02:48PM wrz 17, 2007 by Maciej Browarski in SUN Solaris  |  Comments[2]

OpenSolaris Zone - test

Mając dalej do dyspozycji serwer X4100 wykonałem podobne testy jak poprzednio, ale na zone'ach solarisowych.
Oto wyniki:
1 zona
1. 44 sekund
2. 2 minuty 56 sekund
3. 11 sekund
4. 1 minuta 50 sekund
2 równoległe zony
1. 44 sekund
2. 5 minut 45 sekund
3. 24 sekundy
4. 2 minuty 15 sekund

Jak widać z wyników i porównania z poprzednimi wynikami z XEN, OpenSolaris + Zone mają lepszą wydajność w operacjach I/O ponieważ nie są one emulowane.
Oczywiście można dużo pisać o różnicach między Zone i XEN, i czy można je porównywać, ale chyba najważniejszymi rzeczami są wydajność i bezpieczeństwo dla uruchamianych programów, a to obydwa produkty zapewniają.
Ktoś może zarzucić, że w Zone'ach można uruchomić tylko programy pod Solarisa, nic bardziej mylnego, bo ostatnio pojawiło się BrandZ. Zwiększa on możliwość o, bez rekompilacji, uruchamianie aplikacji Linuksowych w Zone'ach. Ale o tym następnym razem.

Posted at 03:00PM wrz 12, 2007 by Maciej Browarski in Wirtualizacja - PL  |  Comments[0]

OpenSolaris XEN - test

Mając do dyspozycji serwer X4100 z procesorami Dual-Core AMD Opteron(tm) Processor 2220, które to wspierają sprzętową wirtualizację, można pokusić się o przeprowadzenie testów wirtualizacji za pomocą XEN.
Wersję OpenSolaris z XEN można pobrać z domowej strony projektu.
Instalacja przebiega bezproblemowo i po restarcie mamy już gotową maszynę do testów.
Po skonfigurowaniu wirtualnej maszyny (wspierając się tą stroną), został tam zainstalowany Linux Debian 4.0 etch.

Test podzieliliśmy na 4 etapy:
1. uruchomienie programu obciążającego procesor w 100%,
2. uruchomienie 16 programów obciążających procesor w 100%,
3. pobranie 40MB pliku ze strony www,
4. pobranie równolegle szesnastu 40 MB plików ze strony www.
Oto wyniki z czystego OpenSolarisa bez XEN (4 logiczne procesory):
1. 43 sekundy
2. 2 minuty 53 sekundy
3. 12 sekund
4. 1 minuta 50 sekund
dom0 (domena kontrolująca, 4 logiczne procesory):
1. 43 sekundy
2. 2 minuty 56 sekund
3. 12 sekund
4. 1 minuta 39 sekund

Wyniki z domU (4 wirtualne procesory 1GB pamięci):
1. 43 sekundy
2. 2 minuty 52 sekundy
3. 27 sekund
4. 3 minuty 10 sekund

Wyniki z domU-1 i domU-2 (uruchomione równolegle 2 domen i 2 testów):
domU-1:
1. 43 sekundy
2. 5 minut 45 sekund
3. 43 sekundy
4. 5 minut 40 sekund
domU-2:
1. 43 sekundy
2. 5 minut 45 sekund
3. 40 sekundy
4. 5 minut 41 sekundy
Podsumowanie testów:
Podanego wyżej czasu nie powinniśmy traktować dokładnie, lecz należy przyjrzeć się proporcjom liczb, które ukazują Nam jakie właściwości daje sprzętowa wirtualizacja za pomocą XEN.
Jak widać z testów, wydajność procesorów jest taka sama, co może oznaczać, że XEN dodatkowo nie obciąża maszyny, a moc jest równomiernie rozdzielana. Niestety problem z wydajnością widać przy operacjach I/O. Tutaj widać narzut XEN na urządzenia. Trzeba pamiętać, że sieć i dyski są emulowane.
Kolejną rzeczą, to że DomU-1 i DomU-2 korzystało z jednej fizycznej karty sieciowej, także ich wydajność została podzielona na dwa równoległe strumienie.
Dlatego przy wirtualizacji trzeba pamiętać o dobrym Capacity Planningu bo maszyny fizyczne i ich zasoby nie są z gumy i łatwiej jest o skonsumowaniu całych zasobów.

Posted at 10:07AM wrz 11, 2007 by Maciej Browarski in OpenSolaris  |  Comments[0]