P2V (Xen)

Virtualizzare una macchina Linux fisica sotto Xen potrebbe non essere semplice e immediato. Vediamo come fare in pochi semplici passi:

1. creare (ovviamente) la macchina virtuale Xen e avviarla in rescue mode come spiegato in precedenza;
2. partizionare i dischi (fdisk /dev/xvda) usando eventualmente LVM (se si usano i CD di Red Hat in rescue mode occorre anteporre "lvm" ad ogni comando: lvm pvcreate, lvm vgcreate, lvm lvcreate);
3. creare i filesystem su tutti i device che lo necessitano (mkfs.ext3 /dev/xvda1, mkswap /dev/rootvg/swapvol);
4. creare una apposita directory e montarci il filesystem di root (mount /dev/rootvg/rootvol /mnt/sysimage);
5. creare sotto il filesystem di root le directory necessarie agli altri mountpoint (boot, home, initrd, opt, proc, selinux, sys, tmp, usr, var);
6. montare tutti gli altri filesystem;
7. sincronizzare la macchina fisica con la macchina virtuale usando netcat:
   eseguire sulla macchina virtuale
   
   

   nc -l -p 8888 | tar -xvC /mnt/sysimage

   eseguire sulla macchina fisica:
   
   

   tar -cf - / --exclude=/dev --exclude=/initrd --exclude=lost+found --exclude=/proc | nc ipvm 8888

8. montare /proc (mount /proc /mnt/sysimage/proc -o bind) ed entrare nella nuova macchina (chroot /mnt/sysimage)
9. configurare i driver scsi:
   
   

   # /etc/modprobe.conf
   alias eth0 xennet
   alias scsi_hostadapter xenblk

10. creiamo i device necessari al boot (da Red Hat 4 è sufficiente solo il riferimento al filesystem di root):
    
    

    mkdir -p /dev/mapper /dev/rootvg
    chmod 755 /dev/mapper
    chmod 700 /dev/rootvg/
    mknod -m 700 /dev/mapper/control c 10 63
    mknod -m 660 /dev/mapper/rootvg-rootvol b 253 0
    ln -s /dev/mapper/rootvg-rootvol /dev/rootvg/rootvol

11. Installiamo kernel per Xen e rimuoviamo i kernel non necessari:
    
    

    yum -y install kernel-xenU
    rpm -e kernel-2.6.9-55.EL

12. Controlliamo che pyGrub sia stato aggiornato correttamente:
    
    

    [...]
    title Red Hat Enterprise Linux AS (2.6.9-89.0.9.ELxenU)
    root (hd0,0)
    kernel /vmlinuz-2.6.9-89.0.9.ELxenU ro root=/dev/rootvg/rootvol console=ttyS0
    initrd /initrd-2.6.9-89.0.9.ELxenU.img

    In particolare controlliamo che il device di root sia corretto.
    
13. configuriamo /etc/inittab in modo da avere una console seriale disponibile:
    
    

    # Run gettys in standard runlevels
    co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

14. possiamo riavviare il sistema virtuale ed eseguire un'ultima sincronizzazione da quella fisica (fermando eventualmente i servizi che hanno file aperti):
    
    

    rsync -avz -e ssh --exclude /dev --exclude /var --exclude /otherfs --stats physical::/ /

    Il comando è solo un esempio e va ovviamente adattato allo specifico caso.
    

Ci possono essere diversi problemi nella fase del primo boot della macchina virtuale; la maggior parte dei problemi dipende dal fatto che il sistema non riesce a montare il filesystem di root e quind eseguire chroot su di esso. Il problema principale è che spesso l'errore a video non riesce a dare una chiara indicazione di cosa non va:

Kernel panic - not syncyng: VFS: Unable to mount root fs on unknown-block(0,0)

Oppure per esempio:

Mounting root filesystem
mount: error 6 mounting ext3
mount: error 2 mounting none
Switching to new root
switchroot: mount failed: 22
umount /initrd/dev failed: 2
Kernel panic - not syncing: Attempted to kill init!

Brevemente il processo di boot si articola nelle seguenti fasi:

• viene caricato il kernel (specificato o dalla configurazione della virtual machine o dalla configurazione di pyGrub);
• viene montato il filesystem initrd (specificato sempre o dalla configurazione della virtual machine o dalla configurazione di pyGrub)
• se initrd viene montato correttamente (generalmente questo accade sempre a meno che non sia corrotto), viene cercato il device di root (specificato ancora o dalla configurazione della virtual machine o dalla configurazione di pyGrub);
• il device di root (presente in /dev) viene usato per montare il filesystem di root (è importante che il modulo per il filesystem sia compilato nel kernel o installato nell'initrd (solitamente viene fatto in automatico);
• vengono scambiati i filesystem di root (appena montato) e quello di initrd, quindi viene effettuato un chroot sul filesystem di root;
• viene avviata la normale procedura di init.

In caso di problemi controllare che:

• /etc/modprobe.conf contenga i driver corretti, e in particolare xenblk e xennet;
• /boot/grub/menu.lst abbia configurato il corretto device di root (nel mio caso solitamente è root=/dev/rootvg/rootvol);
• /dev abbia i device di necessari al boot (nel mio caso sono: /dev/mapper/control, /dev/mapper/rootvg/rootvol, /dev/rootvg/rootvol);

Se è tutto corretto probabilmente l'installazione del kernel non è stata completata correttamente, e quindi initrd è probabilmente corrotto o non correttamente configurato:

• cancellare e rigenerare initrd:
  
  

  /sbin/mkinitrd /boot/initrd-2.6.9-89.0.9.ELxenU.img 2.6.9-89.0.9.ELxenU

• al limite cancellare e reinstallare il kernel:
  
  

  rpm --justdb --nodeps -e kernel-xenU-2.6.9-89.0.9.ELl
  yum install kernel-xenU kernel-xenU-devel