Un sistema operativo già installato come xen domU

Questa guida è scritta per mostrare come adoperare l’installazione di un sistema operativo non virtualizzato come base per un domU di Xen.
Se si dispone di un sistema operativo esistente già installato con incluso il supporto per Xen, è possibile effettuare la sua installazione in un domU. Tuttavia, ci sono alcune cose da conoscere per utilizzarlo correttamente.

Si potrebbe pensare che, poiché, l’attuale installazione sul disco funziona non sono necessarie modifiche. Invece non appena si mette il sistema operativo esistente in un domU non funziona e il file di log di Xen riporta degli avvertimenti; ciò è connesso al file di configurazione interno al domU. Dunque è necessario modificare l’installazione del sistema da trasferire per usare alcune risorse che generano problemi.

Una variazione importante da fare si trova nel file /etc/fstab (questo file indica al kernel come mappare le partizioni del disco rigido con le directory nel file system). Per facilitarne la lettura, è stato rimossa l’opzione error = remount-ro per la partizione /dev/hda1, così le opzioni per i file system ntfs per comodità non sono state riportate in tutto l’articolo.

# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 defaults 0 1
/dev/hda4 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660user,noauto 0 0

Si noti che il file /etc/fstab si riferisce a ciò che veramente è sul disco o sui dischi locali, compresa la partizione di root /dev/hda1, e la partizione di swap /dev/hda2. In un sistema Xen, il Domain0 è tipicamente configurato per l’utilizzo esclusivo di queste risorse fisiche. Anche alle virtual machine può essere concesso di accedere a talune partizioni sullo stesso disco. Ma non è sicuro permettere a più domU di accedere allo stesso dispositivo a blocchi (ovvero la stessa partizione) a meno che non sia in sola lettura. Se due VM vogliono scrivere sullo stesso dispositivo a blocchi si può verificare una race condition, la quale può portare ad una corruzione dei metadati del file system.

Xend, effettivamente, impedisce il mount di un blocco del dispositivo in lettura-scrittura su più di una virtual machine. Anche se esistono modi di ignorare tale imposizione, però è sconsigliato. Il modo migliore per condividere un dispositivo a blocchi è usare una rete con un server di file (come NFS) oppure un file system cluster (come ad esempio Global File System [GFS]) o Oracle cluster file system [ocfs2]).

Quindi, è opportuno modificare il file /etc/fstab nell’installazione esistente in modo associare al punto di innesto corretto i dispositivi (reali o virtuali che siano) che verranno esplicitamente esportati dal Domain0 al domU. Insomma la virtual machine avrà accesso solo ai dispositivi giustamente adoperati.

# <file system> <mount point> <type> <options> <dump> <pass>
Proc /proc proc defaults 0 0
/dev/hda5 / ext3 defaults 0 1
/dev/hda1 /media/hda1 ntfs defaults,* 0 1
/dev/hda3 /media/hda3 ext3 defaults 0 2
/dev/hda2 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0

Per questo esempio, vogliamo che la partizione /dev/hda5 diventi la partizione di root “/” per la macchina virtuale mentre /dev/hda4 sarà la partizione di root “/” per Domain0. Di default, crederà di essere il nuovo sistema di base e, senza intervento, tenterà di montare partizione di root del Domain0 (/dev/hda3) in /media/hda3 all’avvio della macchina virtuale. Per sicurezza, non si vuole montare nel domU ogni partizione già montata dal Domain0, in particolare la sua partizione di root. Allo stesso modo, qualsiasi partizione montata nella virtual machine non deve essere montata in Domain0 mentre è in esecuzione (è possibile solo se è montata in sola lettura). L’unica eccezione a questa regola è che a volte le partizioni delle virtual machine sono montati temporaneamente in modalità scrittura sul Domain0 per apportare modifiche, come quello che stiamo facendo a /etc/fstab. Tuttavia mai mentre il domU è in esecuzione.
Fondamentale è commentare o rimuovere la riga di riferimento per il file system root (/dev/hda3) del domain0. Allo stesso modo il file di configurazione del domU ha bisogno di essere modificato per poter esportare la partizione necessaria alla virtual machine. Notare che il simbolo # rappresenta un commento che viene ignorato dal kernel.

# <file system> <mount point> <type> <options> <dump> <pass>
Proc /proc proc defaults 0 0
/dev/hda5 / ext3 defaults 0 1
#/dev/hda1 /media/hda1 ntfs defaults,* 0 1
#/dev/hda3 /media/hda3 ext3 defaults 0 2
/dev/hda2 none swap sw 0 0
#/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0

Un altro dettaglio di cui curarsi è la copia di moduli del kernel che sono compatibili con il kernel del Domain0 nel domU. Questo non sarà più un problema, dato che è stato aggiunto a partire dal kernel Linux 2.6.23 il supporto di paravirt_ops.
Le API paravirt_ops sono frutto della standardizzazione delle funzioni per la virtualizzazione contenuti nel kernel Linux, hanno lo scopo di favorire e facilitare lo sviluppo di soluzioni per la virtualizzazione compatibili. Con queste API un kernel dovrebbe essere in grado di funzionare nativamente sia come domU sia come virtual machine VMI.
Tuttavia, se queste funzionalità nel kernel della macchina virtuale non sono supportate, c’è bisogno di fare il boot con un kernel esterno. In questo caso, si dovrebbe aggiungere nei corrispondenti moduli del kernel. La prima cosa, quando si copiano i moduli del kernel, da fare è una directory temporanea (con mkdir) per montare la partizione della virtual machine, poi si monta la partizione (in mnt), dopo copiare i moduli (con cp) e, infine, smontare la partizione con umount.

[root@dom0]# mkdir /mnt/VMpartition
[root@dom0]# mount /dev/hda5 /mnt/VMpartition
[root@dom0]# cp -r /lib/modules/`uname -r` \
/mnt/VMpartition/lib/modules/
[root@dom0]# umount /mnt/VMpartition

(uname -r mostra il nome del kernel in uso sul sistema)
Ora è necessario un file di configurazione per la VM che conceda l’accesso alla partizione. Indichiamo il percorso del kernel e ramdisk per il domU presenti sul Domain0. Impostiamo il file system di root che la macchina virtuale si aspetta, /dev/hda5, così come lo spazio di swap che si aspetta, /dev/hda2. C’è da assicurarsi di non utilizzare lo stesso spazio di swap sia per l’domU e sia per il Domain0.

kernel = “/boot/vmlinuz-2.6.16-xen”

ramdisk = “/boot/initrd-2.6.16.33-xen”

name = “systemdomU”

memory = 256

vif = [ ” ]

dhcp = “dhcp”

disk = [‘phy:hda5,hda5,w’,hda2,hda2,w’]

root = “/dev/hda5 ro”

Infine, è possibile lanciare xm create per avviare la macchina virtuale appena preparata utilizzando il sistema operativo modificato.

[root@dom0]# xm create -c systemdomU

È ora possibile utilizzare la VM in modo simile a come la si sarebbe adoperata se si trattasse di un’installazione fisica esistente, accettando i limiti di essere una virtual machine per Xen.