Virtualisering som helgnöje

Jag har börjat roa mig med att lära mig mycket om virtualisering. Dvs, att köra låtsasdatorer inuti mina servrar. Fast virtualisering är inte så mycket på låtsas längre, det är en av de snabbast framväxande marknaderna på Internet. Och jag är väl en av de få en inte har köpt en VPS (Virtual Private Server) för att köra mina tjänster på. Jag har riktig hårdvara. Med ett riktigt nät. Det finns virtuella nät också.

Först måste jag erkänna att jag trodde det var väldigt enkelt att köra virtualisering. Och det är det ju också på ytan, ända tills man vill börja göra lite mer intressanta saker med virtualisering.

Den första frågan man ställer sig när man vill börja köra lite virtuella maskiner är förstås vilken virtualiseringprogramvara man vill köra (eller “hypervisor“). Den självklara plattformen att köra hypervisor på är för mig idag Linux. Det finns lite att välja bland, men själv kom jag att fundera på Xen, VirtualBox eller nånting jag aldrig tittat på, Qemu-KVM. VirtualBox har jag kört litegrann på min MacOS-maskin för att snabbt och enkelt testa lite saker under andra operativsystem. Men aldrig för att permanent köra en virtuell server. Vad jag visste är dock att KVM finns i Linux-kärnan sedan ett par år tillbaka, och det har känts som om det är den tekniken som utvecklas mest just nu. Så jag bestämde mig för att titta närmare på Qemu och KVM.

Steg ett var att titta närmare på Qemu och komma underfund med hur det fungerade. För att skapa en virtuell maskin måste man först skapa en image att installera ett operativsystem på. Qcow2 är det image-format som man vill använda idag för att köra virtuella servrar. Mycket arbete pågår för att förbättra tekniken för hur virtualiserade operativsystem fungerar på dessa images, både vad gäller hur de växer i storlek med att den virtuella maskinen använder diskytan, men också prestandan kan förbättras både i den virtuella maskinen och i hypervisorn.

Hur som helst, skapa en 10GB qcow2-image med följande kommando:

twobot$~>qemu-img create -f qcow2 foo.img 10G
Formatting ‘foo.img’, fmt=qcow2 size=10737418240 encryption=off cluster_size=0

Man kan ha krypterade images, vilket ju är trevligt. Med AES-kryptering och ett långt lösenord borde det dessutom bli riktigt säkert.

Vad gäller dessa images i övrigt så verkar det finnas en del trevliga verktyg baserade på libguestfs att jobba med för att titta inuti dem. Med guestfish kan du manipulera filer direkt i en disk-image. Det är praktiskt om man vill duplicera många images, och därefter anpassa varje image med exempelvis hostnamn och annat. Görs lämpligast när maskinen inte körs förstås. Med guestmount används FUSE för att montera valt filsystem i en image direkt i det lokala filsystemet.

När man vill bygga sina virtuella servrar så vill man förstås att de ska få sina IP-adresser ut mot Internet, och inte bara vara lokalt åtkomliga från hypervisorn. Default-inställningen verkar vara att köra på väldigt lokala IP-adresser. I Linux kan man dock skapa ett bridge-interface för att hänga på de virtuella instanserna på det externa interfacet. Så i stället för att konfigurera eth0 som vanligt konfigurerar man upp sin br0 såhär:

auto br0
iface br0 inet static
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
address 192.168.0.2
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.0.1
broadcast 192.168.0.255
up ifconfig br0 add 2001:16d8:dead::dead/64

och sedan ersätter man sin eth0 såhär:

auto eth0
iface eth0 inet manual

br0 blir då statiskt konfigurerad. Hypervisorn kan dock köra en DHCP-server så att de virtuella servrarna får en automatiskt konfigurerad IP-adress. (Exemplet ovan är en Debian.)

Nu har vi en image och ett nätverk som är rätt konfigurerat. Då återstår bara att installera ett operativsystem. Mitt första försök använde qemu direkt för att installera operativsystemet. Man konfigurerar upp qemu för att montera på en cdrom, eftersom så fort man kör igång qemu så är det ju en virtuell maskin man startar.

sudo qemu -enable-kvm -k sv -ctrl-grab -hda foo.img -m 1024 -net nic,macaddr=DE:AD:BE:EF:A7:A2 -net tap,ifname=tap2 -monitor pty -vnc 0.0.0.0:1 -name foo-dator -cdrom debian-testing-i386-businesscard.iso -boot d

Tyvärr verkar det som om man måste köra qemu som root för att kunna köra mot bridge-interfacet. Kör man qemu såhär så når man den via VNC på den första lediga porten (VNC körs från port 5900 och uppåt). Anlut och se datorn boota upp, och förhoppningsvis boota från cdrom. Sedan när du installerat operativsystemet är det bara att boota om och köra igång det installerade systemet.

Vill man inte köra qemu-kommandona för hand kan man istället välja att köra ytterligare ett abstraktionslager högre upp. Det finns antagligen flera. Jag vet att Ubuntu har baserat något på virsh för att via grafiska gränssnitt för att konfigurera upp qemu, och förmodligen har alla OS sina verktyg. Virsh är dock ett CLI som verkar vanligt, och motsvarande qemu-kommando är detta:

virt-install –connect qemu:///system –virt-type kvm –accelerate –name demo –ram 1024 –disk path=debian.img,size=10,format=qcow2 -w bridge:br0 –mac=DE:AD:BE:EF:A7:A2 –graphics vnc,listen=0.0.0.0,keymap=sv,password=’foo’ –noautoconsole –cdrom debian-testing-i386-businesscard.iso

Det är viktigt att sätta olika MAC-adresser för de virtuella nätverksgränssnitten, annars kommer de att kollidera på ditt LAN. Hur som helst, poängen med att köra virsh framför qemu direkt är att du får ett management-lager ovanpå qemu som har koll på vilka virtuella maskiner som finns tillgängliga, vilka som är igång, hur mycket CPU de drar, och så vidare. Dessutom blir det enklare att skapa kloner av en maskin du kan utgå ifrån för att skapa nya projekt.

Jag inser vid det här laget att jag skulle kunna skriva tio bloggposter till, så det kommer jag att göra. Kan du inte slita dig från att lära dig så vet jag inte riktigt var man ska börja läsa. Men själv sitter jag och pluggar presentationerna från KVM-konferensen som var nu i augusti. Och jag har inte ens börjat skriva om user-mode-linux som jag tycker är väldigt trevligt. Eller virtuella nätverk.

Med ett oerhört kommersiellt intresse för virtualisering har jag insett att det händer oerhört mycket inom det här området. Mycket går givetvis mot att klämma in fler och fler virtuella maskiner i en och samma hypervisor för att kunna sälja till fler kunder, men också mot management och monitoring. Men det är ju intressant även för mig, som vill kunna använda min hårdvara till roliga saker också.

Vad har ni för erfarenheter av virtualisering?

04
Sep 2011
POSTED BY
DISCUSSION 8 Comments
TAGS

8 Responses to : Virtualisering som helgnöje

  1. Albert says:

    Min erfarenhet av VirtualBox är att det funkade bra tills Oracle köpte upp Sun. Sen kom helt plötsligt en uppdatering som fick USB att sluta funka och det kom upp ett meddelande om att Oracle ville ta betalt för USB. Då kändes plötsligt VirtualBox som VMware. Man kanske skulle testa qemu istället för att slippa den typen av problem.

    • JoachimS says:

      Aloha!

      Ett annat vbox-bekymmer efter post-Oracle är att dom inte tvekar att bryta ABI:t för sina images. Har uppgraderat >1 gång och mötts av den glada överraskningen att det inte längre går att starta maskinerna i de nya versionen.

    • spe says:

      Intressant! Vet du när de gjorde USB-utbrytningen? Så att jag kan undvika att uppgradera. Jag _tror_ USB:n funkar fortfarande. ;) Galet många uppdateringar tyckte jag det var.

  2. Jakob says:

    Jag har kört XEN länge, eftersom det känts både moget, ganska stabilt och mycket snabbt. KVM kändes först helt nyligen som att det är moget att använda på riktigt. Virtualbox känns som en bra ersättning till gamla VMWare Player för skrivbordet, men knappast mer.

  3. spe says:

    Intressant artikel, fortsätt dina VM-utforskande. Själv kör jag VirtualBox för de tillfällen jag behöver antingen bygga nåt Windoze eller för att köra nåt infernaliskt program som Wine inte fixar. Oftast ett program som kommunicerar via nån serieport eller liknande.
    Ett fluffigt GUI till Qemu/KVM skulle ju sitta som en schmäck, ska jag köra nån VM var tredje månad vill jag inte lära mig de där fina kommandoradsharangerna ovan.

  4. nsg says:

    Min personliga favorit är KVM, jag använder det uteslutande med hjälp av libvirt, använder det grafiska virt-manager då det går, annars blir det virsh.

    Det jag gillar med lösningen är att display:en är en vanlig VNC-anslutningen och all kommunikation går över en ssh-tunnel, d.v.s. har du tillgång till ssh så har du allt du behöver. Inget krångel med att öppna massa extra portar o.s.v.
    virt-manager gör allt enkelt, du kan ändra i konfiguration, få information, kontrollera maskinerna samt få upp en VNC-ruta smidigt och enkelt, dock stödjer den inte allt så det blir ibland lite konfigurerade med virsh och/eller ändra i xml-configen.

    Något att tänka på med KVM, som jag nämnde ovan så kör den med VNC som skärm, det gör att du inte får någon större prestanda på grafik. Är det viktigt för dig så är det nog VirtualBox eller VMWare som du vill ha. Men för virtuella servrar så är KVM guld.
    Det går att komma runt problemet med x-forward.

    Yttligare en fördel med libvirt är att det även stödjer Xen, så har du en Xen-server så kan du använda libvirt till det på samma sätt.

    Jag har KVM maskiner på min dator för att abstrahera i väg olika saker, t.ex. en maskin för php-kodande, en för rails o.s.v. Använder sedan x-forward för att allt ska flyta ihop fint. Maskinerna kör NAT.

    På min server kör jag KVM för virtuella maskiner, där har jag satt upp en brygga, ett internt närverk samt NAT och lägger maskinerna på de interfacen där de passar.

    På jobbet kör vi KVM med för vi hostar att 20-tal maskiner, funkar fint och smidigt och vi gör så mycket vi kan med virt-manager. Vi körde tidigare Xen men migrerade bort då de flesta distributioner siktar på KVM i dag.

    Jag är även ansvarig för en Xen-maskin, gör inte så mycket jobb med den mer än att ser till att den snurrar men det är trevligt att jag kan använda samma verktyg mot den.

    Har även en till server som kör VitualBox, det funkar bra. Även om VirtualBox har CLI-verktyg så märker man fort att det är först och främst designat för att bli kontrollerat med att GUI. Jag “gav upp” och orkade inte brottas med CLI-kommandorna och kör i dag GUI:t med x-forwarad.

    Hm, blev lite längre svar än jag trodde, hade tydligen mer att säga än jag trodde :) Hoppas det hjälper någon.