azns.it

Creiamo una VM Ubuntu su un server Xen CentOS

giu 302011

In questi giorni ho avuto la necessità di installare una DomU Ubuntu avendo a disposizione un server Xen Dom0 su CentOS.

Non è una delle operazioni più immediate, pertanto vi spiego la procedura che ho utilizzato.

Innanzi tutto ho creato una immagine per la root del sistema operativo della dimensione di 4 GB usando il comando dd:

dd if=/dev/zero of=ubuntu.img bs=1024 count=4096

Quindi formattiamo l’immagine con il filesystem ext3:

mke2fs -j ubuntu.img

Ora scarichiamo il cd di installazione di Ubuntu: in questo caso utilizzo Ubuntu 10.10, ma vale per qualsiasi versione:

wget http://archive.ubuntu.com/ubuntu/dists/maverick/main/installer-amd64/current/images/netboot/mini.iso

Creiamo il file di configurazione di xen per eseguire il boot dall’immagine CD:

/etc/xen/ubuntu
name="ubuntu"
memory=512
vif=['bridge=xenbr0']
disk = ['file:/home/user/mini.iso,xvdc:cdrom,r', 'file:/home/user/ubuntu.img,xvda,w']
bootloader="/usr/bin/pygrub"
on_reboot='restart'
on_crash='restart'

e avviamo la nuova vm con

xm create /etc/xen/ubuntu -c

Ora seguiamo i passi di installazione standard, con due sole eccezioni:

quando l’installer chiederà di partizionare il disco, prestate molta attenzione a NON ripartizionare il disco, dicendogli di montare l’unica partizione rilevata in / senza formattarla nuovamente.
quando, al termine dell’installazione, chiederà di installare il bootloader grub, saltate questo passaggio

Al termine dell’installazione l’immagine si riavvierà, ma dato che non avete “espulso” il CD ripartirà il processo di installazione. Lanciate il seguente comando per spegnere la VM:

xm destroy ubuntu

Ora arriva la parte divertente: il comando pygrub di centos non è in grado di avviare correttamente le immagini di Ubuntu, pertanto utilizzeremo in vecchio e caro metodo di Xen andando a specificare quale kernel utilizzare.
Montiamo provvisoriamente l’immagine di Ubuntu:

mkdir /mnt/tmp
mount -o loop /home/user/ubuntu.img /tmp/mnt
cp /tmp/mnt/boot/vmlinuz* /tmp/mnt/boot/initrd* /home/user

Andiamo a modificare il file di configurazione di Xen per avviare correttamente la nostra immagine:

/etc/xen/ubuntu
name="ubuntu"
memory=512
vif=['bridge=xenbr0']
disk = ['file:/home/user/ubuntu.img,xvda,w']
kernel = "/srv/vms/kernel/ubuntu/vmlinuz-2.6.35-30-generic"
ramdisk = "/srv/vms/kernel/ubuntu/initrd.img-2.6.35-30-generic"
root = '/dev/sda'
on_reboot='restart'
on_crash='restart'

e avviamo nuovamente la vm con:

xm create /etc/xen/ubuntu -c

Comandiamo le VM in OpenNebula

Articoli Blog, OpenNebula No Responses »

mag 122011

Come già detto nel precedente articolo, OpenNebula include il comando onevm per gestire le istanza delle VM.
Sinceramente la documentazione ufficiale e il manuale del comando mi hanno un po’ tratto in inganno per cui inquesto articolo cercherò di fare un po’ di chiarezza.
Ovviamente i comandi lanciabili attraverso onevm possono tranquillamente essere lanciati anche attraverso l’interfaccia web sunstone.

create
Abbiamo già visto l’utilizzo di “create”: con questo comando si crea l’istanza di una nuova VM partendo da un file template oppure dai dati inseriti attraverso l’interfaccia web sunstone. Una volta lanciato il comando, l’immagine viene posta in stato “pending”, in attesa quindi che lo schedulatore interno di opennebula si faccia carico di eseguire tutte le operazioni necessarie per avviare l’istanza su un hypervisor.
Dopo qualche istante, quindi, l’immagine entrerà nello stato “boot” per poi passare in stato “running”.

shutdown
Qui arriva il mio primo misunderstanding: siamo in un cloud e non in un semplice hypervisor, quindi le istanze delle VM non sono altro che dei servizi. Ciò vuol dire che con shutdown non chiedo semplicemente lo spegnimento della VM, ma ne chiedo, sostanzialmente, la disattivazione!
Quindi, lanciando lo shutdown, la VM viene spenta e cancellata senza alcuna possibilità di essere riavviata a meno di non creare una nuova istanza! Tenetelo ben presente…
La voce relativa all’istanza rimane comunque memorizzata per motivi storici fintantochè non viene cancellata.

delete
Serve per cancellare una VM. Nel caso in cui la VM sia accessa, prima viene operato uno shutdown.

suspend e resume
Il comando suspend mette in pausa la macchina virtuale. Lo stato viene salvato in un’area temporanea all’interno del nodo di clacolo locale, pronto per essere riutilizzato quando si lancia il resume.

stop e resume
Il comando stop è simile al suspend ma la macchina virtuale viene salvata in un’area temporanea all’interno del controlle per essere riutilizzata quando si lancia il resume e funziona solo se l’immagine ha il flag “SAVE” attivo. La differenza tra stop e suspend sta proprio nella posizione ove viene salvato lo stato della VM: averla nel nodo locale (suspend) permette di rendere il resume più rapido, però è necessario che tutte le risorse necessarie per far funzionare la VM siano disponibili. Al contrario, con lo stop, i dati della VM vengono spostati all’interno del controller, per cui in fase di resume viene scelto l’host più adatto per ospitare la VM.

migrate e livemigrate
I comandi migrate e livemigrate permettono di spostare l’immagine della VM da un server Hypervisor all’altro. Nel caso di migrate, viene fermata la VM, salvato lo stato sul cloud controller e poi viene eseguito il resume sul secondo host; nel caso di livemigrate, si sfruttano le potenzialità offerte dall’hypervisor per migrare la VM senza soluzione di continuità.

restart
Altro comando che crea imbarazzo: non serve per riavviare una istanza attiva, ma per far ripartire una istanza in stato sconosciuto. Se una VM si blocca (o se spegnamo una VM attraverso il comando “halt” di linux) è possibile farla riprtire attraverso il comando reboot.

Riassumendo, quindi:

una macchina virtuale può essere messa in pausa con stop o suspend, ma non può essere spenta “alla VMWare” tramite hypervisor, ma solo attraverso shell locale
se una macchina virtuale si blocca, oppure se il controller viene riavviato, lo stato della VM diventa “UNKNOWN”: in questo caso è possibile riavviare l’istanza della VM attraverso “restart”
il “reboot” da linux è ininfluente per lo stato della VM in OpenNebula
per riavviare una VM che appare in “RUNNING” ma che in realtà è bloccata (ad es. se riempite il disco della VM ) l’unica possibilità è quella di cancellare l’istanza e ricrearla

Iniziamo a lavorare con OpenNebula: istanza VM

Articoli Blog, OpenNebula No Responses »

mag 092011

Chiudiamo questa serie di articoli sull’utilizzo pratico di OpenNebula con la creazione dell’istanza vera e propria alla VM.

Come nei precedenti casi, è necessario creare un file template e poi utilizzare il comando onevm per far partire l’istanza.

vm1.vm
#---------------------------------------
# VM definition example
#---------------------------------------

NAME = test

CPU    = 0.1
MEMORY = 128

OS = [
  BOOTLOADER = "/usr/bin/pygrub",
  BOOT = hd ]

DISK = [
  image     = "centos",
  driver     = "file:",
  target     = "xvda" ]

NIC = [ network = "test" ]

e creiamo l’istanza con:

onecm create vm1.vm

Nel nostro caso abbiamo creato la VM utilizzando l’immagine “centos” inserita precedentemente nell’image server e il network test anch’esso preconfigurato all’interno del nostro ambiente di test. Trattandosi di un hypervisor XEN, ho forzato alcuni parametri come il driver disco (file: invece tu blktap:) e ho scelto di utilizzare la virtualizzazione hardware invece della paravirtualizzazione dichiarando il bootloader invece dei parametri KERNEL ed INITRD. In qualsiasi caso i parametri di configurazione del template sono recuperabili dal sito ufficiale, mentre qui sotto trovate le immagini per eseguire la medesima operazione attraverso sunstone.

Nel prossimo

Installazione di uno storage ZFS/NFS su OpenSolaris per OpenNebula

Articoli Blog, OpenNebula No Responses »

apr 102011

Se avete seguito l’HowTo su OpenNebula del precedente articolo, ora avete un sistema di cloud formato da un controller e due nodi, perfettamente funzionante e completamente fault tolerant.

In questo howto useremo OpenSolaris per creare uno storage NFS4; alla base del datastore ci sarà ZFS che incorpora le funzionalità di snapshooting e modificheremo i driver NFS di OpenNebula per utilizzare gli snapshot in fase di deploy al posto della copia fisica: per una VM con un disco di 4 GB i tempi di deploy passeranno da circa 2 minuti a circa un secondo!
Questo articolo è tratto da questo blog.

Installazione dello storage server
Partiamo da una installazione pulita di OpenSolaris e, attraverso l’apposito pannello, assegnamo un indirizzo IP statico. In questo esempio assumiamo di usare l’IP 172.16.0.250 con la configurazione degli altri host dell’articolo precedente.
Inoltre, modifichiamo il file /etc/hosts per aggiungere gli altri host:

/etc/hosts
172.16.0.1 cloud-cc
172.16.0.2 cloud-01
172.16.0.3 cloud-02

Quindi creiamo la configurazione dell’utente rispettando uid e gid del precedente articolo aprendo una shell e lanciando i seguenti comandi:

pfexec groupadd -g 1001 cloud
pfexec useradd -u 1001 -g cloud -d /srv/cloud/one -s /bin/bash oneadmin

Ora è il momento di creare la configurazione NFS:

pfexec zfs create rpool/export/home/cloud
pfexec zfs set mountpoint=/srv/cloud rpool/export/home/cloud
pfexec zfs create rpool/export/home/cloud/images
pfexec zfs create rpool/export/home/cloud/one
pfexec zfs create rpool/export/home/cloud/one/var
pfexec chown -R oneadmin:cloud /srv/cloud
pfexec zfs set sharenfs='rw=@172.16.0.0/24' rpool/export/home/cloud
cat /var/run/nfs4_domain # Segnarsi il risultato di quest'ultimo comando

Bene, la configurazione dello storage è ultimata.

Modifica della configurazione dei nodi del cloud per montare lo storage NFS
E’ necessario modificare la configurazione dei tre server del precedente esempio per poter sfruttare il nuovo storage.
Innanzi tutto, sui due nodi di calcolo smontiamo la directory condivisa:

umount /srv/cloud

Sul nodo controller, invece, spostiamo la directory con tutti i file di opennebula in un luogo diverso:

mv /srv/cloud /srv/cloud.old
mkdir /srv/cloud

leviamo la riga dal file /etc/export e lanciamo

exportfs -a

Ora configuriamo tutti i 3 server per accedere allo storage; modifichiamo innanzi tutto il file /etc/export per montare il filesystem nfs in /srv/cloud. Nel caso del colud controller questa riga anfrà aggiunta, nel caso dei due nodi di calcolo bisognerà modificare la vecchia riga. Attenzione che nel caso precedente il filesystem esportato era nfs3 mentre in questo caso sarà nfs4.

/etc/fstab
172.16.0.250:/srv/cloud /srv/cloud/ nfs4 noauto 0 0

Inoltre bisognerà modificare il file /etc/idmapd.conf come da esempio seguente, prestando attenzione a settare Domain al valore precedentemente rilevato sul server OpenSolaris

/etc/idmapd.conf
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = mydomain.priv # Modificare questo valore

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

Come ultima cosa, bisogna modificare il file /etc/default/nfs-kernel-server per abilitare il demone idmapd:

/etc/default/nfs-kernel-server
NEED_IDMAPD=yes
NEED_STATD=
STATDOPTS=

A questo punto riavviamo il demone nfs-common e montiamo lo storage:

/etc/init.d/nfs-common restart
mount /srv/cloud

Sul cloud controller, infine, spostiamo tutti i file si OpenNebula dalla directory temporanea allo storage sul server:

mv /srv/cloud.old/* /srv/cloud
rmdir /srv/cloud.old

A questo punto OpenNebula si comperterebbe esattamente come nella precedente installazione, però userà lo storage NFS invece del filesystem locale sul cloud controller. Vediamo ora come modificare il setup di default per utilizzare le possibilità offerte da ZFS… e qui il gioco si fa davvero duro!

Innanzi tutto, sullo storage OpenSolaris lanciamo il seguente comando per consentire all’utente oneadmin di gestire gli snapshot con ZFS:

pfexec zfs allow oneadmin clone,create,mount,share,sharenfs rpool/export/home/cloud

Creiamo quindi uno storage ZFS all’interno del quale sposteremo i file relativi alla VM creati nel precedente articolo:

pfexec zfs create rpool/export/home/cloud/images/lenny
pfexec mv /srv/cloud/images/debian/* /srv/cloud/images/lenny
pfexec rmdir /srv/cloud/images/debian

Condizione essenziale per il funzionamento dello script è che il file dell’immagine del disco si chiami disk.0.
A questo punto creiamo un “golden snapshot” della nostra immagine, che sarà clonata per tutte le istanze delle macchine virtuali che andremo ad allocare ai nostri utenti:

pfexec zfs snapshot rpool/export/home/cloud/images/S10U8@gold

Ultima cosa da fare è verificare che i nodi possano accedere in ssh anche allo storage come user “oneadmin” senza usare la password. Bisogna prima aver aggiunto la riga corrispondente nel file /srv/cloud/one/.ssh/authorized_keys

ssh 172.16.0.250 echo > /dev/null && echo success

Ora bisognerà sostituire sul cloud controller gli script per clonare una VM e per cancellare una VM con questi… ed il gioco è fatto!

Testiamo il Cloud OpenNebula

Articoli Blog, OpenNebula No Responses »

apr 092011

Nel precedente articolo abbiamo realizzato il setup di un cloud con un contrloller OpenNebula e due nodi di calcolo XEN. Bene, in questo articolo andremo a creare la nostra prima VM e utilizzeremo i potenti comandi shell per controllare il cloud.
Innanzi tutto, la scelta di utilizzare XEN come Hypervisor, ci consente di utilizzare sia le numerose VM già “preconfezionate” oppure è possibile utilizzare gli “xen-tools” per crearci delle VM. In questo articolo useremo proprio questo secondo approccio.
Innanzi tutto, su uno dei due nodi di calcolo installiamo gli xen-tools con:

apt-get install xen-tools

Il file /etc/xen-tools/xen-tools.conf contiene la configurazione di xen tools, potete modificarla a vostro piacimento.
A questo punto creiamo la nostra prima macchina virtuale:

xen-create-image --hostname=debian \
  --ip=172.16.0.200 \
  --dir=/home/xen \
  --dist=lenny

con questo comando verrà creato un file di configurazione di all’interno di /etc/xen/debian.cfg e una directory chiamata “debian” all’interno di /home/xen con all’interno i file delle immagini della VM.
A questo punto testiamo il funzionamento dell’immagine usando direttamente XEN:

xm create /etc/xen/debian.cfg
xm console debian
--- per uscire premere CTRL-]
ping 172.16.0.200
xm delete debian

Ora che siamo certi del funzionamento della nostra VM e dell’Hypervisor, trasportiamo la VM all’interno della struttura di OpenNebula.
Spostiamo i file della VM all’interno dello storage NFS del cloud controller:

mv /home/xen/debian /srv/cloud/images
mv /srv/cloud/images/debian/disk.img /srv/cloud/images/debian/disk.0
chown -R oneadmin:cloud /srv/cloud/images/debian

Ora creiamo il file di configurazione dell’immagine di opennebula:

/srv/cloud/images/debian/debian.one
NAME   = debian
CPU    = 0.1
MEMORY = 128

OS = [ bootloader = /usr/lib/xen-default/bin/pygrub,
       root = sda2
 ]

RAW = [ type ="xen",
       data = "root = '/dev/sda2 ro'" ]

DISK   = [
  source   = "/srv/cloud/images/lenny/disk.0",
  target   = "sda2",
  readonly = "no",
  clone = "no",
  driver = "file:" ]

NIC    = [ IP = "172.16.0.200",
	   MAC = "00:16:3E:5C:12:AC" ]

FEATURES=[ acpi="no" ]

Ora andiamo ad operare sul cloud controller per creare le istanze delle VM e gestirle. Il funzionamento di OpenNebula è lineare: l’immagine appena creata è la “golden image”, cioè una immagine base in sola lettura che servirà da base per le immagini delle VM istanziate. Alla creazione di una nuova istanza, la golden image verrà duplicata in modo che ci sia un disco riservato per ogni istanza.

Con il comando seguente creeremo una nuova istanza della VM. La directory /srv/cloud/images/debian sarà duplicata all’interno di /srv/cloud/one/var/xxx, dove xxx è un valore progressivo che identifica l’istanza;

onevm create /srv/cloud/images/debian/debian.one

Con il seguente comando andremo a vedere quali VM sono istanziate e in quale stato sono;

onevm list

mentre con il seguente andemo a vedere i dettagli della VM:

onevm show [id]

Per cancellare una istanza usiamo:

onevm delete [id]

I comandi per avviare e spegnere una VM sono

onevm deploy [id] [cn]
onevm shutdown [id]

Per migrare una istanza su un diverso nodo di calcolo, infine,

onevm livemigrate [id] [cn]

Come ultima nota, se non vi piace lavorare con la shell, nel precedente articolo abbiamo installato anche una interfaccia web di gestione raggiungibile all’indirizzo:


http://172.16.0.1:4567

Older Entries