Fedora 12

Virtualization Guide

La guida definitiva per la virtualizzazione su Fedora

Edizione 1

Logo

Christoph Curran

Nota Legale

Copyright © 2009 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
All other trademarks are the property of their respective owners.
Sommario
La Fedora 12 Virtualization Guide contiene le informazioni relative all'installazione, configurazione, amministrazione, i consigli e le tecnologie per il troubleshooting della virtualizzazione usati con Fedora 12.
Prefazione
1. Informazioni su questo libro
2. Convenzioni del documento
2.1. Convenzioni tipografiche
2.2. Convenzioni del documento
2.3. Note ed avvertimenti
3. Inviateci i vostri commenti!
I. Installation
1. Installazione dei pacchetti di virtualizzazione
1.1. Installazione di KVM con una nuova installazione di Fedora
1.2. Installazione dei pacchetti KVM su di un sistema Fedora esistente
2. Panoramica installazione del guest virtualizzato
2.1. Creazione di un guest con virt-install
2.2. Creazione di un guest con virt-manager
2.3. Installazione dei guest con PXE
3. Procedure per l'installazione del sistema operativo guest
3.1. Installazione di Red Hat Enterprise Linux 5 come guest para-virtualizzato
3.2. Installazione di Red Hat Enterprise Linux 5 come guest completamente virtualizzato
3.3. Installazione di Windows XP come guest completamente virtualizzato
3.4. Installazione di Windows Server 2003 come guest completamente virtualizzato
3.5. Installazione di Windows Server 2008 come guest completamente virtualizzato
II. Configuration
4. Dispositivi a blocchi virtualizzati
4.1. Creazione di un controllore del dischetto floppy virtualizzato
4.2. Come aggiungere dispositivi di storage sui guest
4.3. Configurazione memoria persistente
4.4. Aggiungere un dispositivo DVD o CD-ROM virtualizzato ad un guest
5. Storge condiviso e virtualizzazione
5.1. Utilizzo di iSCSI per l'archiviazione dei guest
5.2. Utilizzo di NFS per l'archiviazione dei guest
5.3. Utilizzo di GFS2 per l'archiviazione dei guest
6. Pratiche consigliate per il server
7. Sicurezza per la virtualizzazione
7.1. SELinux e virtualizzazione
7.2. Considerazioni su SELinux
8. Configurazione di rete
8.1. Network address translation (NAT) con libvirt
8.2. Bridged networking con libvirt
9. Driver para-virtualizzati KVM
9.1. Installazione dei driver paravirtualizzati Windows di KVM
III. Administration
10. Gestione dei guest utilizzando xend
11. Gestione dell'ora del guest KVM
12. Migrazione Live KVM
12.1. Requisiti per una migrazione live
12.2. Esempio di storage condiviso: NFS per una semplice migrazione
12.3. Migrazione KVM live con virsh
12.4. Migrazione con virt-manager
13. Gestione remota dei guest virtualizzati
13.1. Gestione remota con SSH
13.2. Gestione remota attraverso TLS e SSL
13.3. Modalità di trasporto
IV. Virtualization Reference Guide
14. Strumenti per la virtualizzazione
15. Gestione dei guest con virsh
16. Gestione dei guest con Virtual Machine Manager (virt-manager)
16.1. La finestra apri collegamento
16.2. Finestra principale del Virtual Machine Manager
16.3. Finestra delle informazioni del Virtual Machine Manager
16.4. Console grafica della macchina virtuale
16.5. Starting virt-manager
16.6. Ripristino di una macchina salvata
16.7. Visualizzazione delle informazioni sul guest
16.8. Monitoraggio dello stato
16.9. Visualizzazione degli identificatori del guest
16.10. Visualizzazione dello stato del guest
16.11. Visualizzazione delle CPU virtuali
16.12. Visualizzazione utilizzo della CPU
16.13. Visualizzazione utilizzo della memoria
16.14. Gestione di una rete virtuale
16.15. Creazione di una rete virtuale
V. Tips and Tricks
17. Suggerimenti e trucchi
17.1. Avvio automatico dei guest
17.2. Come smistarsi tra l'hypervisor KVM e Xen
17.2.1. Da Xen a KVM
17.2.2. Da KVM a Xen
17.3. Utilizzo di qemu-img
17.4. Processo di overcommit con KVM
17.5. Modifica di /etc/grub.conf
17.6. Verifica delle estensioni per la virtualizzazione
17.7. Identificare il tipo di guest e l'implementazione
17.8. Come generare un nuovo indirizzo MAC unico
17.9. Very Secure ftpd
17.10. Come configurare la persistenza LUN
17.11. Come disabilitare lo SMART disk monitoring per i guest
17.12. Come clonare i file di configurazione del guest
17.13. Duplicazione di un guest esistente e dei suoi file di configurazione
18. Creazione script libvirt personalizzati
18.1. Come utilizzare i file di configurazione XML con virsh
VI. Troubleshooting
19. Troubleshooting
19.1. Errori del dispositivo loop
19.2. Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS
A. Risorse aggiuntive
A.1. Risorse online
A.2. Documentazione installata
B. Cronologia
C. Colophon
Glossario

Prefazione

Questa guida è la Fedora 12 Virtualization Guide. Essa contiene le informazioni necessarie per l'utilizzo e la gestione della virtualizzazione su Fedora 12.

1. Informazioni su questo libro

Questo libro è diviso in 7 sezioni:
  • Requisiti del sistema
  • Installation
  • Configuration
  • Administration
  • Riferimenti
  • Tips and Tricks
  • Troubleshooting

2. Convenzioni del documento

Questo manuale utilizza numerose convenzioni per evidenziare parole e frasi, ponendo attenzione su informazioni specifiche.
Nelle edizioni PDF e cartacea questo manuale utilizza caratteri presenti nel set Font Liberation. Il set Font Liberation viene anche utilizzato nelle edizioni HTML se il set stesso è stato installato sul vostro sistema. In caso contrario, verranno mostrati caratteri alternativi ma equivalenti. Da notare: Red Hat Enterprise Linux 5 e versioni più recenti, includono per default il set Font Liberation.

2.1. Convenzioni tipografiche

Vengono utilizzate quattro convenzioni tipografiche per richiamare l'attenzione su parole e frasi specifiche. Queste convenzioni, e le circostanze alle quali vengono applicate, sono le seguenti.
Neretto monospazio
Usato per evidenziare l'input del sistema, incluso i comandi della shell, i nomi dei file ed i percorsi. Utilizzato anche per evidenziare tasti singoli e combinazione di tasti. Per esempio:
To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a key cap, all presented in Mono-spaced Bold and all distinguishable thanks to context.
Key-combinations can be distinguished from key caps by the hyphen connecting each part of a key-combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F1 to switch to the first virtual terminal. Press Ctrl+Alt+F7 to return to your X-Windows session.
The first sentence highlights the particular key cap to press. The second highlights two sets of three key caps, each set pressed simultaneously.
If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in Mono-spaced Bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialogue box text; labelled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
Choose System > Preferences > Mouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
To insert a special character into a gedit file, choose Applications > Accessories > Character Map from the main menu bar. Next, choose Search > Find… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose Edit > Paste from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in Proportional Bold and all distinguishable by context.
Note the > shorthand used to indicate traversal through a menu and its sub-menus. This is to avoid the difficult-to-follow 'Select Mouse from the Preferences sub-menu in the System menu of the main menu bar' approach.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether Mono-spaced Bold or Proportional Bold, the addition of Italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
When the Apache HTTP Server accepts requests, it dispatches child processes or threads to handle them. This group of child processes or threads is known as a server-pool. Under Apache HTTP Server 2.0, the responsibility for creating and maintaining these server-pools has been abstracted to a group of modules called Multi-Processing Modules (MPMs). Unlike other modules, only one module from the MPM group can be loaded by the Apache HTTP Server.

2.2. Convenzioni del documento

Due tipi di dati, comunemente con più righe, vengono evidenziati rispetto al testo circostante.
L'output inviato ad un terminale è impostato su Tondo monospazio e così presentato: 
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Gli elenchi del codice sorgente sono impostati in Mono-spaced Roman ma vengono presentati ed evidenziati nel modo seguente: 
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
   
}

2.3. Note ed avvertimenti

E per finire, tre stili vengono usati per richiamare l'attenzione su informazioni che in caso contrario potrebbero essere ignorate.

Nota Bene

Una nota è un suggerimento o un approccio alternativo per il compito da svolgere. Non dovrebbe verificarsi alcuna conseguenza negativa se la nota viene ignorata, ma al tempo stesso potreste non usufruire di qualche trucco in grado di facilitarvi il compito.

Importante

Caselle importanti riportano informazioni che potrebbero passare facilmente inosservate: modifiche alla configurazione applicabili solo alla sessione corrente, o servizi i quali necessitano di un riavvio prima di applicare un aggiornamento. Ignorare queste caselle non causa alcuna perdita di dati, ma potrebbe causare irritazione e frustrazione da parte dell'utente.

Avvertenza

Un avvertimento non dovrebbe essere ignorato. Se ignorato, potrebbe verificarsi una perdita di dati.

3. Inviateci i vostri commenti!

Se individuate degli errori di battitura in questo manuale, o se pensate di poter contribuire al suo miglioramento, contattateci subito! Inviate i vostri suggerimenti tramite Bugzilla: http://bugzilla.redhat.com/bugzilla/ sul componente Fedora Documentation.
Quando inviate un bug report, assicuratevi di indicare l'identificatore del manuale: Virtualization_Guide
Se inviate un suggerimento per contribuire al miglioramento della guida, cercate di essere il più specifici possibile. Se avete individuato un errore, indicate il numero della sezione e alcune righe di testo, in modo da agevolare la ricerca dell'errore.

Parte I. Installation

Argomenti relativi alla virtualizzazione

Questi capitoli descrivono le fasi necessarie per l'impostazione di un host e l'installazione di guest virtualizzati con Fedora. È consigliato leggere attentamente i suddetti capitoli per poter eseguire una installazione corretta di sistemi operativi del guest virtualizzato.

Indice

1. Installazione dei pacchetti di virtualizzazione
1.1. Installazione di KVM con una nuova installazione di Fedora
1.2. Installazione dei pacchetti KVM su di un sistema Fedora esistente
2. Panoramica installazione del guest virtualizzato
2.1. Creazione di un guest con virt-install
2.2. Creazione di un guest con virt-manager
2.3. Installazione dei guest con PXE
3. Procedure per l'installazione del sistema operativo guest
3.1. Installazione di Red Hat Enterprise Linux 5 come guest para-virtualizzato
3.2. Installazione di Red Hat Enterprise Linux 5 come guest completamente virtualizzato
3.3. Installazione di Windows XP come guest completamente virtualizzato
3.4. Installazione di Windows Server 2003 come guest completamente virtualizzato
3.5. Installazione di Windows Server 2008 come guest completamente virtualizzato

Capitolo 1. Installazione dei pacchetti di virtualizzazione

1.1. Installazione di KVM con una nuova installazione di Fedora
1.2. Installazione dei pacchetti KVM su di un sistema Fedora esistente

1.1. Installazione di KVM con una nuova installazione di Fedora

Questa sezione affronta le fasi attraverso le quali è possibile installare gli strumenti di virtualizzazione ed il pacchetto KVM come parte di una nuova installazione Fedora 12.

Hai bisogno di assistenza durante l'installazione?

La Fedora 12 Installation Guide (disponibile su http://docs.fedoraproject.org) riporta le informazioni dettagliate sull'installazione di Fedora 12.
  1. Iniziare una installazione interattiva di Fedora da un DVD, CD-ROM o PXE d'installazione di Fedora 12.
  2. Completare le altre fasi fino a quella relativa alla selezione del pacchetto.
    Selezionare il gruppo dei pacchetti per la Virtualizzazione e fare clic sul pulsante Personalizza ora.
  3. Selezionare il gruppo di pacchetti KVM. Deselezionare il gruppo di pacchetti Virtualizzazione. Così facendo verrà selezionato l'hypervisor KVM, virt-manager, libvirt e virt-viewer per l'installazione.

  4. Personalizzare i pacchetti (se necessario)

    Personalizzare il gruppo Virtualizzazione se sono necessari altri pacchetti per la virtualizzazione.
    Premere Chiudi seguito da Successivo per continuare l'installazione.
Installazione dei pacchetti KVM con i file kickstart
Questa sezione descrive il metodo attraverso il quale usare i file kickstart per installare Fedora con i pacchetti per l'hypervisor KVM. I file kickstart permettono installazioni automatizzate senza che l'utente installi manualmente ogni sistema. Le fasi presenti in questa sezione vi aiuteranno a creare ed utilizzare un file kickstart per l'installazione di Fedora con i pacchetti di virtualizzazione.
Nella sezione %packages del file kickstart aggiungere il seguente gruppo di pacchetti: 
%packages
@kvm
Maggiori informazioni sui file kickstart sono disponibili sul sito web del Fedora Project, http://docs.fedoraproject.org, nella Fedora 12 Installation Guide.

1.2. Installazione dei pacchetti KVM su di un sistema Fedora esistente

Questa sezione descrive le fasi necessarie per l'installazione dell'hypervisor KVM su di un Fedora 12 o versione più recente.
Installazione dell'hypervisor KVM con yum
Per usare la virtualizzazione su Fedora è necessario il pacchetto kvm. Il pacchetto kvm contiene il modulo del kernel KVM il quale fornisce l'hypervisor KVM sul kernel di Linux predefinito.
Per installare il pacchetto kvm eseguire: 
# yum install kvm
Ora installare i pacchetti aggiuntivi di gestione della virtualizzazione.
Installazione di altri pacchetti consigliati per la virtualizzazione: 
# yum install virt-manager libvirt libvirt-python python-virtinst

Capitolo 2. Panoramica installazione del guest virtualizzato

2.1. Creazione di un guest con virt-install
2.2. Creazione di un guest con virt-manager
2.3. Installazione dei guest con PXE
Dopo aver installato i pacchetti per la virtualizzazione sul sistema host sarà possibile creare i sistemi operativi guest. Questo capitolo descrive i processi generali per l'installazione dei sistemi operativi guest sulle macchine virtuali. Sarà possibile creare guest utilizzando il pulsante Nuovo in virt-manager, o usare l'interfaccia della linea di comando virt-install. Entrambi i metodi sono presenti all'interno di questo capitolo.
Informazioni dettagliate relative all'installazione sono disponibili per le versioni specifiche di Fedora, altre distribuzioni Linux, Solaris e Windows. Consultare il Capitolo 3, Procedure per l'installazione del sistema operativo guest per maggiori informazioni.

2.1. Creazione di un guest con virt-install

È possibile utilizzare virt-installper la creazione di guest virtualizzati dalla linea di comando. virt-install può essere usato in modo interattivo o in uno script in modo da automatizzare la creazione di macchine virtuali. Utilizzando virt-install con file kickstart, sarà possibile eseguire una installazione delle macchine virtuali senza alcun intervento dell'utente.
Lo strumento virt-install fornisce un numero di opzioni passabili sulla linea di comando. Per visualizzare un elenco completo di opzioni: 
$ virt-install --help
La pagina man di virt-install documenta ogni opzione del comando e le variabili importanti.
qemu-img è un comando che può essere usato prima di virt-install per configurare le opzioni di storage.
Una opzione importante è --vnc la quale è in grado di aprire una finestra grafica per l'installazione del guest.
All'interno di questo esempio viene creato un guest Red Hat Enterprise Linux 3, rhel3support, da un CD-ROM con networking virtuale e con una immagine del dispositivo a blocchi basato sul file di 5GB. In questo esempio viene usato un hypervisor KVM. 
# virt-install --accelerate --hvm --connect qemu:///system \
        --network network:default \
        --name rhel3support --ram=756\
        --file=/var/lib/libvirt/images/rhel3support.img \
        --file-size=6 --vnc --cdrom=/dev/sr0
Esempio 2.1. Utilizzo di virt-install con KVM per la creazione di un guest Red Hat Enterprise Linux 3

# virt-install --name Fedora11 --ram 512 --file=/var/lib/libvirt/images/Fedora11.img \
        --file-size=3 --vnc --cdrom=/var/lib/libvirt/images/Fedora11.iso
Esempio 2.2. Come usare virt-install per creare un guest di Fedora 11

2.2. Creazione di un guest con virt-manager

virt-manager conosciuto come Virtual Machine Manager, è uno strumento grafico per la creazione e la gestione dei guest virtualizzati.
Procedura 2.1. Creazione di un guest virtualizzato con virt-manager
  1. Per avviare virt-manager eseguire quanto riportato di seguito come utente root: 
    # virt-manager &
    Il comando virt-manager apre una nuova interfaccia utente grafica. Diverse funzioni non sono disponibili agli utenti senza privilegi root o senza aver configurato sudo, incluso il pulsante Nuovo, senza di essi non sarà possibile creare un nuovo guest virtuale.
  2. Aprire la finestra File -> Apri collegamento. A questo punto verrà visualizzata la finestra di dialogo. Selezionare un hypervisor e successivamente fare clic su Collega.
  3. La finestra principale di virt-manager permetterà di creare una nuova macchina virtuale. Selezionare Nuovo per creare un nuovo guest. Tale operazione aprirà il wizard mostrato nella schermata:
  4. La finestra Crea un nuovo sistema virtuale fornisce un sommario delle informazioni necessarie per la creazione di una macchina virtuale:
    Controllare le informazioni relative all'installazione e successivamente fare clic su Avanti.
  5. Verrà visualizzata la finestra Selezione metodo di virtualizzazione. Scegliere tra Paravirtualizzato o Completamente virtualizzato.
    Full virtualization richiede un sistema con processori Intel® VT o AMD-V. Se le estensioni di virtualizzazione non sono presenti i pulsanti di selezione completamente virtualizzato o Abilita accelerazione kernel/hardware non potranno essere selezionati. L'opzione Paravirtualizzato non potrà essere selezionata se kernel-xen non è il kernel attualmente in esecuzione.
    Se si è collegati ad un hypervisor KVM sarà disponibile solo full virtualization.
    Selezionare il tipo di virtualizzazione e successivamente fare clic su Successivo.
  6. Il prompt Localizzazione dispositivo di installazione richiederà il dispositivo di installazione per il tipo di installazione selezionato. Questa schermata dipende dalle scelte fatte nella fase precedente.
    1. L'installazione paravirtualizzata ha bisogno di un albero di installazione accessibile usando uno dei seguenti protocolli di rete: HTTP, FTP o NFS. L'URL del dispositivo d'installazione deve contenere un albero d'installazione di Fedora. Il suddetto albero viene ospitato usando NFS, FTP o HTTP. I file ed i servizi di rete possono essere ospitati usando i servizi di rete sull'host o un altro mirror.
      Usando una immagine DVD o CD-ROM (etichettata come file .iso), montare l'immagine CD-ROM e posizionare i file montati con uno dei protocolli indicati.
      In alternativa, copiare l'albero d'installazione da un mirror di Fedora.
    2. L'installazione di un guest completamente virtualizzato ha bisogno di DVD, CD-ROM o immagini avviabili di DVD o CD-ROM avviabili localmente (con un tipo di file .iso o .img). Le installazioni Windows utilizzano file .iso o DVD e CD-ROM. Numerosi sistemi operativi Linux o unix utilizzano un file .iso per l'installazione di un sistema di base prima di terminare l'installazione con un albero basato sulla rete.
    Dopo aver selezionato il dispositivo d'installazione locale fare clic sul pulsante Avanti.
  7. The Assigning storage space window displays. Choose a disk partition, LUN or create a file based image for the guest storage.
    La convenzione per le immagini basate su file in Fedora riporta che tutte le immagini guest basate su file sono archiviate nella cartella /var/lib/xen/images/. Altre posizioni della cartella per le immagini basate sul file sono proibite da SELinux. Se si esegue SELinux in modalità enforcing consultare la Sezione 7.1, «SELinux e virtualizzazione» per maggiori informazioni sull'installazione dei guest.
    Your guest storage image should be larger than the size of the installation, any additional packages and applications, and the size of the guests swap file. The installation process will choose the size of the guest's swap file based on size of the RAM allocated to the guest.
    Allocate extra space if the guest needs additional space for applications or other data. For example, web servers require additional space for log files.
    Choose the appropriate size for the guest on your selected storage type and click the Forward button.

    Nota

    È consigliato utilizzare la cartella predefinita, /var/lib/xen/images/, per le immagini della macchina virtuale. Se si utilizza una posizione diversa (come ad esempio /xen/images/) assicurarsi di aggiungerla alla propria politica di SELinux e di rietichettarla prima di continuare con l'installazione (più avanti nella documentazione si trovano le informazioni su come modificare la politica di SELinux)
  8. The Allocate memory and CPU window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    I guest hanno bisogno di una memoria fisica (RAM) sufficiente per una esecuzione effettiva ed efficiente. Selezionare un valore per la memoria in grado di soddisfare i requisiti delle applicazioni e del sistema operativo guest. Numerosi sistemi operativi necessitano di almeno 512MB di RAM per funzionare correttamente. Ricordare che i guest utilizzano la RAM fisica. L'esecuzione di un numero molto elevato di guest o una memoria non sufficiente per il sistema host potrà causare un uso molto elevato della memoria virtuale. Se la memoria virtuale è molto lenta anche le prestazioni e i tempi di risposta saranno molto lenti. Assicurarsi di assegnare memoria sufficiente per tutti i guest e gli host in modo da operare correttamente.
    Assign sufficient virtual CPUs for the virtualized guest. If the guest runs a multithreaded application assign the number of virtualized CPUs it requires to run most efficiently. Do not assign more virtual CPUs than there are physical processors (or hyper-threads) available on the host system. It is possible to over allocate virtual processors, however, over allocating has a significant, negative affect on guest and host performance due to processor context switching overheads.
  9. Durante questa fase verrà presentata una schermata riassuntiva su tutte le informazioni relative alla configurazione appena inserite. Ricontrollare le informazioni ed utilizzare il pulsante Indietro per eseguire le opportune modifiche. Se si è soddisfatti dei dati inseriti fare clic sul pulsante Fine ed il processo d'installazione avrà inizio.
    A questo punto verrà visualizzata una finestra VNC la quale mostra l'avvio del processo d'installazione del sistema operativo guest.
Ciò conclude il processo generale per la creazione dei guest con virt-manager. Capitolo 3, Procedure per l'installazione del sistema operativo guest contiene le fasi da seguire per l'installazione di una varietà di sistemi operativi comuni.

2.3. Installazione dei guest con PXE

Questa sezione contiene le fasi necessarie per l'installazione dei guest con PXE. L'installazione del guest PXE necessita di un dispositivo di rete condiviso, conosciuto anche come bridge di rete. Le procedure sotto riportate sono relative alla creazione di un bridge ed il suo utilizzo.

  1. Creazione di un nuovo bridge

    1. Creare un nuovo file script di rete nella cartella /etc/sysconfig/network-scripts/. In questo esempio viene creato un file chiamato ifcfg-installation il quale crea un bridge installation 
      # cd /etc/sysconfig/network-scripts/
# vim ifcfg-installation
DEVICE=installation
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes

      Warning

      The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'. 
    2. Avvio del nuovo bridge.
# ifup installation
    3. Non sono state ancora aggiunte le interfacce al nuovo bridge. Utilizzare il comando brctl show per visualizzare le informazioni sui bridge di rete presenti sul sistema. 
      # brctl show
bridge name     bridge id               STP enabled     interfaces
installation    8000.000000000000       no
virbr0          8000.000000000000       yes
      Il bridge virbr0 è il bridge predefinito usato da libvirt per il Network Address Translation (NAT) sul dispositivo ethernet predefinito.

  2. Aggiungere una interfaccia al nuovo bridge

    Modificare il file di configurazione per l'interfaccia. Aggiungere il parametro BRIDGE al file di configurazione con il nome del bridge creato nelle fasi precedenti. 
    # Intel Corporation Gigabit Network Connection
DEVICE=eth1
BRIDGE=installation
BOOTPROTO=dhcp
HWADDR=00:13:20:F7:6E:8E
ONBOOT=yes
    Dopo aver modificato il file di configurazione riavviare il networking o eseguire il riavvio. 
    # service network restart
    Verificare che l'interfaccia sia stata collegata con il comando brctl show: 
    # brctl show
bridge name     bridge id               STP enabled     interfaces
installation    8000.001320f76e8e       no              eth1
virbr0          8000.000000000000       yes

  3. Configurazione della sicurezza

    Configure iptables to allow all traffic to be forwarded across the bridge. 
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

    Disable iptables on bridges

    Alternatively, prevent bridged traffic from being processed by iptables rules. In /etc/sysctl.conf append the following lines: 
    net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
    Reload the kernel parameters configured with sysctl 
    # sysctl -p /etc/sysctl.conf

  4. Riavviare libvirt prima dell'installazione

    Restart the libvirt daemon. 
    # service libvirtd reload
Il bridge è stato configurato, ora sarà possibile iniziare l'installazione.
Installazione PXE con virt-install
Per virt-install aggiungere il parametro d'installazione --network=bridge:BRIDGENAME dove installazione è il nome del proprio bridge. Per le installazioni PXE usare il parametro --pxe. 
# virt-install --accelerate --hvm --connect qemu:///system \
    --network=bridge:installation --pxe\
    --name EL10 --ram=756 \
    --vcpus=4
    --os-type=linux --os-variant=rhel5
    --file=/var/lib/libvirt/images/EL10.img \
Esempio 2.3. Installazione PXE con virt-install

Installazione PXE con virt-manager
Le fasi di seguito riportate variano da quelle per una installazione standard di virt-manager. Per le installazioni standard consultare il Capitolo 3, Procedure per l'installazione del sistema operativo guest.

  1. Selezione di PXE

    Selezionare PXE come metodo d'installazione.

  2. Selezione del bridge

    Selezionare Dispositivo fisico condiviso e successivamente il bridge creato nella fase precedente.

  3. Inizio dell'installazione

    L'installazione è pronta per essere iniziata.
A tal proposito verrà inviata una richiesta DHCP, e se rilevato un server PXE valido, i processi per l'installazione del guest verranno avviati.

Capitolo 3. Procedure per l'installazione del sistema operativo guest

3.1. Installazione di Red Hat Enterprise Linux 5 come guest para-virtualizzato
3.2. Installazione di Red Hat Enterprise Linux 5 come guest completamente virtualizzato
3.3. Installazione di Windows XP come guest completamente virtualizzato
3.4. Installazione di Windows Server 2003 come guest completamente virtualizzato
3.5. Installazione di Windows Server 2008 come guest completamente virtualizzato
Questo capitolo si riferisce alle fasi necessarie per l'installazione dei vari sistemi operativi guest in un ambiente virtualizzato su Fedora. Per comprendere i processi di base consultare il Capitolo 2, Panoramica installazione del guest virtualizzato.

3.1. Installazione di Red Hat Enterprise Linux 5 come guest para-virtualizzato

Questa sezione descrive come installare Red Hat Enterprise Linux 5 come guest paravirtualizzato. Para-virtualization è più veloce e presenta tutti i vantaggi di un full virtualization. Para-virtualization richiede un kernel supportato speciale, kernel-xen.

Nota importante sulla paravirtualization

Para-virtualization funziona solo con l'hypervisor Xen ma non con l'hypervisor KVM.
Prima di iniziare l'installazione assicurarsi di avere un accesso root.
Questo metodo installa Red Hat Enterprise Linux da un server remoto. Le informazioni relative all'installazione presenti in questa sezione sono simili a quelle relative all'installazione minima tramite CD-ROM live.
Creare i guest di Red Hat Enterprise Linux 5 paravirtualizzati usando virt-manager o virt-install. Per informazioni su virt-manager, consultare le procedure presenti in Sezione 2.2, «Creazione di un guest con virt-manager».
Creare un guest paravirtualizzato con lo strumento virt-install basato sulla linea di comando. L'opzione --vnc mostra l'installazione grafica. Il nome del guest all'interno dell'esempio è rhel5PV, l'immagine del disco è rhel5PV.dsk ed il mirror locale dell'albero d'installazione di Red Hat Enterprise Linux 5 è ftp://10.1.1.1/trees/CentOS5-B2-Server-i386/. Sostituire quei valori con valori accurati per il sistema e la rete. 
# virt-install -n rhel5PV -r 500 \
-f /var/lib/libvirt/images/rhel5PV.dsk -s 3 --vnc -p \
-l ftp://10.1.1.1/trees/CentOS5-B2-Server-i386/

Installazione automatizzata

Red Hat Enterprise Linux può essere installato senza l'interfaccia grafica o input manuale. Usare i file kickstart per automatizzare il processo d'installazione.
L'utilizzo di questi metodi aprirà una finestra all'interno della quale verranno visualizzate le fasi iniziali dell'avvio del proprio guest:
Quando il guest ha completato il primo avvio, avrà inizio il processo d'installazione standard di Red Hat Enterprise Linux. Per la maggior parte delle installazioni le risposte predefinite sono accettabili.
Procedura 3.1. Procedura per l'installazione del guest di Red Hat Enterprise Linux paravirtualizzato
  1. Selezionare la lingua e successivamente OK.
  2. Selezionare il tipo di tastiera e OK.
  3. Assegnare l'indirizzo di rete del guest. È possibile scegliere tra DHCP (come di seguito indicato) o inidirizzo IP statico:
  4. Se si è scelto DHCP il processo d'installazione cercherà di acquisire un indirizzo IP:
  5. Se invece si è scelto di usare un indirizzo IP statico per il proprio guest, la schermata successiva richiederà di inserire le informazioni sulla configurazione del networking del guest:
    1. Inserire un indirizzo IP valido ed assicurarsi che l'indirizzo IP inserito sia in grado di raggiungere il server con l'albero d'installazione.
    2. Inserire una maschera di rete valida, un gateway predefinito ed un indirizzo del server dei nomi.
    Selezionare la lingua e successivamente OK.
  6. Di seguito viene riportato un esempio di una configurazione di indirizzo IP statico:
  7. Il processo d'installazione ora recupera i file necessari dal server:
Una volta completate le fasi iniziali verrà avviato il processo per l'installazione grafica.
Se si stà installando una versione Beta o una distribuzione di release precedenti sarà necessario confermare l'installazione del sistema operativo. Fare clic su Installa Comunque e successivamente su OK:
Procedura 3.2. Processo d'installazione grafico
  1. Inserire un codice di registrazione valido. Se si è in possesso di una chiave di sottoscrizione RHN valida inserira nel campo Installation Number:

    Note

    Se la fase di registrazione viene saltata sarà possibile confermare le informazioni relative all'account di rete di fedora dopo l'installazione con il comando rhn_register. Il comando rhn_register richiede un accesso root. 
    # rhn_register
  2. L'installazione confermerà ora il desiderio di rimuovere i dati presenti sugli storage selezionati per l'installazione:
    Fare clic su Si per continuare.
  3. Questa schermata permetterà di ricontrollare la configurazione dello storage e la disposizione della partizione. È inoltre possibile selezionare la configurazione avanzata dello storage se si desidera usare iSCSI come storage del guest:
    Selezionare le impostazioni desiderate e successivamente fare clic su Successivo.
  4. Confermare lo storage selezionato per l'installazione.
    Fare clic su Si per continuare.
  5. Configurare le impostazioni per il networking e dell'hostname. Le informazioni verranno popolate con i dati inseriti nel processo d'installazione. Modificare le suddette impostazioni se necessario:
    Fare clic su OK per continuare.
  6. Selezionare il fuso orario appropriato per il proprio ambiente.
  7. Inserire la password di root per il guest.
    Fare clic su Successivo per continuare.
  8. Selezionare i pacchetti software da installare. A tal proposito selezionare Personalizza ora. È necessario installare il pacchetto kernel-xen nella cartella del Sistema. Il pacchetto kernel-xen è necessario per il para-virtualization.
    Fare clic su Successivo.
  9. Vengono calcolate le dipendenze ed i requisiti per lo spazio.
  10. Una volta verificato i requisiti per lo spazio e le dipendenze per l'installazione fare clic su Successivo per iniziare l'installazione.
  11. Tutti i pacchetti software selezionati verranno installati automaticamente.
  12. Una volta terminata l'installazione sarà necessario riavviare il proprio guest:
  13. Il guest appena installato non si riavvierà, al contrario si arresterà..
  14. Avviare il guest. Il nome del guest è stato scelto durante l'utilizzo di virt-install in Sezione 3.1, «Installazione di Red Hat Enterprise Linux 5 come guest para-virtualizzato». Se si utilizza l'esempio predefinito il nome è rhel5PV.
    Eseguire: 
    virsh reboot rhel5PV
    Alternativamente aprire virt-manager, selezionare il nome del guest e fare clic su Apri, successivamente selezionare Esegui.
    A questo punto verrà visualizzata una finestra VNC nella quale sono presenti i processi d'avvio del guest.
  15. L'accensione del guest avvia la schermata di configurazione First Boot. Questa schermata guiderà attraverso alcune fasi di configurazione di base per il proprio guest:
  16. Leggere ed accettare la license agreement.
    Fare clic su Avanti sulle finestre del license agreement.
  17. Configurare il firewall.
    Click Forward to continue.
    1. Se si disabilita il firewall verrà richiesto di confermare la propria scelta. Fare clic su Si per confermare e continuare.
  18. Successivamente è la volta di SELinux. È fortemente consigliato eseguire SELinux in modalità enforcing. È possibile eseguire SELinux sia in modalità permissive che completamente disabilitato.
    Click Forward to continue.
    1. Se si desidera disabilitare SELinux verrà visualizzato un messaggio d'avvertimento. Fare clic su Si per disabilitare SELinux.
  19. Se necessario abilitare kdump.
    Click Forward to continue.
  20. Confermare che l'ora e la data siano stati impostati correttamente per il guest. Se si installa un guest para-vitualizzato la data e l'ora dovrebbero essere in sincronizzazione con l'hypervisor.
    Click Forward to continue.
  21. Impostare gli aggiornamenti software. Se si è in possesso di una sottoscrizione di rete di fedora o se si desidera provarne una, utilizzare la schermata di seguito riportata per la registrazione del nuovo guest in RHN.
    Click Forward to continue.
    1. Confermare le proprie scelte per RHN.
    2. Una volta terminata l'impostazione si potrebbe visualizzare una schermata aggiuntiva se non si è scelto RHN. A questo punto non si riceveranno aggiornamenti software.
      Fare clic sul pulsante Avanti.
  22. Creare un account utente non-root. È consigliato creare un utente non-root per un utilizzo normale e per una sicurezza più elevata. Inserire il nome utente, il nome e la password.
    Fare clic sul pulsante Avanti.
  23. Se l'audio è necessario ed è stato rilevato un dispositivo audio, bisogna regolarlo. Completare il processo e fare clic su Avanti.
  24. Usare questa schermata se si desidera installare qualsiasi pacchetto software aggiuntivo da CD. È consigliato non installare alcun software durante questa fase, ma aggiugerlo più avanti usando yum. Fare clic su Fine.
  25. Il guest configurerà qualsiasi impostazione modificata dall'utente e continuerà con il processo d'avvio.
  26. Ora si è in grado di visualizzare la schermata di registrazione per il Red Hat Enterprise Linux 5. Eseguire il log in utilizando il nome utente creato nelle fasi precedenti.
  27. A questo punto l'installazione di un guest paravirtualizzato di Red Hat Enterprise Linux 5 è completata.

3.2. Installazione di Red Hat Enterprise Linux 5 come guest completamente virtualizzato

Questa sezione affronta il metodo attraverso il quale è possibile installare un guest Red Hat Enterprise Linux 5 completamente virtualizzato.
Procedura 3.3. Creazione di un guest Red Hat Enterprise Linux 5 completamente virtualizzato con virt-manager

  1. Open virt-manager

    Start virt-manager. Launch the Virtual Machine Manager application from the Applications menu and System Tools submenu. Alternatively, run the virt-manager command as root.

  2. Select the hypervisor

    Select the hypervisor. If installed, select Xen or KVM. For this example, select KVM. Note that presently KVM is named qemu.
    Se non precedentemente fatto collegarsi ad un hypervisor. Aprire il menu File e selezionare l'opzione Aggiungi collegmento.... Consultare la Sezione 16.1, «La finestra apri collegamento».
    Una volta selezionato il collegamento sarà disponibile il pulsante Nuovo. A questo punto premere il pulsante Nuovo.

  3. Start the new virtual machine wizard

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.

  4. Name the virtual machine

    Conferire un nome al proprio guest paravirtualizzato. Non sono permessi alcuna punteggiatura e spazi.
    Premere Avanti per continuare.

  5. Choose a virtualization method

    Scegliere un metodo per la virtualizzazione per il guest virtualizzato. Da notare che è possibile solo selezionare un metodo di virtualizzazione installato. Se KVM o Xen sono stati precedentemente selezionati (Passo 4) sarà necessario utilizzare l'hypervisor scelto. In questo esempio viene utilizzato l'hypervisor KVM.
    Premere Avanti per continuare.

  6. Select the installation method

    Selezionare Dispositivo d'installazione locale per l'installazione da un disco ottico o immagine ISO; Albero d'installazione di rete da un server NFS, FTP o HTTP; o Avvio di rete per una installazione da un server PXE.
    Impostare il Tipo di OS su Linux e Variante OS su Red Hat Enterprise Linux 5 come mostrato nella figura.
    Premere Avanti per continuare.

  7. Locate installation media

    Selezionare la posizione dell'immagine ISO o dispositivo DVD o CD-ROM. Questo esempio utilizza una immagine del file ISO del DVD d'installazione di Red Hat Enterprise Linux 5.
    1. Press the Browse button.
    2. Andare alla ricerca della posizione del file ISO e selezionare l'immagine ISO. Selezionare Apri per confermare la selezione fatta.
    3. Il file è selezionato e pronto all'installazione.
      Premere Avanti per continuare.

    Image files and SELinux

    Per i file immagine ISO e le immagini dello storage del guest è consigliato utilizzare la cartella /var/lib/libvirt/images/. Qualsiasi altra posizione potrebbe richiedere una configurazione aggiuntiva di SELinux, consultare la Sezione 7.1, «SELinux e virtualizzazione» per informazioni.

  8. Storage setup

    Assegnare un dispositivo di storage fisico (Dispositivo a blocchi) o una immagine basata sul file (File). Le immagini basate sul file devono essere posizionate nella cartella /var/lib/libvirt/images/. Assegnare storage e spazio sufficiente per il guest virtualizzato ed applicazioni necessarie.
    Premere Avanti per continuare.

    Come migrare questo guest

    Le migrazioni live e offline hanno bisogno di una installazione dei guest su storage di rete condivisi. Per informazioni su come impostare lo storage condiviso per i guest consultare il Capitolo 5, Storge condiviso e virtualizzazione.

  9. Network setup

    Select either Virtual network or Shared physical device.
    The virtual network option uses Network Address Translation (NAT) to share the default network device with the virtualized guest. Use the virtual network option for wireless networks.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.

  10. Memory and CPU allocation

    The Allocate memory and CPU window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Virtualized guests require sufficient physical memory (RAM) to run efficiently and effectively. Choose a memory value which suits your guest operating system and application requirements. Windows Server 2008. Remember, guests use physical RAM. Running too many guests or leaving insufficient memory for the host system results in significant usage of virtual memory and swapping. Virtual memory is significantly slower causing degraded system performance and responsiveness. Ensure to allocate sufficient memory for all guests and the host to operate effectively.
    Assign sufficient virtual CPUs for the virtualized guest. If the guest runs a multithreaded application assign the number of virtualized CPUs it requires to run most efficiently. Do not assign more virtual CPUs than there are physical processors (or hyper-threads) available on the host system. It is possible to over allocate virtual processors, however, over allocating has a significant, negative affect on guest and host performance due to processor context switching overheads.
    Press Forward to continue.

  11. Verify and start guest installation

    Verificare la configurazione.
    Premere Fine per avviare la procedura d'installazione del guest.

  12. Installazione di Linux

    Completare la sequenza di installazione di Red Hat Enterprise Linux 5. Le suddette fasi vengono affrontate nella Red Hat Enterprise Linux Installation Guide disponibile su http://redhat.com/docs.
È stato ora installato un guest Red Hat Enterprise Linux 5 completamente virtualizzato.

3.3. Installazione di Windows XP come guest completamente virtualizzato

Windows XP può essere installato come un guest completamente virtualizzato. Questa sezione descrive le fasi necessarie per installare Windows XP come guest completamente virtualizzato su Linux.
Prima di iniziare questa procedura assicurarsi di avere un accesso root.

  1. Starting virt-manager

    Aprire Applicazioni > Strumenti di sistema > Virtual Machine Manager. Successivamente aprire un collegamento con l'host (fare clic su File > Apri collegamento). Fare clic su Nuovo per creare una nuova macchina virtuale.

  2. Come nominare il proprio sistema virtuale

    Inserire il nome del sistema e successivamente fare clic su Avanti.

  3. Selezione di un metodo di virtualizzazione

    Se è stato selzionato KVM o Xen (Fase Passo 1) è necessario usare l'hypervisor precedentemente selezionato. In questo esempio è stato utilizzato l'hypervisor KVM.
    Windows può essere installato solo utilizzando full virtualization.

  4. Selezione di un metodo d'installazione

    Questa schermata permetterà di specificare il metodo d'installazione ed il tipo di sistema operativo.
    Per una installazione DVD o CD-ROM selezionare il dispositivo con il disco di installazione di Windows al suo interno. Se si seleziona Posizione immagine ISO inserire il percorso per una installazione di Windows .iso image.
    Selezionare Windows dall'elenco Tipo di OS e Microsoft Windows XP dall'elenco Variante OS.
    L'installazione PXE non è riportata in questo capitolo.
    Press Forward to continue.

    Image files and SELinux

    Per i file immagine ISO e le immagini di storage del guest è consigliato utilizzare la directory /var/lib/libvirt/images/. Qualsiasi altra posizione potrebbe richiedere una configurazione aggiuntiva di SELinux, consultare la Sezione 7.1, «SELinux e virtualizzazione» per informazioni.
  5. The Assigning storage space window displays. Choose a disk partition, LUN or create a file based image for the guest storage.
    La convenzione per le immagini basate su file in Fedora riporta che tutte le immagini guest basate su file sono archiviate nella directory /var/lib/libvirt/images/. Altre posizioni della directory per le immagini basate sul file sono proibite da SELinux. Se si esegue SELinux in modalità enforcing consultare la Sezione 7.1, «SELinux e virtualizzazione» per maggiori informazioni sull'installazione dei guest.
    Your guest storage image should be larger than the size of the installation, any additional packages and applications, and the size of the guests swap file. The installation process will choose the size of the guest's swap file based on size of the RAM allocated to the guest.
    Allocate extra space if the guest needs additional space for applications or other data. For example, web servers require additional space for log files.
    Choose the appropriate size for the guest on your selected storage type and click the Forward button.

    Nota

    È consigliato utilizzare la cartella predefinita, /var/lib/xen/images/, per le immagini della macchina virtuale. Se si utilizza una posizione diversa (come ad esempio /images/) assicurarsi di aggiungerla alla propria politica di SELinux e di rietichettarla prima di continuare con l'installazione (più avanti nella documentazione è possibile trovare le informazioni su come modificare la politica di SELinux)

  6. Network setup

    Select either Virtual network or Shared physical device.
    The virtual network option uses Network Address Translation (NAT) to share the default network device with the virtualized guest. Use the virtual network option for wireless networks.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  7. The Allocate memory and CPU window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    I guest virtualizzati hanno bisogno di una memoria fisica (RAM) sufficiente per una esecuzione efficiente ed effettiva. Selezionare un valore idoneo per il proprio sistema operativo guest e per i requisiti dell'applicazione. Numerosi sistemi operativi hanno bisogno di almeno 512MB di RAM per funzionare correttamente. Ricordare, i guest utilizzano una RAM fisica. L'esecuzione di troppi guest o una memoria insufficiente per il sistema host potrà provocare un utilizzo molto elevato di memoria virtuale e dello swapping. La memoria virtuale è molto più lenta e causa un degrado delle prestazioni e dei tempi di risposta. Assicurarsi di assegnare memoria sufficiente per tutti i guest e per l'host in modo da operare correttamente.
    Assign sufficient virtual CPUs for the virtualized guest. If the guest runs a multithreaded application assign the number of virtualized CPUs it requires to run most efficiently. Do not assign more virtual CPUs than there are physical processors (or hyper-threads) available on the host system. It is possible to over allocate virtual processors, however, over allocating has a significant, negative affect on guest and host performance due to processor context switching overheads.
  8. Prima che l'installazione continui verrà visualizzata una schermata riassuntiva. Selezionare Fine per procedere con l'installazione del guest:
  9. Poichè sarà necessario scegliere l'hardware è importante aprire velocemente una finestra della console dopo l'avvio del processo d'installazione. Una volta premuto il pulsante Fine assicurarsi di controllare attentamente la finestra riassuntiva del virt-manager e selezionare il nuovo guest di Windows appena avviato. Fare un doppio clic sul nome del sistema, così facendo si aprirà una finestra della console. Premere velocemente F5 per selezionare un nuovo HAL, una volta ottenuta la casella di dialogo selezionare la scheda corrispondente alla Piattaforma i486 generica (è possibile scorrere l'elenco usando i tasti freccetta Su e Giù).
  10. Il processo continuerà con l'installazione di Windows standard.
  11. Partizionare l'hard drive quando richiesto.
  12. Dopo aver formattato il proprio drive, Windows inizierà a copiare i file sull'hard drive.
  13. I file vengono copiati sul dispositivo di storage, a questo punto Windows eseguirà una procedura di riavvio.
  14. Riavviare il guest Windows: 
    # virsh start WindowsGuest
    Dove WindowsGuest è il nome della macchina virtuale.
  15. Quando si apre la console di Windows si sarà in grado di visualizzare la fase per l'impostazione dell'installazione di Windows.
  16. Se il processo d'installazione sembra arrestarsi durante la fase d'impostazione, riavviate il guest utilizzando il comando virsh reboot WindowsGuestName. Il suddetto comando dovrebbe ripristinare tale processo. Durante il riavvio della macchina virtuale è possibile visualizzare il messaggio Setup is being restarted:
  17. Una volta terminata la fase di impostazione sarà possibile visualizzare la schermata d'avvio di Windows:
  18. È ora possibile continuare con l'impostazione normale del processo d'installazione di Windows:
  19. Il processo d'installazione è ora completato, a questo punto verrà visualizzato il desktop di Windows.

3.4. Installazione di Windows Server 2003 come guest completamente virtualizzato

Questo capitolo descrive l'installazione di un guest Windows Server 2003 completamente virtualizzato con il comando virt-install. virt-install può essere usato al posto di virt-manager. Questo processo è simile all'installazione di Windows XP riportata nella Sezione 3.3, «Installazione di Windows XP come guest completamente virtualizzato».
  1. Tramite l'utilizzo di virt-install per l'installazione di Windows Server 2003 come console per il guest Windows è possibile visualizzare la finestra di virt-viewer. Un esempio di come utilizzare virt-install per l'installazione di un guest Windows Server 2003:
    Iniziare l'installazione con il comando virt-install. 
    # virt-install -hvm -s 5 -f /var/lib/libvirt/images/windows2003spi1.dsk \
-n windows2003sp1 -cdrom=/ISOs/WIN/en_windows_server_2003_sp1.iso  \
-vnc -r 1024
  2. Dopo aver iniziato l'installazione del proprio guest sarà necessario selezionare velocemente F5. Se non si preme F5 al momento opportuno sarà necessario iniziare nuovamente l'installazione. Premendo F5 si aprirà una finestra di dialogo per la selzione di un HAL diverso o tipo di computer. A questo punto selezionare Standard PC. Questa è la sola fase non standard necessaria:
  3. Completare il resto dell'installazione.
  4. Windows Server 2003 come guest completamente virtualizzato.

3.5. Installazione di Windows Server 2008 come guest completamente virtualizzato

Questa sezione riporta le fasi necessarie per l'installazione di un guest di Windows Server 2008 completamente virtualizzato.
Procedura 3.4. Installazione di Windows Server 2008 con virt-manager

  1. Open virt-manager

    Start virt-manager. Launch the Virtual Machine Manager application from the Applications menu and System Tools submenu. Alternatively, run the virt-manager command as root.

  2. Select the hypervisor

    Select the hypervisor. If installed, select Xen or KVM. For this example, select KVM. Note that presently KVM is named qemu.
    Dopo aver selezionato l'opzione verrà visualizzato il pulsante Nuovo. Premere il pulsante Nuovo.

  3. Start the new virtual machine wizard

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.

  4. Name the virtual machine

    Fornire un nome per il proprio guest virtualizzato. La punteggiatura e gli spazi non sono permessi.
    Premere Avanti per continuare.

  5. Choose a virtualization method

    Selezionare un metodo per il guest virtualizzato. È possibile selezionare solo un metodo di virtualizzazione installato. Se avete precedentemente selezionato KVM o Xen (Fase 2) è necessario usare l'hypervisor da voi selezionato. In questo esempio viene usato un hypervisor KVM.
    Premere Avanti per continuare.

  6. Select the installation method

    Per tutte le versioni di Windows è necessario utilizzare il dispositivo d'installazione locale, una immagine ISO o un dispositivo ottico fisico.
    È possibile usare PXE se avete configurato un server PXE per l'installazione di rete di Windows. L'installazione di PXE Windows non viene affrontata in questa guida.
    Impostare Tipo di OS su Windows e Variante OS su Microsoft Windows 2008 come mostrato in figura.
    Premere Avanti per continuare.

  7. Locate installation media

    Selezionare una posizione dell'immagine ISO o dispositivo DVD o CD-ROM. In questo esempio viene usato un file image ISO del CD d'installazione di Windows Server 2008.
    1. Press the Browse button.
    2. Andare alla ricerca della posizione del file ISO e selezionarla.
      Premere Apri per confermare la propria scelta.
    3. Il file viene selezionato e pronto all'installazione.
      Premere Avanti per continuare.

    Image files and SELinux

    Per i file immagine ISO e le immagini di storage del guest è consigliato l'utilizzo della cartella /var/lib/libvirt/images/. Qualsiasi altra posizione potrebbe aver bisogno di una configurazione aggiuntiva di SELinux, consultare la Sezione 7.1, «SELinux e virtualizzazione» per informazioni.

  8. Storage setup

    Assegnare un dispositivo di storage fisico (Dispositivo a blocchi) o una immagine basata sul file (File). Le suddette immagini devono essere archiviate nella cartella /var/lib/libvirt/images/. Assegnare uno storage sufficiente per il proprio guest virtualizzato. Assegnare spazio sufficiente per il guest virtualizzato e qualsiasi applicazione necessaria.
    Premere Avanti per continuare.

  9. Network setup

    Select either Virtual network or Shared physical device.
    The virtual network option uses Network Address Translation (NAT) to share the default network device with the virtualized guest. Use the virtual network option for wireless networks.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.

  10. Memory and CPU allocation

    The Allocate memory and CPU window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Virtualized guests require sufficient physical memory (RAM) to run efficiently and effectively. Choose a memory value which suits your guest operating system and application requirements. Windows Server 2008. Remember, guests use physical RAM. Running too many guests or leaving insufficient memory for the host system results in significant usage of virtual memory and swapping. Virtual memory is significantly slower causing degraded system performance and responsiveness. Ensure to allocate sufficient memory for all guests and the host to operate effectively.
    Assign sufficient virtual CPUs for the virtualized guest. If the guest runs a multithreaded application assign the number of virtualized CPUs it requires to run most efficiently. Do not assign more virtual CPUs than there are physical processors (or hyper-threads) available on the host system. It is possible to over allocate virtual processors, however, over allocating has a significant, negative affect on guest and host performance due to processor context switching overheads.
    Press Forward to continue.

  11. Verify and start guest installation

    Verificare la configurazione.
    Premere Fine per iniziare la procedura d'installazione del guest.

  12. Installazione di Windows

    Completare la sequenza per l'installazione di Windows Server 2008. La sequenza non è affrontata in questa guida, consultare la documentazione di Microsoft per informazioni su come installare Windows.

Parte II. Configuration

Configurazione della virtualizzazione con Fedora

Questi capitoli riportano le fasi necessarie per la configurazione delle procedure dei compiti avanzati relativi alla virtualzzazione. I suddetti compiti includono l'aggiunta di dispositivi di storage e di rete, il miglioramento della sicurezza, delle prestazioni e l'utilizzo di driver paravirtualizzati su guest completamente virtualizzati.

Indice

4. Dispositivi a blocchi virtualizzati
4.1. Creazione di un controllore del dischetto floppy virtualizzato
4.2. Come aggiungere dispositivi di storage sui guest
4.3. Configurazione memoria persistente
4.4. Aggiungere un dispositivo DVD o CD-ROM virtualizzato ad un guest
5. Storge condiviso e virtualizzazione
5.1. Utilizzo di iSCSI per l'archiviazione dei guest
5.2. Utilizzo di NFS per l'archiviazione dei guest
5.3. Utilizzo di GFS2 per l'archiviazione dei guest
6. Pratiche consigliate per il server
7. Sicurezza per la virtualizzazione
7.1. SELinux e virtualizzazione
7.2. Considerazioni su SELinux
8. Configurazione di rete
8.1. Network address translation (NAT) con libvirt
8.2. Bridged networking con libvirt
9. Driver para-virtualizzati KVM
9.1. Installazione dei driver paravirtualizzati Windows di KVM

Capitolo 4. Dispositivi a blocchi virtualizzati

4.1. Creazione di un controllore del dischetto floppy virtualizzato
4.2. Come aggiungere dispositivi di storage sui guest
4.3. Configurazione memoria persistente
4.4. Aggiungere un dispositivo DVD o CD-ROM virtualizzato ad un guest
Questo capitolo affronta le fasi per l'installazione e la configurazione dei dispositivi a blocchi nei guest virtualizzati. Il termine dispositivi a blocchi si riferisce a varie forme di dispositivi storage.

4.1. Creazione di un controllore del dischetto floppy virtualizzato

I controllori del dischetto floppy sono necessari per un certo numero di sistemi operativi più vecchi, ed in particolare per l'installazione dei driver. Al momento non è possibile accedere ai dospositivi del dischetto floppy fisici da guest virtualizzati. Tuttavia la creazione e l'accesso delle immagini del dischetto floppy dalle unità floppy virtualizzate è supportato. Questa sezione affronta le fasi necessarie per la creazione di un dispositivo floppy virtualizzato.
È necessario avere un file immagine di un dischetto floppy. Creare i file immagine del dischetto floppy con il comando dd. Sostituire /dev/fd0 con il nome di un dispositivo floppy e nominare il dischetto in modo appropriato. 
# dd if=/dev/fd0 of=~/legacydrivers.img

Nota per i driver para-virtualizzati

I driver paravirtualizzati possono mappare i dispositivi floppy fisici su guest completamente virtualizzati.
In questo esempio si utilizza un guest creato con virt-manager il quale esegue una installazione Linux completamente virtualizzata con l'immagina posizionata in /var/lib/libvirt/images/rhel5FV.img. In questa circostanza si utilizza l'hypervisor Xen.
  1. Creare il file di configurazione XML per l'immagine del guest usando il comando virsh su di un guest in esecuzione. 
    # virsh dumpxml rhel5FV > rhel5FV.xml
    Tale operazione salverà le impostazioni di configurazione come file XML, esso potrà essere modificato per personalizzare le operazioni ed i dispositivi usati dal guest. Per maggiori informazioni su come usare i file di configurazione XML consultare il Capitolo 18, Creazione script libvirt personalizzati.
  2. Creare una immagine del dischetto floppy per il guest. 
    # dd if=/dev/zero of=/var/lib/libvirt/images/rhel5FV-floppy.img bs=512 count=2880
  3. Aggiungere quanto di seguito riportato apportando le modifiche necessarie sul file XML di configurazione del guest. In questo esempio verrà creato un guest con un dispositivo floppy come dispositivo virtuale basato sul file. 
    <disk type='file' device='floppy'>
        <source file='/var/lib/libvirt/images/rhel5FV-floppy.img'/>
        <target dev='fda'/>
</disk>
  4. Arrestare il guest. 
    # virsh stop rhel5FV
  5. Riavviare il guest utilizzando il file di configurazione XML. 
    # virsh create rhel5FV.xml
Il dispositivo floppy è ora disponibile nel guest e conservato come file d'immagine sull'host.

4.2. Come aggiungere dispositivi di storage sui guest

Questa sezione affronta il metodo attraverso il quale è possibile aggiungere i dispositivi di storage su di una macchina guest virtuale. È possibile implementare storage aggiuntivo solo dopo aver creato i guest. I dispositivi di storage ed il protocollo supportati includono:
  • partizioni del disco fisso locale,
  • logical volume,
  • Fibre channel o iSCSI collegati direttamente all'host.
  • I contenitori basati sul file che risiedono in un file system sull'host.
  • file system NFS montati direttamente dalla macchina virtuale.
  • storage iSCSI accessibili direttamente dal guest.
  • Cluster File Systems (GFS).
Come aggiungere uno storage basato sul file su di un guest
Uno storage basato sul file, o contenitori basati sul file, sono file presenti sul file system host i quali si comportano come hard drive virtualizzati per guest virtualizzati. Per aggiungere i suddetti file eseguire le fasi di seguito riportate:
  1. Creare un file del container vuoto oppure usare un container di un file esistente (come ad esempio un file ISO).
    1. Creare uno sparse file usando il comando dd. L'utilizzo di sparse file non è consigliato a causa di alcune problematiche relative all'integrità dei dati ed alle prestazioni che ne possono derivare. Essi possono essere creati più velocemente ed usati per l'effettuazione di test ma non in ambienti di produzione. 
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
    2. Per i contenitori di storage basati sui file è consigliato l'utilizzo di file non-sparse pre-assegnati. Per la creazione di file non-sparse eseguire: 
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M count=4096
    Entrambi i comandi creano un file di 400MB il quale può essere usato come storage aggiuntivo per un guest virtualizzato.
  2. Eseguire il dump della configurazione per il guest. In questo esempio il guest è Guest1 ed il file viene salvato nella cartella home degli utenti. 
    # virsh dumpxml Guest1 > ~/Guest1.xml
  3. Aprire il file di configurazione (in questo esempio Guest1.xml) e andare alla ricerca delle voci che iniziano con "disk=". La voce in questione potrebbe somigliare alla seguente: 
    >disk type='file' device='disk'<
        >driver name='tap' type='aio'/<
        >source file='/var/lib/libvirt/images/Guest1.img'/<
        >target dev='xvda'/<
>/disk<
  4. Per aggiungere storage supplementare modificare la parte finale della voce disk=. Assicurarsi di aver specificato un nome del dispositivo per il dispositivo a blocchi virtuale non ancora usato nel file di configurazione. Di seguito viene riportato un esempio di voce che aggiunge un file chiamato FileName.img come contenitore di storage basato sul file: 
    >disk type='file' device='disk'<
        >driver name='tap' type='aio'/<
        >source file='/var/lib/libvirt/images/Guest1.img'/<
        >target dev='xvda'/<
>/disk<
>disk type='file' device='disk'<
        >driver name='tap' type='aio'/<
        >source file='/var/lib/libvirt/images/FileName.img'/<
        >target dev='hda'/<
>/disk<
  5. Riavviare il guest dal file di configurazione aggiornato. 
    # virsh create Guest1.xml
  6. Le seguenti fasi sono specifiche al guest di Linux. Altri sistemi operativi gestiscono nuovi dispositivi di storage in modo differente. Per i sistemi non-Linux consultare la documentazione relativa ai sistemi operativi guest in questione.
    Il guest utilizza ora il file FileName.img come dispositivo /dev/hdb. Questo dispositivo necessita di una formattazione da parte del guest. Sul guest, partizionare il dispositivo in una partizione primaria per l'intero dispositivo e successivamente formattare il dispositivo stesso.
    1. Inserire n per una nuova partizione. 
      # fdisk /dev/hdb
Command (m for help):
    2. Inserire p per una partizione primaria. 
      Command action
   e   extended
   p   primary partition (1-4)
    3. Selezionare un numero disponibile per la partizione. In questo esempio la prima partizione viene selezionata inserendo 1. 
      Partition number (1-4): 1
    4. Inserire il primo cilindro predefinito selezionando Enter. 
      First cylinder (1-400, default 1):
    5. Selezionare la dimensione della partizione. In questo esempio l'intero disco viene assegnato selezionando Enter. 
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
    6. Impostare il tipo di partizione inserendo t. 
      Command (m for help): t
    7. Selezionare la partizione precedentemente creata. In questo esempio risulterà essere la partizione 1. 
      Partition number (1-4): 1
    8. Inserire 83 per una partizione Linux. 
      Hex code (type L to list codes): 83
    9. salvare le modifiche sul disco ed uscire. 
      Command (m for help): w 
Command (m for help): q
    10. Formattare la nuova partizione con il file system ext3. 
      # mke2fs -j /dev/hdb
  7. Montare il disco sul guest. 
    # mount /dev/hdb1 /myfiles
Il guest ora presenta un dispositivo aggiuntivo di storage basato sul file virtualizzato.
Come aggiungere hard drive ed altri dispositivi a blocchi su di un guest
Gli amministratori di sistema utilizzano dischi fissi aggiuntivi in modo da fornire un maggiore spazio di memorizzazione o per separare i dati del sistema da quelli dell'utente. Questa procedura, Procedura 4.1, «Come aggiungere un dispositivo a blocchi fisico su guest virtualizzati», descrive come aggiungere un disco fisso su di un host per un guest virtualizzato.
La procedura funziona per tutti i dispositivi a blocchi fisici, ciò include dispositivi floppy, CD-ROM e DVD.
Procedura 4.1. Come aggiungere un dispositivo a blocchi fisico su guest virtualizzati
  1. Collegare fisicamente il dispositivo disco fisso all'host. Configurare l'host se l'unità non è accessibile per default.
  2. Configurare il dispositivo con multipath e la persistenza sull'host se necessario.
  3. Utilizzare il comando virsh attach. Sostituire: myguest con il nome del vostro guest, /dev/hdb1 con il dispositivo da aggiungere, e hdc con la posizione per il dispositivo sul guest. hdc deve essere un nome del dispositivo non acora utilizzato. Usare l'annotazione hd* per i guest di Windows, in questo modo il guest riconoscerà in modo corretto il dispositivo.
    Aggiungere il parametro --type hdd al comando per i dispositivi DVD o CD-ROM.
    Aggiungere il parametro --type floppy al comando per i dispositivi floppy. 
    # virsh attach-disk myguest /dev/hdb1 hdc --driver tap --mode readonly
  4. A questo punto il guest possiede un nuovo dispositivo disco fisso chiamato /dev/hdb su Linux o D: drive, o simile, su Windows. A tal proposito potrebbe essere necessario formattare questo dispositivo.

4.3. Configurazione memoria persistente

Questa sezione si riferisce ai sistemi con una memoria esterna o collegata alla rete; cioè dispositivi di immagazzinamento dati basati su iSCSI o Fibre Channel. È consigliato configurare i nomi del dispositivo persistente sugli host. Tale operazione aiuterà anche durante la migrazione live e per una implementazione uniforme dei nomi del dispositivo e di memorizzazione per sistemi multipli virtualizzati.
L'Universally Unique Identifier (UUID) è un metodo standardizzato per l'identificazione dei computer e dei dispositivi in ambienti computerizzati distribuiti. Questa sezione utilizza UUID per identificare i LUN Fibre Channel o iSCSI. Gli UUID sono persistenti anche dopo un riavvio, uno scollegamento e uno scambio di dispositivi. L'UUID è simile ad una etichetta su di un dispositivo.
I sistemi che non eseguono multipath devono utilizzare Configurazione di un percorso singolo. Mentre quelli che eseguono multipath possono usare Configurazione di percorsi multipli.
Configurazione di un percorso singolo
Questa procedura implementa la persistenza del dispositivo LUN utilizzando udev. Usare questa procedura solo per gli host che non usano multipath.
  1. Modificare il file /etc/scsi_id.config.
    1. Assicurarsi che la riga options=-b sia commentata. 
      # options=-b
    2. Aggiungere la seguente riga: 
      options=-g
      Questa opzione configurerà udev in modo da assumere che tutti i dispositivi SCSI ritorneranno un UUID.
  2. Per visualizzare l'UUID per un dato dispositivo eseguire il comando scsi_id -g -s /block/sd*. Per esempio: 
    # scsi_id -g -s /block/sd*
3600a0b800013275100000015427b625e
    L'output potrebbe scostarsi dall'esempio sopra citato. Esso mostra l'UUID del dispositivo /dev/sdc.
  3. Verificare che l'output UUID del comando scsi_id -g -s /block/sd* sia identico a quello del computer che accede al dispositivo.
  4. Creare una regola per il nome del vostro dispositivo. Create un file 20-names.rules nella directory /etc/udev/rules.d. A questo punto le nuove regole dovranno essere aggiunte al file. Tutte le regole sono aggiunte allo stesso file utilizzando lo stesso formato. Le regole dovranno avere il seguente formato: 
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT=UUID, NAME=devicename
    Sostituire UUID e devicename con l'UUID sopra indicato e con il nome desiderato per il dispositivo. Nell'esempio la regola somiglierà a quanto di seguito riportato: 
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="rack4row16"
    Il demone udev ora andrà alla ricerca di tutti i dispositivi chiamati /dev/sd* per l'UUID presente nella regola. Una volta che il dispositivo corrispondente è stato collegato al sistema, esso verrà assegnato allo stesso il nome della regola. Un dispositivo con un UUID di 3600a0b800013275100000015427b625e apparirà come /dev/rack4row16.
  5. Aggiungere la seguente riga su /etc/rc.local: 
    /sbin/start_udev
  6. Copiare le modifiche presenti su /etc/scsi_id.config, /etc/udev/rules.d/20-names.rules, e /etc/rc.local su tutti gli host rilevanti. 
    /sbin/start_udev
I dispositivi di storage 'networked' con regole configurate avranno ora nomi persistenti su tutti gli host sui quali sono stati aggiornati i file. Ciò significa che sarà possibile migrare i guest tra host utilizzando la memoria condivisa, così facendo i guest potranno accedere ai dispositivi di storage nei propri file di configurazione.
Configurazione di percorsi multipli
Il pacchetto multipath viene usato per sistemi con più di un percorso fisico dal computer ai dispositivi di memorizzazione. multipath fornisce condizioni di elevata resistenza 'fault tolerant', fail-over, e migliori prestazioni per i dispositivi di storage della rete collegati ai sistemi Linux.
L'implementazione della persistenza LUN in un ambiente multipath necessita di nomi di alias definiti per i dispositivi multipath. Ogni dispositivo di storage presenta un UUID il quale funge da chiave per i nomi con alias. Identificare un UUID di un dispositivo tramite il comando scsi_id: 
# scsi_id -g -s /block/sdc
I dispositivi multipath verranno creati nella directory /dev/mpath. Nell'esempio di seguito riportato sono stati definiti 4 dispositivi in /etc/multipath.conf: 
multipaths { 
        multipath { 
        wwid                3600805f30015987000000000768a0019 
        alias                oramp1 
        } 
        multipath { 
        wwid                3600805f30015987000000000d643001a 
        alias                oramp2 
        } 
        mulitpath { 
        wwid                3600805f3001598700000000086fc001b 
        alias                oramp3 
        } 
        mulitpath { 
        wwid                3600805f300159870000000000984001c 
        alias                oramp4 
        } 
}
Questa configurazione creerà 4 LUN chiamati /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 e /dev/mpath/oramp4. Una volta inseriti, la mappatura degli WWID dei dispositivi sui nuovi nomi sarà persistente durante ogni processo di riavvio.

4.4. Aggiungere un dispositivo DVD o CD-ROM virtualizzato ad un guest

Per collegare un file ISO ad un guest online usate virsh con il parametro attach-disk. 
# virsh attach-disk [domain-id] [source] [target] --driver file --type cdrom --mode readonly
. I parametri source e target sono i percorsi per i file ed i dispositivi rispettivamente per l'host ed il guest. Il parametro source può essere un percorso per un file ISO o il dispositivo della cartella /dev.

Capitolo 5. Storge condiviso e virtualizzazione

5.1. Utilizzo di iSCSI per l'archiviazione dei guest
5.2. Utilizzo di NFS per l'archiviazione dei guest
5.3. Utilizzo di GFS2 per l'archiviazione dei guest
Questo capitolo affronta argomenti specifici per lo storage di rete condiviso con virtualizzazione su Fedora.
Per la virtualizzazione sono supportati i seguenti metodi:
  • Fibre Channel
  • iSCSI
  • NFS
  • GFS2
Lo storage 'networked' è essenziale per i processi di migrazione del guest live e offline. Non sarà possibile migrare i guest senza uno storage condiviso.

5.1. Utilizzo di iSCSI per l'archiviazione dei guest

Questa sezione si riferisce all'utilizzo dei dispositivi basati su iSCSI per salvare i guest virtualizzati.

5.2. Utilizzo di NFS per l'archiviazione dei guest

Questa sezione riporta l'utilizzo di NFS per l'archiviazione dei guest virtualizzati.

5.3. Utilizzo di GFS2 per l'archiviazione dei guest

Questa sezione riporta l'utilizzo di fedora Global File System 2 (GFS2) per l'archiviazione dei guest virtualizzati.

Capitolo 6. Pratiche consigliate per il server

Di seguito sono riportati i compiti ed i suggerimenti per rendere sicuro ed affidabile il Fedora server host (dom0).
  • Eseguire SELinux in modalità enforcing. Per fare questo eseguire il comando riportato di seguito. 
    # setenforce 1
  • Rimuovere o disabilitare qualsiasi servizio non necessario come ad esempio AutoFS, NFS, FTP, HTTP, NIS, telnetd, sendmail e così via.
  • Aggiungere solo il numero minimo di account utenti per la gestione della piattaforma sul server e rimuovere gli account non necessari.
  • Evitate di eseguire applicazioni non essenziali sull'host. L'esecuzione di applicazioni sull'host potrebbe incidere negativamente sulle prestazioni della macchina virtuale e sulla stabilità del server. Qualsiasi applicazione in grado di arrestare inaspettatamente il server sarà in grado di causare l'arresto delle macchine virtuali sul server interessato.
  • Utilizzare una posizione centrale per le immagini e le installazioni della macchina virtuale. Le immagini della macchina virtuale dovrebbero essere conservate in /var/lib/libvirt/images/. Se si sta utilizzando una directory diversa per le immagini della macchina virtuale, assicurarsi di aggiungere la directory nella politica SELinux rietichettandola prima di eseguire l'installazione.
  • I media usati per l'installazione, gli alberi e le immagini devono essere conservati in una posizione centrale, solitamente risulta essere la posizione del vostro server vsftpd.

Capitolo 7. Sicurezza per la virtualizzazione

7.1. SELinux e virtualizzazione
7.2. Considerazioni su SELinux
Quando si implementano le tecnologie per la virtualizzazione sulla propria infrastruttura corporativa, assicurarsi di non compromettere l'host. L'host nell'hypervisior Xen è un dominio privilegiato che amministra la gestione del sistema e tutte le macchine virtuali. Se l'host non è sicuro tutti i domini presenti nel sistema sono vulnerabili. Sono disponibili diversi metodi attraverso i quali è possibile aumentare la sicurezza dei sistemi che utilizzano la virtualizzazione. Insieme ad altri utenti presenti nella propria organizzazione è possibile creare un piano d'impiego che contenga le specifiche operative ed i servizi necessari sui propri guest virtualizzati e server host, insieme al supporto richiesto per i suddetti servizi. Ecco alcune problematiche riguardanti la sicurezza da considerare al momento della creazione di un piano d'impiego:
  • Eseguire solo i servizi necessari sugli host. Minore è il numero di compiti e servizi in esecuzione presenti all'interno dell'host, più elevato è il livello di sicurezza e delle prestazioni.
  • Abilitare SELinux sull'hypervisor. Consultare la Sezione 7.1, «SELinux e virtualizzazione» per maggiori informazioni su come utilizzare la virtualizzazione e SELinux.
  • Utilizzare un firewall per limitare il traffico per il dom0. È possibile impostare un firewall con regole default-reject il quale assicura una protezione del dom0. È altresì importante limitare l'esposizione della rete ai servizi.
  • Non permettere ad utenti normali di accedere al dom0. Se si abilita il loro accesso si corre il rischio di rendere dom0 vulnerabile. Ricordare, dom0 risulta essere privilegiato e conferire account non privilegiati potrebbe compromettere il livello di sicurezza.

7.1. SELinux e virtualizzazione

Il Security Enhanced Linux è stato sviluppato da NSA con l'ausilio della comunità di Linux per una sicurezza più elevata di Linux. SELinux limita le funzioni di un aggressore ed impedisce il verificarsi di numerosi exploit relativi alla sicurezza come ad esempio attacchi buffer overflow e privilege escalation. Grazie a questi benefici Fedora consiglia a tutti i sistemi Linux l'abilitazione di SELinux durante la propria esecuzione in modalità enforcing.
SELinux impedisce il caricamento delle immagini del guest se SELinux è stato abilitato e le immagini non sono presenti nella directory corretta. Con SELinux tutte le immagini devono essere conservate in /var/lib/libvirt/images.
Come aggiungere uno storage basato su LVM con SELinux in modalità enforcing
La seguente sezione è un esempio su come aggiungere un volume logico ad un guest virtualizzato con SELinux abilitato. Queste informazioni possono essere utili anche per le partizioni dell'hard drive.
Procedura 7.1. Creazione e montaggio di un volume logico su di un guest virtualizzato con SELinux abilitato
  1. Creare un volume logico. In questo esempio viene creato un volume logico di 5GB chiamato NewVolumeName sul gruppo di volumi volumegroup. 
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. Formattare il volume logico NewVolumeName con un file system in grado di supportare gli attributi estesi come ad esempio ext3. 
    # mke2fs -j /dev/volumegroup/NewVolumeName
  3. Creare una nuova cartella per il montaggio del nuovo volume logico. Questa cartella può essere posizionata in qualsiasi luogo del file system. È consigliato non conservarla all'interno di cartelle molto importanti (/etc, /var, /sys) o nelle cartelle home /home o /root). In questo esempio viene usata una cartella chiamata /virtstorage 
    # mkdir /virtstorage
  4. Come montare un volume logico. 
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Impostare il tipo corretto di SELinux per la cartella Xen. 
    semanage fcontext -a -t xen_image_t "/virtualization(/.*)?"
    Alternativamente impostare il tipo corretto di SELinux per una cartella KVM. 
    semanage fcontext -a -t virt_image_t "/virtualization(/.*)?"
    Se si utilizza la targeted policy (targeted è la politica predefinita) il comando aggiungerà una riga sul file /etc/selinux/targeted/contexts/files/file_contexts.local rendendo la modifica persistente. La riga potrebbe somigliare alla seguente: 
    /virtstorage(/.*)?    system_u:object_r:xen_image_t:s0
  6. Eseguire il comando per modificare il tipo di mount point (/virtstorage) e tutti i file sottostanti su xen_image_t (restorecon e setfiles leggono i file in /etc/selinux/targeted/contexts/files/). 
    # restorecon -R -v /virtualization

7.2. Considerazioni su SELinux

Questa sezione contiene informazioni importanti per l'implementazione di SELinux all'interno dell'ambiente virtualizzato. Quando si implementano alcune modifiche che riguardano il sistema oppure si desidera aggiungere alcuni dispositivi, sarà necessario aggiornare di conseguenza la propria politica SELinux. Per configurare un volume LVM per un guest è necessario modificare il contesto di SELinux per il dispositivo a blocchi sottostante e per il gruppo di volumi corrispondenti. 
# semanage fcontext -a -t xen_image _t -f -b /dev/sda2
# restorecon /dev/sda2
Il parametro booleano xend_disable_t imposta xend in modalità unconfined dopo il riavvio del demone. È consigliato disabilitare la protezione per un demone singolo invece di disabilitarla per l'intero sistema. Altresì non rietichettare le cartelle come xen_image_t utilizzate in altre parti.

Capitolo 8. Configurazione di rete

8.1. Network address translation (NAT) con libvirt
8.2. Bridged networking con libvirt
Questa pagina fornisce una introduzione alle configurazioni comuni per il networking usate dalle applicazioni basate su libvirt. Queste informazioni sono applicate su tutti gli hypervisor siano essi Xen, KVM o altri. Per informazioni aggiuntive consultare la documentazione dell'architettura di rete di libvirt.
Le due impostazioni comuni sono "rete virtuale" o "dispositivo fisico condiviso". Il primo è identico su tutte le distribuzioni e disponibile senza alcuna configurazione specifica. Il secondo invece necessita di una configurazione manuale specifica.

8.1. Network address translation (NAT) con libvirt

Uno dei metodi più comuni per la condivisione dei collegamenti di rete è quello di usare il Network address translation (NAT) forwarding (conosciuto anche come reti virtuali).
Configurazione host
Qualsiasi installazione di libvirt standard fornisce una connettività basata sul NAT alle macchine virtuali, senza la necessità di una configurazione aggiuntiva. Ciò viene chiamato rete virtuale predefinita. Verificatene la disponibilità con il comando virsh net-list --all. 
# virsh net-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes
Se mancante, il file di configurazione XML d'esempio può essere ricaricato e attivato: 
# virsh net-define /usr/share/libvirt/networks/default.xml
La rete predefinita viene indicata da /usr/share/libvirt/networks/default.xml
Contrassegnare la rete predefinita in modo da eseguire un avvio automatico: 
# virsh net-autostart default
Rete predefinita contrassegnata come autostarted
Avviare la rete predefinita: 
# virsh net-start default
Rete predefinita avviata
Una volta avviata la rete predefinita di libvirt verrà visualizzato un dispositivo bridge isolato. Il suddetto dispositivo non avrà alcuna interfaccia fisica ad esso aggiunta poichè verrà utilzzato l'IP forwarding e NAT per collegarsi con l'esterno. Non aggiungere nuove interfacce. 
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
libvirt aggiunge le regole iptables le quali abilitano il traffico da e per i guest collegati al dispositivo virbr0 nelle catene INPUT, FORWARD, OUTPUT e POSTROUTING. Successivamente libvirt cerca di abilitare il parametro ip_forward. Altre applicazioni potrebbero disabilitare ip_forward e per questo motivo l'opzione migliore è quella di aggiungere quanto segue a /etc/sysctl.conf. 
net.ipv4.ip_forward = 1
Configurazione del guest
Una volta completata la configurazione dell'host sarà possibile collegare un guest alla rete virtuale in base al proprio nome. Per collegare un guest alla rete virtuale predefinita è possibile utilizzare il seguente XML all'interno del guest: 
<interface type='network'>
  <source network='default'/>
</interface>

Note

La definizione di un indirizzo MAC è facoltativa. Un indirizzo MAC viene generato automaticamente se omesso. In alcune situazioni è utile impostare manualmente l'indirizzo MAC. 
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
  </interface>

8.2. Bridged networking con libvirt

Il Bridged networking (conosciuto anche come condivisione del dispositivo fisico) è usato per rendere disponibile un dispositivo fisico ad una macchina virtuale. Il Bridging viene spesso usato per impostazioni più avanzate e su server con interfacce di rete multiple.
Disabilitare gli script di rete Xen
Se il sistema utilizza un bridge Xen è consigliato disabilitare il bridge di rete Xen predefinito modificando /etc/xen/xend-config.sxp ed in particolare la riga: 
(network-script network-bridge)
In: 
(network-script /bin/true)
Disabilitare il NetworkManager
NetworkManager non supporta il bridging. A tal proposito è necessario disabilitare il NetworkManager per poter usare il vecchio networking per gli script di rete. 
# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Note

A tale scopo sarà possibile aggiungere NM_CONTROLLED=no" agli script ifcfg-* usati negli esempi.
Creazione initscripts di rete
Creare o modificare i seguenti file di configurazione di rete. Questa fase può essere ripetuta (con nomi diversi) per bridge di rete aggiuntivi.
Andare nella cartella /etc/sysconfig/network-scripts: 
# cd /etc/sysconfig/network-scripts
Aprire lo script di rete per il dispositivo che si sta aggiungendo al bridge. In questo esempio ifcfg-eth0 definisce l'interfaccia di rete fisica impostata come parte di un bridge: 
DEVICE=eth0
# change the hardware address to match the hardware address your NIC uses
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0

Suggerimento

È possibile configurare il Maximum Transfer Unit (MTU) del dispositivo aggiungendo una variabile MTU alla fine del file di configurazione. 
MTU=9000
Creare un nuovo script di rete nella cartella /etc/sysconfig/network-scripts chiamato ifcfg-br0 o simile. br0 è il nome del bridge, può essere qualsiasi cosa se il nome del file è uguale al parametro del DISPOSITIVO. 
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

Warning

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
Dopo la configurazione riavviare il networking oppure eseguire un riavvio. 
# service network restart
Configure iptables to allow all traffic to be forwarded across the bridge. 
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Disable iptables on bridges

Alternatively, prevent bridged traffic from being processed by iptables rules. In /etc/sysctl.conf append the following lines: 
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Reload the kernel parameters configured with sysctl 
# sysctl -p /etc/sysctl.conf
Restart the libvirt daemon. 
# service libvirtd reload
Ora si dovrebbe avere un "dispositivo fisico condiviso" al quale è possibile collegare i guest ed avere un accesso LAN completo. Verificare il nuovo bridge: 
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0
Da notare che il bridge è completamente indipendente dal bridge virbr0. È consigliato non collegare un dispositivo fisico a virbr0. Il bridge virbr0 è solo per la connettività Network Address Translation (NAT).

Capitolo 9. Driver para-virtualizzati KVM

9.1. Installazione dei driver paravirtualizzati Windows di KVM
I driver paravirtualizzati sono disponibili per guest Windows virtualizzati in esecuzione su host KVM. I suddetti driver sono inclusi nel pacchetto virtio. Il pacchetto virtio supporta i dispositivi a blocchi (storage) ed i controllori dell'interfaccia di rete.
I driver paravirtualizzati aumentano le prestazioni dei guest completamente virtualizzati. Con i driver paravirtualizzati la latenza I/O del guest diminuisce ed il numero di dati trasmessi aumenta a livelli prossimi al bare-metal. È consigliato l'utilizzo dei driver paravirtualizzati per guest completamente virtualizzati che eseguono numerose applicazioni e compiti I/O.
I driver paravirtualizzati KVM vengono automaticamente caricati ed installati sulle versioni più recenti di Fedora. Le suddette versioni di Fedora rilevano ed installano i driver eliminando così la necessità di eseguire fasi aggiuntive per l'installazione.
Come con il modulo KVM, i driver virtio sono solo disponibili su host che eseguono le versioni più recenti di Fedora.

Note

Per guest sono disponibili 28 alloggiamenti PCI per i dispositivi aggiuntivi. Ogni rete paravirtualizzata o dispositivo a blocchi utilizza un solo alloggiamento. Ogni guest è in grado di utilizzare fino a 28 dispositivi aggiuntivi costituiti da ogni combinazione di rete paravirtualizzata, dispositivi a disco paravirtualizzati o altri dispositivi PCI che utilizzano VTd.
Le seguenti versioni di Microsoft Windows presentano un supporto dei driver paravirtualizzati KVM:
  • Windows XP,
  • Windows Server 2003,
  • Windows Vista, e
  • Windows Server 2008.

9.1. Installazione dei driver paravirtualizzati Windows di KVM

Questa sezione si riferisce al processo d'installazione per i driver paravirtualizzati KVM di Windows. I driver paravirtualizzati KVM possono essere caricati durante l'installazione di Windows o installati dopo l'installazione del guest.
È possibile installare i driver paravirtualizzati sul vostro guest tramite uno dei seguenti metodi:
  • mantanendo i file d'installazione su di una rete accessibile al guest,
  • usando un dispositivo CD-ROM virtualizzato del file iso del CD d'installazione del driver, o
  • utilizzando un dispositivo floppy per installare i driver durante il processo d'avvio (per guest Windows).
Questa guida descrive il processo d'installazione eseguito tramite un CD d'installazione paravirtualizzato come dispositivo CD-ROM virtualizzato.

  1. Scaricare i driver

    I driver sono disponibili anche tramite Microsoft (windowsservercatalog.com).
    Il pacchetto virtio-win installa una immagine del CD-ROM (il file virtio-win.iso) nella cartella /usr/share/virtio-win/.

  2. Installare i driver para-virtualizzati

    È consigliato installare i driver sul guest prima di collegare o modificare un dispositivo per l'utilizzo dei driver paravirtualizzati.
    Per i dispositivi a blocchi con file system root o altri dispositivi a blocchi necessari per il processo d'avvio del guest, i driver devono essere installati prima di modificare il dispositivo. Se i driver non sono stati installati sul guest ed il driver è impostato sul driver virtio, il guest non verrà avviato.
Montaggio dell'immagine con virt-manager
Consultare Procedura 9.1, «Utilizzo di virt-manager per il montaggio di una immagine CD-ROM per un guest di Windos» per aggiungere l'immagine del CD-ROM con virt-manager.
Procedura 9.1. Utilizzo di virt-manager per il montaggio di una immagine CD-ROM per un guest di Windos
  1. Aprire virt-manager, selezionare il vostro guest virtualizzato dall'elenco delle macchine virtuali e premere il pulsante Dettagli:
  2. Selezionare Aggiungi nel pannello Dettagli.
  3. Ciò aprirà un wizard per aggiungere il nuovo dispositivo. Selezionare Dispositivo di storage dal menu a tendina e successivamente Avanti.
  4. Selezionare l'opzione File (disk image) ed impostare la posizione del file .iso dei driver paravirtualizzati. La posizione dei file .iso è /usr/share/xenpv-win se è stato usato yum per installare i pacchetti del driver paravirtualizzato.
    Se i driver sono stati salvati su CD fisici usare l'opzione Partizione disco normale.
    Impostare Tipo dispositivo su IDE cdrom e successivamente fare clic su Avanti per procedere.
  5. Il dischetto è stato assegnato ed è disponibile per il guest una volta che lo stesso è stato avviato. Fare clic su Fine per chiudere il wizard o indietro se avete commesso un errore.
Installazione con dischetto floppy virtualizzato
Questa procedura si riferisce all'installazione dei driver paravirtualizzati durante una installazione di Windows.
  • Previa installazione della VM di Windows per la prima volta usando il menu run-once, inserire viostor.vfd come floppy

    1. Windows Server 2003

      Quando windows richiede la selezione di F6 per driver di terze parti, selezionare il tasto in questione e seguire le istruzioni presenti sulla schermata.

    2. Windows Server 2008

      Quando il programma d'installazione richiede il driver fare clic su "Carica driver", indicare al programma d'installazione l'unità A: e selezionare il driver più idoneo all'architettura del sistema operativo in uso.
Utilizzo dei driver paravirtualizzati KVM per dispositivi esistenti
Modificare un dispositivo del disco fisso esistente collegato al guest per poter utilizzare il driver virtio al posto del driver IDE virtualizzato. In questo esempio sono stati modificati i file di configurazione di libvirt. Alternativamente virt-manager, virsh attach-disk o virsh attach-interface possono aggiungere un nuovo dispositivo utilizzando i driver paravirtualizzati Utilizzo dei driver paravirtualizzati KVM per nuovi dispositivi.
  1. Di seguito viene riportato un dispositivo a blocchi basato sul file il quale utilizza il driver IDE virtualizzato. Questa è una voce tipica per un guest virtualizzato il quale non utilizza i driver paravirtualizzati. 
    <disk type='file' device='disk'>
   <source file='/var/lib/libvirt/images/disk1.img'/>
   <target dev='hda' bus='ide'/>
</disk>
  2. Modificare la voce in modo da usare il dispositivo paravirtualizzato da bus= a virtio. 
    <disk type='file' device='disk'>
   <source file='/var/lib/libvirt/images/disk1.img'/>
   <target dev='hda' bus='virtio'/>
</disk>
Utilizzo dei driver paravirtualizzati KVM per nuovi dispositivi
Questa procedura si riferisce alla creazione di nuovi dispositivi utilizzando i driver paravirtualizzati KVM con virt-manager.
Alternativamente i comandi virsh attach-disk o virsh attach-interface possono essere usati per collegare i dispositivi utilizzando i driver paravirtualizzati.

Installare prima i driver

Assicurarsi di aver installato i driver sul guest di Windows prima di procedere con l'installazione dei nuovi dispositivi. Se i driver non sono disponibili il dispositivo non li riconoscerà e quindi non funzionerà.
  1. Aprire il guest virtualizzato facendo doppio clic sul nome del guest in virt-manager.
  2. Aprire la scheda Hardware.
  3. Selezionare Aggiungi Hardware.
  4. Nella scheda Aggiungi Hardware virtuale selezionare Storage o Rete per il tipo di dispositivo.
    1. Nuovi dispositivi a disco
      Selezionare il dispositivo di storage o l'immagine basata sul file. Selezionare Virtio Disk come Tipo di dispositivo e premere Avanti.
    2. Nuovi dispositivi di rete
      Selezionare Rete virtuale o Dispositivo fisico condiviso. Successivamente virtio come Tipo di dispositivo e Avanti.
  5. Selezionare Fine per salvare il dispositivo.
  6. Riavviare il guest. Il dispositivo potrebbe non essere riconosciuto dal guest di Windows fino al successivo processo di riavvio.

Parte III. Administration

Amministrazione dei sistemi virtualizzati

Questi capitoli contengono le informazioni necessarie per l'amministrazione dei guest virtualizzati e degli host utilizzando gli strumenti presenti in Fedora.

Indice

10. Gestione dei guest utilizzando xend
11. Gestione dell'ora del guest KVM
12. Migrazione Live KVM
12.1. Requisiti per una migrazione live
12.2. Esempio di storage condiviso: NFS per una semplice migrazione
12.3. Migrazione KVM live con virsh
12.4. Migrazione con virt-manager
13. Gestione remota dei guest virtualizzati
13.1. Gestione remota con SSH
13.2. Gestione remota attraverso TLS e SSL
13.3. Modalità di trasporto

Capitolo 10. Gestione dei guest utilizzando xend

Il demone di controllo del nodo xend, esegue alcune funzioni di gestione del sistema che si riferiscono alle macchine virtuali. Questo demone controlla le risorse virtualizzate, ed è necessario che xend sia in esecuzione per interagire con le macchine virtuali. Prima di avviare xend specificare i parametri operativi modificando il file di configurazione di xend, /etc/xen/xend-config.sxp. Ecco i parametri da abilitare o disabilitare nel file di configurazione xend-config.sxp:
Item Description
(limite-console)
Determina lo xend_unix_server, il limite del buffer di memoria del server della console ed assegna i valori in base al dominio
(min-mem)
Determina il numero minimo di megabyte riservati per il domain0 (se inserite 0, il valore non varia).
(dom0-cpus)
Determina il numero delle CPU utilizzate dal domain0 (almeno 1 CPU è assegnata per default).
(enable-dump)
Determina la presenza di un arresto inaspettato 'crash', e abilita un dump (il default è 0).
(external-migration-tool)
Determina lo script o l'applicazione che gestisce la migrazione del dispositivo esterno. Gli script devono risiedere in etc/xen/scripts/external-device-migrate.
(logfile)
Determina la posizione del file di log (il predefinito è /var/log/xend.log).
(loglevel)
Filtra i valori log mode: DEBUG, INFO, WARNING, ERROR, o CRITICAL (il default è DEBUG).
(network-script)
Determina lo script che abilita l'ambiente di networking (gli script devono risiedere nella cartella etc/xen/scripts ).
(xend-http-server)
Abilita il server per l'http stream packet management (il predefinito è no).
(xend-unix-server)
Abilita il server unix domain socket, un server socket rappresenta un punto finale delle comunicazioni, che gestisce i collegamenti low level network ed accetta o rifiuta i collegamenti in entrata. Il valore predefinito è si.
(xend-relocation-server)
Abilita il server di riposizionamento per migrazioni 'cross-machine' (il predefinito è no).
(xend-unix-path)
Determina la posizione dove il comando xend-unix-server esegue l'output dei dati (il predefinito è var/lib/xend/xend-socket)
(xend-port)
Determina la porta utilizzata dal server di gestione http (il predefinito è 8000).
(xend-relocation-port)
Determina la porta utilizzata dal server di riposizionamento (il predefinito è 8002).
(xend-relocation-address)
Determina gli indirizzi dell'host abilitati per la migrazione. Il valore predefinito è il valore di xend-address.
(xend-address)
Determina l'indirizzo al quale si lega il server del domain socket. Il valore predefinito permette tutti i collegamenti.
Tabella 10.1. Parametri di configurazione di xend

Dopo aver impostato i parametri operativi, verificare la corretta esecuzione di xend, ed in caso contrario, inizializzare il demone. Al prompt del comando avviare il demone xend inserendo quanto segue: 
service xend start
Utilizzare xend per arrestare il demone: 
service xend stop
Questo comando arresterà l'esecuzione del demone.
Per riavviare il demone utilizzare xend: 
service xend restart
Per riavviare il demone.
Controllare lo stato del demone xend. 
service xend status
L'output mostra lo stato del demone.

Abilitazione di xend al momento dell'avvio

Usare il comando chkconfig per aggiungere xend a initscript.
chkconfig --level 345 xend
xend verrà ora avviato nei runlevel 3,4 e 5.

Capitolo 11. Gestione dell'ora del guest KVM

KVM utilizza la funzione constant Time Stamp Counter (TSC) presente nelle moderne CPU. Alcune CPU non utilizzano un constant Time Stamp Counter (TSC) e ciò influenzerà il modo attraverso il quale i guest in esecuzione su KVM gestiscono l'ora. I guest in esecuzione senza una gestione accurata possono avere effetti molto seri su alcune applicazioni della rete, poiché i guest interessati verranno eseguiti più velocemente o più lentamente rispetto all'ora esatta.
A causa di un orologio o contatore non accurati i guest possono presentare diversi problemi:
  • Gli orologi possono essere sfasati rispetto all'ora attuale causando sessioni invalide ed interessando negativamente le reti.
  • I guest con orologi più lenti potranno avere problemi durante il processo di migrazione.
  • I guest potranno arrestarsi inaspettatamente.
I suddetti problemi sono presenti su altre piattaforme di virtualizzazione ed è consigliato sempre di eseguire un test sulla gestione dell'ora.

NTP

Il demone Network Time Protocol (NTP) deve risultare in esecuzione sull'host e sui guest. Abilitare il servizio ntpd: 
# service ntpd start
Aggiungere il servizio ntpd alla sequenza d'avvio predefinita: 
# chkconfig ntpd on
L'utilizzo del servizio ntpd dovrebbe diminuire gli effetti relativi all'alterazione dell'orologio in qualsiasi caso.
Come determinare se la CPU possiede un constant Time Stamp Counter
La CPU possiede un constant Time Stamp Counter se è presente il flag constant_tsc. Per determinare la presenta del flag constant_tsc eseguire il seguente comando: 
$ cat /proc/cpuinfo | grep constant_tsc
Se qualsiasi output viene visualizzato ciò indicherà la presenza del bit constant_tsc nella CPU. Se al contrario nessun output viene visualizzato allora seguire le istruzioni di seguito indicate.
Configurazione di un host senza un constant Time Stamp Counter
I sistemi che non possiedono alcun constant time stamp counter avranno bisogno di una configurazione aggiuntiva. Le funzioni di gestione dell'alimentazione interferiscono con la gestione accurata dell'ora e devono essere disabilitate. Così facendo sarà possibile per un guest con KVM gestire accuratamente l'ora.

Note

Queste informazioni sono rivolte solo alle AMD revision F cpu
Se la CPU non possiede il bit constant_tsc, disabilitare tutte le funzioni di gestione dell'alimentazione (BZ#513138). Ogni sistema possiede diversi timer per controllare l'ora. TSC non è stabile sull'host, tale comportamento viene causato talvolta dalle modifiche cpufreq, da stati deep C state oppure da una migrazione su di un host con un TSC più veloce. Per interrompere uno stato deep C state, il quale è in grado di arrestare TSC, aggiungere sull'host "processor.max_cstate=1" nelle opzioni d'avvio del kernel in grub: 
term Fedora (vmlinuz-2.6.29.6-217.2.3.fc11)
        root (hd0,0)
        kernel /vmlinuz-vmlinuz-2.6.29.6-217.2.3.fc11 ro root=/dev/VolGroup00/LogVol00 rhgb quiet processor.max_cstate=1
Disabilitare cpufreq (necessario solo su host senza constant_tsc) modificando il file di configurazione /etc/sysconfig/cpuspeed e successivamente le variabili MIN_SPEED e MAX_SPEED sulla frequenza più alta disponibile. I limiti validi sono disponibili nei file /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies.
Utilizzo dell'orologio paravirtualizzato con i guest di Red Hat Enterprise Linux
Per alcuni guest di Red Hat Enterprise Linux sono necessari alcuni parametri aggiuntivi del kernel. I suddetti parametri possono essere impostati aggiungendoli alla fine della riga del /kernel nel file /boot/grub/grub.conf del guest.
La seguente tabella riporta le versioni di Red Hat Enterprise Linux ed i parametri necessari per i guest sui sistemi senza un Time Stamp Counter costante.
Red Hat Enterprise LinuxParametri aggiuntivi relativi al kernel del guest
5.4 AMD64/Intel 64 con orologio paravirtualizzatoI parametri aggiuntivi non sono necessari
5.4 AMD64/Intel 64 senza orologio paravirtualizzatodivider=10 notsc lpj=n
5.4 x86 con orologio paravirtualizzato I parametri aggiuntivi non sono necessari
5.4 x86 senza orologio paravirtualizzatodivider=10 clocksource=acpi_pm lpj=n
5.3 AMD64/Intel 64divider=10 notsc
5.3 x86divider=10 clocksource=acpi_pm
4.8 AMD64/Intel 64notsc divider=10
4.8 x86clock=pmtmr divider=10
3.9 AMD64/Intel 64 I parametri aggiuntivi non sono necessari
3.9 x86I parametri aggiuntivi non sono necessari
Utilizzo dell'orologio paravirtualizzato con guest di Windows
Abilitare l'orologio paravirtualizzato sui guest di Windows modificando i parametri d'avvio. Le impostazioni d'avvio di Windows sono conservate nel file boot.ini. Per abilitare l'orologio paravirtualizzato aggiungere la seguente riga: 
/use pmtimer
Per maggiori informazioni sulle impostazioni d'avvio di Windows e sull'opzione pmtimer consultare le Opzioni di cambiamento disponibili per i file Boot.ini di Windows XP e Windows Server 2003.

Capitolo 12. Migrazione Live KVM

12.1. Requisiti per una migrazione live
12.2. Esempio di storage condiviso: NFS per una semplice migrazione
12.3. Migrazione KVM live con virsh
12.4. Migrazione con virt-manager
Questo capitolo descrive la migrazione dei guest, in esecuzione su di un hypervisor KVM, su un host KVM.
La migrazione è un processo usato per migrare un guest virtualizzato da un host all'altro. Esso è una funzione importante della virtualizzazione in quanto il software è completamente separato dall'hardware. Il processo di migrazione è utile per:
  • Load balancing - guests can be moved to hosts with lower usage when a host becomes overloaded.
  • Hardware failover - when hardware devices on the host start to fail, guests can be safely relocated so the host can be powered down and repaired.
  • Energy saving - guests can be redistributed to other hosts and host systems powered off to save energy and cut costs in low usage periods.
  • Geographic migration - guests can be moved to another location for lower latency or in serious circumstances.
I processi di migrazione possono essere live o offline. Per migrare i guest lo storage deve essere condiviso. Il processo di migrazione consiste nell'invio della memoria dei guest all'host di destinazione. Lo storage condiviso conserva il file system predefinito del guest. L'immagine del file system non viene inviata sulla rete da un host sorgente all'host di destinazione.
An offline migration suspends the guest then moves an image of the guests memory to the destination host. The guest is resumed on the destination host and the memory the guest used on the source host is freed.
Il tempo necessario per una migrazione offline dipende dalla larghezza di banda della rete e dalla latenza. Un guest con 2GB di memoria avrà bisogno di circa dieci secondi con un link Ethernet di 1 Gbit.
Una migrazione live mantiene il guest in esecuzione sull'host sorgente migrando la memoria senza arrestare il guest. Tutte le pagine modificate della memoria sono monitorate ed inviate alla destinazione durante l'invio dell'immagine. La memoria viene aggiornata con le pagine modificate. Il processo continua fino a quando il tempo di pausa conferito al guest è uguale al tempo previsto per il trasferimento delle ultime pagine. KVM è in grado di prevedere il tempo rimasto e cerca di trasferire il numero massimo di pagine dall'origine alla destinazione fino a quando KVM prevede che il numero delle pagine rimanenti può essere trasferito durante un breve arco di tempo entro il quale la VM risulta sospesa. I registri vengono caricati sul nuovo host ed il guest viene ripristinato sull'host di destinazione. Se non è possibile eseguire il merge del guest (tale comportamento si verifica quando i guest sono sotto un carico molto elevato), il guest stesso viene sospeso e successivamente verrà eseguita una migrazione offline.
Il tempo necessario per una migrazione offline dipende dalla larghezza di banda della rete e dalla latenza. Se la rete viene utilizzata in maniera estesa o se in presenza di una larghezza di banda bassa la migrazione avrà bisogno di più tempo.

12.1. Requisiti per una migrazione live

La migrazione dei guest richiede quanto segue:
Requisiti per una migrazione
  • Un guest virtualizzato installato su di uno storage 'networked' condiviso, e l'utilizzo di uno dei seguenti protocolli:
    • Fibre Channel
    • iSCSI
    • NFS
    • GFS2
  • Due o più sistemi Fedora della stessa versione con gli stessi aggiornamenti.
  • Entrambi i sistemi dovranno avere porte appropriate aperte.
  • I sistemi devono avere configurazioni di rete identiche. Tutte le configurazioni di rete ed il bridging devono essere uguali su entrambi gli host.
  • Lo storage condiviso deve essere montato sulla stessa posizione sui sistemi sorgente e di destinazione. Il nome della directory montata deve essere identico.
Configurazione dello storage di rete
Configurare lo storage condiviso ed installare un guest sullo storage in questione. Per informazioni sullo storage condiviso consultare il Capitolo 5, Storge condiviso e virtualizzazione.
Alternativamente usare l'esempio relativo a NFS in Sezione 12.2, «Esempio di storage condiviso: NFS per una semplice migrazione».

12.2. Esempio di storage condiviso: NFS per una semplice migrazione

In questo esempio viene utilizzato NFS per condividere le immagini del guest con altri host KVM. Il suddetto esempio non è pratico per installazioni molto grandi, esso viene usato solo per dimostrare le tecniche di migrazione e per implementazioni piccole. Non usare questo esempio per la migrazione o l'esecuzione di numerosi guest virtualizzati.
Per informazioni più avanzate e per uno storage condiviso più robusto consultate Capitolo 5, Storge condiviso e virtualizzazione

  1. Esportare la cartella dell'immagine di libvirt

    Aggiungere la directory dell'immagine predefinita al file /etc/exports: 
    /var/lib/libvirt/images *.bne.redhat.com(rw,no_root_squash,async)
    Modificare il parametro degli host in modo appropriato per il vostro ambiente:

  2. Avvio NFS

    1. Se non precedentemente fatto installare i pacchetti NFS: 
      # yum install nfs
    2. Aprire le porte per NFS in iptables ed aggiungere NFS nel file /etc/hosts.allow.
    3. Avviare il servizio NFS: 
      # service nfs start

  3. Montare lo storage predefinito sulla destinazione

    Sul sistema di destinazione montare la cartella /var/lib/libvirt/images: 
    # mount sourceURL:/var/lib/libvirt/images /var/lib/libvirt/images

    Le posizioni devono essere uguali sia sulla sorgente che sulla destinazione

    Qualsiasi cartella sia stata scelta per i guest essa deve essere la stessa sia sull'host che sul guest. Ciò deve essere applicato su tutti i tipi di storage condivisi. Se la cartella non risulta essere la stessa il processo di migrazione fallirà.

12.3. Migrazione KVM live con virsh

È possibile migrare un guest su di un host diverso attraverso il comando virsh. Il comando migrate accetta i parametri nel seguente formato: 
# virsh migrate --live GuestName DestinationURL
The GuestName parameter represents the name of the guest which you want to migrate.
The DestinationURL parameter is the URL or hostname of the destination system. The destination system must run the same version of Fedora, be using the same hypervisor and have libvirt running.
Once the command is entered you will be prompted for the root password of the destination system.
Esempio: migrazione live con virsh
In questo esempio viene eseguita una migrazione da test1.bne.redhat.com a test2.bne.redhat.com. Modificare gli hostname per l'ambiente. Nell'esempio è riportata una migrazione di una macchina virtuale chiamata CentOS4test.
In questo esempio si presume che l'utente sia in possesso di uno storage condiviso configurato e che tutti i prerequisiti siano stati soddisfatti (di seguito riportati: Requisiti per una migrazione).

  1. Verificare che il guest sia in esecuzione

    Dal sistema d'origine, test1.bne.redhat.com, verificare che CentOS4test sia in esecuzione: 
    [root@test1 ~]# virsh list
Id Name                 State
----------------------------------
 10 CentOS4                running

  2. Migrare il guest

    Eseguire il seguente comando per una migrazione live del guest per la destinazione test2.bne.redhat.com. Aggiungere /system alla fine dell'URL di destinazione per indicare a libvirt la necessità di avere un accesso completo. 
    # virsh migrate --live CentOS4test qemu+ssh://test2.bne.redhat.com/system
    Once the command is entered you will be prompted for the root password of the destination system.

  3. Attesa

    La migrazione potrebbe richiedere qualche minuto a seconda del carico e della dimensione del guest. virsh riporta solo gli errori. Il guest continua la sua esecuzione sull'host sorgente fino alla migrazione completa.

  4. Verificare che il guest sia arrivato sull'host di destinazione

    Dal sistema di destinazione, test2.bne.redhat.com, verificare che CentOS4test sia in esecuzione: 
    [root@test2 ~]# virsh list
Id Name                 State
----------------------------------
 10 CentOS4                running
La migrazione live è ora conclusa.

Altri metodi di networking

libvirt supporta una varietà di metodi per il networking incluso TLS/SSL, unix sockets, SSH, e TCP non cifrato. Per maggiori informazioni sull'utilizzo di altri metodi consultare il Capitolo 13, Gestione remota dei guest virtualizzati.

12.4. Migrazione con virt-manager

Questa sezione si riferisce alla migrazione dei guest basati su KVM con virt-manager
  1. Eseguire il collegamento con gli host target e sorgente. Sul menu File, selezionare Aggiungi collegamento, a questo punto verrà visualizzata la finestra Aggiungi collegamento.
    Inserire le seguenti informazioni:
    • Hypervisor: Selezionare QEMU.
    • Collegamento: Selezionare il tipo di collegamento.
    • Hostname: Inserire l'hostname.
    Fare clic su Collega.
    Il Virtual Machine Manager mostra un elenco di host collegati.
  2. Aggiungere un gruppo di storage con lo stesso NFS sugli host sorgente e di destinazione.
    Sul menu Modifica, selezionare Dettagli host, per visualizzare la finestra Dettagli host.
    Fare clic sulla scheda Storage.
  3. Aggiungere un nuovo gruppo di storage. Nella parte bassa a sinistra della finestra fare clic sul pulsante +. A questo punto verrà visualizzata la finestra Aggiungi un nuovo gruppo di storage.
    Inserire le seguenti informazioni:
    • Nome: Inserire il nome del gruppo per lo storage.
    • Tipo: Selezionare netfs: Network Exported Directory.
    Fare clic su Avanti.
  4. Inserire le seguenti informazioni:
    • Formato: Selezionare il tipo di storage. Esso deve essere NFS o iSCSI per migrazioni live.
    • Host Name: Inserire l'indirizzo IP o il fully-qualified domain name del server di storage.
    Fare clic su Fine.
  5. Creare un nuovo volume nel gruppo di storage condiviso, fare click su Nuovo Volume.
  6. Inserite le informazioni necessarie e successivamente fare clic su Crea Volume.
  7. Creare una macchina virtuale con il nuovo volume e successivamente, eseguirla.
    A questo punto verrà visualizzata la finestra della Macchina Virtuale.
  8. Nella finestra del Virtual Machine Manager, fare clic con il pulsante destro del mouse sulla macchina virtuale e selezionare Migra, successivamente selezionare la posizione desiderata per la migrazione.
  9. Fare clic su Si per confermare la migrazione.
    Il Virtual Machine Manager mostra la macchina virtuale nella nuova posizione.
    La finestra del Virtual Machine Manager mostra la nuova posizione della macchina virtuale.

Capitolo 13. Gestione remota dei guest virtualizzati

13.1. Gestione remota con SSH
13.2. Gestione remota attraverso TLS e SSL
13.3. Modalità di trasporto
Questa sezione affronta il modo attraverso il quale è possibile gestire in modo remoto i guest virtualizzati utilizzando ssh o TLS e SSL.

13.1. Gestione remota con SSH

Il pacchetto ssh fornisce un protocollo di rete cifrato attraverso il quale è possibile inviare in modo sicuro le funzioni di gestione ai server di virtualizzazione remoti. Il metodo descritto usa il libvirt management connection attraverso un tunnel sicuro su di un collegamento SSH per la gestione delle macchine remote. L'autenticazione viene fatta tramite la cifratura della chiave pubblica SSH e le password, oppure tramite le frasi segrete raccolte dal vostro agent SSH locale. In aggiunta, la console VNC per ogni macchina del guest virtuale verrà collegata a SSH tramite un tunnel.
SSH viene generalmente configurato per default, e per questo motivo dovreste essere in possesso di una impostazione delle chiavi SSH, senza aver bisogno quindi di regole firewall aggiuntive per accedere ai servizi di gestione o alla console VNC.
Fare attenzione alle problematiche che si possono verificare usando SSH per la gestione remota delle proprie macchine:
  • è necessario un accesso di root per le macchine remote per poter gestire le macchine virtuali,
  • il processo d'impostazione per il collegamento iniziale potrebbe essere lento,
  • non vi è alcun metodo standard per revocare una chiave dell'utente su tutti gli host o guest,
  • e ssh non interagisce bene con un numero molto elevato di macchine remote.
Configurazione accesso SSH per virt-manager
Le seguenti informazioni presumono che l'utente stia iniziando da zero e che non sia in possesso di una impostazione delle chiavi SSH.
  1. Sarà necessario una coppia di chiavi pubbliche sulla macchina nella quale viene utilizzato virt-manager. Se ssh è stato precedentemente configurato allora si può saltare questo comando. 
    $ ssh-keygen -t rsa
  2. Per eseguire un login remoto virt-manager avrà bisogno di una copia della chiave pubblica su ogni macchina remota che eseuge libvirt. Copiare il file $HOME/.ssh/id_rsa.pub dalla macchina da usare per la gestione remota tramite il comando scp: 
    $ scp $HOME/.ssh/id_rsa.pub root@somehost:/root/key-dan.pub
  3. Una volta copiato il file utilizzare ssh per eseguire il collegamento alle macchine remote come utente root, ed aggiungere il file copiato sull'elenco di chiavi autorizzate. Se l'utente root presente sull'host remoto non possiede un elenco di chiavi autorizzate, assicurarsi che i permessi del file siano stati impostati correttamente 
    $ ssh root@somehost
# mkdir /root/.ssh
# chmod go-rwx /root/.ssh
# cat /root/key-dan.pub >> /root/.ssh/authorized_keys
# chmod go-rw /root/.ssh/authorized_keys
Il demone libvirt (libvirtd)
Il demone libvirt fornisce un interfaccia per la gestione delle macchine virtuali. È necessario aver installato il demone libvirtd ed eseguirlo su ogni host remoto che si desidera gestire. 
$ ssh root@somehost
# chkconfig libvirtd on
# service libvirtd start
Dopo aver configurato sia libvirtd che SSH, si è in grado di accedere in modo remoto alle proprie macchine virtuali. A questo punto sarà possibile accedere ai guest anche con VNC.

13.2. Gestione remota attraverso TLS e SSL

È possibile gestire le macchine virtuali utilizzando TLS e SSL. TLS e SSL forniscono una maggiore scalabilità ma è più complicato di ssh (consultare la Sezione 13.1, «Gestione remota con SSH»). TLS e SSL è la stessa tecnologia usata dal web browser per collegamenti sicuri. Il collegamento di gestione di libvirt aprirà una porta TCP per i collegamenti in entrata, la quale risulta essere cifrata ed autenticata in base ai certificati x509. Altresì la console VNC per ogni macchina virtuale del guest verrà impostata in modo da utilizzare TLS con l'autenticazione del certificato x509.
Utilizzando questo metodo non sarà necessario conferire agli utenti alcun account della shell sulle macchine remote gestite. Tuttavia saranno necessarie regole firewall aggiuntive per accedere al servizio di gestione o alla console VNC. È possibile utilizzare gli elenchi di revoca del certificato per revocare l'accesso agli utenti.
Fasi necessarie per l'impostazione dell'accesso TLS/SSL per virt-manager
Questa breve guida presume che l'utente stia iniziando da zero e che non sia in possesso di alcuna conoscenza del certificato TLS/SSL. Se si è fortunati da avere un server per la gestione del certificato si possono saltare le prime fasi.
Impostazione del server di libvirt
Per maggiori informazioni su come creare i certificati consultare il sito web di libvirt, http://libvirt.org/remote.html.
Server VNC di Xen
È possibile abilitare TLS sul server VNC di Xen attraverso la modifica del file di configurazione, /etc/xen/xend-config.sxp. Rimuovere il commento sul parametro di configurazione (vnc-tls 1) all'interno del file di configurazione.
La cartella /etc/xen/vnc necessita dei seguenti file:
  • ca-cert.pem - Il certificato CA
  • server-cert.pem - Il certificato del server firmato dal CA
  • server-key.pem - La chiave privata del server
Ciò fornisce la cifratura del canale dei dati. Sarebbe appropriato richiedere ai client di presentare i propri certificati x509 come forma di autenticazione. Per abilitare tale processo rimuovere il commento presente sul parametro (vnc-x509-verify 1).
Impostazione client virsh e virt-manager
L'impostazione per i client è leggermente inconsistente in questo momento. Per abilitare l'API di gestione libvirt tramite TLS, i certificati client e CA devono essere posizionati in /etc/pki. Per informazioni consultare http://libvirt.org/remote.html
All'interno dell'interfaccia utente virt-manager utilizzare l'opzione del meccanismo di trasporto SSL/TLS durante il collegamento ad un host.
Per virsh URI ha il seguente formato:
  • qemu://hostname.guestname/system per KVM.
  • xen://hostname.guestname/ per Xen.
Per abilitare SSL e TLS per VNC è necessario posizionare il certificate authority ed i certificati del client in $HOME/.pki, quindi i seguenti file:
  • CA o ca-cert.pem - Il certificato CA.
  • libvirt-vnc o clientcert.pem - Il certificato del client firmato dal CA.
  • libvirt-vnc o clientkey.pem - La chiave privata del client.

13.3. Modalità di trasporto

Per una gestione remota, libvirt supporta le seguenti modalità di trasporto:
Transport Layer Security (TLS)
Il Transport Layer Security TLS 1.0 (SSL 3.1) authenticated and encrypted TCP/IP socket è generalmente in ascolto su di un numero di porta pubblica. Per il suo utilizzo sarà necessario generare i certificati server e client. La porta standard è 16514.
Socket UNIX
I socket per il dominio Unix sono accessibili solo sulla macchina locale. I socket non sono cifrati ed utilizzano i permessi UNIX o SELinux per l'autenticazione. I nomi standard per i socket sono /var/run/libvirt/libvirt-sock e /var/run/libvirt/libvirt-sock-ro (per collegamenti di sola-lettura).
SSH
Collegamento Transported over a Secure Shell protocol (SSH). Questo collegamento necessita di Netcat (il pacchetto nc). Il demone di libvirt (libvirtd) deve essere in esecuzione sulla macchina remota. La porta 22 deve essere aperta per permettere un accesso SSH. Sarà necessario utilizzare una specie di gestione della chiave ssh (per esempio, ssh-agent) in caso contrario vi sarà richiesta una password.
ext
Il parametro ext viene usato per qualsiasi programma esterno in grado di creare una connessione alla macchina remota esternamente a libvirt. Tale operazione generalmente interessa applicazioni non supportate di sicurezza e third-party.
tcp
Socket TCP/IP non cifrato. Non consigliati per un loro utilizzo in ambienti di produzione, esso è normalmente disabilitato, ma un amministratore sarà in grado di abilitarlo per operazioni di test o per un suo utilzzo su reti fidate. La porta predefinita è 16509.
Il trasporto predefinito se non diversamente indicato è tls.
URI remoti
Un Uniform Resource Identifier (URI) viene usato da virsh e libvirt per il collegamento ad un host remoto. Gli URI possono essere usati con il parametro --connect per il comando virsh in modo da eseguire comandi singoli o migrazioni su host remoti.
Il formato generale degli URI di libvirt (il contenuto all'interno di parentesi quadre, "[]", rappresenta le funzioni facoltative): 
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
È necessario fornire il metodo di trasporto o l'hostname per poter distinguerlo da un URI locale.
Esempi di parametri di gestione remota
  • Collegamento ad un hypervisor Xen remoto sull'host towada, usando un trasporto SSH ed il nome utente SSH ccurran. 
    xen+ssh://ccurran@towada/
  • Collegamento ad un hypervisor Xen remoto sull'host towada utilizzando TLS. 
    xen://towada/
  • Collegamento ad un hypervisor Xen remoto sull'host towada usando TLS. Il parametro no_verify=1 indica a libvirt di non verificare il certificato del server. 
    xen://towada/?no_verify=1
  • Collegamento ad un hypervisor KVM remoto sull'host towada usando SSH. 
    qemu+ssh://towada/system
Esempi di test
  • Collegamento ad un hypervisor KVM locale con un socket UNIX non standard. Il percorso completo per il socket Unix in questo caso viene esplicitamente fornito. 
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
  • Collegamento al demone libvirt con un collegamento TCP/IP non cifrato per il server con un indirizzo IP 10.1.1.10 sulla porta 5000. Verrà utilizzato il test driver con le impostazioni predefinite. 
    test+tcp://10.1.1.10:5000/default
Parametri URI aggiuntivi
I parametri supplementari possono essere aggiunti agli URI remoti. La tabella di seguito riportata Tabella 13.1, «Parametri URI aggiuntivi» riporta i parametri riconosciuti. Tutti gli altri verranno ignorati. Da notare che i valori dei parametri devono essere URI-escaped (cioè, viene aggiunto un punto interrogativo (?) prima della conversione del parametro e dei caratteri speciali in un formato URI).
Nome Modalità di trasporto Description Esempio di utilizzo
name tutte le modalità Il nome passato alla funzione virConnectOpen remota. Esso è formato generalmente rimuovendo il trasporto, il nome utente, il numero della porta, l'hostname ed i parametri aggiuntivi dall'URI remoto, ma in alcuni casi molto complessi è meglio conferire esplicitamente il nome. name=qemu:///system
comando ssh e ext Il comando esterno. Per il trasporto ext questo è necessario. Per ssh l'impostazione predefinita è ssh. Per il comando viene eseguita la ricerca del PATH. command=/opt/openssh/bin/ssh
socket unix e ssh Il percorso per il socket del dominio UNIX il quale sovrascrive l'impostazione predefinita. Per il trasporto ssh, esso viene passato al comando netcat remoto (consultare netcat). socket=/opt/libvirt/run/libvirt/libvirt-sock
netcat ssh Il nome del comando netcat sulla macchina remota. L'impostazione predefinita è nc. Per il trasporto ssh, libvirt crea un comando ssh il quale è simile al seguente: command -p port [-l username] hostname netcat -U socket dove porta, nome utente, hostname possono essere specificati come parte dell'URI remoto, e comando, netcat e socket provengono da parametri aggiuntivi (o impostazioni predefinite sensibili). netcat=/opt/netcat/bin/nc
no_verify tls Se impostato su di un valore diverso da zero verranno disabilitati i controlli del certificato del server. Da notare che per disabilitare i controlli server del certificato del client o indirizzo IP, è necessario modificare la configurazione di libvirtd. no_verify=1
no_tty ssh Se impostato su di un valore diverso da zero ssh non richiederà più alcuna password se non riesce ad eseguire automaticamente un log in su di una macchina remota (per l'utilizzo di ssh-agent o simile). Da usare quando non si è in possesso di un accesso ad un terminale - per esempio in programmi grafici che utilizzano libvirt. no_tty=1
Tabella 13.1. Parametri URI aggiuntivi

Parte IV. Virtualization Reference Guide

I comandi per la virtualizzazione, gli strumenti del sistema, le applicazioni e riferimenti aggiuntivi dei sistemi

Questi capitoli forniscono una descrizione dettagliata dei comandi per la virtualizzazione, strumenti del sistema e applicazioni presenti in Fedora. Gli utenti che desiderano avere informazioni sulle funzionalità avanzate dovrebbero consultare i suddetti capitoli.

Indice

14. Strumenti per la virtualizzazione
15. Gestione dei guest con virsh
16. Gestione dei guest con Virtual Machine Manager (virt-manager)
16.1. La finestra apri collegamento
16.2. Finestra principale del Virtual Machine Manager
16.3. Finestra delle informazioni del Virtual Machine Manager
16.4. Console grafica della macchina virtuale
16.5. Starting virt-manager
16.6. Ripristino di una macchina salvata
16.7. Visualizzazione delle informazioni sul guest
16.8. Monitoraggio dello stato
16.9. Visualizzazione degli identificatori del guest
16.10. Visualizzazione dello stato del guest
16.11. Visualizzazione delle CPU virtuali
16.12. Visualizzazione utilizzo della CPU
16.13. Visualizzazione utilizzo della memoria
16.14. Gestione di una rete virtuale
16.15. Creazione di una rete virtuale

Capitolo 14. Strumenti per la virtualizzazione

Di seguito viene riportato un elenco di strumenti per la gestione della virtualizzazione, del debugging ed il networking utili per i sistemi che eseguono Xen.
Strumenti di amministrazione del sistema
  • vmstat
  • iostat
  • lsof 
    # lsof -i :5900
xen-vncfb 10635  root  5u  IPv4 218738  TCP grumble.boston.redhat.com:5900 (LISTEN)
  • qemu-img
Strumenti di debugging avanzato
  • systemTap
  • crash
  • xen-gdbserver
  • sysrq
  • sysrq t
  • sysrq w
  • sysrq c
Networking
brtcl 
  • # brctl show
bridge name  bridge id            STP enabled    interfaces
xenbr0       8000.feffffffffff    no             vif13.0
                                                 pdummy0
                                                 vif0.0

  • # brctl showmacs xenbr0
port no  mac addr                is local?       aging timer
  1      fe:ff:ff:ff:ff:ff       yes             0.00

  • # brctl showstp xenbr0
xenbr0
bridge id              8000.feffffffffff
designated root        8000.feffffffffff
root port              0                    path cost                 0
max age                20.00                bridge max age            20.00
hello time             2.00                 bridge hello time         2.00
forward delay          0.00                 bridge forward delay      0.00
aging time            300.01
hello timer            1.43                 tcn timer                 0.00
topology change timer  0.00                 gc timer                  0.02
flags

vif13.0 (3)
port id                8003                 state                    forwarding
designated root        8000.feffffffffff    path cost                100
designated bridge      8000.feffffffffff    message age timer        0.00
designated port        8003                 forward delay timer      0.00
designated cost        0                    hold timer               0.43
flags

pdummy0 (2)
port id                8002                 state                    forwarding
designated root        8000.feffffffffff    path cost                100
designated bridge      8000.feffffffffff    message age timer        0.00
designated port        8002                 forward delay timer      0.00
designated cost        0                    hold timer               0.43
flags

vif0.0 (1)
port id                8001                 state                    forwarding
designated root        8000.feffffffffff    path cost                100
designated bridge      8000.feffffffffff    message age timer        0.00
designated port        8001                 forward delay timer      0.00
designated cost        0                    hold timer               0.43
flags
  • ifconfig
  • tcpdump
Tool di KVM
  • ps
  • pstree
  • top
  • kvmtrace
  • kvm_stat
Xen tools
  • xentop
  • xm dmesg
  • xm log

Capitolo 15. Gestione dei guest con virsh

virsh è uno strumento dell'interfaccia della linea di comando per la gestione dei guest e dell'hypervisor.
Lo strumento virsh è stato creato considerando l'API di gestione libvirt e funziona come alternativa allo strumento xm e al graphical guest Manager (virt-manager). Gli utenti non privilegiati possono usare virsh per operazioni di sola lettura. Utilizzare virsh per eseguire gli script per le macchine del guest.
riferimento rapido del comando virsh
Le seguenti tabelle forniscono un riferimento rapido per tutte le opzioni della linea di comando di virsh:
Comando Description
help Visualizza le informazioni di base d'aiuto.
list Elenca tutti i guest.
dumpxml Esegue l'output del file di configurazione XML per il guest.
create Crea un guest da un file di configurazione XML ed avvia il nuovo guest.
start Avvia un guest inattivo.
destroy Forza l'arresto di un guest.
define Esegue un output di un file di configurazione XML per un guest.
domid Mostra l'ID del guest.
domuuid Mostra l'UUID del guest.
dominfo Mostra le informazioni del guest.
domname Mostra il nome del guest.
domstate Mostra lo stato di un guest.
quit Esce dal terminale interattivo.
reboot Riavvia un guest.
restore Ripristina una sessione del guest precedentemente salvata in un file.
resume Ripristina un guest in pausa.
save Salva lo stato corrente di un guest su di un file.
shutdown Arresta correttamente (gracefully) un guest.
suspend Mette in pausa un guest.
undefine Cancella tutti i file associati con un guest.
migrate Migra un guest su di un altro host.
Tabella 15.1. Comandi di gestione delle risorse

Le seguenti opzioni del comando virsh sono utilizzate per gestire le risorse dell'hypervisor e del guest:
Comando Description
setmem Imposta la memoria assegnata per un guest.
setmaxmem Imposta il limite massimo della memoria per l'hypervisor.
setvcpus Modifica il numero di CPU virtuali assegnate per un guest.
vcpuinfo Mostra le informazioni della CPU virtuale di un guest.
vcpupin Controlla l'affinità della CPU virtuale di un guest.
domblkstat Mostra le statistiche relative al dispositivo a blocchi per un guest in esecuzione.
domifstat Mostra le statistiche relative all'interfaccia di rete per un guest in esecuzione.
attach-device Collega un dispositivo ad un guest usando una definizione del dispositivo in un file XML.
attach-disk Collega un nuovo dispositivo a disco ad un guest.
attach-interface Collega una nuova interfaccia di rete ad un guest.
detach-device Scollega un dispositivo da un guest, accetta lo stesso tipo di descrizione XML come il comando attach-device.
detach-disk Scollega un dispositivo a disco da un guest.
detach-interface Scollega l'interfaccia di rete da un guest.
Tabella 15.2. Opzioni di gestione delle risorse

Di seguito vengono elencate le opzioni varie di virsh:
Comando Description
version Mostra la versione di virsh
nodeinfo Esegue l'output delle informazioni sull'hypervisor
Tabella 15.3. Opzioni varie

Collegamento ad un hypervisor
Per collegarsi ad una sessione dell'hypervisor con virsh : 
# virsh connect {hostname OR URL}
Dove <name> è il nome della macchina dell'hypervisor. Per inizializzare un collegamento di sola lettura inserire il comando sopra riportato con -readonly.
Creazione dump XML di una macchina virtuale (file di configurazione)
Esegue un output del file di configurazione XML con virsh: 
# virsh dumpxml {domain-id, domain-name or domain-uuid}
Questo comando esegue l'output del file di configurazione XML del guest su standard out (stdout). È possibile salvare i dati eseguendo il pipe dell'output su di un file. Esempio di pipe sul file guest.xml: 
# virsh dumpxml GuestID > guest.xml
Questo file guest.xml è in grado di ricreare il guest (consultate Come modificare un file di configurazione del guest. Modificare il file di configurazione XML per configurare i dispositivi aggiuntivi o per implementare i guest supplementari. Consultare la Sezione 18.1, «Come utilizzare i file di configurazione XML con virsh» per maggiori informazioni su come modificare i file creati con virsh dumpxml.
Un esempio di output virsh dumpxml: 
# virsh dumpxml r5b2-mySQL01
<domain type='xen' id='13'>
    <name>r5b2-mySQL01</name>
    <uuid>4a4c59a7ee3fc78196e4288f2862f011</uuid>
    <bootloader>/usr/bin/pygrub</bootloader>
    <os>
        <type>linux</type>
        <kernel>/var/lib/libvirt/vmlinuz.2dgnU_</kernel>
        <initrd>/var/lib/libvirt/initrd.UQafMw</initrd>
        <cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline>
    </os>
    <memory>512000</memory>
    <vcpu>1</vcpu>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>restart</on_crash>
    <devices>
        <interface type='bridge'>
            <source bridge='xenbr0'/>
            <mac address='00:16:3e:49:1d:11'/>
            <script path='vif-bridge'/>
        </interface>
        <graphics type='vnc' port='5900'/>
        <console tty='/dev/pts/4'/>
    </devices>
</domain>
Come creare un guest da un file di configurazione
I guest possono essere creati tramite i file di configurazione XML. È possibile copiare l'XML esistente dai guest precedentemente creati oppure utilizzare l'opzione dumpxml (a tal proposito consultate Creazione dump XML di una macchina virtuale (file di configurazione)). Per creare un guest con virsh da un file XML: 
# virsh create configuration_file.xml
Come modificare un file di configurazione del guest
Al posto dell'opzione dumpxml (consultare Creazione dump XML di una macchina virtuale (file di configurazione)) i guest possono essere modificati durante la loro esecuzione o se sono offline. Il comando virsh edit fornisce questo tipo di funzionalità. Per esempio per modificare il guest chiamato softwaretesting: 
# virsh edit softwaretesting
Così facendo si aprirà un editor di testo. L'editor di testo predefinito è il parametro della shell $EDITOR (impostato per default su vi).
Sospensione di un guest
Per sospendere un guest con virsh: 
# virsh suspend {domain-id, domain-name or domain-uuid}
Quando un guest si trova in uno stato di sospensione esso continuerà a consumare RAM ma non le risorse del processore. Altresì, non sarà presente alcun disco e I/O di rete durante la sospensione del guest. Questa operazione sarà immediata ed il guest dovrà essere riavviato con l'opzione resume (Ripristino di un guest).
Ripristino di un guest
Per ripristinare un guest sospeso con virsh con l'opzione resume: 
# virsh resume {domain-id, domain-name or domain-uuid}
Questa operazione è immediata ed i parametri del guest vengono preservati per operazioni suspend e resume.
Come salvare un guest
Per salvare lo stato attuale di un guest su di un file usando il comando virsh: 
# virsh save {domain-name, domain-id or domain-uuid} filename
Questo comando arresta il guest specificato salvando i dati su di un file, tale operazione potrebbe richiedere qualche minuto a causa della quantità di memoria utilizzata dal guest. È possibile ripristinare lo stato del guest con l'opzione restore (Ripristino di un guest). L'operazione di salvataggio è simile a quella di pausa, invece di mettere in pausa un guest lo stato corrente del guest verrà salvato.
Ripristino di un guest
Ripristino di un guest precedentemente salvato con il comando virsh save (Come salvare un guest) utilizzando il comando virsh: 
# virsh restore filename
Tale operazione riavvia il guest salvato. Il nome e l'UUID del guest vengono conservati, ma assegnati per un nuovo id.
Come arrestare un guest
Per arrestare un guest usando il comando virsh: 
# virsh shutdown {domain-id, domain-name or domain-uuid}
È possibile controllare il comportamento del guest durante l'avvio modificando il parametro on_shutdown nel file di configurazione del guest.
Riavvio di un guest
Riavvio di un guest con il comando virsh: 
#virsh reboot {domain-id, domain-name or domain-uuid}
È possibile controllare il comportamento del guest durante l'avvio modificando il parametro on_reboot del file di configurazione del guest.
Come forzare l'arresto di un guest
Per forzare l'arresto di un guest con il comando virsh: 
# virsh destroy {domain-id, domain-name or domain-uuid}
Questo comando esegue un 'ungraceful shutdown' arrestando il guest specificato. L'utilizzo di virsh destroy può corrompere i file system del guest. Utilizzare l'opzione destroy solo quando il guest non risponde. Per un guest paravirtualizzato usare l'opzione shutdown (Come arrestare un guest).
Come ottenere un domain ID di un guest
Per ottenere un domain ID di un guest: 
# virsh domid {domain-name or domain-uuid}
Come ottenere il nome del dominio di un guest
Per ottenere il nome del dominio di un guest: 
# virsh domname {domain-id or domain-uuid}
Come ottenere l'UUID di un guest
Per ottenere un Universally Unique Identifier (UUID) per un guest: 
# virsh domuuid {domain-id or domain-name}
Un esempio di output di virsh domuuid: 
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011
Visualizzazione informazioni del guest
Usando virsh con domain ID del guest, nome del dominio o UUID è possibile mostrare le informazioni sul guest specifico: 
# virsh dominfo {domain-id, domain-name or domain-uuid}
Esempio di output virsh dominfo: 
# virsh dominfo r5b2-mySQL01
id:             13
name:           r5b2-mysql01
uuid:           4a4c59a7-ee3f-c781-96e4-288f2862f011
os type:              linux
state:          blocked
cpu(s):         1
cpu time:             11.0s
max memory:     512000 kb
used memory:    512000 kb
Visualizzazione informazioni relative all'host
Per mostrare le informazioni sull'host: 
# virsh nodeinfo
Un esempio di output di virsh nodeinfo: 
# virsh nodeinfo
CPU model                    x86_64
CPU (s)                      8
CPU frequency                2895 Mhz
CPU socket(s)                2      
Core(s) per socket           2
Threads per core:            2
Numa cell(s)                 1
Memory size:                 1046528 kb
Così facendo vengono riportate le informazioni del nodo, e le macchine che supportano il processo di virtualizzazione.
Visualizzazione dei guest
Per visualizzare l'elenco dei guest e dei rispettivi stati con virsh: 
# virsh list
Altre opzioni disponibili includono:
l'opzione --inactive elenca i guest inattivi (i guest definiti ma non ancora attivi) e
l'opzione --all elenca tutti i guest. Per esempio: 
# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  1 Domain202            paused
  2 Domain010            inactive
  3 Domain9600           crashed
L'output di virsh list viene categorizzato come uno di sei stati (di seguito riportati).
  • Lo stato running si riferisce ai guest attualmente attivi su di una CPU.
  • I guest elencati come blocked sono bloccati e non risultano essere in esecuzione e non possono essere eseguiti. Tale comportamento è dovuto a causa di un guest in attesa sull'I/O (uno stato di attesa tradizionale), o se i guest sono in pausa 'sleep mode'.
  • Lo stato paused elenca i domini che sono in pausa. Tale comportamento si verifica se un amministratore usa il pulsante pause in virt-manager, xm pause o virsh suspend. Quando un guest è in uno stato di pausa esso continuerà a consumare memoria ed altre risorse, pur essendo non eleggibile per una sua programmazione o per le risorse dell'hypervisor.
  • Lo stato shutdown è per i guest in procinto di spegnersi. In questo caso verrà inviato al guest un segnale di spegnimento abilitando un processo di spegnimento corretto delle proprie funzioni. Tale procedura potrebbe non funzionare con tutti i sistemi operativi guest; infatti alcuni di essi non rispondono a tali segnali.
  • I domini in uno stato dying sono domini 'morenti', ciò significa che il dominio non è ancora stato completamente arrestato.
  • I guest crashed sono guest che hanno fallito durante la loro esecuzione. Questo stato si verifica solo se il guest è stato configurato in modo da non eseguire il riavvio dopo un crash.
Visualizzazione informazioni della CPU virtuale
Per visualizzare le informazioni della CPU virtuale da un guest con virsh: 
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
Un esempio di output virsh vcpuinfo: 
# virsh vcpuinfo r5b2-mySQL01
VCPU:           0
CPU:            0
State:          blocked
CPU time:       0.0s
CPU Affinity:   yy
Configurazione affinità CPU virtuale
Per configurare l'affinità delle CPU virtuali con CPU fisiche: 
# virsh vcpupin {domain-id, domain-name or domain-uuid} vcpu, cpulist
Dove vcpu è il numero della VCPU virtuale e cpulist elenca il numero fisico delle CPU.
Configurazione conteggio delle CPU virtuali
Per modificare il numero delle CPU assegnate ad un guest con virsh: 
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
Il nuovo valore count non può eccedere il valore del count specificato durante la creazione del guest.
Configurazione dell'assegnazione della memoria
Per modificare l'assegnazione della memoria del guest con virsh : 
# virsh setmem {domain-id or domain-name} count
Specificare count in kilobyte. Da notare che il nuovo conteggio non può eccedere la quantità specificata durante la creazione del guest. I valori più bassi di 64MB probabilmente non funzioneranno con la maggior parte dei sistemi operativi del guest. La memoria massima non interesserà il guest attivo se il nuovo valore non è più basso, in tal caso ne deriva una diminuzione dell'utilizzo della memoria.
Visualizzazione informazioni del dispositivo a blocchi del guest
Usare virsh domblkstat per mostrare le statistiche dei dispositivi a blocchi per un guest in esecuzione. 
# virsh domblkstat GuestName block-device
Visualizzazione informazioni del dispositivo di rete del guest
Usare virsh domifstat per visualizzare le statistiche dell'interfaccia di rete per un guest in esecuzione. 
# virsh domifstat GuestName interface-device
Migrazione dei guest con virsh
È possibile migrare un guest su di un altro host con virsh. Migrare il dominio su di un altro host. Aggiungere --live per una migrazione live. Il comando migrate accetta i parametri nel seguente formato: 
# virsh migrate --live GuestName DestinationURL
Il parametro --live è facoltativo. Aggiungere il parametro --live per le migrazioni live.
The GuestName parameter represents the name of the guest which you want to migrate.
The DestinationURL parameter is the URL or hostname of the destination system. The destination system must run the same version of Fedora, be using the same hypervisor and have libvirt running.
Once the command is entered you will be prompted for the root password of the destination system.
Gestione reti virtuali
Questa sezione affronta la gestione delle reti virtuali con il comando virsh. Per elencare le reti virtuali: 
# virsh net-list
Questo comando genera un output simile a: 
# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes      
vnet1                     active     yes      
vnet2                     active     yes
Per visualizzare le informazioni di rete per una rete virtuale specifica: 
# virsh net-dumpxml NetworkName
Così facendo verranno mostrate le informazioni relative ad una rete virtuale specifica in formato XML: 
# virsh net-dumpxml vnet1
<network>
  <name>vnet1</name>
  <uuid>98361b46-1581-acb7-1643-85a412626e70</uuid>
  <forward dev='eth0'/>
  <bridge name='vnet0' stp='on' forwardDelay='0' />
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254' />
    </dhcp>
  </ip>
</network>
Altri comandi virsh utilizzati per la gestione di reti virtuali sono:
  • virsh net-autostart network-name — Avvia automaticamente una rete specificata come network-name.
  • virsh net-create XMLfile — genera ed avvia una nuova rete utilizzando un file XML già esistente.
  • virsh net-define XMLfile — genera un nuovo dispositivo di rete da un file XML esistente senza avviarlo.
  • virsh net-destroy network-name — annulla una rete specificata come network-name.
  • virsh net-name networkUUID — converte un networkUUID specifico in un nome della rete.
  • virsh net-uuid network-name — converte un network-name specificato in un UUID della rete.
  • virsh net-start nameOfInactiveNetwork — avvia una rete inattiva.
  • virsh net-undefine nameOfInactiveNetwork — rimuove la definizione di una rete inattiva.

Capitolo 16. Gestione dei guest con Virtual Machine Manager (virt-manager)

16.1. La finestra apri collegamento
16.2. Finestra principale del Virtual Machine Manager
16.3. Finestra delle informazioni del Virtual Machine Manager
16.4. Console grafica della macchina virtuale
16.5. Starting virt-manager
16.6. Ripristino di una macchina salvata
16.7. Visualizzazione delle informazioni sul guest
16.8. Monitoraggio dello stato
16.9. Visualizzazione degli identificatori del guest
16.10. Visualizzazione dello stato del guest
16.11. Visualizzazione delle CPU virtuali
16.12. Visualizzazione utilizzo della CPU
16.13. Visualizzazione utilizzo della memoria
16.14. Gestione di una rete virtuale
16.15. Creazione di una rete virtuale
Questa sezione descrive le finestre del Virtual Machine Manager (virt-manager), le caselle di dialogo ed i vari controlli GUI.
virt-manager fornisce una visuale grafica degli hyparvisor e del guest sul sistema e sulle macchine remote. Per definire i guest paravirtualizzati e completamente virtualizzati è possibile utilizzare virt-manager. virt-manager è in grado di eseguire compiti di gestione della virtualizzazione incluso:
  • assegnazione della memoria
  • assegnazione delle CPU virtuali
  • controllo prestazioni operative,
  • processi di salvataggio e ripristino, pausa e riavvio, arresto ed avvio dei guest virtualizzati,
  • collega alle console grafiche e di testo, e
  • alle migrazioni live e offline.

16.1. La finestra apri collegamento

Questa finestra viene visualizzata per prima e richiede all'utente di scegliere una sessione per l'hypervisor. Gli utenti non privilegiati possono iniziare una sessione di sola-lettura. Gli utenti root saranno in grado di iniziare una sessione di lettura-scrittura. Per utenti normali selezionare l'opzione Host Xen locale o QEMU (per KVM).
Finestra di collegamento del Virtual Machine Manager
Figura 16.1. Finestra di collegamento del Virtual Machine Manager

16.2. Finestra principale del Virtual Machine Manager

Questa finestra principale visualizza tutte le macchine virtuali in esecuzione, insieme alle risorse ad esse assegnate (incluso il domain0), è altresì possibile visualizzare il campo desiderato. Facendo doppio clic sulla macchina virtuale desiderata, si è in grado di visualizzare la console relativa alla macchina interessata. Selezionando una macchina virtuale e facendo doppio clic sul pulsante Dettagli , si visualizzeranno le informazioni relative alla macchina interessata. Per creare una nuova macchina virtuale utilizzare il menu File .
Finestra principale del Virtual Machine Manager
Figura 16.2. Finestra principale del Virtual Machine Manager

16.3. Finestra delle informazioni del Virtual Machine Manager

Questa finestra contiene i grafici e le statistiche dei dati relativi all'uso delle risorse live di un guest disponibili su virt-manager. Il campo UUID mostra l'identificatore unico globale per le macchine virtuali.
finestra dei dettagli di virt-manager
Figura 16.3. finestra dei dettagli di virt-manager

16.4. Console grafica della macchina virtuale

Questa finestra mostra una console grafica della macchina virtuale. I guest paravirtualizzati e completamente virtualizati utilizzano tecniche diverse per esportare i rispettivi framebuffer virtuali locali, ma entrambe le tecnologie utilizzano VNC per renderli disponibili alla finestra della console del Virtual Machine Manager. Se la macchina virtuale è impostata in modo da richiedere un'autenticazione, la console grafica della macchina virtuale richiederà l'utilizzo di una password prima di visualizzare il display.
Finestra console grafica
Figura 16.4. Finestra console grafica

Nota sulla sicurezza e su VNC

VNC viene considerato non sicuro da numerosi esperti del settore, tuttavia sono state eseguite diverse modifiche per permettere l'uso sicuro di VNC per la virtualizzazione su Fedora. Le macchine guest sono in ascolto solo per l'indirizzo loopback dell'host locale (dom0) (127.0.0.1). Tale comportamento assicura l'accesso a virt-manager ed alla macchina virtuale attraverso VNC, solo a coloro che possiedono privilegi per la shell.
L'amministrazione remota può essere eseguita seguendo le istruzioni presenti nel Capitolo 13, Gestione remota dei guest virtualizzati. TLS può essere usato per fornire una sicurezza di livello enterprise per la gestione del guest e dei sistemi host.
Il proprio desktop locale è in grado di intercettare le diverse combinazioni di tasti (per esempio, Ctrl+Alt+F11), in modo da evitare il loro invio alla macchina guest. È possibile utilizzare la capacità dello 'sticky key' virt-manager per inviare le suddette sequenze. È necessario premere qualsiasi tasto modificatore (come Ctrl o Alt) 3 volte, così facendo il tasto specificato verrà considerato attivo fino a quando non verrà premuto il modificatore successivo. A questo punto sarà possibile inviare Ctrl-Alt-F11 al guest inserendo la sequenza dei tasti 'Ctrl Ctrl Ctrl Alt+F1'.

16.5. Starting virt-manager

Per avviare la sessione virt-manager aprire il menu Applicazioni fare clic su Strumenti di sistema e selezionare Virtual Machine Manager(virt-manager).
Apparirà la finestra principale del virt-manager.
Avvio di virt-manager
Figura 16.5. Avvio di virt-manager

Alternativamente virt-manager può essere avviato in modo remoto usando ssh come indicato dal seguente comando: 
ssh -X host's address[remotehost]# virt-manager
L'utilizzo di ssh per la gestione delle macchine virtuali e degli host viene affrontato nella Sezione 13.1, «Gestione remota con SSH».

16.6. Ripristino di una macchina salvata

Dopo aver avviato il Virtual Machine Manager, tutte le macchine virtuali sul sistema verranno visualizzate nella finestra principale. Domain0 è il sistema host. Se non è presente alcuna macchina, ciò indicherà che nessuna macchina è in esecuzione sul sistema.
Per ripristinare una sessione precedentemente salvata:
  1. Dal menu File, selezionare Ripristina una macchina salvata.
    Ripristino di una macchina virtuale
    Figura 16.6. Ripristino di una macchina virtuale

  2. Apparirà la finestra principale di Ripristina macchina virtuale.
  3. Andare nella cartella corretta e selezionare il file della sessione salvata.
  4. Fare clic su Apri.
A questo punto apparirà il sistema virtuale salvato all'interno della finestra principale del Virtual Machine Manager.
Una sessione del virtual machine manager ripristinata
Figura 16.7. Una sessione del virtual machine manager ripristinata

16.7. Visualizzazione delle informazioni sul guest

È possibile utilizzare il monitor della macchina virtuale, per visualizzare le informazioni dei dati riguardanti le attività di qualsiasi macchina virtuale presente sul sistema.
Per visualizzare le informazioni di un sistema virtuale:
  1. Nella finestra principale del Virtual Machine Manager, selezionare la macchina virtuale che si desidera visualizzare.
    Selezione di una macchina virtuale da visualizzare
    Figura 16.8. Selezione di una macchina virtuale da visualizzare

  2. Dal menu Modifica del Virtual Machine Manager, selezionare Dettagli macchina (oppure fare clic sul pulsante Dettagli, nella parte bassa della finestra principale del Virtual Machine Manager).
    Visualizzazione menu dettagli della macchina virtuale
    Figura 16.9. Visualizzazione menu dettagli della macchina virtuale

    Visualizzazione finestra Panoramica dettagli della macchina virtuale. Questa finestra riassume l'utilizzo della memoria e della CPU per i domini specificati.
    Visualizzazione panoramica dettagli del guest
    Figura 16.10. Visualizzazione panoramica dettagli del guest

  3. Nella finestra dei Dettagli della macchina virtuale fare clic su Hardware .
    A questo punto si è in grado di visualizzare la finestra Hardware dettagli della macchina virtuale.
    Visualizzazione informazioni hardware del guest
    Figura 16.11. Visualizzazione informazioni hardware del guest

  4. Sulla tabella Hardware fare clic su Processore per visualizzare o modificare l'assegnazione corrente del processore.
    Pannello assegnazione del processore
    Figura 16.12. Pannello assegnazione del processore

  5. Sulla tabella Hardware, fare clic su Memoria per visualizzare o modificare l'assegnazione della memoria RAM corrente.
    Visualizzazione assegnazione della memoria
    Figura 16.13. Visualizzazione assegnazione della memoria

  6. Sulla tabella Hardware, fare clic su Disco per visualizzare o modificare la configurazione corrente del disco fisso.
    Visualizzazione configurazione del disco
    Figura 16.14. Visualizzazione configurazione del disco

  7. Sulla tabella Hardware, fare clic su Rete per visualizzare o modificare la configurazione di rete corrente.
    Visualizzazione configurazione di rete
    Figura 16.15. Visualizzazione configurazione di rete

16.8. Monitoraggio dello stato

È possibile utilizzare il Virtual Machine Manager per modificare lo Status monitoring del sistema virtuale.
Per configurare lo Status monitoring ed abilitare le console:
  1. Dal menu Modifica, selezionare Preferenze.
    Modifica preferenze del guest
    Figura 16.16. Modifica preferenze del guest

    Verrà visualizzata la finestra preferenze del Virtual Machine Manager.
  2. Dalla casella di selezione dello Status monitoring, specificare il periodo (in secondi) che il sistema deve aggiornare.
    Configurazione monitoraggio dello stato
    Figura 16.17. Configurazione monitoraggio dello stato

  3. Dall'area della console, specificare come aprire una console insieme al dispositivo input.

16.9. Visualizzazione degli identificatori del guest

Per visualizzare il guest ID per tutte le macchine virtuali presenti sul sistema:
  1. Dal menu Visualizza, selezionare la casella Domain ID.
    Visualizzazione dei guest ID
    Figura 16.18. Visualizzazione dei guest ID

  2. Il Virtual Machine Manager elenca gli ID del dominio per tutti i domini sul sistema.
    Visualizzazione degli ID del dominio
    Figura 16.19. Visualizzazione degli ID del dominio

16.10. Visualizzazione dello stato del guest

Per visualizzare lo stato di tutte le macchine virtuali sul sistema:
  1. Dal menu Visualizza, selezionare la casella Stato.
    Selezione dello stato di una macchina virtuale
    Figura 16.20. Selezione dello stato di una macchina virtuale

  2. Il Virtual Machine Manager elenca lo stato di tutte le macchine virtuali presenti sul sistema.
    Visualizzazione dello stato di una macchina virtuale
    Figura 16.21. Visualizzazione dello stato di una macchina virtuale

16.11. Visualizzazione delle CPU virtuali

Per visualizzare il numero delle CPU virtuali per tutte le macchine virtuali sul sistema:
  1. Dal menu Visualizza, selezionare la casella CPU virtuali.
    Selezione dell'opzione delle CPU virtuali
    Figura 16.22. Selezione dell'opzione delle CPU virtuali

  2. Il Virtual Machine Manager elenca le CPU virtuali per tutte le macchine virtuali presenti sul sistema.
    Visualizzazione delle CPU virtuali
    Figura 16.23. Visualizzazione delle CPU virtuali

16.12. Visualizzazione utilizzo della CPU

Per visualizzare l'utilizzo della CPU per tutte le macchine virtuali presenti sul sistema:
  1. Dal menu Visualizza, selezionare la casella Utilizzo CPU.
    Selezione utilizzo della CPU
    Figura 16.24. Selezione utilizzo della CPU

  2. Il Virtual Machine Manager elenca la percentuale di CPU in uso per tutte le macchine virtuali presenti sul sistema.
    Visualizzazione utilizzo della CPU
    Figura 16.25. Visualizzazione utilizzo della CPU

16.13. Visualizzazione utilizzo della memoria

Per visualizzare l'uso della memoria per tutte le macchine virtuali sul sistema:
  1. Dal menu Visualizza, selezionare la casella Utilizzo memoria.
    Selezione utilizzo della memoria
    Figura 16.26. Selezione utilizzo della memoria

  2. Il Virtual Machine Manager elenca la percentuale di memoria in uso (in megabyte), per tutte le macchine virtuali presenti sul sistema.
    Visualizzazione utilizzo della memoria
    Figura 16.27. Visualizzazione utilizzo della memoria

16.14. Gestione di una rete virtuale

Per configurare una rete virtuale sul sistema:
  1. Dal menu Modifica, selezionare Dettagli host.
    Selezione dettagli host
    Figura 16.28. Selezione dettagli host

  2. Verrà aperto il menu Dettagli host. A questo punto fare clic sulla scheda Reti virtuali.
    Configurazione rete virtuale
    Figura 16.29. Configurazione rete virtuale

  3. Tutte le reti virtuali disponibili vengono elencate nella casella sinistra del menu. È possibile modificare la configurazione di una rete virtuale selezionandola direttamente da questa casella e modificandola nel modo desiderato.

16.15. Creazione di una rete virtuale

Per creare una rete virtuale sul sistema:
  1. Aprire il menu Dettagli host (consultare Sezione 16.14, «Gestione di una rete virtuale») e successivamente selezionare il pulsante Aggiungi.
    Configurazione rete virtuale
    Figura 16.30. Configurazione rete virtuale

    In tal modo verrà aperto il menu Crea una nuova rete virtuale. Per continuare fare clic su Avanti.
    Creazione di una nuova rete virtuale
    Figura 16.31. Creazione di una nuova rete virtuale

  2. Inserire il nome appropriato per la propria rete virtuale e successivamente fare clic su Avanti.
    Come nominare la propria rete virtuale
    Figura 16.32. Come nominare la propria rete virtuale

  3. Inserire uno spazio per l'indirizzo IPv4 per la propria rete virtuale e fare clic su Avanti.
    Scelta di uno spazio per l'indirizzo IPv4
    Figura 16.33. Scelta di uno spazio per l'indirizzo IPv4

  4. Definire il DHCP range per la propria rete virtuale specificando un range di Inizio e Fine di indirizzi IP. Fare clic su Avanti per continuare.
    Selezione del range di DHCP
    Figura 16.34. Selezione del range di DHCP

  5. Selezionare il modo attraverso il quale una rete virtuale si collega alle rete fisica.
    Collegamento alla rete fisica
    Figura 16.35. Collegamento alla rete fisica

    Se si seleziona Inoltro ad una rete fisica, scegliere se la Destinazione debba essere NAT per qualsiasi dispositivo fisico o NAT per il dispositivo fisico eth0.
    Click Forward to continue.
  6. Ora si è in grado di creare una rete. Controllare la configurazione della propria rete e fare clic su Fine.
    Pronti per creare la rete
    Figura 16.36. Pronti per creare la rete

  7. La nuova rete virtuale sarà ora disponibile tramite la scheda Rete virtuale del menu Dettagli host.
    È ora disponibile la nuova rete virtuale
    Figura 16.37. È ora disponibile la nuova rete virtuale

Parte V. Tips and Tricks

Suggerimenti e trucchi per aumentare la produttività

Questi capitoli contengono i suggerimenti ed i consigli utili per migliorare le prestazioni, la scalabilità e stabilità.

Indice

17. Suggerimenti e trucchi
17.1. Avvio automatico dei guest
17.2. Come smistarsi tra l'hypervisor KVM e Xen
17.2.1. Da Xen a KVM
17.2.2. Da KVM a Xen
17.3. Utilizzo di qemu-img
17.4. Processo di overcommit con KVM
17.5. Modifica di /etc/grub.conf
17.6. Verifica delle estensioni per la virtualizzazione
17.7. Identificare il tipo di guest e l'implementazione
17.8. Come generare un nuovo indirizzo MAC unico
17.9. Very Secure ftpd
17.10. Come configurare la persistenza LUN
17.11. Come disabilitare lo SMART disk monitoring per i guest
17.12. Come clonare i file di configurazione del guest
17.13. Duplicazione di un guest esistente e dei suoi file di configurazione
18. Creazione script libvirt personalizzati
18.1. Come utilizzare i file di configurazione XML con virsh

Capitolo 17. Suggerimenti e trucchi

17.1. Avvio automatico dei guest
17.2. Come smistarsi tra l'hypervisor KVM e Xen
17.2.1. Da Xen a KVM
17.2.2. Da KVM a Xen
17.3. Utilizzo di qemu-img
17.4. Processo di overcommit con KVM
17.5. Modifica di /etc/grub.conf
17.6. Verifica delle estensioni per la virtualizzazione
17.7. Identificare il tipo di guest e l'implementazione
17.8. Come generare un nuovo indirizzo MAC unico
17.9. Very Secure ftpd
17.10. Come configurare la persistenza LUN
17.11. Come disabilitare lo SMART disk monitoring per i guest
17.12. Come clonare i file di configurazione del guest
17.13. Duplicazione di un guest esistente e dei suoi file di configurazione
Questo capitolo contiene i suggerimenti ed i consigli utili per migliorare le prestazioni relative alla virtualizzazione, scalabilità e stabilità.

17.1. Avvio automatico dei guest

Questa sezione affronta il metodo attraverso il quale è possibile avviare automaticamente i guest virtualizzati durante la fase d'avvio del sistema host.
Questo esempio utilizza virsh per impostare un guest, TestServer, per un avvio automatico all'avvio dell'host. 
# virsh autostart TestServer
Dominio TestServer contrassegnato come autostarted
Ora il guest esegue un avvio automatico con l'host.
Per arrestare un guest che esegue un avvio automatico usare il parametro --disable 
# virsh autostart --disable TestServer
Dominio TestServer non contrassegnato più come autostarted
Il guest non esegue più automaticamente un avvio con l'host.

17.2. Come smistarsi tra l'hypervisor KVM e Xen

Questa sezione affronta il metodo attraverso il quale è possibile smistarsi da un hypervisor KVM ad uno Xen.
Fedora supporta solo un hypervisor attivo per volta.

Migrazione di guest virtualizzati tra gli hypervisor

Per Xen al momento non è presente alcuna applicazione per lo smistamento dei guest basati su Xen o basati su KVM. I guest possono essere usati solo sul tipo di hypervisor sui quali sono stati creati.

17.2.1. Da Xen a KVM

La seguente procedura riporta le fasi necessarie per lo smistamento da un hypervisor Xen ad uno KVM. Per eseguire la suddetta procedura è necessario aver installato ed abilitato il pacchetto kernel-xen.

  1. Installare il pacchetto KVM

    Installare il pacchetto kvm se non precedentemente fatto. 
    # yum install kvm

  2. Verificare quale kernel è in esecuzione

    Il pacchetto kernel-xen potrebbe essere installato. Usare il comando uname per determinare quale kernel è in esecuzione: 
    $ uname -r
2.6.23.14-107.fc8xen
    Il kernel "2.6.23.14-107.fc8xen" è in esecuzione sul sistema. Se il kernel predefinito, "2.6.23.14-107.fc8", è in esecuzione sul sistema è possibile saltare la fase secondaria.

    1. Modifica del kernel Xen nel kernel predefinito

      Il file grub.conf determina quale kernel è stato avviato. Per modificare il kernel predefinito modificare il file /boot/grub/grub.conf come di seguito indicato. 
      default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.23.14-107.fc8)
        root (hd0,0)
        kernel /vmlinuz-2.6.23.14-107.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd /initrd-2.6.23.14-107.fc8.img
title Fedora (2.6.23.14-107.fc8xen)
        root (hd0,0)
        kernel /xen.gz-2.6.23.14-107.fc8
        module /vmlinuz-2.6.23.14-107.fc8xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        module /initrd-2.6.23.14-107.fc8xen.img
      Da notare il parametro default=1. Tale parametro indica al boot loader GRUB di avviare la seconda voce, il kernel Xen. Modificare l'impostazione predefinita in 0 (o sul numero per il kernel predefinito): 
      default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.23.14-107.fc8)
        root (hd0,0)
        kernel /vmlinuz-2.6.23.14-107.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd /initrd-2.6.23.14-107.fc8.img
title Fedora (2.6.23.14-107.fc8xen)
        root (hd0,0)
        kernel /xen.gz-2.6.23.14-107.fc8
        module /vmlinuz-2.6.23.14-107.fc8xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        module /initrd-2.6.23.14-107.fc8xen.img

  3. Eseguire un riavvio per caricare il nuovo kernel

    Riavviare il sistema. Il computer eseguirà un riavvio con il kernel predefinito. Il modulo KVM dovrebbe essere caricato automaticamente con il kernel. Verificare che KVM sia in esecuzione: 
    $ lsmod | grep kvm
kvm_intel              85992  1 
kvm                   222368  2 ksm,kvm_intel
    Il modulo kvm ed il modulo kvm_intel o kvm_amd saranno presenti se la procedura è stata corretta.

17.2.2. Da KVM a Xen

La seguente procedura rappresenta il metodo attraverso il quale è possibile smistarsi da un hypervisor KVM ad un hypervisor Xen.Tale procedura presume che il pacchetto kvm sia stato installato ed abilitato.

  1. Installare i pacchetti Xen

    Installare i pacchetti kernel-xen e xen se non precedentemente fatto. 
    # yum install kernel-xen xen
    Il pacchetto kernel-xen può essere installato e disabilitato.

  2. Verificare quale kernel è in esecuzione

    Utilizzare il comando uname per determinare quale kernel è in esecuzione. 
    $ uname -r
2.6.23.14-107.fc8
    Il kernel "2.6.23.14-107.fc8" è in esecuzione sul sistema. Questo è il kernel predefinito. Se il kernel presenta xen alla fine (per esempio 2.6.23.14-107.fc8xen) allora risulterà in esecuzione il kernel Xen; a tal proposito è possibile saltare la fase secondaria.

    1. Modifica del kernel predefinito in kernel Xen

      Il file grub.conf determina quale kernel è stato avviato. Per modificare il kernel predefinito modificare il file /boot/grub/grub.conf come di seguito indicato. 
      default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.23.14-107.fc8)
        root (hd0,0)
        kernel /vmlinuz-2.6.23.14-107.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd /initrd-2.6.23.14-107.fc8.img
title Fedora (2.6.23.14-107.fc8xen)
        root (hd0,0)
        kernel /xen.gz-2.6.23.14-107.fc8
        module /vmlinuz-2.6.23.14-107.fc8xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        module /initrd-2.6.23.14-107.fc8xen.img
      Da notare il parametro default=0. Tale parametro indica al boot loader GRUB di avviare la prima voce, il kernel predefinito. Modificate l'impostazione predefinita su 1 (o il numero corrispondente per il kernel Xen): 
      default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.23.14-107.fc8)
        root (hd0,0)
        kernel /vmlinuz-2.6.23.14-107.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd /initrd-2.6.23.14-107.fc82.6.23.14-107.fc8.img
title Fedora (2.6.23.14-107.fc8xen)
        root (hd0,0)
        kernel /xen.gz-2.6.23.14-107.fc8
        module /vmlinuz-2.6.23.14-107.fc8xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        module /initrd-2.6.23.14-107.fc8xen.img

  3. Eseguire un riavvio per caricare il nuovo kernel

    Riavviare il sistema. Il computer eseguirà il riavvio con il kernel Xen. Eseguire una verifica con il comando uname: 
    $ uname -r
2.6.23.14-107.fc8xen
    Se xen è presente alla fine dell'output allora il kernel in esecuzione sarà Xen.

17.3. Utilizzo di qemu-img

Lo strumento della linea di comando qemu-img viene usato per la formattazione di vari file system usati da Xen e KVM. qemu-img deve essere usato per la formattazione delle immagini del guest virtualizzato, dei dispositivi di storage aggiuntivi e per lo storage di rete. Le opzioni qemu-img ed il loro utilizzo sono riportati di seguito.
Formattazione e creazione di nuove immagini o dispositivi
Crearte il nuovo nome del file immagine del disco con una dimensione e formato. 
# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
Se base_image è stato specificato allora l'immagine registrerà solo le differenze di base_image. Non è necessario specificare alcuna dimensione in questo caso. base_image non sarà mai modificato a meno che non avete usato il comando monitor "commit".
Convertire una immagine esistente in un altro formato
L'opzione convert viene usata per convertire un formato conosciuto in un formato dell'immagine diverso.
Comando di formattazione: 
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
converte il nome del file dell'immagine del disco in un disk image output_filename usando il formato output_format. Esso può essere facoltativamente cifrato (opzione "-e") o compresso (opzione "-c").
solo il formato "qcow" supporta la cifratura o la compressione. Il processo di compressione è di sola-lettura. Ciò significa che se si riscrive un settore nei confronti del quale è stata eseguita una compressione, allora lo stesso viene scritto nuovamente con dati non compressi.
La cifratura utilizza un formato AES con chiavi 128 bit molto sicure. Per ottenere una protezione massima usare una password molto lunga (16 caratteri).
La conversione dell'immagine è utile anche per ottenere un'immagine più piccola quando si utilizza un formato in grado di crescere, come ad esempio qcow o cow. I settori vuoti sono rilevati ed eliminati dall'immagine di destinazione.
come ottenere le informazioni dell'immagine
il parametro info mostra le informazioni relative all'immagine del disco. Il formato per l'opzione info è il seguente: 
# qemu-img info [-f format] filename
informazioni sul nome del file dell'immagine del disco. Usaro per conoscere la dimensione riservata sul disco la quale può essere diversa dalla dimensione mostrata. Se le istantanee della vm sono state salvate sull'immagine del disco esse verranno mostrate.
Formati supportati
Il formato di una immagine viene stimato automaticamente. I seguenti formati sono supportati:
raw
Formato immagine del disco Raw (predefinito). Questo formato ha il vantaggio di essere semplice e facilmente esportabile su tutti gli altri emulatori. Se il file system in uso supporta gli holes (per esempio in ext2 o ext3 su Linux o NTFS su Windows), allora solo i settori scritti riserveranno lo spazio. Utilizzare qemu-img info per sapere la dimensione reale usata dall'immagine o ls -ls su Unix/Linux.
qcow2
Il formato dell'immagine QEMU è il formato più versatile. Usarlo per avere immagini più piccole (utile se il file system non supporta gli hole, per esempio: su Windows), cifratura AES facoltativa, compressione basata su zlib e supporto di istantanee multiple della VM.
qcow
Formato immagine QEMU vecchio. Incluso solo per compatibilità con le versioni più vecchie.
cow
Formato immagine User Mode Linux Copy On Write. Il formato cow viene incluso solo per compatibilità con le versioni precedenti. Non funziona con Windows.
vmdk
Formato immagine compatibile VMware 3 e 4.
cloop
Immagine Linux Compressed Loop utile solo per usare le immagini CD-ROM compresse presenti per esempio nei CD-ROM di Knoppix.

17.4. Processo di overcommit con KVM

L'hypervisor KVM supporta l'overcommit delle CPU e della memoria. Il processo di overcommit è quel processo attraverso il quale si assegna un numero maggiore di CPU virtualizzate o memoria rispetto alle risorse fisiche presenti sul sistema. Con un overcommit dellle CPU i desktop o i server non utilizzati al meglio possono essere eseguiti su un numero minore di server risparmiando così soldi e alimentazione.

Supporto Xen

Il processo di overcommit delle CPU non è supportato con l'hypervisor Xen. Tale processo con l'hypervisor Xen potrebbe causare l'instabilità del sistema con conseguenti arresti inaspettati dell'host e dei guest virtualizzati.
Processo di overcommit della memoria
Numerosi sistemi operativi e applicazioni non sempre utilizzano al 100% la RAM disponibile. Questo comportamento può essere corretto con KVM in modo da utilizzare più memoria per i guest virtualizzati rispetto a quella fisicamente disponibile.
Con KVM le macchine virtuali sono processi Linux. Ai guest presenti sull'hypervisor KVM non vengono assegnati blocchi di RAM fisica, al contrario essi funzionano come processi. Ad ogni processo viene assegnata memoria quando lo stesso la richiede. KVM utilizza ciò per assegnare memoria per i guest quando il sistema operativo guest richiede una quantità maggiore o minore di memoria. Il guest utilizza solo una quantità leggermente superiore di memoria fisica rispetto a quella usata dal sistema operativo virtualizzato.
Quando la memoria fisica è quasi del tutto utilizzata, o un processo risulta essere inattivo per un periodo di tempo, Linux sposta la memoria del processo su swap. Swap è generalmente una partizione su di una unità del disco fisso o su un disco allo stato solido usata da Linux per estendere la memoria virtuale. Swap è molto più lento della RAM.
Poichè le macchine virtuali sono processi Linux la memoria usata dai guest virtualizzati può essere posizionata nello swap se il guest è in uno stato di idle o se non pesantemente utilizzato. È possibile eseguire il commit della memoria usando la dimensione totale dello swap e della RAM fisica. Tale operazione potrebbe causare alcuni problemi se i guest virtualizzati utilizzano la loro RAM totale. Senza uno spazio di swap sufficiente per i processi della macchina virtuale per uno swap con il processo pdflush, verrà avviato il processo di eliminazione. pdflush eliminerà i processi per liberare la memoria necessaria in modo da evitare un arresto inaspettato del sistema. pdflush in questo caso potrebbe eliminare i guest virtualizzati o altri processi del sistema, causando la generazione di errori del file system e lasciando i guest virtualizzati non avviabili.

Warning

Se non è disponibile uno spazio di swap sufficiente i sistemi operativi guest verranno arrestati. Tale operazione potrebbe causare l'inoperatività dei guest. Per evitare tale situazione non eseguire il commit di una quantità di memoria maggiore rispetto allo spazio di swap disponibile.
La partizione di swap viene usata per scambiare la memoria non completamente utilizzata per l'hard drive ed aumentare le prestazioni della memoria. La dimensione predefinita della partizione di swap viene calcolata considerando la quantità di RAM ed il rapporto del processo di overcommit. È consigliato creare una partizione di swap più grande se si desidera eseguire l'overcommit della memoria con KVM. Un rapporto consigliato è 50% (0.5). La formula usata è la seguente: 
(0.5 * RAM) + (overcommit ratio * RAM) = Dimensione partizione swap consigliata
Il Red Hat Knowledgebase presenta un paragrafo su come determinare con efficienza e sicurezza la misura della partizione di swap — a tal proposito consultare il Knowledgebase.
È possibile l'esecuzione con un rapporto di overcommit pari a dieci volte il numero di guest virtualizzati attraverso la RAM fisica. Questo funzionerà solo con determinati carichi di lavoro (per esempio una virtualizzazione desktop con un utilizzo inferiore al 100%). L'impostazione di un rapporto per l'overcommit non è difficile, è necessario provare e personalizzare il repporto più adatto per l'ambiente in uso.
Overcommit delle CPU virtualizzate
L'hypervisor KVM supporta l'overcommit delle CPU virtualizzate. È possibile eseguire l'overcommit delle suddette CPU fino a quando consentito dai limiti di carico dei guest virtualizzati. Fate attenzione durante l'overcommit delle VCPU poichè i carichi prossimi al 100% potrebbero causare una interruzione delle richieste o tempi di risposta non utilizzabili.
Il momento più opportuno per l'esecuzione di un overcommit delle CPU virtualizzate è quando ogni guest virtualizzato ha una singola VCPU. Il Linux scheduler è molto efficiente con questo tipo di carico. KVM dovrebbe supportare in modo sicuro i guest con carichi inferiori al 100% con un rapporto di 5 VCPU. L'overcommit di guest virtualizzati VCPU singoli non rappresenta alcun problema.
Non è possibile eseguire l'overcommit dei symmetric multiprocessing guest su di un numero maggiore di core processor rispetto al numero fisico effettivo. Per esempio, un guest con quattro VCPU non dovrebbe essere eseguito su di un host con un processore dual core. L'operazione di overcommit dei symmetric multiprocessing guest su di un numero superiore di core di processazione causerà un abbassamento delle prestazioni.
L'assegnazione delle VCPU dei guest pari al numero di core fisici è appropriato e funziona come previsto. Per esempio, l'esecuzione di guest virtualizzati con quattro VCPU su di un quad core host. Con questa impostazione i guest con carichi inferiori al 100% dovrebbero funzionare in modo corretto.

Eseguire sempre prima un test

Non eseguire l'overcommit della memoria o CPU in un ambiente di produzione senza aver eseguito test approfonditi. Le applicazioni che utilizzano il 100% di memoria o delle risorse di processazione, potrebbero non essere stabili in ambienti nei quali è stato eseguito un processo di overcommit. Eseguire sempre prima un test.

17.5. Modifica di /etc/grub.conf

Questa sezione mostra come modificare correttamente ed in modo sicuro il vostro file /etc/grub.conf in modo da usare il kernel di virtualizzazione. È necessario utilizzare il kernel xen per utilizzare l'hypervisor Xen. Copiate la voce del kernel xen esistente, ed assicuratevi di copiare tutte le righe importanti o il vostro sistema potrebbe entrare in uno stato di panic durante il processo d'avvio (initrd avrà una durata di 0). È necessario specificare i valori specifici dell'hypervisor per aggiungerli sulla riga di xen della voce relativa a grub.
L'output di seguito riportato è un esempio di una voce grub.conf di un sistema sul quale viene eseguito il pacchetto kernel-xen. grub.conf sul vostro sistema potrebbe variare. La parte più importante nell'esempio è la sezione corrispondente alla riga title fino alla nuova riga successiva. 
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Fedora (2.6.23.14-107.fc8xen)
        root (hd0,0)
        kernel /xen.gz-2.6.23.14-107.fc8 com1=115200,8n1
        module /vmlinuz-2.6.23.14-107.fc8xen ro root=/dev/VolGroup00/LogVol00
        module /initrd-2.6.23.14-107.fc8xen.img

Un punto importante per la modifica di grub.conf...

Il grub.conf potrebbe essere molto diverso se è stato manualmente modificato o copiato da un esempio.
Per impostare una quantità di memoria assegnata al vostro sistema host al momento dell'avvio su 256MB, sarà necessario inserire dom0_mem=256M sulla riga xen all'interno del vostro grub.conf. Una versione modificata del file di configurazione di grub nell'esempio precedente: 
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Fedora (2.6.23.14-107.fc8xen)
        root (hd0,0)
        kernel /xen.gz-2.6.23.14-107.fc8 com1=115200,8n1 dom0_mem=256MB
        module /vmlinuz-2.6.23.14-107.fc8xen ro
        root=/dev/VolGroup00/LogVol00
        module /initrd-2.6.23.14-107.fc8xen.img

17.6. Verifica delle estensioni per la virtualizzazione

Usare questa sezione per determinare la presenza sul sistema delle estensioni di virtualizzazione hardware. Le suddette estensioni (Intel VT o AMD-V) sono necessarie per una full virtualization.

Posso usare la virtualizzazione senza avere le estensioni di virtualizzazione?

Se le estensioni della virtualizzazione hardware non sono presenti è possibile usare Xen para-virtualization con il pacchetto kernel-xen di fedora.
Eseguire il seguente comando per la verifica della disponibilità delle estensioni per la virtualizzazione della CPU: 
$ grep -E 'svm|vmx' /proc/cpuinfo
Il seguente output contiene una voce vmx la quale indica un processore Intel con estensioni Intel VT: 
flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush 
        dts acpi mmx fxsr sse sse2 ss ht  tm syscall lm constant_tsc pni monitor ds_cpl
        vmx est tm2 cx16 xtpr lahf_lm
Il seguente output contiene una voce svm la quale indica un processore AMD con estensioni AMD-V: 
flags   :  fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush
        mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16
        lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
Il contenuto di "flags:" potrebbe apparire numerose volte per ogni hyperthread, core o CPU sul sistema.
Le estensioni per la virtualizzazione possono essere disabilitate nel BIOS. Se le suddette estensioni non sono presenti o se full virtualization non funziona correttamente consultare Procedura 19.1, «Come abilitare le estensioni di virtualizzazione nel BIOS».

17.7. Identificare il tipo di guest e l'implementazione

Lo script di seguito riportato è in grado di identificare se un ambiente, un'applicazione o uno scirpt è in esecuzione su di un guest completamente virtualizzato o para-virtualizzato o su di un hypervisor. 
#!/bin/bash
declare -i IS_HVM=0
declare -i IS_PARA=0
check_hvm()
{
        IS_X86HVM="$(strings /proc/acpi/dsdt | grep int-xen)"
          if [ x"${IS_X86HVM}" != x ]; then
           echo "Guest type is full-virt x86hvm"
           IS_HVM=1
        fi
}
check_para()
{
        if $(grep -q control_d /proc/xen/capabilities); then
          echo "Host is dom0"
          IS_PARA=1
        else
          echo "Guest is para-virt domU"
          IS_PARA=1
        fi
}
if [ -f /proc/acpi/dsdt ]; then 
        check_hvm
fi

if [ ${IS_HVM} -eq 0 ]; then
        if [ -f /proc/xen/capabilities ] ; then
                check_para
        fi
     fi
if [ ${IS_HVM} -eq 0 -a ${IS_PARA} -eq 0 ]; then
        echo "Baremetal platform"
fi

Analisi di un host

Per l'analisi degli host usare il comando virsh capabilites.

17.8. Come generare un nuovo indirizzo MAC unico

In alcuni casi sarà necessario generare per un guest un nuovo ed unico Indirizzo MAC. Attualmente non vi è alcuno strumento della linea di comando disponibile per generare un nuovo indirizzo MAC. Lo script di seguito indicato è in grado di generare un nuovo indirizzo MAC per i guest. Salvare lo script sul vostro guest come macgen.py. Ora dalla directory in questione è possibile eseguire lo script usando ./macgen.py, generando così un nuovo indirizzo MAC. Un esempio di output dovrebbe somigliare al seguente: 
$ ./macgen.py 
00:16:3e:20:b0:11
        
#!/usr/bin/python
# macgen.py script to generate a MAC address for virtualized guests on Xen
#
import random
#
def randomMAC():
        mac = [ 0x00, 0x16, 0x3e,
                random.randint(0x00, 0x7f),
                random.randint(0x00, 0xff),
                random.randint(0x00, 0xff) ]
        return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()
Metodo alternativo per la generazione di un nuovo MAC per il vostro guest
È possibile utilizzare anche i moduli interni di python-virtinst per generare un nuovo indirizzo MAC e UUID, per un utilizzo all'interno del file di configurazione: 
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
Lo script indicato può essere implementato anche come un file di script simile a quello riportato di seguito. 
#!/usr/bin/env python
#  -*- mode: python; -*-
print ""
print "New UUID:"
import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID())
print "New MAC:"
import virtinst.util ; print virtinst.util.randomMAC()
print ""

17.9. Very Secure ftpd

vsftpd fornisce l'accesso necessario agli alberi d'installazione per i guest paravirtualizzati o altri dati. Se non è stato ancora installato vsftpd durante l'installazione del server, è possibile ottenere il pacchetto RPM dalla directory Server del dispositivo d'installazione, ed installarlo usando rpm -ivh vsftpd*.rpm (da notare che il pacchetto RPM deve essere presente all'interno della directory corrente).
  1. Per configurare vsftpd, modificate /etc/passwd usando vipw, e cambiate la home directory dell'utente ftp con la directory che utilizzerete per conservare gli alberi d'installazione per i guest para-virtualizzati. Un esempio di voce per l'utente FTP sarà simile alla seguente: 
    ftp:x:14:50:FTP User:/xen/pub:/sbin/nologin
  2. per avviare automaticamente vsftpd durante l'avvio del sistema, usare la utilità chkconfig per abilitare vsftpd a questo procedimento.
  3. verificare che vsftpd non sia stato abilitato usando chkconfig --list vsftpd: 
    $ chkconfig --list vsftpd
vsftpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
  4. eseguire chkconfig --levels 345 vsftpd on per avviare vsftpd automaticamente per i runlevel 3, 4 e 5.
  5. utilizzare il comando chkconfig --list vsftpd per verificare che vsftdp sia stato abilitato all'avvio durante il processo di boot del sistema: 
    $ chkconfig --list vsftpd
vsftpd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
  6. utilizzare service vsftpd start vsftpd per l'avvio del servizio vsftpd: 
    $service vsftpd start vsftpd
Starting vsftpd for vsftpd:                  [  OK  ]

17.10. Come configurare la persistenza LUN

Questa sezione affronta come implementare la persistenza LUN nei guest e sulle macchine host con o senza multipath.
Implementazione persistenza LUN senza multipath
Se il proprio sistema non utilizza multipath allora usare udev per l'implementazione della persistenza LUN. Prima di implementare la persistenza LUN nel sistema, assicurarsi di aver acquisito gli UUID corretti. Fatto questo, sarà possibile configurare la persistenza LUN modificando il file scsi_id il quale risiede nella directory /etc . Una volta aperto il file con un editor di testo, decommentate la seguente riga: 
# options=-b
Successivamente sostituirla con questo parametro: 
# options=-g
Ciò indicherà a udev di monitorare tutti i dispositivi SCSI del sistema per gli UUID ritornati. Per determinare gli UUID del sistema utilizzare il comando scsi_id: 
# scsi_id -g -s /block/sdc
*3600a0b80001327510000015427b625e*
Questa stringa molto lunga di caratteri rappresenta l'UUID. Gli UUID non cambiano quando aggiungete un nuovo dispositivo al vostro sistema; acquisite l'UUID per ogni dispositivo in modo da creare le regole per i dispositivi. Per creare nuove regole del dispositivo modificare il file 20-names.rules nella directory /etc/udev/rules.d Le regole usate per nominare il dispositivo devono seguire il seguente formato: 
# KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="UUID", NAME="devicename"
Sostituire l'UUID e devicename con la voce dell'UUID sopra riportato. Quindi la regola dovrebbe somigliare alla seguente: 
KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="3600a0b80001327510000015427b625e", NAME="mydevicename"
Ciò causerà da parte del sistema l'abilitazione di tutti i dispositivi che corrispondono a /dev/sd* in modo da controllare l'UUID dato. Una volta trovato un dispositivo corrispondente, esso creerà un nodo del dispositivo chiamato /dev/devicename. Per questo esempio il nodo del dispositivo è /dev/mydevice . Per finire, sarà necessario aggiungere al file /etc/rc.local la seguente stringa: 
/sbin/start_udev
Implementazione persistenza LUN con multipath
Per implementare la persistenza LUN in un ambiente multipath, sarà necessario definire i nomi degli alias per i dispositivi multipath. Per questo esempio definite quattro alias del dispositivo modificando il file multipath.conf che risiede nella directory /etc/: 
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp1
}
multipath  {  
             wwid       3600a0b80001327510000015427b6
             alias      oramp2
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp3
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp4
}
Ciò definisce 4 LUN: /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3, e dev/mpath/oramp4. I dispositivi risiederanno nella directory /dev/mpath . I nomi dei LUN resteranno invariati anche dopo aver eseguito diversi processi di riavvio, poichè i suddetti nomi verranno creati sul wwid dei LUN.

17.11. Come disabilitare lo SMART disk monitoring per i guest

Lo SMART disk monitoring può essere disabilitato durante l'esecuzione sui dischi virtuali mentre lo storage fisico viene gestito dall'host. 
/sbin/service smartd stop
/sbin/chkconfig --del smartd

17.12. Come clonare i file di configurazione del guest

Copiare un file di configurazione esistente in modo da creare un nuovo guest. Modificare il parametro del nome del file di configurazione del guest. Il nuovo nome unico apparirà nell'hypervisor e sarà visibile alle utilità di gestione. Generare un UUID nuovo utilizzando il comando uuidgen. Successivamente per le voci vif definire un indirizzo MAC unico per ogni guest (se si copia una configurazione del guest da un guest esistente creare uno script per la sua gestione). Per le informazioni relative al brigde di Xen, se si sposta un file di configurazione del guest esistente su di un nuovo host, sarà necessario aggiornare la voce xenbr in modo da corrispondere alla configurazione di networking locale. Per le voci relative al dispositivo sarà necessario modificare le voci presenti nella sezione 'disk=' per indicare l'immagine del guest corretto.
Modificare altresì sul proprio guest le impostazioni relative alla configurazione del sistema. Identificare la voce HOSTNAME del file /etc/sysconfig/network per corrispondere all'hostname del nuovo guest.
Modificare l'indirizzo HWADDR del file /etc/sysconfig/network-scripts/ifcfg-eth0 per corrispondere all'output generato dal file ifconfig eth0, e se si utilizzano gli indirizzi IP statici, modificare la voce IPADDR.

17.13. Duplicazione di un guest esistente e dei suoi file di configurazione

Questa sezione affronta come copiare un file di configurazione esistente in modo da creare un nuovo guest. Prestare molta attenzione ad alcuni parametri molto importanti all'interno del file di configurazione del proprio guest i quali devono essere modificati per duplicare con successo un guest.
name
Il nome del proprio guest come conosciuto dall'hypevisor e mostrato nelle utilità di gestione. Questa voce dovrebbe essere unica sul sistema.
uuid
Una gestione unica per il guest, è possibile rigenerare un nuovo UUID utilizzando il comando uuidgen. Esempio di output UUID: 
$ uuidgen 
a984a14f-4191-4d14-868e-329906b211e5
vif
  • L'indirizzo MAC deve definire un indirizzo MAC unico per ogni guest. Tale processo viene eseguito automaticamente se si usano gli strumenti standard. Se si copia una configurazione guest da un guest esistente sarà possibile usare lo script Sezione 17.8, «Come generare un nuovo indirizzo MAC unico».
  • Se si desidera muovere o duplicare un file di configurazione esistente del guest sul nuovo host assicurarsi di modificare la voce xenbr, in modo che essa corrisponda alla propria configurazione di networking locale (è possibile ottenere le informazioni del bridge usando il comando brctl show).
  • Voci del dispositivo, assicurarsi di modificare le voci presenti nella sezione disk=, in modo da indicare l'immagine del guest corretto.
Modificare ora le impostazioni della configurazione del sistema sul proprio guest:
/etc/sysconfig/network
Modificare la voce HOSTNAME con il nuovo hostname del guest.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • Modificare l'indirizzo HWADDR con l'output di ifconfig eth0
  • Modificare la voce IPADDR se si usa un indirizzo IP statico.

Capitolo 18. Creazione script libvirt personalizzati

18.1. Come utilizzare i file di configurazione XML con virsh
Questa sezione contiene le informazioni utili per programmatori ed amministratori di sistema per la scrittura di script personalizzati atti a facilitare il proprio compito utilizzando libvirt.
Capitolo 17, Suggerimenti e trucchi ne è consigliata la lettura ai programmatori che desiderano creare nuove applicazioni in grado di utilizzare libvirt.

18.1. Come utilizzare i file di configurazione XML con virsh

virsh è in grado di gestire i file di configurazione XML. È possibile utilizzarlo per facilitare lo script di implementazioni molto grandi con opzioni speciali. Sarà possibile aggiungere i dispositivi definiti in un file XML su di un guest paravirtualizzato in esecuzione. Per esempio per aggiungere un file ISO come hdc su di un guest in esecuzione sarà necessario creare un file XML: 
# cat satelliteiso.xml
<disk type="file" device="disk">
        <driver name="file"/>
        <source file="/var/lib/libvirt/images/rhn-satellite-5.0.1-11-redhat-linux-as-i386-4-embedded-oracle.iso"/>
        <target dev="hdc"/>
        <readonly/>
</disk>
Eseguire virsh attach-device per collegare ISO come hdc ad un guest chiamato "satellite" : 
# virsh attach-device satellite satelliteiso.xml

Parte VI. Troubleshooting

Introduzione all'individuazione ed alla risoluzione dei problemi

I seguenti capitoli forniscono le informazioni necessarie per assistervi alla risoluzione dei problemi che potreste incontrare durante l'utilizzo della virtualizzazione.

Note importanti sulle problematiche relative alla virtualizzazione

Il problema potrebbe non essere presente all'interno di questa guida a causa di un continuo processo di sviluppo il quale crea e corregge eventuali bug. Per avere l'elenco più aggiornato di bug conosciuti, problematiche e bug fix consultare le Note di rilascio di Fedora per la versione ed architettura hardware desiderate. Le Note di rilascio sono disponibili nella sezione di documentazione del sito web di Fedora, http://docs.fedoraproject.org.

Indice

19. Troubleshooting
19.1. Errori del dispositivo loop
19.2. Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS

Capitolo 19. Troubleshooting

19.1. Errori del dispositivo loop
19.2. Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS
Questo capitolo affronta i problemi e le soluzioni comuni con Fedora virtualization.

19.1. Errori del dispositivo loop

Se si utilizzano le immagini del guest basate sul file, allora potrebbe essere necessario aumentare il numero di dispositivi loop configurati. La configurazione predefinita permette fino ad un massimo di 8 dispositivi loop attivi. Se è necessario un numero superiore a 8 guest basati sul file o dispositivi loop, il numero di dispositivi loop configurati potrà essere modificato in /etc/modprobe.conf. Modificare /etc/modprobe.conf ed aggiungere la seguente riga: 
options loop max_loop=64
Questo esempio ne utilizza 64 ma è possibile specificare un altro numero per impostare il valore loop massimo. Altresì, è possibile implementare i loop device backed guest sul proprio sistema. Per impostare i loop device backed guest per un guest paravirtualizzato usare i comandi phy: block device o tap:aio. Per implementare i loop device backed guest per un sistema completamente virtualizzato utilizzare i comandi phy: device o file: file .

19.2. Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS

Questa sezione descrive il metodo attraverso il quale identificare le estensioni di virtualizzazione hardware abilitandole nel BIOS se risultano disabilitate.
Le estensioni Intel VT possono essere disabilitate nel BIOS. Alcuni rivenditori di portatili hanno disabilitato le estensioni Intel VT per impostazione predefinita nelle rispettive CPU.
Le estensioni di virtualizzazione non possono essere disabilitate nel BIOS per AMD-V (processori installati in un socket Rev 2).
Le estensioni per la virtualizzazione vengono talvolta disabilitate nel BIOS generalmente dalle case costruttrici di portatili. Consultare la Sezione 19.2, «Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS» per maggiori informazioni su come abilitare le estensioni per la virtualizzazione disabilitate.
Come prima cosa verificare se le estensioni di virtualizzazione sono state abilitate nel BIOS. Le impostazioni del BIOS per Intel® VT o AMD-V sono generalmente nei menu Chipset o Processore. Tuttavia queste impostazioni possono essere nascoste sotto altri menu non standard come ad esempio Impostazioni di sicurezza.
Procedura 19.1. Come abilitare le estensioni di virtualizzazione nel BIOS
  1. Riavviare il computer ed aprire il menu BIOS del sistema. Per fare questo premere delete o Alt + F4.
  2. Selezionare Ripristina predefiniti, e successivamente selezionare Salva & Esci.
  3. Spegnere la macchina e disconnettere l'alimentazione.
  4. Successivamente accendere la macchina ed aprire Utilità impostazione del BIOS. Aprire la sezione Processore ed abilitare Intel®Virtualization Technology o AMD-V. I valori possono essere chiamati Estensioni per la virtualizzazione su alcune macchine. Selezionare Salva & Esci.
  5. Spegnere la macchina e disconnettere l'alimentazione.
  6. Eseguire il comando cat /proc/cpuinfo | grep vmx svm. Se il comando genera un output ciò indicherà che le estensioni di virtualizzazione sono state abilitate. Se tale output risulta assente ciò indicherà che le estensioni di virtualizzazione o l'impostazione corretta del BIOS potrebbero non essere abilitati.

Risorse aggiuntive

Per saperne di più sulla virtualizzazione e Linux consultare le seguenti risorse.

A.1. Risorse online

  • http://www.cl.cam.ac.uk/research/srg/netos/xen/ Il sito web del progetto Xen™ para-virtualization machine manager dal quale deriva il pacchetto kernel-xen di Fedora. Il sito gestisce i binari dell'upstream del progetto xen ed il codice sorgente insieme alle informazioni, alle panoramiche sulle architetture, alla documentazione ed ai link relativi riguardanti xen e le tecnologie ad esso associate.
  • Il sito web di Xen Community
    http://www.xen.org/
  • http://www.libvirt.org/ è il sito web ufficiale per l'API di virtualizzazione libvirt.
  • http://virt-manager.et.redhat.com/ è il sito web del progetto per il Virtual Machine Manager (virt-manager), l'applicazione grafica per la gestione delle macchine virtuali.

A.2. Documentazione installata

  • /usr/share/doc/xen-<version-number>/ è la directory che contiene numerose informazioni sull'hypervisor para-virtualization di Xen, sui tool di gestione associati, presenta altresì numerosi esempi di configurazione, informazioni specifiche sull'hardware, e la documentazione per l'utente upstream di Xen corrente.
  • man virsh e /usr/share/doc/libvirt-<version-number> — Contiene i sottocomandi e le opzioni per la utility di gestione della macchina virtuale virsh, insieme alle informazioni complete sull'API della libreria di virtualizzazione libvirt.
  • /usr/share/doc/gnome-applet-vm-<version-number> — La documentazione per l'applet del pannello grafico di GNOME, che controlla e gestisce macchine virtuali in esecuzione in modo locale.
  • /usr/share/doc/libvirt-python-<version-number> — Fornisce le informazioni sui binding di Python per la libreria libvirt. Il pacchetto libvirt-python permette agli sviluppatori di python di creare i programmi che interfacciano la libreria di gestione della virtualizzazione libvirt.
  • /usr/share/doc/python-virtinst-<version-number> — Fornisce la documentazione sul comando virt-install di ausilio durante l'avvio delle installazioni di Fedora e delle distribuzioni Linux all'interno delle macchine virtuali.
  • /usr/share/doc/virt-manager-<version-number> — Fornisce una documentazione sul Virtual Machine Manager, il quale fornisce un tool grafico per la gestione delle macchine virtuali.

Cronologia

Diario delle Revisioni
Revisione 12.1.3Mon Oct 12 2009Christopher Curran
Divisione da Red Hat Enterprise Linux 5.4 Virtualization Guide versione 5.4-61.

Colophon

Questo manuale è stato scritto in un formato DocBook XML v4.3.
Questo libro si basa sul lavoro svolto da Jan Mark Holzer e Chris Curran.
Altri crediti vanno a:
Publican, il tool di pubblicazione attraverso il quale è stato prodotto questo manuale, compilato da Jeffrey Fearn.
Il Red Hat Localization Team consiste nelle seguenti persone:

Glossario

Questo glossario intende definire i termini usati nella Installation Guide.
Bare-metal
Il termine bare-metal si riferisce all'architettura fisica sottostante di un computer. L'esecuzione di un sistema operativo in modalità bare-metal è un altro modo attraverso il quale si fa riferimento all'esecuzione di una versione non modificata del sistema operativo sull'hardware fisico. Gli esempi di sistemi operativi in esecuzione in modalità bare metal sono dom0 o un sistema operativo installato normalmente.
dom0
Anche conosciuto come Host o sistema operativo host.
dom0 si riferisce all'istanza dell'host di Linux che esegue Hypervisor, il quale facilita il processo di virtualizzazione dei sistemi operativi guest. Dom0 viene eseguito su, e gestisce, l'hardware fisico e l'assegnazione delle risorse per se e per i sistemi operativi guest.
Domains
domU e Domains sono entrambi dei domini. I domini vengono eseguiti su Hypervisor. Il termine dominio ha un significato simile a Macchine virtuali, ed i due sono tecnicamente intercambiabili. Un dominio è una Virtual Machine.
domU
domU si riferisce al sistema operativo guest il quale viene eseguito sul sistema host (Domains).
Full virtualization
Xen e KVM possono utilizzare full virtualization. Il Full virtualization utilizza caratteristiche hardware del processore per fornire un'astrazione totale del sistema fisico sottostante (Bare-metal), e crea un nuovo sistema virtuale nel quale i sistemi operativi guest possono essere eseguiti. Non è necessaria alcuna modifica nel sistema operativo guest. Il sistema operativo guest e qualsiasi applicazione presente sul guest, non è a conoscenza dell'ambiente virtualizzato e vengono eseguiti normalmente. Il Para-virtualization richiede una versione modificata del sistema operativo di Linux.
Completamente virtualizzato
Consultare Full virtualization.
Sistema guest
Conosciuti anche come guest, macchine virtuali o domU.
Hardware Virtual Machine
Consultare Full virtualization
Hypervisor
L'hypervisor rappresenta il livello software in grado di estrarre l'hardware dal sistema operativo e quindi di permettere ai sistemi operativi multipli di essere eseguiti sullo stesso hardware. L'hypervisor viene eseguito sul sistema operativo host e permette così l'esecuzione di altri sistemi operativi virtualizzati sull'hardware dell'host.
Host
Il sistema operativo host conosciuto anche come dom0.
L'ambiente del sistema operativo host esegue il software di virtualizzazione per i sistemi guest Para-virtualizzato e per Completamente virtualizzato.
I/O
Abbreviazione per input/output (pronunciato "eye-oh"). Il termine I/O viene usato per descrivere qualsiasi programma, operazione o dispositivo in grado di trasferire dati da o per un computer, e da o per un dispositivo periferico. Ogni trasferimento è un output da un dispositivo ed un input per un altro dispositivo. I dispositivi come ad esempio le tastiere ed i mouse, sono dispositivi di solo input, mentre dispositivi come le stampanti sono dispositivi di solo output. Un CD-ROM scrivibile è un dispositivo input e output.
Kernel-based Virtual Machine
KVM (Kernel-based Virtual Machine) è una soluzione Full virtualization per Linux su hardware AMD64 e Intel 64. VM è un modulo del kernel di Linux creato per il kernel Linux standard. KVM è in grado di eseguire multipli guest di Windows virtualizzati e non modificati e sistemi operativi Linux. KVM è un hypervisor il quale utilizza i tool di virtualizzazione di libvirt (virt-manager e virsh).
KVM è un set di moduli kernel di Linux in grado di gestire i dispositivi, la memoria e le API di gestione per il modulo Hypervisor. I guest virtualizzati vengono eseguiti come processi Linux e thread e controllati dai suddetti moduli.
LUN
Un Logical Unit Number (LUN) è il numero assegnato ad una unità logica (una entità del protocollo SCSI).
Migrazione
La migrazione è un processo in cui un guest virtualizzato viene spostato da un host all'altro. Tale processo può essere eseguito offline (dove il guest risulta sospeso e successivamente spostato) o live (dove il guest viene spostato senza alcuna sospensione). A tal proposito è possibile migrare i guest completamente virtualizzati e paravirtualizzati di Xen ed i guest completamente virtualizzati di KVM.
La migrazione rappresenta una funzione molto importante nella virtualizzazione poiché il software viene completamente separato dall'hardware. Questo processo è utile per:
  • Load balancing - guests can be moved to hosts with lower usage when a host becomes overloaded.
  • Hardware failover - when hardware devices on the host start to fail, guests can be safely relocated so the host can be powered down and repaired.
  • Energy saving - guests can be redistributed to other hosts and host systems powered off to save energy and cut costs in low usage periods.
  • Geographic migration - guests can be moved to another location for lower latency or in serious circumstances.
Lo storage 'networked' condiviso viene usato per il salvataggio delle immagini del guest. Senza la migrazione dello storage condiviso tale operazione non è possibile.
An offline migration suspends the guest then moves an image of the guests memory to the destination host. The guest is resumed on the destination host and the memory the guest used on the source host is freed.
Il tempo necessario per una migrazione offline dipende dalla larghezza di banda e dalla latenza. Un guest con 2GB di memoria necessita di diversi secondi su di un link Ethernet di 1 Gbit.
Una migrazione live mantiene il guest in esecuzione sull'host sorgente ed inizia il processo di migrazione senza arrestare il guest. Tutte le pagine della memoria modificate vengono rilevate ed inviate alla destinazione dopo aver inviato l'immagine. La memoria viene aggiornata con le pagine modificate. Questo processo continua fino a quando si raggiunge comportamenti euristici; il processo è riuscito a copiare tutte le pagine o l'origine cambia troppo velocemente e l'host di destinazione non riesce a fare progressi. Se si verificano tali comportamenti il guest verrà brevemente arrestato sull'host sorgente e verranno inviati i buffer insieme ai registri. I registri vengono caricati sul nuovo host ed il guest riavviato sull'host di destinazione. Se è impossibile eseguire il merge del guest (tale comportamento si verifica se il guest presenta carichi molto elevati), il guest viene arrestato e subito dopo verrà eseguita una migrazione offline.
Il tempo necessario per una migrazione offline dipende dalla larghezza di banda, latenza ed attività del guest. Se il guest utilizza una quantità significativa di I/O o CPU, il processo di migrazione richiederà un periodo più lungo.
Indirizzi MAC
Il Media Access Control Address è l'indirizzo hardware per un Network Interface Controller. In un contesto di virtualizzazione, gli indirizzi MAC devono essere generati per le interfacce di rete virtuali con un MAC unico presente sul vostro dominio locale.
Para-virtualization
Il para-virtualization utilizza un kernel speciale, talvolta riferito come xen kernel o pacchetto kernel-xen. I kernel del guest paravirtualizzato vengono eseguiti contemporaneamente sull'host durante l'utilizzo delle librerie e dei dispositivi dell'host. Una installazione para-virtualizzata avrà un accesso completo a tutti i dispositivi presenti sul sistema e può essere limitato attraverso le impostazioni di sicurezza (SELinux e file control). Il para-virtualization risulta essere molto più veloce di un full virtualization e può essere usato con ottimi risultati per il bilanciamento del carico, il provisioning, e per un consolidamento della sicurezza.
Dall'introduzione di Fedora 9 non sarà più necessario un kernel speciale. Una volta accettata questa patch all'interno dell'albero principale di Linux, tutti i kernel di Linux con una versione più recente, avranno il para-virtualization abilitato o disponibile.
Para-virtualizzato
Consultare Para-virtualization,
Driver para-virtualizzati
I driver para-virtualizzati sono driver del dispositivo i quali operano su guest linux completamente virtualizzati. I suddetti driver aumentano le prestazioni I/O dei dispositivi a blocchi e di rete per guest completamente virtualizzati.
Security Enhanced Linux
Abbreviazione di Security Enhanced Linux, SELinux usa i Linux Security Module (LSM) nel kernel di Linux per fornire una gamma di privilegi minimi necessari per le politiche sulla sicurezza.
Universally Unique Identifier
L'Universally Unique Identifier (UUID) è un metodo di numerazione per dispositivi, sistemi e per alcuni componenti software in ambienti informatici distribuiti. Nella virtualizzazione gli UUID includono: identificatori per file system ext2 e ext3, identificatori per dispositivi RAID, identificatori per dispositivi iSCSI e LUN, indirizzi MAC ed identificatori per macchine virtuali.
Virtualization
Virtualizzazione è un termine informatico il quale indica un software in esecuzione, generalemente sistemi operativi, contemporaneamente ed isolati da altri programmi su di un sistema. Numerose implementazioni utilizzano un hypervisor, un livello software al di sopra del sistema operativo, per estrarre l'hardware. L'hypervisor permette l'esecuzione di sistemi operativi multipli sullo stesso sistema virtuale conferendo al sistema operativo guest hardware virtualizzato. Sono presenti diversi metodi per la virtualizzazione dei sistemi operativi:
  • La virtualizzazione hardware-assistita è una tecnica usata per la full virtualization con Xen e KVM (definizione: Full virtualization)
  • Para-virtualization rappresenta una tecnica usata da Xen per l'esecuzione di guest di Linux (definizione: Para-virtualization)
  • Software di virtualizzazione o emulazione. Il software di virtualizzazione utilizza una traduzione dei binari ed altre tecniche di emulazione per eseguire sistemi operativi non modificati. Questo software è molto più lento della virtualizzazione hardware-assistita o della para-virtualizzazione.
Virtualized CPU
Un sistema presenta un numero di virtual CPU (VCPU) relativi al numero di processori core fisici. Il numero di virtual CPU è un numero finito e rappresenta il numero totale di virtual CPU assegnabile alle macchine virtuali del guest.
Macchine virtuali
Una macchina virtuale è una implementazione software di una macchina fisica o di linguaggi di programmazione (per esempio Java Runtime Environment o LISP). Le macchine virtuali, in un contesto di virtualizzazione, sono sistemi operativi in esecuzione su hardware virtualizzati.
Xen
Fedora supporta l'hypervisor Xen e KVM (consultare Kernel-based Virtual Machine). Entrambi gli hypervisor hanno architetture ed approcci diversi. L'hypervisor Xen viene eseguito al di sotto di un sistema operativo Linux Il quale funge come host di gestione delle risorse del sistema e delle API di virtualizzazione. L'host è anche conosciuto come dom0 o Domain0.