Product SiteDocumentation Site

Red Hat Enterprise Linux 5

Virtualization Guide

Virtualization Documentation

Edizione 5.8

Red Hat Engineering Content Services

Nota Legale

Copyright © 2008, 2009, 2010, 2011, 2012 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/. 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.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.


1801 Varsity Drive
 RaleighNC 27606-2072 USA
 Phone: +1 919 754 3700
 Phone: 888 733 4281
 Fax: +1 919 754 3701

Sommario
The Red Hat Enterprise Linux Virtualization Guide contains information on installation, configuring, administering, and troubleshooting virtualization technologies included with Red Hat Enterprise Linux.

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. We need your feedback
3.1. Technical review requests
4. What is Virtualization?
5. Types of Virtualization
5.1. Full Virtualization
5.2. Para-Virtualization
5.3. Para-virtualized drivers
6. How CIOs should think about virtualization
I. Requisiti e limitazioni per la virtualizzazione su piattaforme Red Hat Enterprise Linux
1. Requisiti del sistema
2. Supporto e restrizioni di Xen
3. Supporto e restrizioni di KVM
4. Hyper-V restrictions and support
5. Limiti della virtualizzazione
5.1. Limitazioni generali per la virtualizzazione
5.2. LImitazioni KVM
5.3. Limitazione di Xen
5.4. Limiti dell'applicazione
II. Installazione
6. Installazione dei pacchetti di virtualizzazione
6.1. Installazione di Xen con una nuova installazione di Red Hat Enterprise Linux
6.2. Installazione dei pacchetti Xen su di un sistema Red Hat Enterprise Linux esistente
6.3. Installazione di KVM con una nuova installazione Red Hat Enterprise Linux
6.4. Installazione dei pacchetti KVM su di un sistema Red Hat Enterprise Linux esistente
7. Panoramica installazione del guest virtualizzato
7.1. Creazione di un guest con virt-install
7.2. Creazione di un guest con virt-manager
7.3. Installazione dei guest con PXE
8. Procedure per l'installazione del sistema operativo guest
8.1. Installazione di Red Hat Enterprise Linux 5 come guest para-virtualizzato
8.2. Installazione di Red Hat Enterprise Linux 5 come guest completamente virtualizzato
8.3. Installazione di Windows XP come guest completamente virtualizzato
8.4. Installazione di Windows Server 2003 come guest completamente virtualizzato
8.5. Installazione di Windows Server 2008 come guest completamente virtualizzato
III. Configurazione
9. Virtualized storage devices
9.1. Creazione di un controllore del dischetto floppy virtualizzato
9.2. Come aggiungere dispositivi di storage sui guest
9.3. Come configurare uno storage persistente in Red Hat Enterprise Linux 5
9.4. Aggiungere un dispositivo DVD o CD-ROM virtualizzato ad un guest
10. Configurazione di rete
10.1. Network address translation (NAT) con libvirt
10.2. Bridged networking con libvirt
11. Pre-Red Hat Enterprise Linux 5.4 Xen networking
11.1. Come configurare bridge multipli di rete per il guest per l'utilizzo di schede ethernet multiple.
11.2. Configurazione di rete per laptop con Red Hat Enterprise Linux 5.0
12. Driver paravirtualizzati Xen
12.1. Requisiti del sistema
12.2. Supporto e restrizioni per il para-virtualization
12.3. Installazione dei driver paravirtualizzati
12.3.1. Fasi comuni del processo d'installazione
12.3.2. Installazione e configurazione di driver para-virtualizzati su Red Hat Enterprise Linux 3
12.3.3. Installazione e configurazione dei driver para-virtualizzati su Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Configurazione dei driver di rete para-virtualizzati
12.5. Configurazione hardware para-virtualizzata aggiuntiva
12.5.1. Interfacce di rete virtualizzate
12.5.2. Dispositivi di storage virtuali
13. Driver para-virtualizzati KVM
13.1. Installazione dei driver paravirtualizzati Windows di KVM
13.2. Installing drivers with a virtualized floppy disk
13.3. Utilizzo dei driver paravirtualizzati KVM per dispositivi esistenti
13.4. Utilizzo dei driver paravirtualizzati KVM per nuovi dispositivi
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Gestione dell'ora del guest KVM
IV. Amministrazione
17. Pratiche consigliate per il server
18. Sicurezza per la virtualizzazione
18.1. Storage security issues
18.2. SELinux e virtualizzazione
18.3. SELinux
18.4. Virtualization firewall information
19. Gestione dei guest utilizzando xend
20. Migrazione live di Xen
20.1. Un esempio di migrazione live
20.2. Configurazione della migrazione live del guest
21. Migrazione Live KVM
21.1. Requisiti per una migrazione live
21.2. Esempio di storage condiviso: NFS per una semplice migrazione
21.3. Migrazione KVM live con virsh
21.4. Migrazione con virt-manager
22. Gestione remota dei guest virtualizzati
22.1. Gestione remota con SSH
22.2. Gestione remota attraverso TLS e SSL
22.3. Modalità di trasporto
V. Virtualization Storage Topics
23. Using shared storage with virtual disk images
23.1. Using iSCSI for storing virtual disk images
23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux
23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install
VI. Virtualization Reference Guide
24. Tool per la virtualizzazione
25. Gestione dei guest con virsh
26. Gestione dei guest con Virtual Machine Manager (virt-manager)
26.1. The Add Connection window
26.2. Finestra principale del Virtual Machine Manager
26.3. The guest Overview tab
26.4. Console grafica della macchina virtuale
26.5. Avvio di virt-manager
26.6. Ripristino di una macchina salvata
26.7. Visualizzazione delle informazioni sul guest
26.8. Monitoraggio dello stato
26.9. Visualizzazione degli identificatori del guest
26.10. Displaying a guest's status
26.11. Visualizzazione delle CPU virtuali
26.12. Visualizzazione utilizzo della CPU
26.13. Visualizzazione utilizzo della memoria
26.14. Gestione di una rete virtuale
26.15. Creazione di una rete virtuale
27. Riferimento rapido del comando xm
28. Configurazione dei parametri d'avvio del kernel di Xen
29. Configurazione di ELILO
30. libvirt configuration reference
31. File di configurazione di Xen
VII. Suggerimenti e trucchi
32. Suggerimenti e trucchi
32.1. Avvio automatico dei guest
32.2. Come selezionare un hypervisor tra KVM e Xen
32.2.1. Da Xen a KVM
32.2.2. Da KVM a Xen
32.3. Utilizzo di qemu-img
32.4. Overcommitting Resources
32.5. Modifica di /etc/grub.conf
32.6. Verifica delle estensioni per la virtualizzazione
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. Come generare un nuovo indirizzo MAC unico
32.10. Come limitare la larghezza di banda della rete per un guest Xen
32.11. Configurazione delle affinità del processore Xen
32.12. Come modificare l'hypervisor Xen
32.13. Very Secure ftpd
32.14. Come configurare la persistenza LUN
32.15. Come disabilitare lo SMART disk monitoring per i guest
32.16. Pulizia di vecchi file di configurazione Xen
32.17. Come configurare un server VNC
32.18. Come clonare i file di configurazione del guest
32.19. Duplicazione di un guest esistente e dei relativi file di configurazione
33. Creazione script libvirt personalizzati
33.1. Come utilizzare i file di configurazione XML con virsh
VIII. Troubleshooting
34. Risoluzione problematiche di Xen
34.1. Debugging e troubleshooting di Xen
34.2. Panoramica sui file di log
34.3. Descrizioni del file di log
34.4. Posizioni importanti della directory
34.5. Troubleshooting con i log
34.6. Troubleshooting con console seriale
34.7. Accesso alla console del guest para-virtualizzato
34.8. Accesso alla console del guest completamente virtualizzato
34.9. Problematiche comuni di Xen
34.10. Errori durante la creazione di un guest
34.11. Troubleshooting con console seriali
34.11.1. Output della console seriale per Xen
34.11.2. Output della console seriale di Xen dei guest paravirtualizzati
34.11.3. Output console seriali da guest completamente virtualizzati
34.12. File di configurazione di Xen
34.13. Interpretazione dei messaggi d'errore di Xen
34.14. Disposizione delle directory di log
35. Troubleshooting
35.1. Come identificare lo storage e le partizioni disponibili
35.2. Dopo aver riavviato i guest basati sul guest la console si arresta
35.3. I dispositivi ethernet virtualizzati non vengono rilevati dai tool di networking
35.4. Errori del dispositivo loop
35.5. Errore nella creazione del dominio causato da una memoria insufficiente
35.6. Errore immagine del kernel errata
35.7. Immagine del kernel errata - kernel non-PAE su di una piattaforma PAE
35.8. Il guest a 64 bit completamente virtualizzato non riesce ad avviarsi
35.9. Mancanza della voce localhost con conseguente errore di virt-manager
35.10. Errore del microcodice durante l'avvio del guest
35.11. Messaggi di avviso relativi a Python durante l'avvio di una macchina virtuale
35.12. Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS
35.13. Prestazioni del KVM networking
36. Troubleshoot dei driver paravirtualizzati Xen
36.1. Directory e file di log di Red Hat Enterprise Linux 5 Virtualization
36.2. I guest para-virtualizzati non vengono caricati sul sistema operativo guest di Red Hat Enterprise Linux 3
36.3. Visualizzazione di un messaggio di avvertimento su Red Hat Enterprise Linux 3 durante l'installazione dei driver para-virtualizzati.
36.4. Caricamento manuale dei driver para-virtualizzati
36.5. Verifica caricamento corretto dei driver para-virtualizzati
36.6. Il sistema presenta un throughput limitato con driver para-virtualizzati
Glossary
A. Risorse aggiuntive
A.1. Risorse online
A.2. Documentazione installata
B. Colophon

Prefazione

The Red Hat Enterprise Linux Virtualization Guide covers all aspects of using and managing virtualization products included with Red Hat Enterprise Linux.

1. Informazioni su questo libro

This book is divided into 8 parts:
  • Requisiti del sistema
  • Installazione
  • Configurazione
  • Amministrazione
  • Storage
  • Riferimento
  • Suggerimenti e trucchi
  • Troubleshooting
Key terms and concepts used throughout this book are covered in the Glossary.
This book covers virtualization topics for Red Hat Enterprise Linux 5. The KVM and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization. Refer to Sezione 4, «What is Virtualization?» and the Glossary for more details on these terms.

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 e combinazione di tasti. Per esempio:
Per visualizzare i contenuti del file my_next_bestselling_novel nella vostra directory di lavoro corrente, inserire il comando cat my_next_bestselling_novel al prompt della shell e premere Invio per eseguire il comando.
Quanto sopra riportato include il nome del file, un comando della shell ed un tasto, il tutto riportato in neretto monospazio e distinguibile grazie al contesto.
Le combinazioni di tasti possono essere distinte dai tasti tramite il trattino che collega ogni parte della combinazione. Per esempio:
Premere Invio per eseguire il comando.
Premere Ctrl+Alt+F2 per smistarsi sul primo virtual terminal. Premere Ctrl+Alt+F1 per ritornare alla sessione X-Windows.
Il primo paragrafo evidenzia il tasto specifico singolo da premere. Il secondo riporta due combinazioni di tasti, (ognuno dei quali è un set di tre tasti premuti contemporaneamente).
Se si discute del codice sorgente, i nomi della classe, i metodi, le funzioni i nomi della variabile ed i valori ritornati indicati all'interno di un paragrafo, essi verranno indicati come sopra, e cioè in neretto monospazio. Per esempio:
Le classi relative ad un file includono filesystem per file system, file per file, e dir per directory. Ogni classe possiede il proprio set associato di permessi.
Proportional Bold
Ciò denota le parole e le frasi incontrate su di un sistema, incluso i nomi delle applicazioni; il testo delle caselle di dialogo; i pulsanti etichettati; le caselle e le etichette per pulsanti di selezione, titoli del menu e dei sottomenu. Per esempio:
Selezionare SistemaPreferenzeMouse dalla barra del menu principale per lanciare Preferenze del Mouse. Nella scheda Pulsanti, fate clic sulla casella di dialogo mouse per mancini, e successivamente fate clic su Chiudi per cambiare il pulsante primario del mouse da sinistra a destra (rendendo così il mouse idoneo per un utilizzo con la mano sinistra).
Per inserire un carattere speciale in un file gedit, selezionare ApplicazioniAccessoriMappa carattere dalla barra menu principale. Successivamente, selezionare CercaTrova… dalla barra del menu Mappa carattere, inserire il nome del carattere nel campo Cerca e cliccare Successivo. Il carattere ricercato verrà evidenziato nella Tabella caratteri. Fare un doppio clic sul carattere evidenziato per posizionarlo nel campo Testo da copiare, e successivamente fare clic sul pulsante Copia. Ritornare ora al documento e selezionare ModificaIncolla dalla barra del menu di gedit.
Il testo sopra riportato include i nomi delle applicazioni; nomi ed oggetti del menu per l'intero sistema; nomi del menu specifici alle applicazioni; e pulsanti e testo trovati all'interno di una interfaccia GUI, tutti presentati in neretto proporzionale e distinguibili dal contesto.
Corsivo neretto monospazio o Corsivo neretto proporzionale
Sia se si tratta di neretto monospazio o neretto proporzionale, l'aggiunta del carattere corsivo indica un testo variabile o sostituibile . Il carattere corsivo denota un testo che non viene inserito letteralmente, o visualizzato che varia a seconda delle circostanze. Per esempio:
Per collegarsi ad una macchina remota utilizzando ssh, digitare ssh username@domain.name al prompt della shell. Se la macchina remota è example.com ed il nome utente sulla macchina interessata è john, digitare ssh john@example.com.
Il comando mount -o remount file-system rimonta il file system indicato. Per esempio, per rimontare il file system /home, il comando è mount -o remount /home.
Per visualizzare la versione di un pacchetto attualmente installato, utilizzare il comando rpm -q package. Esso ritornerà il seguente risultato: package-version-release.
Da notare la parola in Corsivo neretto — nome utente, domain.name, file-system, pacchetto, versione e release. Ogni parola racchiude il testo da voi inserito durante l'emissione di un comando o per il testo mostrato dal sistema.
Oltre all'utilizzo normale per la presentazione di un titolo, il carattere Corsivo denota il primo utilizzo di un termine nuovo ed importante. Per esempio:
Publican è un sistema di pubblicazione per DocBook.

2.2. Convenzioni del documento

Gli elenchi originati dal codice sorgente e l'output del terminale 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 tondo monospazio 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

Le caselle 'importante' 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. We need your feedback

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you. Submit a report in Bugzilla: http://bugzilla.redhat.com/ against Red Hat Enterprise Linux with the Virtualization_Guide component.
When submitting a bug report, be sure to mention the manual's identifier: Virtualization_Guide and version number: 5.
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, include the section number and some of the surrounding text so we can find it easily.

3.1. Technical review requests

All review requests are classified into one of the following five categories:
New content
content documented for the first time — an entirely new feature, procedure, or concept. For example: "Section now describes the new procedure for creating bootable USB devices."
Correction
a factual error previously present in the text has been corrected. For example: "Section previously stated (incorrectly) that IPv4 and IPv6 were both supported; section now states that IPv6 has never been supported."
Clarification
material that was already factually correct but is now better explained. Clarifications are usually in response to reader feedback that the previous content was confusing or misleading in some way. For example: "Paths described in Example 1.2.3 now better reflect the directory structure of an actual installed system."
Obsoletion
a description of a feature or a procedure has been dropped. Material might be obsolete because of a feature that is no longer supported, a known issue that has been corrected, or hardware that is now obsolete. For example, "Section no longer describes how to update kernel modules using a floppy disk."
Verification
a request to check a fact, procedure, or whether material should be obsoleted. For example, "Section describes how to connect to a generic iSCSI storage device. Please verify this on your hardware" or "Section still describes how to update kernel modules using a LS-120 SuperDisk; please verify that we still need to tell readers about this obsolete hardware."

4. What is Virtualization?

Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer that controls hardware and provides guest operating systems with access to underlying hardware devices. The hypervisor allows multiple operating systems to run on the same physical system by offering virtualized hardware to the guest operating system.

5. Types of Virtualization

5.1. Full Virtualization

Red Hat Enterprise Linux contains virtualization packages and tools which provide system administrators with the means to run fully virtualized, unmodified, operating system guests on Red Hat Enterprise Linux. This provides companies with the ability to consolidate older systems onto newer, more efficient hardware. This reduces physical space and operating costs involved with powering and cooling older, less efficient systems. Full virtualization incurs worse I/O performance than native, also known as bare-metal, installations of operating systems.

5.2. Para-Virtualization

Para-virtualization is a virtualization technique which involves running modified versions of operating systems. The para-virtualized operating system is modified to be aware that it is being virtualized, offering an increased ability for optimization as the guest is more aware of its environment. Performance is generally very close to running bare-metal, non-virtualized operating systems.

5.3. Para-virtualized drivers

These two techniques, para-virtualization and full virtualization, can be combined to allow unmodified operating systems to receive near native I/O performance by using para-virtualized drivers on fully virtualized operating systems. This guide covers installation and configuration of the Red Hat Enterprise Linux para-virtualized drivers package for fully virtualized Microsoft Windows® guests.
The para-virtualized drivers package contains storage and network device drivers for fully virtualized Microsoft Windows® guests. The drivers provide Microsoft Windows® guests running on Red Hat Enterprise Linux with enhanced disk and network I/O performance.

6. How CIOs should think about virtualization

by Lee Congdon, Chief Information Officer, Red Hat, Inc.
Se in precedenza avete investito un numero molto elevato di risorse in tecnologie emergenti come la virtualizzazione, allora questo è il momento giusto per sfruttare al massimo i vantaggi che ne derivano. A tal proposito sono riportate qui di seguito alcune idee.
La virtualizzazione fornisce un insieme di tool che garantisce una maggiore flessibilità abbassando al tempo stesso i costi. Questo concetto è molto importante in ogni organizzazione enterprise e di Information Technology. Le soluzioni offerte dalla Virtualizzazione sono sempre più ricche e più facilmente reperibili.
Poichè la virtualizzazione è in grado di fornire benefici molto importanti per la vostra organizzazione in diverse aree, è consigliato stabilire programmi pilota, sviluppare la propria conoscenza ed implementare questa tecnologia appena possibile.
Virtualizzazione in termini di innovazione
Per essere più specifici, la virtualizzazione è in grado di aumentare la flessibilità attraverso uno sdoppiamento del sistema operativo, dei servizi e delle applicazioni supportati dal sistema, da una piattaforma hardware fisica specifica. Ciò permette di stabilire ambienti virtuali multipli su di una piattaforma hardware condivisa.
Le organizzazioni interessate ad una loro innovazione possono interpretare la possibilità di creare nuovi sistemi e servizi senza installare hardware aggiuntivo (e sbarazzarsi più velocemente di quei sistemi e servizi a loro non più necessari), come un metodo attraverso il quale è possibile velocizzare tale processo di innovazione.
Tra i processi più significativi vi è la possibilità di stabilire sistemi di sviluppo per la creazione di software personalizzato, l'abilità d'impostare rapidamente gli ambienti di prova, la capacità di fornire soluzioni software alternative e confrontarle senza investire ingenti capitali in nuovo hardware, un supporto per il rapid prototyping e per ambienti di sviluppo agili, e la possibilità di stabilire nuovi servizi di produzione a richiesta.
Questi ambienti possono essere creati internamente o esternamente, come nell'offerta EC2di Amazon. Poichè il costo per la creazione di un nuovo ambiente virtuale può essere molto basso e può trarre vantaggio dall'hardware esistente, l'innovazione può essere facilitata ed accelerata da investimenti minimi.
La virtualizzazione può rappresentare una soluzione eccellente per il supporto delle innovazioni, attraverso l'utilizzo degli ambienti virtuali per i processi di formazione e di test. I suddetti servizi rappresentano delle applicazioni ideali per la virtualizzazione. In questo contesto uno studente potrà iniziare il suo lavoro usando un ambiente standard del sistema conosciuto. Il lavoro svolto in classe potrà essere isolato dalla rete di produzione. Gli studenti potranno utilizzare ambienti software isolati senza richiedere l'uso esclusivo di risorse hardware.
Con la continua crescita delle capacità degli ambienti virtuali, potremmo assistere ad un aumento dell'uso della virtualizzazione per abilitare ambienti portatili specifici alle necessità di un utente. I suddetti ambienti possono essere spostati dinamicamente su di un ambiente di processazione locale o accessibile, senza considerare la posizione dell'utente. Gli ambienti virtuali dell'utente possono essere conservati sulla rete o spostati su di un dispositivo di memoria portatile.
Un concetto correlato è l'Appliance Operating System, un sistema operativo orientato sul pacchetto dell'applicazione creato per eseguire un ambiente virtuale. Tale approccio è in grado di ridurre i costi di supporto e di sviluppo, assicurando al tempo stesso l'esecuzione dell'applicazione in un ambiente conosciuto e sicuro. Una soluzione Appliance Operating System fornisce benefici sia agli sviluppatori dell'applicazione che agli utenti delle stesse.
L'implementazione delle applicazioni appartenenti alla tecnologia di virtualizzazione potrebbe variare in base al vostro tipo di enterprise. Se state già utilizzando questo tipo di tecnologia in più di un'area, come precedentemente descritto, considerate allora un ulteriore investimento per una soluzione che necessita di uno sviluppo rapido. Se invece non avete ancora implementato questo tipo di tecnologia, iniziate con una implementazione di tipo training e learning (di formazione) per lo sviluppo delle vostre conoscenze, e successivamente implementate l'application development e testing. Gli enterprise con una esperienza più vasta nel campo della virtualizzazione, potrebbero considerare l'implementazione di ambienti virtuali portatili o di application appliances.
Virtualizzazione e riduzione dei costi
È possibile utilizzare la virtualizzazione per ridurre i costi. Uno dei suoi benefici è quello del consolidamento dei server all'interno di un set più piccolo di piattaforme hardware più potenti, in grado di eseguire un gruppo di piattaforme virtuali. Il costo può essere ridotto non solo attraverso la riduzione della quantità hardware e della capacità non utilizzata, ma anche attraverso il miglioramento delle prestazioni delle applicazioni poichè i guest virtuali vengono eseguiti su hardware più potenti.
Benefici aggiuntivi includono la possibilità di aggiungere capacità hardware senza intaccare le normali funzioni, e la possibilità di migrare dinamicamente i carichi di lavoro su risorse disponibili.
In base alle necessità della vostra organizzazione sarà possibile creare un ambiente virtuale per il disaster recovery. L'introduzione delle tecnologie di virtualizzazione potrebbe ridurre significativamente la necessità di replicare ambienti hardware identici, con la possibilità di creare scenari di errori critici a costi più bassi.
La virtualizzazione fornisce una soluzione eccellente per affrontare qualsiasi tipo di carico di lavoro. Se siete in presenza di carichi di lavoro complementari, avrete la possibilità di assegnare dinamicamente le vostre risorse alle applicazioni che presentano un numero di richieste più grande. Se la vostra organizzazione ha raggiunto il livello massimo del carico di lavoro, allora sarà possibile acquistare esternamente la capacità necessaria ed implementarla in modo efficiente utilizzando la tecnologia di virtualizzazione.
La riduzione dei costi dovuto al consolidamento del server potrebbe essere un fattore trainante. Se attualmente usate la virtualizzazione per questo scopo, vi consigliamo di avviare un programma a tal proposito. Man mano che l'utente acquisisce esperienza, è consigliato conoscere i benefici offerti dal bilanciamento del carico e dagli ambienti di disaster recovery virtualizzati.
La virtualizzazione come soluzione standard
Senza tener presente dei requisiti specifici del vostro enterprise, è consigliato considerare la virtualizzazione come un elemento integrante del portfolio del vostro sistema e delle vostre applicazioni, poichè questo tipo di tecnologia sarà in futuro molto diffusa. Tutti i rivenditori di sistemi operativi includeranno la virtualizzazione come componente standard, ed i rivenditori hardware creeranno capacità virtuali all'interno delle proprie piattaforme. Ed infine, i rivenditori di tecnologie di virtualizzazione cercheranno di sviluppare sempre di più il proprio prodotto.
Se non avete ancora deciso di implementare la virtualizzazione all'interno della vostra architettura ora è il momento giusto per farlo, così facendo potrete individuare un progetto pilota. A tal proposito assegnate alcune piattaforme hardware poco utilizzate, ed approfondite la vostra conoscenza con questa nuova tecnologia. Successivamente estendete la vostra architettura target in modo da incorporare soluzioni virtuali. Anche se è possibile avere benefici sostanziali dovuti alla virtualizzazione di servizi esistenti, la creazione di nuove applicazioni integrando una strategia di virtualizzazione appropriata, potrebbe apportare maggiori benefici sia in termini di gestione che di disponibilità.
Per saperne di più sulle soluzioni offerte dalla virtualizzazione di Red Hat consultate http://www.redhat.com/products/

Parte I. Requisiti e limitazioni per la virtualizzazione su piattaforme Red Hat Enterprise Linux

Requisiti del sistema, supporto, restrizioni e limitazioni

Questi capitoli contengono i requisiti del sistema, le restrizioni del supporto e le limitazioni della virtualizzazione con Red Hat Enterprise Linux.

Capitolo 1. Requisiti del sistema

This chapter lists system requirements for successfully running virtualization with Red Hat Enterprise Linux. Virtualization is available for Red Hat Enterprise Linux 5 Server.
The requirements for virtualization vary depending on the type of hypervisor. The Kernel-based Virtual Machine (KVM) and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization.
For information on installing the virtualization packages, read Capitolo 6, Installazione dei pacchetti di virtualizzazione.
Requisiti minimi del sistema
  • 6 GB di spazio libero.
  • 2GB di RAM.

KVM overcommit

KVM can overcommit physical resources for virtualized guests. Overcommiting resources means the total virtualized RAM and processor cores used by the guests can exceed the physical RAM and processor cores on the host. For information on safely overcommitting resources with KVM refer to Sezione 32.4, «Overcommitting Resources».
Requisiti per Xen para-virtualization
Per i guest paravirtualizzati è necessario utilizzare l'albero d'installazione di Red Hat Enterprise Linux 5 attraverso la rete usando i protocolli NFS, FTP o HTTP.
Requisiti per Xen full virtualization
Il Full virtualization con l'hypervisor Xen necessita di:
  • an Intel processor with the Intel VT extensions, or
  • un processore AMD con le estensioni AMD-V o
  • un processore Intel Itanium.
Refer to Sezione 32.6, «Verifica delle estensioni per la virtualizzazione» to determine if your processor has the virtualization extensions.
Requisiti KVM
L'hypervisor KVM necessita di:
  • un processore Intel con le estensioni Intel 64 e Intel VT o
  • un processore AMD con le estensioni AMD64 e AMD-V.
Refer to Sezione 32.6, «Verifica delle estensioni per la virtualizzazione» to determine if your processor has the virtualization extensions.
Supporto dello storage
I metodi supportati per lo storage del guest sono:
  • Files on local storage
  • Physical disk partitions
  • Locally connected physical LUNs
  • LVM partitions
  • iSCSI and Fibre Channel based LUNs

Storage per il guest basato sul file

File-based guest images are stored in the /var/lib/libvirt/images/ directory by default. If you use a different directory you must label the new directory according to SELinux policy. Refer to Sezione 18.2, «SELinux e virtualizzazione» for details.

Capitolo 2. Supporto e restrizioni di Xen

Red Hat Enterprise Linux 5 supports various architecture combinations for hosts and virtualized guests. All architectures have processor and memory limitations. Refer to the following URLs for the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Nota

To utilize para-virtualization on Red Hat Enterprise Linux 5, your processor must have the Physical Address Extension (PAE) instruction set.

supporto Itanium®

Virtualization with the Xen hypervisor on the Intel Itanium architecture requires the guest firmware image package, refer to Installazione dell'hypervisor Xen con yum for more information.

Capitolo 3. Supporto e restrizioni di KVM

The KVM hypervisor requires a processor with the Intel-VT or AMD-V virtualization extensions.
To verify whether your processor supports the virtualization extensions and for information on enabling the virtualization extensions if they are disabled, refer to Sezione 32.6, «Verifica delle estensioni per la virtualizzazione».
The following URLs explain the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Capitolo 4. Hyper-V restrictions and support

Certification of guests running under the Microsoft Hyper-V server is conducted by Microsoft. Red Hat Enterprise Linux 5 is fully certified to run under the Microsoft Hyper-V server.

Nota

To avoid timing errors when running Red Hat Enterprise Linux 5 under the Microsoft Hyper-V server, use the divider=10 option in the grub.conf file.

Capitolo 5. Limiti della virtualizzazione

Questo capitolo riporta le limitazioni aggiuntive relative ai pacchetti per la virtualizzazione in Red Hat Enterprise Linux.

5.1. Limitazioni generali per la virtualizzazione

Converting between hypervisors
Presently, there is no support for converting Xen-based guests to KVM or KVM-based guests to Xen. Guests can only be supported on the hypervisor type on which they were created. However, at the time of writing, a tool is in development which may be released with future versions of Red Hat Enterprise Linux.
Altre limitazioni
For other details affecting virtualization, refer to the Red Hat Enterprise Linux Release Notes at http://docs.redhat.com for your version. The Release Notes cover the present new features, known issues and limitations as they are updated or discovered.
Eseguire una prova prima dell'impiego
You should test for the maximum anticipated system and virtualized network load before deploying heavy I/O applications. Load testing and planning are important as virtualization performance can suffer due to high I/O usage.

5.2. LImitazioni KVM

Le seguenti limitazioni vengono applicate all'hypervisor KVM:
Constant TSC bit
Systems without a Constant Time Stamp Counter require additional configuration. Refer to Capitolo 16, Gestione dell'ora del guest KVM for details on determining whether you have a Constant Time Stamp Counter and configuration steps for fixing any related issues.
Overcommit della memoria
KVM supports memory overcommit and can store the memory of guests in swap. A guest will run slower if it is swapped frequently. When Kernel SamePage Merging (KSM) is used, make sure that the swap size is equivalent to the size of the overcommit ratio.
Overcommit della CPU
Non è supportato avere un numero maggiore a 10 CPU virtuali per core processor fisico. L'overcommit di qualsiasi numero di CPU virtuali maggiore rispetto al numero di core processor fisici potrebbe causare qualche problema con alcuni guest virtualizzati.
Overcommitting CPUs has some risk and can lead to instability. Refer to Sezione 32.4, «Overcommitting Resources» for tips and recommendations on overcommitting CPUs.
Dispositivi SCSI virtualizzati
SCSI emulation is presently not supported. Virtualized SCSI devices are disabled in KVM.
Dispositivi IDE virtualizzati
KVM è limitato ad un massimo di quattro dispositivi IDE (emulati) virtualizzati per guest.
Dispositivi paravirtualizzati
I dispositivi paravirtualizzati che utilizzano i driver virtio sono dispositivi PCI. Al momento i guest sono limitati ad un massimo di 32 dispositivi PCI. Alcuni dispositivi PCI sono critici per l'esecuzione del guest e per questo motivo non possono essere rimossi. I dispositivi necessari predefiniti sono:
  • il bridge host,
  • il bridge ISA e usb (I bridge usb e isa sono lo stesso dispositivo),
  • le schede grafiche (sia il driver qxl che Cirrus), e
  • il dispositivo balloon della memoria.
Su 32 dispositivi PCI disponibili per un guest, 4 non possono essere rimossi. Ciò significa che solo 28 alloggiamenti PCI sono disponibili per dispositivi aggiuntivi per ogni guest. Ogni rete paravirtualizzata o dispositivo a blocchi utilizza solo un alloggiamento. Ogni guest è in grado di utilizzare fino ad un massimo di 28 dispositivi aggiuntivi di qualsiasi combinazione di rete paravirtualizzate, dispositivi a disco paravirtualizzati o altri dispositivi PCI che utilizzano VTd.
Limitazioni del processo di migrazione
La migrazione live è solo possibile con CPU provenienti dallo stesso rivenditore (cioè da Intel ad Intel o da AMD a AMD).
Il bit No eXecution (NX) deve essere impostato su on o off per antrambe le CPU per una migrazione live.
Storage limitations
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guests should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.

5.3. Limitazione di Xen

Nota Bene

All limitations in this chapter are limitations for Red Hat Enterprise Linux 5.8 except where noted. Older versions may have fewer limitations.
Limitazioni host di Xen (dom0)
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.

Soluzione alla limitazione del dispositivo paravirtualizzato

There are two methods for working around the para-virtualized device limit: using phy devices (devices using the physical access mode) or using LVM on the guest.
Un host non presenta alcun limite sul numero di dispositivi phy se possiede risorse sufficienti.
LVM, o un tool di partizionamento logico simile, può essere usato su di un dispositivo a blocchi per creare partizioni logiche aggiuntive su di un dispositivo a blocchi paravirtualizzato singolo.
LImitazioni per Xen Para-virtualization
  • For x86 guests, a maximum of 16GB memory per guest.
  • For x86_64 guests, a maximum of 168GB memory per guest.
  • A maximum of 254 devices per virtualized guest.
  • Un massimo di 15 dispositivi di rete per guest virtualizzato.
Limitazioni per Xen full virtualization
  • For x86 guests, a maximum of 16GB memory per guest.
  • Un massimo di quattro dispositivi IDE (emulati) virtualizzati per guest.
    I dispositivi che utilizzano i driver paravirtualizzati per guest completamente virtualizzati non hanno questo tipo di limitazione.
  • Virtualized (emulated) IDE devices are limited by the total number of loopback devices supported by the system. The default number of available loopback devices on Red Hat Enterprise Linux 5.8 is 8. That is, by default, all virtualized guests on the system can each have no more than 8 virtualized (emulated) IDE devices.
    For more information on loopback devices, refer to the Red Hat KnowledgeBase, article DOC-1722.

    Utilizzo di un numero maggiore di 8 dispositivi loopback

    Per impostazione predefinita Red Hat Enterprise Linux limita il numero di dispositivi loopback disponibili. Questo numero può essere elevato modificando il limite del kernel.
    In /etc/modprobe.conf aggiungete la seguente riga:
    options loop max_loop=64
    
    Reboot the machine or run the following commands to update the kernel with this new limit:
    # rmmod loop
    # modprobe loop
    
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.
  • A maximum of 254 block devices using the para-virtualized drivers per virtualized guest.
  • Un massimo di 15 dispositivi di rete per guest virtualizzato.
  • Un massimo di 15 dispositivi SCSI virtualizzati per guest virtualizzato.
PCI passthrough limitations
  • PCI passthrough (attaching PCI devices to guests) is presently only supported on the following architectures:
    • 32 bit (x86) systems.
    • Intel 64 systems.
    • Intel Itanium 2 systems.

5.4. Limiti dell'applicazione

Diversi aspetti relativi alla virtualizzazione rendono la virtualizzazione stessa non idonea a certi tipi di applicazioni.
È consigliato per le applicazioni con elevati requisiti I/O l'uso di driver paravirtualizzati per guest completamente virtualizzati. Senza i driver paravirtualizzati alcune applicazioni possono diventare instabili sotto elevati carichi di I/O.
Le seguenti applicazioni dovrebbero essere evitate a causa degli elevati requisiti I/O:
  • server kdump
  • server netdump
You should carefully evaluate database applications before running them on a virtualized guest. Databases generally use network and storage I/O devices intensively. These applications may not be suitable for a fully virtualized environment. Consider para-virtualization or para-virtualized drivers in these cases for increased I/O performance.
Other applications and tools which heavily utilize I/O or require real-time performance should be evaluated carefully. Using full virtualization with the para-virtualized drivers or para-virtualization results in better performance with I/O intensive applications. Applications still suffer a small performance loss from running in virtualized environments. The performance benefits of virtualization through consolidating to newer and faster hardware should be evaluated against the potential application performance issues associated with using fully virtualized hardware.

Parte II. Installazione

Capitolo 6. Installazione dei pacchetti di virtualizzazione

Prima di poter usare la virtualizzazione è necessario installare i pacchetti relativi su Red Hat Enterprise Linux. I pacchetti per la virtualizzazione possono essere installati sia durante la sequenza d'installazione che dopo tale processo utilizzando il comando yum e Red Hat Network (RHN).
È possibile installare entrambi gli hypervisor KVM e Xen su di un solo sistema. L'hypervisor Xen utilizza il pacchetto kernel-xen mentre KVM utilizza il kernel predefinito di Red Hat Enterprise Linux con il modulo kernel kvm. Poichè ogni hypervisor utilizza un kernel diverso solo un hypervisor può essere attivo in un dato momento. Red Hat consiglia l'installazione di un solo hypervisor e cioè quello che desiderate usare per la virtualizzazione.
To change hypervisor from Xen to KVM or KVM to Xen refer to Sezione 32.2, «Come selezionare un hypervisor tra KVM e Xen».

6.1. Installazione di Xen con una nuova installazione di Red Hat Enterprise Linux

Questa sezione riporta le fasi necessarie per l'installazione dei tool di virtualizzazione e dei pacchetti di Xen come parte di una nuova installazione di Red Hat Enterprise Linux.

Avete bisogno di assistenza durante l'installazione?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.
  1. Iniziare una installazione interattiva di Red Hat Enterprise Linux da un DVD, CD-ROM o PXE d'installazione di Red Hat Enterprise Linux.
  2. You must enter a valid installation number when prompted to receive access to the virtualization and other Advanced Platform packages. Installation numbers can be obtained from Red Hat Customer Service.
  3. Complete all steps until you see the package selection step.
    Selezionate il gruppo dei pacchetti per la Virtualizzazione e fate clic sul pulsante Personalizza ora.
  4. Selezionare il gruppo di pacchetti Virtualizzazione. Il gruppo di pacchetti Virtualizzazione seleziona l'hypervisor Xen, virt-manager, libvirt e virt-viewer e tutte le dipendenze per l'installazione.
  5. Personalizzare i pacchetti (se necessario)

    Personalizzare il gruppo Virtualizzazione se avete bisogno di altri pacchetti per la virtualizzazione.
    Press the Close button then the Forward button to continue the installation.

Nota Bene

È necessario essere in possesso di un entitlement di virtualizzazione RHN valido per ricevere gli aggiornamenti per i pacchetti della virtualizzazione.
Installazione dei pacchetti Xen con i file kickstart
Questa sezione descrive il metodo attraverso il quale usare i file kickstart per installare Red Hat Enterprise Linux con i pacchetti dell'hypervisor Xen. 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 Red Hat Enterprise Linux con i pacchetti di virtualizzazione.
Nella sezione %packages del file kickstart aggiungere il seguente gruppo di pacchetti:
%packages
@xen

Per sistemi Intel Itanium

Fully virtualized guests on the Itanium® architecture require the guest firmware image package (xen-ia64-guest-firmware). Append the following package to your kickstart file:
xen-ia64-guest-firmware
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.2. Installazione dei pacchetti Xen su di un sistema Red Hat Enterprise Linux esistente

Questa sezione descrive le fasi necessarie per l'installazione dei pacchetti di virtualizzazione su di un sistema in esecuzione Red Hat Enterprise Linux.
Come aggiungere i pacchetti nel vostro elenco di entitlement di Red Hat Network
Questa sezione descrive come abilitare gli entitlement di Red Hat Network (RHN) per i pacchetti di virtualizzazione. È necessario abilitare questi entitlement per installare ed aggiornare i suddetti pacchetti su Red Hat Enterprise Linux. A tal proposito bisogna disporre di un account Red Hat Network valido per poter installare i pacchetti su Red Hat Enterprise Linux.
Altresì è necessario registrare le vostre macchine con RHN. Per registrare una installazione di Red Hat Enterprise Linux eseguire il comando rhn_register seguendo le prompt successive.
Se non siete in possesso di una sottoscrizione valida di Red Hat consultate la Red Hat online store.
Procedura 6.1. Aggiunta di un entitlement di Virtualizzazione con RHN
  1. Eseguite il login su RHN utilizzando la vostra password e nome utente di RHN.
  2. Selezionate i sistemi sui quali desiderate installare la Virtualizzazione.
  3. Nella sezione Proprietà del sistema gli entitlement dei sistemi presenti sono elencati accanto all'intestazione Entitlements. Utilizzate il link (Modifica queste proprietà) per modificare gli entitlement.
  4. Selezionate la casella Virtualizzazione.
Il vostro sistema ora avrà diritto a ricevere i pacchetti di virtualizzazione. La sezione successiva affronta il metodo usato per installare questi pacchetti.
Installazione dell'hypervisor Xen con yum
Per iniziare ad usare la virtualizzazione su Red Hat Enterprise Linux avrete bisogno dei pacchetti xen e kernel-xen. Il pacchetto xen contiene l'hypervisor insieme ai suoi tool di base. Il pacchetto kernel-xen contiene un kernel di Linux modificato eseguito come un guest della macchina virtuale sull'hypervisor.
Per installare i pacchetti xen e kernel-xen eseguite:
# yum install xen kernel-xen
I guest completamente virtualizzati presenti sull'architettura Itanium® hanno bisogno del pacchetto per l'immagine firmware del guest (xen-ia64-guest-firmware) presente nel DVD d'installazione aggiuntivo. Questo pacchetto può essere anche installato da RHN con il comando yum:
# yum install xen-ia64-guest-firmware
It is advised to install additional virtualization packages for management and configuration. Pacchetti consigliati per la virtualizzazione: lists the recommended packages.
Installazione di altri pacchetti consigliati per la virtualizzazione:
# yum install virt-manager libvirt libvirt-python python-virtinst

6.3. Installazione di KVM con una nuova installazione Red Hat Enterprise Linux

Questa sezione affronta le fasi attraverso le quali è possibile installare i tool di virtualizzazione ed il pacchetto KVM come parte di una nuova installazione Red Hat Enterprise Linux

Avete bisogno di assistenza durante l'installazione?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.

È necessario avere un numero di installazione valido

Non è possibile selezionare i pacchetti di virtualizzazione durante l'installazione senza un numero d'installazione valido.
  1. Iniziare una installazione interattiva di Red Hat Enterprise Linux da un DVD, CD-ROM o PXE d'installazione di Red Hat Enterprise Linux.
  2. Quando richiesto è necessario inserire un numero di installazione valido per accedere alla Virtualizzazione e ad altri pacchetti della Piattaforma avanzata.
  3. Complete all steps up to the package selection step.
    Selezionate il gruppo dei pacchetti per la Virtualizzazione e fate clic sul pulsante Personalizza ora.
  4. 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.
  5. Personalizzare i pacchetti (se necessario)

    Personalizzare il gruppo Virtualizzazione se avete bisogno di altri pacchetti per la virtualizzazione.
    Press the Close button then the Forward button to continue the installation.

Nota Bene

È necessario essere in possesso di un entitlement di virtualizzazione RHN valido per ricevere gli aggiornamenti per i pacchetti della virtualizzazione.
Installazione dei pacchetti KVM con i file kickstart
Questa sezione descrive il metodo attraverso il quale usare i file kickstart per installare Red Hat Enterprise Linux con i pacchetti dell'hypervisor KVM. I file di 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 Red Hat Enterprise Linux con i pacchetti di virtualizzazione.
Nella sezione %packages del file kickstart aggiungere il seguente gruppo di pacchetti:
%packages
@kvm
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.4. Installazione dei pacchetti KVM su di un sistema Red Hat Enterprise Linux esistente

Questa sezione descrive le fasi necessarie per l'installazione dell'hypervisor KVM su di un Red Hat Enterprise Linux 5.4 o sistema più recente.
Come aggiungere i pacchetti nel vostro elenco di entitlement di Red Hat Network
Questa sezione descrive come abilitare gli entitlement di Red Hat Network (RHN) per i pacchetti di virtualizzazione. È necessario abilitare questi entitlement per installare ed aggiornare i suddetti pacchetti su Red Hat Enterprise Linux. A tal proposito bisogna disporre di un account Red Hat Network valido per poter installare i pacchetti su Red Hat Enterprise Linux.
Altresì è necessario registrare le vostre macchine con RHN. Per registrare una installazione di Red Hat Enterprise Linux eseguire il comando rhn_register seguendo le prompt successive.
Se non siete in possesso di una sottoscrizione valida di Red Hat consultate la Red Hat online store.
Procedura 6.2. Aggiunta di un entitlement di Virtualizzazione con RHN
  1. Eseguite il login su RHN utilizzando la vostra password e nome utente di RHN.
  2. Selezionate i sistemi sui quali desiderate installare la Virtualizzazione.
  3. Nella sezione Proprietà del sistema gli entitlement dei sistemi presenti sono elencati accanto all'intestazione Entitlements. Utilizzate il link (Modifica queste proprietà) per modificare gli entitlement.
  4. Selezionate la casella Virtualizzazione.
Il vostro sistema ora avrà diritto a ricevere i pacchetti di virtualizzazione. La sezione successiva affronta il metodo usato per installare questi pacchetti.
Installazione dell'hypervisor KVM con yum
Per usare la virtualizzazione su Red Hat Enterprise Linux avrete bisogno del pacchetto kvm. Il pacchetto kvm contiene il modulo del kernel KVM che fornisce l'hypervisor KVM sul kernel di Red Hat Enterprise Linux predefinito.
Per installare il pacchetto kvm eseguite:
# yum install kvm
Ora installate 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 7. Panoramica installazione del guest virtualizzato

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.
Detailed installation instructions are available for specific versions of Red Hat Enterprise Linux, other Linux distributions and Windows. Refer to Capitolo 8, Procedure per l'installazione del sistema operativo guest for those procedures.

7.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.
Il tool 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.
An important option is the --vnc option which opens a graphical window for the guest's installation.
Esempio 7.1. Utilizzo di virt-install con KVM per la creazione di un guest Red Hat Enterprise Linux 3
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 7.2. Come usare virt-install per creare un guest fedora 11
# virt-install --name fedora11 --ram 512 --file=/var/lib/libvirt/images/fedora11.img \
	--file-size=3 --vnc --cdrom=/var/lib/libvirt/images/fedora11.iso

7.2. Creazione di un guest con virt-manager

virt-manager conosciuto come Virtual Machine Manager, è un tool grafico per la creazione e la gestione dei guest virtualizzati.
Procedura 7.1. Creazione di un guest 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. Optional: Open a remote hypervisor

    Open the File -> Add Connection. The dialog box below appears. Select a hypervisor and click the Connect button:
  3. Create a new guest

    La finestra principale di virt-manager vi permetterà di creare una nuova macchina virtuale. Selezionate Nuovo per creare un nuovo guest. Tale operazione aprirà il wizard mostrato nella schermata:
  4. New guest wizard

    The Create a new virtual machine window provides a summary of the information you must provide in order to create a virtual machine:
    Controllate le informazioni relative all'installazione e successivamente fate clic su Avanti.
  5. Name the virtual machine

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  6. Choose virtualization method

    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 siete collegati ad un hypervisor KVM sarà disponibile solo full virtualization.
    Choose the virtualization type and click the Forward button.
  7. Select the installation method

    The Installation Method window asks for the type of installation you selected.
    Guests can be installed using one of the following methods:
    Local media installation
    This method uses a CD-ROM or DVD or an image of an installation CD-ROM or DVD (an .iso file).
    Network installation tree
    This method uses a mirrored Red Hat Enterprise Linux installation tree to install guests. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS.
    The network services and files can be hosted using network services on the host or another mirror.
    Network boot
    This method uses a Preboot eXecution Environment (PXE) server to install the guest. Setting up a PXE server is covered in the Red Hat Enterprise Linux Deployment Guide. Using this method requires a guest with a routable IP address or shared network device. Refer to Capitolo 10, Configurazione di rete for information on the required networking configuration for PXE installation.
    Set the OS type and OS variant.
    Choose the installation method and click Forward to proceed.

    Para-virtualized guest installation

    Para-virtualized installation must be installed with a network installation tree. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS. The installation media URL must contain a Red Hat Enterprise Linux installation tree. This tree is hosted using NFS, FTP or HTTP.
  8. Installation media selection

    This window is dependent on what was selected in the previous step.
    1. ISO image or physical media installation

      If Local install media was selected in the previous step this screen is called Install Media.
      Select the location of an ISO image or select a DVD or CD-ROM from the dropdown list.
      Click the Forward button to proceed.
    2. Network install tree installation

      If Network install tree was selected in the previous step this screen is called Installation Source.
      Network installation requires the address of a mirror of a Linux installation tree using NFS, FTP or HTTP. Optionally, a kickstart file can be specified to automated the installation. Kernel parameters can also be specified if required.
      Click the Forward button to proceed.
    3. Network boot (PXE)

      PXE installation does not have an additional step.
  9. Storage setup

    The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Sezione 18.2, «SELinux e virtualizzazione» for details.
    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 based on size of the RAM allocated to the guest.
    Assegnate spazio supplementare se il guest ha bisogno di maggiore spazio per applicazioni o per altri dati. Per esempio, i web server hanno bisogno di spazio aggiuntivo per i file di log.
    Selezionate la dimensione appropriata per il guest sul vostro tipo di storage e successivamente fate clic su Avanti.

    Nota

    It is recommend that you use the default directory for virtual machine images, /var/lib/libvirt/images/. If you are using a different location (such as /images/ in this example) make sure it is added to your SELinux policy and relabeled before you continue with the installation (later in the document you will find information on how to modify your SELinux policy).
  10. 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.
  11. Memory and CPU allocation

    The Memory and CPU Allocation 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. Selezionate un valore per la memoria in grado di soddisfare i requisiti delle vostre applicazioni e del sistema operativo guest. Numerosi sistemi operativi necessitano di almeno 512MB di RAM per funzionare correttamente. Ricordate 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 tempi di risposta saranno molto lenti. Assicuratevi di assegnare memoria sufficiente per tutti i guest e gli host in modo da operare correttamente.
    Assegnate un numero sufficiente di CPU virtuali per il guest virtualizzato. Se il guest esegue un'applicazione multithreaded assegnare il numero di CPU virtualizzate necessarie per una esecuzione efficiente. Non assegnate un numero maggiore di CPU virtuali rispetto ai processori fisici (o hyper-threads) disponibili sul sistema host. È possibile assegnare più processori, tuttavia tale assegnazione potrebbe avere un impatto significativo in termini negativi sulle prestazioni del guest e dell'host a causa di effetti switching overheads del contesto del processore.
    Press Forward to continue.
  12. Verify and start guest installation

    The Finish Virtual Machine Creation window presents a summary of all configuration information you entered. Review the information presented and use the Back button to make changes, if necessary. Once you are satisfied click the Finish button and to start the installation process.
    A questo punto verrà visualizzata una finestra VNC la quale mostra l'avvio del processo d'installazione del sistema operativo guest.
This concludes the general process for creating guests with virt-manager. Capitolo 8, Procedure per l'installazione del sistema operativo guest contains step-by-step instructions to installing a variety of common operating systems.

7.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 al suo utilizzo per l'installazione PXE.
  1. Creazione di un nuovo bridge

    1. Create un nuovo file script di rete nella directory /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
      

      Avvertenza

      The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
    2. Start the new bridge by restarting the network service. The ifup installation command can start the individual bridge but it is safer to test the entire network restarts properly.
      # service network restart
      
    3. Non sono state ancora aggiunte le interfacce al nuovo bridge. Utilizzate 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 riavviate il networking o eseguite il riavvio.
    # service network restart
    
    Verificate 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

    Configurate iptables in modo da inoltrare tutto il traffico attraverso il bridge.
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
    # service iptables save
    # service iptables restart
    

    Disabilitare iptables sui bridge

    Alternativamente è possibile impedire la processazione del traffico dei bridge da parte delle regole di iptables. In /etc/sysctl.conf aggiungere le seguenti righe:
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    
    Ricaricare i parametri del kernel configurati con sysctl.
    # sysctl -p /etc/sysctl.conf
    
  4. Riavviare libvirt prima dell'installazione

    Riavviate il demone libvirt.
    # 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:installation dove installation è il nome del vostro bridge. Per le installazioni PXE usare il parametro --pxe.
Esempio 7.3. Installazione PXE con virt-install
# 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 \

Installazione PXE con virt-manager
The steps below are the steps that vary from the standard virt-manager installation procedures. For the standard installations refer to Capitolo 8, 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 8. Procedure per l'installazione del sistema operativo guest

This chapter covers how to install various guest operating systems in a virtualized environment on Red Hat Enterprise Linux. To understand the basic processes, refer to Capitolo 7, Panoramica installazione del guest virtualizzato.

Importante

When installing a Red Hat Enterprise Linux guest, the installer will ask to perform an integrity check on your installation source (CD/DVD media, or ISO file). If you select to perform the check, once the media is tested and the installation continues, you may encounter a message that states: The Red Hat Enterprise Linux Server CD was not found in any of your CDROM drives. Please insert the Red Hat Enterprise Linux Server CD and press OK to retry.
This behavior is intentional, provided as a convenience to make sure media is ejected in case a CD install (requiring multiple discs/images) is being performed as opposed to a DVD install.
To proceed past this message, make sure you either insert the next CD, or edit the guest's XML file specifying the next ISO file (or re-insert the DVD media). Next, run virsh update-device Guest1 ~/Guest1.xml (substituting your guest's name and XML file), and select OK to continue past this step.

8.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 assicuratevi 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.
Create para-virtualized Red Hat Enterprise Linux 5 guests using virt-manager or virt-install. For instructions on virt-manager, refer to the procedure in Sezione 7.2, «Creazione di un guest con virt-manager».
Create un guest paravirtualizzato con il tool 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 per Red Hat Enterprise Linux 5 è ftp://10.1.1.1/trees/RHEL5-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/RHEL5-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 vostro guest:
Quando il guest ha completato il proprio avvio iniziale il processo d'installazione standard di Red Hat Enterprise avrà inizio. Per la maggior parte delle installazioni verranno accettate le risposte predefinite.
Procedura 8.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. Assign the guest's network address. Choose to use DHCP (as shown below) or a static IP address:
  4. Se avete scelto DHCP il processo d'installazione cercherà di acquisire un indirizzo IP:
  5. If you chose a static IP address for your guest this prompt appears. Enter the details on the guest's networking configuration:
    1. Inserite un indirizzo IP valido ed assicuratevi che l'indirizzo IP inserito sia in grado di raggiungere il server con l'albero d'installazione.
    2. Inserite 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 state installando una versione Beta o una distribuzione di release precedenti sarà necessario confermare l'installazione del sistema operativo. Fate clic su Installa Comunque e successivamente su OK:
Procedura 8.2. Processo d'installazione grafico
  1. Inserite un codice di registrazione valido. Se siete in possesso di una chiave di sottoscrizione RHN valida inseritela nel campo Installation Number:

    Nota Bene

    Se saltate la fase di registrazione sarà possibile confermare le informazioni sul vostro account di Red Hat Network dopo l'installazione con il comando rhn_register. Il comando rhn_register richiede un accesso root.
  2. L'installazione confermerà ora il vostro desiderio di rimuovere i dati presenti sullo storage selezionati per l'installazione:
    Fate clic su Si per continuare.
  3. Review the storage configuration and partition layout. You can chose to select the advanced storage configuration if you want to use iSCSI for the guest's storage.
    Make your selections then click Forward.
  4. Confermate lo storage selezionato per l'installazione.
    Fate clic su Si per continuare.
  5. Configurate le impostazioni per il networking e dell'hostname. Le informazioni verranno popolate con i dati inseriti nel processo d'installazione. Se necessario modificate le suddette impostazioni:
    Fate clic su OK per continuare.
  6. Selezionate il fuso orario appropriato per il vostro ambiente.
  7. Inserite la password di root per il guest.
    Fate clic su Avanti per continuare.
  8. Selezionate i pacchetti software da installare. A tal proposito selezionare Personalizza ora. È necessario installare il pacchetto kernel-xen nella directory del Sistema. Il pacchetto kernel-xen è necessario per il para-virtualization.
    Click Forward.
  9. Vengono calcolate le dipendenze ed i requisiti per lo spazio.
  10. After the installation dependencies and space requirements have been verified click Forward to start the actual installation.
  11. Tutti i pacchetti software selezionati sono installati automaticamente.
  12. Una volta terminata l'installazione sarà necessario riavviare il vostro guest:
  13. Il guest appena installato non si riavvierà, al contrario si arresterà:
  14. Boot the guest. The guest's name was chosen when you used the virt-install in Sezione 8.1, «Installazione di Red Hat Enterprise Linux 5 come guest para-virtualizzato». If you used the default example the name is rhel5PV.
    Usate il comando virsh per riavviare il guest:
    # virsh reboot rhel5PV
    Alternativamente aprite virt-manager, selezionate il nome del guest e fate clic su Apri, successivamente selezionate Esegui.
    A VNC window displaying the guest's boot processes now opens.
  15. Il boot del guest avvia la schermata di configurazione First Boot. Questa schermata vi guiderà attraverso alcune fasi di configurazione di base per il vostro guest:
  16. Leggere ed accettare il license agreement.
    Fate clic su Avanti sulle finestre del license agreement.
  17. Configurare il firewall.
    Fate clic su Avanti per continuare.
    1. Se disabilitate il firewall vi verrà richiesto di confermare la vostra scelta. Fate clic su Si per confermare e continuare. Non è consigliato disabilitare il firewall.
  18. Successivamente è la volta di SELinux. È fortemente consigliato eseguire SELinux in modalità enforcing. È possibile eseguire SELinux sia in modalità permissive che completamente disabilitato.
    Fate clic su Avanti per continuare.
    1. Se desiderate disabilitare SELinux verrà visualizzato un messaggio d'avvertimento. Fate clic su Si per disabilitare SELinux.
  19. Disable kdump. The use of kdump is unsupported on para-virtualized guests.
    Fate clic su Avanti per continuare.
  20. Confirm time and date are set correctly for your guest. If you install a para-virtualized guest time and date should synchronize with the hypervisor.
    If the users sets the time or date during the installation it is ignored and the hypervisor's time is used.
    Fate clic su Avanti per continuare.
  21. Impostate gli aggiornamenti software. Se siete in possesso di una sottoscrizione al Red Hat Network o se desiderate provarne una utilizzate la schermata di seguito riportata per la registrazione del nuovo guest in RHN:
    Fate clic su Avanti per continuare.
    1. Confermate le vostre scelte per RHN.
    2. Potreste visualizzare una schermata aggiuntiva se non avete configurato un accesso RHN. Se tale accesso non è stato abilitato non riceverete alcun aggiornamento software.
      Fate clic sul pulsante Avanti.
  22. Create un account utente non-root. È consigliato creare un utente non-root per un utilizzo normale e per una sicurezza più elevata. Inserite il nome utente, il nome e la password.
    Fate clic sul pulsante Avanti.
  23. Se l'audio è necessario ed è stato rilevato un dispositivo audio, regolatelo. Completate il processo e fate clic su Avanti.
  24. You can install additional packages from a CD or another repository using this screen. It is often more efficient to not install any additional software at this point but add packages later using the yum command or RHN. Click Finish.
  25. Il guest configurerà qualsiasi impostazione da voi modificata e continuerà con il processo d'avvio.
  26. Sarete in grado di visualizzare la schermata di registrazione per il Red Hat Enterprise Linux 5. Eseguite il log in utilizando il nome utente creato nelle fasi precedenti.
  27. A questo punto siete riusciti ad installare un guest paravirtualizzato di Red Hat Enterprise Linux.

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

This section covers installing a fully virtualized Red Hat Enterprise Linux 5 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Procedura 8.3. Creazione di un guest Red Hat Enterprise Linux 5 completamente virtualizzato con virt-manager
  1. Aprire virt-manager

    Avviare virt-manager. Lanciare l'applicazione Virtual Machine Manager dal menu Applicazioni fate clic su Tool del sistema. Alternativamente eseguire il comando virt-manager come utente root.
  2. Selezionare un hypervisor

    Selezionare un hypervisor. Se installati selezionate Xen o KVM. Per questo esempio selezionare KVM. Da notare che attualmente KVM è chiamato qemu.
    Connect to a hypervisor if you have not already done so. Open the File menu and select the Add Connection... option. Refer to Sezione 26.1, «The Add Connection window».
    Una volta selezionato il collegamento sarà disponibile il pulsante Nuovo. A questo punto premete il pulsante Nuovo.
  3. Avvio del nuovo wizard della macchina virtuale

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Conferire un nome alla macchina virtuale

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Scegliere un metodo per la virtualizzazione

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (Passo 4) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Selezionare il metodo d'installazione

    Red Hat Enterprise Linux può essere installato tramite uno dei seguenti metodi:
    • dispositivo d'installazione locale, sia esso una immagine ISO o un dispositivo ottico fisico.
    • Selezionare Albero d'installazione di rete se siete in possesso di un albero d'installazione per Red Hat Enterprise Linux presente sulla vostra rete tramite HTTP, FTP o NFS.
    • PXE può essere utilizzato se siete in possesso di un server PXE configurato per l'avvio del dispositivo d'installazione di Red Hat Enterprise Linux. La configurazione di un server per l'avvio tramite PXE di una installazione di Red Hat Enterprise Linux non viene affrontata da questa guida. Tuttavia molte delle fasi d'installazione sono le stesse dopo l'avvio del dispositivo.
    Set OS Type to Linux and OS Variant to Red Hat Enterprise Linux 5 as shown in the screenshot.
    Press Forward to continue.
  7. Individuazione del dispositivo d'installazione

    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.
    1. Selezionare il pulsante Sfoglia.
    2. Andate alla ricerca della posizione del file ISO e selezionate l'immagine ISO. Selezionate Apri per confermare la selezione fatta.
    3. The file is selected and ready to install.
      Press Forward to continue.

    File immagine e SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Sezione 18.2, «SELinux e virtualizzazione» for details.
  8. Impostazione dello storage

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.

    Migrazione

    Live and offline migrations require guests to be installed on shared network storage. For information on setting up shared storage for guests refer to Parte V, «Virtualization Storage Topics».
  9. Impostazioni di rete

    Selezionate Rete virtuale o Dispositivo fisico condiviso.
    L'opzione rete virtuale utilizza il Network Address Translation (NAT) per condividere il dispositivo di rete predefinito con il guest virtualizzato. Utilizzate l'opzione di rete virtuale per reti wireless.
    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. Assegnazione CPU e memoria

    The Memory and CPU Allocation 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 vostro sistema operativo guest e per i requisiti dell'applicazione. Ricordate, 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 swapping. La memoria virtuale è molto più lenta e causa un degrado delle prestazioni e dei tempi di risposta. Assicuratevi di assegnare memoria sufficiente per tutti i guest e l'host in modo da operare correttamente.
    Assegnare un numero sufficiente di CPU virtuali per il guest virtualizzato. Se il guest esegue un'applicazione multithreaded, assegnare il numero di CPU virtualizzate necessarie per una esecuzione corretta. Non assegnate un numero di CPU virtuali maggiore rispetto al numero di processori fisici (o hyper-threads) disponibili sul sistema host. È possibile assegnare più processori virtuali, tuttavia tale assegnazione potrà avere un impatto negativo sulle prestazioni del guest e host a causa di problemi switching overhead del contesto relativi al processore.
    Press Forward to continue.
  11. Verifica ed installazione dell'installazione del guest

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Installazione di Red Hat Enterprise Linux

    Completate la sequenza di installazione di Red Hat Enterprise Linux 5. Le suddette fasi vengono affrontate nella Installation Guide, consultate Red Hat Documentation per la Installation Guide di Red Hat Enterprise Linux.
È stato ora installato un guest Red Hat Enterprise Linux 5 completamente virtualizzato.

8.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 Red Hat Enterprise Linux.
This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Prima di iniziare questa procedura assicuratevi di avere un accesso root.

supporto Itanium®

Al momento gli host di Red Hat Enterprise Linux presenti sulle architetture Itanium® non supportano i guest Windows XP completamente virtualizzati. Per i sistemi basati su Itanium solo Windows Server 2003 è supportato.
  1. Avvio di virt-manager

    Open Applications > System Tools > Virtual Machine Manager. Open a connection to a host (click File > Add Connection). Click the New button to create a new virtual machine.
  2. Come nominare il vostro sistema virtuale

    Inserite il nome del sistema e successivamente fate clic su Avanti.
  3. Selezione di un metodo di virtualizzazione

    If you selected KVM or Xen earlier (step Passo 1 ) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Windows può essere solo installato utilizzando full virtualization.
  4. Selezione di un metodo d'installazione

    Questa schermata vi permetterà di specificare il metodo d'installazione ed il tipo di sistema operativo.
    Selezionate Windows dall'elenco Tipo di OS e Microsoft Windows XP dall'elenco Variante OS.
    Con Red Hat Enterprise Linux 5.2 è supportata l'installazione di guest con PXE. L'installazione PXE non viene affrontata in questo capitolo.

    File immagine e SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Sezione 18.2, «SELinux e virtualizzazione» for details.
    Premere Avanti per continuare.
  5. Choose installation image

    Choose the installation image or CD-ROM. For CD-ROM or DVD installation select the device with the Windows installation disc in it. If you chose ISO Image Location enter the path to a Windows installation .iso image.
    Premere Avanti per continuare.
  6. The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest's storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Sezione 18.2, «SELinux e virtualizzazione» for details.
    Assegnate spazio supplementare se il guest ha bisogno di maggiore spazio per applicazioni o per altri dati. Per esempio, i web server hanno bisogno di spazio aggiuntivo per i file di log.
    Selezionate la dimensione appropriata per il guest sul vostro tipo di storage e successivamente fate clic su Avanti.

    Nota

    È consigliato utilizzare la directory predefinita, /var/lib/xen/images/, per le immagini della macchina virtuale. Se utilizzate una posizione diversa (come ad esempio /images/) assicuratevi di aggiungerla alla vostra politica di SELinux e di rietichettarla prima di continuare con l'installazione (più avanti nella documentazione troverete le informazioni su come modificare la vostra politica di SELinux)
  7. Impostazione della rete

    Selezionate Rete virtuale o Dispositivo fisico condiviso.
    L'opzione della rete virtuale utilizza il Network Address Translation (NAT) per condividere il dispositivo di rete predefinito con il guest virtualizzato. Usare l'opzione della rete virtuale per reti wireless.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  8. The Memory and CPU Allocation 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 vostro sistema operativo guest e per i requisiti dell'applicazione. Numerosi sistemi operativi hanno bisogno di almeno 512MB di RAM per funzionare correttamente. Ricordate, 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. Assicuratevi di assegnare memoria sufficiente per tutti i guest e per l'host in modo da operare correttamente.
    Assegnare un numero sufficiente di CPU virtuali per il guest virtualizzato. Se il guest esegue un'applicazione multithreaded, assegnare il numero di CPU virtualizzate necessarie per una esecuzione corretta. Non assegnate un numero di CPU virtuali maggiore rispetto al numero di processori fisici (o hyper-threads) disponibili sul sistema host. È possibile assegnare più processori virtuali, tuttavia tale assegnazione potrà avere un impatto negativo sulle prestazioni del guest e host a causa di problemi switching overhead del contesto relativi al processore.
  9. Prima che l'installazione continui verrà visualizzata una schermata riassuntiva. Selezionate Fine per procedere con l'installazione del guest:
  10. You must make a hardware selection so open a console window quickly after the installation starts. Click Finish then switch to the virt-manager summary window and select your newly started Windows guest. Double click on the system name and the console window opens. Quickly and repeatedly press F5 to select a new HAL, once you get the dialog box in the Windows install select the 'Generic i486 Platform' tab. Scroll through selections with the Up and Down arrows.
  11. Il processo continuerà con l'installazione di Windows standard.
  12. Partizionate l'hard drive quando richiesto.
  13. Dopo aver formattato il vostro drive, Windows inizierà a copiare i file sull'hard drive.
  14. I file vengono copiati sul dispositivo di storage, a questo punto Windows eseguirà una procedura di riavvio.
  15. Riavviate il vostro guest Windows:
    # virsh start WindowsGuest
    Dove WindowsGuest è il nome della macchina virtuale.
  16. Quando si apre la console di Windows sarete in grado di visualizzare la fase per l'impostazione dell'installazione di Windows.
  17. Se il processo d'installazione sembra arrestarsi durante la fase d'impostazione, riavviate il guest utilizzando il comando virsh reboot WindowsGuestName. Durante il riavvio della macchina virtuale è possibile visualizzare il messaggio Setup is being restarted:
  18. Una volta terminata la fase di impostazione sarà possibile visualizzare la schermata d'avvio di Windows:
  19. È ora possibile continuare con l'impostazione normale del processo d'installazione di Windows:
  20. Il processo d'installazione è ora completato.

8.4. Installazione di Windows Server 2003 come guest completamente virtualizzato

This chapter describes installing a fully virtualized Windows Server 2003 guest with the virt-install command. virt-install can be used instead of virt-manager This process is similar to the Windows XP installation covered in Sezione 8.3, «Installazione di Windows XP come guest completamente virtualizzato».

supporto Itanium®

Al momento gli host di Red Hat Enterprise Linux presenti sulle architetture Itanium® non supportano i guest windows completamente virtualizzati. Questa sezione è valida solo per gli host x86 e x86-64.
  1. Using virt-install for installing Windows Server 2003 as the console for the Windows guest opens the virt-viewer window promptly. The examples below installs a Windows Server 2003 guest with the virt-install command.
    1. Xen virt-install

      # virt-install --virt-type=xen -hvm  \
         --name windows2003sp1 
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
    2. KVM virt-install

      # virt-install --accelerate --hvm --connect qemu:///system \
         --name rhel3support  \
         --network network:default \
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
  2. Dopo aver iniziato l'installazione del vostro guest sarà necessario selezionare velocemente F5. Se non premete F5 al momento opportuno sarà necessario iniziare nuovamente l'installazione. Premendo F5 aprirete una finestra di dialogo per la selzione di un HAL diverso o Tipo di computer. A questo punto selezionate Standard PC come Tipo di computer. La modifica del Tipo di computer è necessaria per i guest virtualizzati di Windows Server 2003.
  3. Completate il resto dell'installazione.
  4. Windows Server 2003 come guest completamente virtualizzato.

8.5. Installazione di Windows Server 2008 come guest completamente virtualizzato

This section covers installing a fully virtualized Windows Server 2008 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Procedura 8.4. Installazione di Windows Server 2008 con virt-manager
  1. Aprire il virt-manager

    Avviare virt-manager. Lanciare l'applicazione Virtual Machine Manager dal menu Applicazioni e Tool del sistema. Alternativamente eseguire il comando virt-manager come utente root.
  2. Selezionare un hypervisor

    Selezionate un hypervisor. Se installato selezionare Xen o KVM. Per questo esempio selezionare KVM. Da notare che attualmente KVM viene indicato come qemu.
    Dopo aver selezionato l'opzione verrà visualizzato il pulsante Nuovo. Premere il pulsante Nuovo.
  3. Avviare il nuovo wizard della macchina virtuale

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Come chiamare una macchina virtuale

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Selezione di un metodo per la virtualizzazione

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (step 2) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Selezione del metodo d'installazione

    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.
    Set OS Type to Windows and OS Variant to Microsoft Windows 2008 as shown in the screenshot.
    Press Forward to continue.
  7. Come localizzare il dispositivo d'installazione

    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. Premere il pulsante Sfoglia.
    2. Search to the location of the ISO file and select it.
      Press Open to confirm your selection.
    3. The file is selected and ready to install.
      Press Forward to continue.

    File d'immagine e SELinux

    For ISO image files and guest storage images, the recommended directory to use is the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Sezione 18.2, «SELinux e virtualizzazione» for details.
  8. Impostazione dello Storage

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.
  9. Impostazione della rete

    Selezionate Rete virtuale o Dispositivo fisico condiviso.
    L'opzione della rete virtuale utilizza il Network Address Translation (NAT) per condividere il dispositivo di rete predefinito con il guest virtualizzato. Usare l'opzione della rete virtuale per reti wireless.
    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. Assegnazione della CPU e della memoria

    The Memory and CPU Allocation 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 vostro sistema operativo guest e per i requisiti dell'applicazione. Ricordate, 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. Assicuratevi di assegnare memoria sufficiente per tutti i guest e per l'host in modo da operare correttamente.
    Assegnare un numero sufficiente di CPU virtuali per il guest virtualizzato. Se il guest esegue un'applicazione multithreaded, assegnare il numero di CPU virtualizzate necessarie per una esecuzione corretta. Non assegnate un numero di CPU virtuali maggiore rispetto al numero di processori fisici (o hyper-threads) disponibili sul sistema host. È possibile assegnare più processori virtuali, tuttavia tale assegnazione potrà avere un impatto negativo sulle prestazioni del guest e host a causa di problemi switching overhead del contesto relativi al processore.
    Press Forward to continue.
  11. Verifica ed avvio dell'installazione del guest

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Installazione di Windows

    Complete the Windows Server 2008 installation sequence. The installation sequence is not covered by this guide, refer to Microsoft's documentation for information on installing Windows.

Parte III. Configurazione

Configurazione della virtualizzazione in Red Hat Enterprise Linux

These chapters cover configuration procedures for various advanced virtualization tasks. These tasks include adding network and storage devices, enhancing security, improving performance, and using the Para-virtualized drivers on fully virtualized guests.

Indice

9. Virtualized storage devices
9.1. Creazione di un controllore del dischetto floppy virtualizzato
9.2. Come aggiungere dispositivi di storage sui guest
9.3. Come configurare uno storage persistente in Red Hat Enterprise Linux 5
9.4. Aggiungere un dispositivo DVD o CD-ROM virtualizzato ad un guest
10. Configurazione di rete
10.1. Network address translation (NAT) con libvirt
10.2. Bridged networking con libvirt
11. Pre-Red Hat Enterprise Linux 5.4 Xen networking
11.1. Come configurare bridge multipli di rete per il guest per l'utilizzo di schede ethernet multiple.
11.2. Configurazione di rete per laptop con Red Hat Enterprise Linux 5.0
12. Driver paravirtualizzati Xen
12.1. Requisiti del sistema
12.2. Supporto e restrizioni per il para-virtualization
12.3. Installazione dei driver paravirtualizzati
12.3.1. Fasi comuni del processo d'installazione
12.3.2. Installazione e configurazione di driver para-virtualizzati su Red Hat Enterprise Linux 3
12.3.3. Installazione e configurazione dei driver para-virtualizzati su Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Configurazione dei driver di rete para-virtualizzati
12.5. Configurazione hardware para-virtualizzata aggiuntiva
12.5.1. Interfacce di rete virtualizzate
12.5.2. Dispositivi di storage virtuali
13. Driver para-virtualizzati KVM
13.1. Installazione dei driver paravirtualizzati Windows di KVM
13.2. Installing drivers with a virtualized floppy disk
13.3. Utilizzo dei driver paravirtualizzati KVM per dispositivi esistenti
13.4. Utilizzo dei driver paravirtualizzati KVM per nuovi dispositivi
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Gestione dell'ora del guest KVM

Capitolo 9. Virtualized storage devices

This chapter covers installing and configuring storage devices in virtualized guests. The term block devices refers to various forms of storage devices. All the procedures in this chapter work with both Xen and KVM hypervisors.

Valid disk targets

The target variable in libvirt configuration files accepts only the following device names:
  • /dev/xvd[a to z][1 to 15]
    Example: /dev/xvdb13
  • /dev/xvd[a to i][a to z][1 to 15]
    Example: /dev/xvdbz13
  • /dev/sd[a to p][1 to 15]
    Example: /dev/sda1
  • /dev/hd[a to t][1 to 63]
    Example: /dev/hdd3

9.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.
An image file of a floppy disk is required. Create floppy disk image files with the dd command. Replace /dev/fd0 with the name of a floppy device and name the disk appropriately.
# dd if=/dev/fd0 of=~/legacydrivers.img

Nota per i driver para-virtualizzati

The para-virtualized drivers can map physical floppy devices to fully virtualized guests. For more information on using para-virtualized drivers read Capitolo 13, Driver para-virtualizzati KVM.
In questa sezione viene usato un guest creato con virt-manager sul quale viene eseguita una installazione completamente virtualizzata di Red Hat Enterprise Linux, con l'immagine posizionata in /var/lib/libvirt/images/rhel5FV.img. In questo esempio viene utilizzato l'Hypervisor Xen.
  1. Create 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
    
    This saves the configuration settings as an XML file which can be edited to customize the operations and devices used by the guest. For more information on using the virsh XML configuration files, refer to Capitolo 33, Creazione script libvirt personalizzati.
  2. Create 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. Add the content below, changing where appropriate, to your guest's configuration XML file. This example is an emulated floppy device using a file-based image.
    <disk type='file' device='floppy'>
    	<source file='/var/lib/libvirt/images/rhel5FV-floppy.img'/>
    	<target dev='fda'/>
    </disk>
    
  4. Force the guest to stop. To shut down the guest gracefully, use the virsh shutdown command instead.
    # virsh destroy 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.

9.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. Create 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'effettuazioni 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 le immagini di storage basate sul file sono consigliati i file pre-allocati e non-sparse. Per la creazione di file non-sparse eseguire:
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M count=4096
      
    Both commands create a 4GB file which can be used as additional storage for a virtualized guest.
  2. Eseguite il dump della configurazione per il guest. In questo esempio il guest è Guest1 ed il file viene salvato nella home directory degli utenti.
    # virsh dumpxml Guest1 > ~/Guest1.xml
    
  3. Aprire il file di configurazione (in questo esempio Guest1.xml) e andate 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 dello storage duplicate o inserite un nuovo elemento <disk>. Assicuratevi di aver specificato un nome del dispositivo per gli attributi del dispositivo a blocchi virtuale. Questi attributi devono essere unici per ogni file di configurazione del guest. Di seguito viene riportato un esempio di voce il quale aggiunge un file chiamato FileName.img come container 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. The following steps are Linux guest specific. Other operating systems handle new storage devices in different ways. For other systems, refer to that operating system's documentation
    The guest now uses the file FileName.img as the device called /dev/sdb. This device requires formatting from the guest. On the guest, partition the device into one primary partition for the entire device then format the device.
    1. Inserire n per una nuova partizione.
      # fdisk /dev/sdb
      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. Impostate 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/sdb1
      
  7. Montare il disco sul guest.
    # mount /dev/sdb1 /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
System administrators use additional hard drives for to provide more storage space or to separate system data from user data. This procedure, Procedura 9.1, «Come aggiungere un dispositivo a blocchi fisico su guest virtualizzati», describes how to add a hard drive on the host to a virtualized guest.
La procedura funziona per tutti i dispositivi a blocchi fisici, ciò include dispositivi floppy, CD-ROM e DVD.

Block device security

The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.
Procedura 9.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. Use the virsh attach command. Replace: myguest with your guest's name, /dev/sdb1 with the device to add, and sdc with the location for the device on the guest. The sdc must be an unused device name. Use the sd* notation for Windows guests as well, the guest will recognize the device correctly.
    Append the --type cdrom parameter to the command for CD-ROM or DVD devices.
    Aggiungere il parametro --type floppy al comando per i dispositivi floppy.
    # virsh attach-disk myguest
    					/dev/sdb1
    					sdc --driver tap --mode readonly
    
  4. The guest now has a new hard disk device called /dev/sdb on Linux or D: drive, or similar, on Windows. This device may require formatting.

9.3. Come configurare uno storage persistente in Red Hat Enterprise Linux 5

Questa sezione si riferisce ai sistemi con uno storage esterno o collegato alla rete; cioè dispositivi di storage basati su iSCSI o Fibre Channel. È consigliato configurare i nomi del dispositivo persistente sui vostri host. Tale operazione vi aiuterà anche durante la migrazione live e per una implementazione uniforme dei nomi del dispositivo e storage 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.
Systems which are not running multipath must use Configurazione di un percorso singolo. Systems running multipath can use Configurazione di percorsi multipli.
Configurazione di un percorso singolo
This procedure implements LUN device persistence using udev. Only use this procedure for hosts which are not using 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[a-z]", BUS=="scsi", PROGRAM="/sbin/scsi_id -g -s /block/%k", RESULT="UUID", NAME="devicename"
    
    Sostituite 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 lo storage condiviso, 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 storage. multipath fornisce condizioni di elevata resistenza 'fault tolerant', fail-over, e migliori prestazioni per i dispositivi di storage della rete collegati ai sistemi di Red Hat Enterprise Linux.
Implementing LUN persistence in a multipath environment requires defined alias names for your multipath devices. Each storage device has a UUID which acts as a key for the aliased names. Identify a device's UUID using the scsi_id command.
# 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 
	} 
}
This configuration will create 4 LUNs named /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 and /dev/mpath/oramp4. Once entered, the mapping of the devices' WWID to their new names are now persistent after rebooting.

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

To attach an ISO file to a guest while the guest is online use virsh with the attach-disk parameter.
# virsh attach-disk [domain-id] [source] [target] --driver file --type cdrom --mode readonly
The source and target parameters are paths for the files and devices, on the host and guest respectively. The source parameter can be a path to an ISO file or the device from the /dev directory.

Capitolo 10. Configurazione di rete

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.
Network services on virtualized guests are not accessible by default from external hosts. You must enable either Network address translation (NAT) ir a network Bridge to allow external hosts access to network services on virtualized guests.

10.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
Every standard libvirt installation provides NAT based connectivity to virtual machines out of the box. This is the so called 'default virtual network'. Verify that it is available with the virsh net-list --all command.
# 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
Contrassegnate la rete predefinita in modo da eseguire un avvio automatico:
# virsh net-autostart default
Network default marked as autostarted
Avviare la rete predefinita:
# virsh net-start default
Network default started
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
Once the host configuration is complete, a guest can be connected to the virtual network based on its name. To connect a guest to the 'default' virtual network, the following XML can be used in the guest:
<interface type='network'>
  <source network='default'/>
</interface>

Nota Bene

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>

10.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)
To:
 (network-script /bin/true)
Disabilitare il NetworkManager
NetworkManager does not support bridging. Running NetworkManager will overwrite any manual bridge configuration. Because of this, NetworkManager should be disabled in order to use networking via the network scripts (located in the /etc/sysconfig/network-scripts/ directory):
# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Nota Bene

As an alternative to turning off NetworkManager, add "NM_CONTROLLED=no" to the ifcfg-* scripts used in the examples. If you do not either set this parameter or disable NetworkManager entirely, any bridge configuration will be overwritten and lost when NetworkManager next starts.
Creazione initscripts di rete
Create o modificate i seguenti file di configurazione di rete. Questa fase può essere ripetuta (con nomi diversi) per bridge di rete aggiuntivi.
Andate sulla directory /etc/sysconfig/network-scripts:
# cd /etc/sysconfig/network-scripts
Aprite lo script di rete per il dispositivo che state 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

Tip

You can configure the device's Maximum Transfer Unit (MTU) by appending an MTU variable to the end of the configuration file.
MTU=9000
Create un nuovo script di rete nella directory /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

IP address configuration

IP address configuration, be it dynamic or static, should be configured on the bridge itself (for example, in the ifcfg-br0 file). Network access will not function as expected if IP address details are configured on the physical interface that the bridge is connected to.

Avvertenza

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
Dopo la configurazione riavviate il networking oppure eseguite un reboot.
# service network restart
Configurate iptables per permettere a tutto il traffico di essere inoltrato verso il bridge.
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Disabilitare iptables sui bridge

Alternativamente evitate la processazione del traffico dei bridge da parte delle regole iptables. In /etc/sysctl.conf aggiungete le seguenti righe:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Ricaricare i parametri del kernel configurato con sysctl.
# sysctl -p /etc/sysctl.conf
Riavviate il demone libvirt.
# service libvirtd reload
Ora dovreste avere un "dispositivo fisico condiviso" al quale è possibile collegare i guest ed avere un accesso LAN completo. Verificate 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 11. Pre-Red Hat Enterprise Linux 5.4 Xen networking

Questo capitolo affronta alcuni argomenti specifici relativi al networking ed alla configurazione di rete con l'hypervisor Xen.
Most guest network configuration occurs during the guest initialization and installation process. To learn about configuring networking during the guest installation process, read the relevant sections of the installation process, Capitolo 7, Panoramica installazione del guest virtualizzato.
Network configuration is also covered in the tool specific reference chapters for virsh (Capitolo 25, Gestione dei guest con virsh) and virt-manager (Capitolo 26, Gestione dei guest con Virtual Machine Manager (virt-manager)). Those chapters provide a detailed description of the networking configuration tasks using both tools.

Tip

Using para-virtualized network drivers improves performance on fully virtualized Linux guests. Capitolo 12, Driver paravirtualizzati Xen explains how to utilize para-virtualized network drivers.

11.1. Come configurare bridge multipli di rete per il guest per l'utilizzo di schede ethernet multiple.

Processo per l'implementazione dei bridge di rete (con hypervisor Xen):
  1. Configurate un'altra interfaccia di rete utilizzando system-config-network oppure create un nuovo file di configurazione chiamato ifcfg-ethX in /etc/sysconfig/network-scripts/ dove X può essere qualsiasi numero non precedentemente utilizzato. Di seguito viene riportato un esempio sul file di configurazione per una seconda interfaccia di rete chiamata eth1
    $ cat /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE=eth1
    BOOTPROTO=static
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    GATEWAY=10.1.1.254
    ARP=yes
    
  2. Copiare /etc/xen/scripts/network-bridge su /etc/xen/scripts/network-bridge.xen.
  3. Comment out any existing network scripts in /etc/xen/xend-config.sxp and add the line (network-xen-multi-bridge). A typical xend-config.sxp file should have the following line. Comment this line out. Use the # symbol to comment out lines.
    network-script network-bridge
    
    Below is the commented out line and the new line, containing the network-xen-multi-bridge parameter to enable multiple network bridges.
    #network-script network-bridge
    network-script network-xen-multi-bridge
  4. Create a script to create multiple network bridges. This example creates a script called network-xen-multi-bridge.sh in the /etc/xen/scripts/ directory. A sample scripts is below, this example script will create two Xen network bridges (xenbr0 and xenbr1) one will be attached to eth1 and the other one to eth0. If you want to create additional bridges just follow the example in the script and copy nad paste the lines as required:
    #!/bin/sh
    # network-xen-multi-bridge
    # Exit if anything goes wrong.
    set -e
    # First arg is the operation.
    OP=$1
    shift
    script=/etc/xen/scripts/network-bridge.xen
    case ${OP} in
    start)
    	$script start vifnum=1 bridge=xenbr1 netdev=eth1
    	$script start vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    stop)
    	$script stop vifnum=1 bridge=xenbr1 netdev=eth1
    	$script stop vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    status)
    	$script status vifnum=1 bridge=xenbr1 netdev=eth1
    	$script status vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    *)
    	echo 'Unknown command: ' ${OP}
    	echo 'Valid commands are: start, stop, status'
    	exit 1
    esac
    
  5. Make the script executable.
    # chmod +x /etc/xen/scripts/network-xen-multi-bridge.sh
  6. Restart networking or restart the system to activate the bridges.
    # service network restart
Multiple bridges should now be configured for guests on the Xen hypervisor.

11.2. Configurazione di rete per laptop con Red Hat Enterprise Linux 5.0

Per Red Hat Enterprise Linux 5.1 o versioni più recenti

Questa sezione descrive come aggiungere manualmente i bridge di rete. Questa procedura non è necessaria o consigliata per tutte le versioni di Red Hat Enterprise Linux più recenti rispetto alla versione 5.0. Per le versioni più recenti usare gli adattatori della "Rete virtuale" durante la creazione dei guest in virt-manager. NetworkManager funziona con i dispositivi di rete virtuali per impostazione predefinita in Red Hat Enterprise Linux 5.1 o nelle versioni più recenti.
Un esempio di file di configurazione XML per un dispositivo di rete virtuale:
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
</interface>
Nei file di configurazione xm i dispositivi di rete sono etichettati "vif".
The challenge in running the Xen hypervisor on a laptop is that most laptops will connected to the network via wireless network or wired connections. Often these connections are switched multiple times a day. In such an environment, the system assumes it has access to the same interface all the time and it also can perform ifup or ifdown calls to the network interface it is using. In addition wireless network cards do not work well in a virtualization environment due to Xen's (default) bridged network usage.
Questa impostazione vi permetterà di eseguire Xen in modalità offline se non siete in possesso di un collegamento di rete attivo sul vostro laptop. La soluzione più semplice per eseguire Xen su di un laptop è la seguente:
  • You will be configuring a 'dummy' network interface which will be used by Xen. In this example the interface is called dummy0. This will also allow you to use a hidden IP address space for your guests.
  • Sarà necessario utilizzare un indirizzo IP statico poichè DHCP non risulterà in ascolto per le richieste DHCP sull'interfaccia dummy. Potrete compilare una versione personalizzata di DHCP in modo da essere in ascolto sulle interfacce dummy, tuttavia sarà possibile usare anche dnsmasq per i servizi DNS, DHCP e tftpboot in un ambiente Xen. I processi d'impostazione e di configurazione saranno affrontati più in avanti all'interno di questa sezione/capitolo.
  • È possibile configurare anche il NAT/IP masquerading per abilitare l'accesso alla rete dei vostri guest.
Come configurare una interfaccia di rete dummy
Eseguire le fasi di seguito riportate sul vostro host:
  1. create una interfaccia di rete chiamata dummy0 ed assegnate un indirizzo IP statico. Nel nostro esempio è stato scelto 10.1.1.1 per evitare problemi di routing all'interno del nostro ambiente. Per abilitare il supporto del dispositivo dummy aggiungere le seguenti righe su /etc/modprobe.conf
    alias dummy0 dummy
    options dummy numdummies=1
    
  2. Per configurare il networking per dummy0 modificate/create /etc/sysconfig/network-scripts/ifcfg-dummy0:
    DEVICE=dummy0
    BOOTPROTO=none
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    ARP=yes
    
  3. Unite xenbr0 con dummy0, in questo modo sarete in grado di utilizzare il networking anche quando non siete collegati ad una rete fisica. Modificate /etc/xen/xend-config.sxp in modo da includere la voce netdev=dummy0:
    (network-script 'network-bridge bridge=xenbr0 netdev=dummy0')
    
  4. Open /etc/sysconfig/network in the guest and modify the default gateway to point to dummy0. If you are using a static IP, set the guest's IP address to exist on the same subnet as dummy0.
    NETWORKING=yes
    HOSTNAME=localhost.localdomain
    GATEWAY=10.1.1.1
    IPADDR=10.1.1.10
    NETMASK=255.255.255.0
    
  5. L'impostazione di NAT all'interno dell'host permetterà ai guest di accedere ad internet, utilizzando anche i collegamenti wireless, risolvendo così le problematiche presenti con la scheda wireless e Xen. Lo script di seguito riportato abiliterà NAT in base all'interfaccia attualmente usata per la connessione di rete.
Configurazione di NAT per i guest virtualizzati
Il Network address translation (NAT) permette agli indirizzi multipli di rete di collegarsi attraverso un indirizzo IP singolo, tramite l'intercettazione dei pacchetti ed il loro passaggio agli indirizzi IP privati. Copiate il seguente scirpt su /etc/init.d/xenLaptopNAT e create un soft link per /etc/rc3.d/S99xenLaptopNAT. Tale operazione avvia automaticamente NAT al momento dell'avvio.

NetworkManager e NAT wireless

Lo scirpt di seguito riportato potrebbe non funzionare bene con reti wireless o con il NetworkManager a causa di alcuni ritardi durante il processo d'avvio. In questo caso eseguite lo scirpt manualmente dopo che la macchina è stata avviata.
#!/bin/bash
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
GATEWAYDEV=`ip route | grep default | awk {'print $5'}`
iptables -F
case "$1" in
start)
	if test -z "$GATEWAYDEV"; then
	echo "No gateway device found"
    else
	echo  "Masquerading using $GATEWAYDEV"
	/sbin/iptables -t nat -A POSTROUTING -o $GATEWAYDEV -j MASQUERADE
fi
	echo "Enabling IP forwarding"
	echo 1 > /proc/sys/net/ipv4/ip_forward
	echo "IP forwarding set to `cat /proc/sys/net/ipv4/ip_forward`"
	echo "done."
	;;
*)
echo "Usage: $0 {start|restart|status}"
;;
esac
Come configurare dnsmasq per i servizi DNS, DHCP e tftpboot
Uno dei problemi durante l'esecuzione della virtualizzazione su di un laptop (o per qualsiasi altro computer non collegato tramite una connessione di rete singola o stabile), è causato dai frequenti cambiamenti delle interfacce di rete e della disponibilità. Usando una interfaccia di rete dummy, potrete creare un ambiente più stabile ma al tempo stesso potreste rendere più difficoltosa la disponibilità di servizi DHCP, DNS e tftpboot per le vostre macchine virtuali/guest. Il demone DHCP predefinito presente con Red Hat Enterprise Linux e Fedora Core non sarà in ascolto sulle interfacce dummy, le informazioni DNS inoltrate porebbero cambiare se eseguirete il collegamento con VPN e reti differenti.
Una soluzione alle suddette problematiche è rappresentata dall'utilizzo di dnsmasq, il quale è in grado di fornire tutti i servizi sopra indicati con un solo pacchetto. Altresì, esso vi permetterà di controllare i propri servizi che saranno disponibili solo alle richieste provenienti dalla vostra interfaccia dummy. Di seguito vengono riportate le fasi relative alla configurazione di dnsmasq su laptop in grado di eseguire la virtualizzazione:
  • Ottenete l'ultimissima versione di dnsmasq da qui.
  • Documentation for dnsmasq can be found here.
  • Copy the other files referenced below from http://et.redhat.com/~jmh/tools/xen/ and grab the file dnsmasq.tgz. The tar archive includes the following files:
    • nm-dnsmasq può essere utilizzato come dispatcher script per NetworkManager. Esso verrà eseguito ogni qualvota NetworkManager rileva una modifica del collegamento forzando un riavvio/ricaricamento di dnsmasq. Copiatelo su /etc/NetworkManager/dispatcher.d/nm-dnsmasq
    • xenDNSmasq può essere usato come script principale d'avvio o di arresto per /etc/init.d/xenDNSmasq
    • dnsmasq.conf è un file di configurazione d'esempio per /etc/dnsmasq.conf
    • dnsmasq è l'immagine binaria per /usr/local/sbin/dnsmasq
  • Una volta scompattato e compilato dnsmasq (l'installazione predefinita sarà il binario presente in /usr/local/sbin/dnsmasq) sarà necessario modificare il file di configurazione del vostro dnsmasq. Il file si trova in /etc/dnsmaqs.conf
  • Modificare la configurazione per soddisfare i vostri requisiti locali. Di seguito vengono riportati i parametri da modificare:
    • Il parametro interface permette a dnsmasq di essere in ascolto per le richieste DHCP e DNS solo su interfacce specifiche, come ad esempio interfacce dummy ma non sulle vostre interfacce pubbliche e di loopback. Aggiungete un'altra riga interface per più di una interfaccia. Un esempio potrebbe essere interface=dummy0 il quale indica l'ascolto sull'interfaccia dummy0.
    • dhcp-range per abilitare il server DHCP integrato sarà necessario fornire la gamma di indirizzi disponibili per il lease,e facoltativamente un lease time. Se siete in possesso di più di una rete sarà necessario ripetere questo processo per ogni rete alla quale desiderate fornire il servizio DHCP. Un esempio potrebbe essere (per la rete 10.1.1.* ed un lease time di 12 ore): dhcp-range=10.1.1.10,10.1.1.50,255.255.255.0,12h
    • dhcp-option per sovrascrivere l'instradamento predefinito fornito da dnsmasq il quale assume che il router sia la stessa macchina che esegue dnsmasq. Un esempio potrebbe essere dhcp-option=3,10.1.1.1
  • Dopo aver configurato dnsmasq è possibile copiare lo script come xenDNSmasq su /etc/init.d
  • Se desiderate avviare automaticamente dnsmasq durante l'avvio del sistema, registratelo utilizando chkconfig(8):
    chkconfig --add xenDNSmasq
    
    Abilitatelo per un avvio automatico:
    chkconfig --levels 345 xenDNSmasq on
    
  • Per configurare dnsmasq al riavvio ogni qualvolta NetworkManager rileva un cambiamento della connettività, utilizzate il seguente script nm-dnsmasq.
    • Copiare lo script nm-dnsmasq su /etc/NetworkManager/dispatcher.d/
    • Il dispatcher NetworkManager eseguirà lo script (in ordine alfabetico se siete in possesso di altri script nella stessa directory) ogni qualvolta si verifica una modifica della connettività
  • dnsmasq rileverà anche le modifiche nel vostro /etc/resolv.conf e le ricaricherà automaticamente (per esempio se avviate una sessione VPN).
  • Entrambi gli script nm-dnsmasq e xenDNSmasq imposteranno NAT se i guest virtuali si trovano in una rete nascosta per garantire loro un accesso alla rete pubblica.

Capitolo 12. Driver paravirtualizzati Xen

Para-virtualized drivers provide increased performance for fully virtualized Red Hat Enterprise Linux guests. Use these drivers if you are using fully virtualized Red Hat Enterprise Linux guests and require better performance.

Altri driver paravirtualizzati

Su Windows sono disponibili altri driver paravirtualizzati per gli hypervisor Xen e KVM.
Per guest di Windows su host Xen consultare la Windows Para-virtualized Drivers Guide relativa ai processi d'installazione e amministrazione
For Windows guests on KVM hosts, refer to Capitolo 13, Driver para-virtualizzati KVM.
I pacchetti RPM per i driver paravirtualizzati includono i moduli per i driver paravirtualizzati del networking e storage per i sistemi operativi guest supportati di Red Hat Enterprise. I suddetti driver permettono di avere prestazioni elevate durante operazioni I/O su sistemi operativi guest non modificati di Red Hat Enterprise Linux su host Red Hat Enterprise Linux 5.1 (o versioni più recenti).
I sistemi operativi guest supportati sono:
  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5

Supporto architettura per driver para-virtualizzati

I requisiti minimi del sistema operativo guest dipendono dall'architettura. Sono supportati solo i guest x86 e x86-64.
I driver non sono supportati sui sistemi operativi guest di Red Hat Enterprise Linux nelle versioni precedenti a Red Hat Enterprise Linux 3.
L'utilizzo di Red Hat Enterprise Linux 5 come piattaforma di virtualizzazione permette agli amministratori di sistema di consolidare i carichi di lavoro Linux e Windows, su hardware nuovi e più potenti, con migliore prestazione ed efficienza termica. Red Hat Enterprise Linux 4 (dall'update 6) ed i sistemi operativi guest di Red Hat Enterprise Linux 5 sono a conoscenza delle nuove caratteristiche tecnologiche di virtualizzazione, e sono in grado di interagire in modo efficace utilizzando capacità ed interfacce specifiche. Questo approccio garantisce caratteristiche di prestazione ed output simili rispetto alla esecuzione su sistemi bare metal.
As para-virtualization requires a modified guest operating system, not all operating systems can use para-virtualization. For operating systems which can not be modified, full virtualization is required. Full virtualization, by default, uses emulated disk, network, video and other hardware devices. Emulated I/O devices can be very slow and are not suited for applications requiring high disk and/or network throughput. The majority of the performance loss with virtualization occurs through the use of emulated devices.
I driver del dispositivo paravirtualizzato sono inclusi nei pacchetti di Red Hat Enterprise Linux. I driver apportano un numero significativo di vantaggi delle prestazioni di sistemi operativi guest paravirtualizzati sui sistemi operativi non modificati, poichè solo il driver del dispositivo paravirtualizzato (ma non il resto del sistema operativo) è a conoscenza della piattaforma di virtualizzazione sottostante.
Dopo aver installato i driver del dispositivo para-virtualizzato verrà visualizzato ancora una scheda di rete o dispositivo a disco come disco fisico o scheda di rete per il sistema operativo. Tuttavia il driver del dispositivo interagisce direttamente con la piattaforma di virtualizzazione (senza emulazione), in modo da permettere un accesso efficiente al disco ed alla rete, garantendo così il funzionamento dei sottosistemi di rete o del disco ad una velocità simile a quella nativa pur trovandosi in un ambiente virtualizzato, e senza aver bisogno di alcuna modifica dei sistemi operativi guest esistenti.
I driver paravirtualizzati presentano alcuni requisiti host. Gli host a 64 bit possono eseguire:
  • guest a 32 bit.
  • guest a 64 bit.
  • un mix tra guest a 32 e 64 bit.

12.1. Requisiti del sistema

Questa sezione fornisce i requisiti necessari per i driver para-virtualizzati con Red Hat Enterprise Linux.
Installazione
Prima di installare i driver para-virtualizzati è necessario soddisfare i seguenti requisiti (di seguito elencati).

Red Hat Enterprise Linux 4.7, 5.3 e versioni più recenti

Tutte le versioni di Red Hat Enterprise Linux da 4.7 e 5.3 possiedono il modulo kernel per i driver paravirtualizzati, pv-on-hvm, nel pacchetto del kernel predefinito. Ciò significa che i driver paravirtualizzati sono disponibili per Red Hat Enterprise Linux 4.7 e versioni più recenti o 5.3 e versioni più recenti.
Per ogni installazione del sistema operativo guest sono necessari per i dirver para virtualizzati i seguenti pacchetti RPM.
Minimum host operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
Minimum guest operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
  • Red Hat Enterprise Linux 4 Update 6 or newer.
  • Red Hat Enterprise Linux 3 Update 9 or newer.
Red Hat Enterprise Linux 5 requires:
  • kmod-xenpv.
Red Hat Enterprise Linux 4 requires:
  • kmod-xenpv,
  • modules-init-tools (for versions prior to Red Hat Enterprise Linux 4.6z you require modules-init-tools-3.1-0.pre5.3.4.el4_6.1 or greater), and
  • modversions.
Red Hat Enterprise Linux 3 requires:
  • kmod-xenpv.
You require at least 50MB of free disk space in the /lib file system.

12.2. Supporto e restrizioni per il para-virtualization

Questa sezione affronta le restrizioni ed i requisiti per il supporto dell'utilizzo di driver para-virtualizzati su Red Hat Enterprise Linux. Il supporto e le relative restrizioni sono disponibili nelle sezioni di seguito riportate.
Sistemi operativi guest supportati
Il supporto per i driver para-virtualizzati è disponibile per i seguenti sistemi operativi e per le seguenti versioni:
  • Red Hat Enterprise Linux 5.1 e versioni più recenti.
  • Red Hat Enterprise Linux 4 Update 6 e versioni più recenti.
  • Red Hat Enterprise Linux 3 Update 9 e versioni più recenti.
L'utente è supportato per l'esecuzione di sistemi operativi di guest a 32 bit con driver para-virtualizzati su Red Hat Enterprise Linux 5 Virtualization.
La tabella sotto riportata indica le varianti del kernel supportate con i driver para-virtualizzati. Potrete utilizzare il comando di seguito riportato per identificare l'esatta revisione del kernel attualmente installata sul vostro host. Confrontate l'output con la tabella per determinare se è supportata.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Le varianti del kernel Red Hat Enterprise Linux 5 i686 e x86_64 includono il Symmetric Multiprocessing(SMP), non è necessario alcun RPM del kernel separato.
Determinate i requisiti kernel specifici del processore per i guest Red Hat Enterprise Linux 3 tramite la tabella di seguito riportata.
Tabella 12.1. Architetture kernel del guest supportate per driver paravirtualizzati
Architettura del kernel Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5
athlon Supportato (AMD)   
athlon-SMP Supportato (AMD)   
i32e Supportato (Intel)   
i686 Supportato (Intel) Supportato Supportato
i686-PAE Supportato
i686-SMP Supportato (Intel) Supportato  
i686-HUGEMEM Supportato (Intel) Supportato  
x86_64 Supportato (AMD) Supportato Supportato
x86_64-SMP Supportato (AMD) Supportato  
x86_64-LARGESMP Supportato  
Itanium (IA64) Supportato

Importante

Il sistema host necessita di Red Hat Enterprise Linux 5.1 e versioni più recenti.

Come sapere quale kernel state utilizzando

Annotate o ricordate l'output del comando sotto riportato. Esso è il valore che determina i pacchetti ed i moduli da scaricare.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Il vostro output dovrebbe essere simile al seguente:
kernel-PAE-2.6.18-53.1.4.el5.i686
Il nome del kernel è PAE (Physical Address Extension), la versione è 2.6.18, la release è 53.1.4.el5 e l'architettura è i686. L'rpm del kernel deve avere sempre il seguente formato kernel-name-version-release.arch.rpm.
Limitazioni importanti
I driver del dispositivo para-virtualizzato possono essere installati dopo aver installato con successo un sistema operativo guest. Sarà necessario avere un host ed un guest funzionanti prima di poter installare i suddetti driver.

Dispositivi a blocchi para-virtualizzati e GRUB

Al momento GRUB non è in grado di accedere ai dispositivi a blocchi para-virtualizzati. Per questo motivo un guest non potrà essere avviato da un dispositivo che utilizza i driver del dispositivo a blocchi para-virtualizzato. Ed in modo specifico, un disco che contiene il Master Boot Record(MBR), o un boot loader (GRUB), o le immagini initrd del kernel. Cioè qualsiasi disco che contiene la directory /boot o partizione non può utilizzare i driver del dispositivo a blocchi para-virtualizzato.
Dipendenze dell'architettura per la variante del kernel di Red Hat Enterprise Linux 3
Per i sistemi operativi guest basati su Red Hat Enterprise Linux 3, è necessario usare il kernel specifico per il processore e gli RPM del driver para-virtualizzato, come riportato nelle seguenti tabelle. Se non installate il pacchetto corrispondente del driver para-virtualizzato il processo di caricamento del modulo xen-pci-platform fallirà.
La tabella di seguito riportata mostra il kernel host necessario per eseguire un guest di Red Hat Enterprise Linux 3, se il guest è stato compilato da un processore Intel.
Tabella 12.2. Architettura del kernel host necessaria per i guest che utilizzano driver para-virtualizzati su Red Hat Enterprise Linux 3 per processori Intel
Tipo di kernel guest Tipo di kernel host necessario
ia32e (UP e SMP) x86_64
i686 i686
i686-SMP i686
i686-HUGEMEM i686

La tabella mostra il kernel host necessario per eseguire un guest di Red Hat Enterprise Linux 3, se il guest è stato compilato per un processore AMD.
Tabella 12.3. Architettura del kernel host necessaria per i guest che utilizzano driver para-virtualizzati su Red Hat Enterprise Linux 3 per processori AMD
Tipo di kernel guest Tipo di kernel host necessario
athlon i686
athlon-SMP i686
x86_64 x86_64
x86_64-SMP x86_64

12.3. Installazione dei driver paravirtualizzati

I seguenti capitoli descrivono il metodo attraverso il quale è possibile installare e configurare i guest completamente virtualizzati, da eseguire su Red Hat Enterprise Linux 5.1 o su versioni più recenti con i driver para-virtualizzati.

Prima di procedere verificate che la vostra architettura sia supportata

I driver paravirtualizzati sono supportati solo su determinate combinazioni hardware-versione. Verificate che i requisiti hardware e del sistema operativo siano stati soddisfatti prima di procedere all'installazione dei driver paravirtualizzati.

Massimizzare i benefici dei driver para-virtualizzati per nuove installazioni

Se state installando un nuovo sistema guest, per poter ottenere il massimo dei benefici dai driver del dispositivo a blocchi para-virtualizzati, create il guest con un minimo di due dischi.
Utilizzo dei driver paravirtualizzati per il disco che contiene l'MBR ed il boot loader (GRUB), e per la partizione /boot. Questa partizione può essere molto piccola poichè deve avere una capacità sufficiente per contenere la partizione /boot.
Utilizzate il secondo disco e qualsiasi altro disco per tutte le atre partizioni (es. /, /usr) o volumi logici.
Usando questo metodo d'installazione, dopo aver installato i driver del dispositivo a blocchi para-virtualizzati e completato l'installazione del guest, è possibile utilizzare i driver del dispositivo a blocchi para-virtualizzati solo con l'avvio del guest e l'accesso alla partizione /boot.

12.3.1. Fasi comuni del processo d'installazione

L'elenco di seguito riportato affronta le fasi comuni attraverso tutte le versioni del sistema operativo del guest.
  1. Copy the RPMs for your hardware architecture to a suitable location in your guest operating system. Your home directory is sufficient. If you do not know which RPM you require verify against the table at Sezione 12.2, «Supporto e restrizioni per il para-virtualization».
  2. Usate il comando rpm o yum per installare i pacchetti. L'utilità rpm installerà quattro nuovi moduli del kernel in /lib/modules/[%kversion][%kvariant]/extra/xenpv/%release:
    • the PCI infrastructure module, xen_platform_pci.ko,
    • the ballooning module, xen_balloon.ko,
    • the virtual block device module, xen_vbd.ko,
    • and the virtual network device module, xen_vnif.ko.
  3. Se il guest non supporta automaticamente il caricamento dei driver paravirtualizzati (per esempio Red Hat Enterprise Linux 3), eseguite le fasi necessarie di post-installazione per copiare i driver nelle posizioni specifiche del sistema operativo.
  4. Arrestate il sistema operativo del vostro guest.
  5. Reconfigure the guest operating system's configuration file on the host to use the installed para-virtualized drivers.
  6. Rimuovere la entry “type=ioemu” per il dispositivo di rete.
  7. Add any additional disk partitions, volumes or LUNs to the guest so that they can be accessed via the para-virtualized (xen-vbd) disk driver.
  8. For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
  9. A typical disk entry resembles the following:
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/dev/hda6'/>
      <target dev='hda'/>
    </disk>
    
    Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/dev/hda6'/>
      <target dev='xvda'/>
    </disk>
    
  10. Aggiungere qualsiasi entità di storage supplementare che desiderate usare per il driver del dispositivo a blocchi para-virtualizzato.
  11. Riavvio del guest:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.
  12. Reconfigure the guest network.

12.3.2. Installazione e configurazione di driver para-virtualizzati su Red Hat Enterprise Linux 3

Questa sezione contiene le informazioni dettagliate per i driver para-virtualizzati in un sistema operativo guest di Red Hat Enterprise 3.

Nota Bene

Questi pacchetti non supportano l'avvio da un disco paravirtualizzato. L'avvio del kernel del sistema operativo guest necessita di un utilizzo del driver IDE emulato, mentre qualsiasi altra applicazione dello spazio utente (non del sistema) e dati, possono usare il driver del dispositivo a blocchi paravirtualizzato.
Installazione del driver
L'elenco riportato affronta le fasi necessarie per l'installazione di un guest Red Hat Enterprise Linux 3 con driver para-virtualizzati.
  1. Install the latest kernel version. The para-virtualized drivers require at least Red Hat Enterprise Linux 3.9 kernel version kernel-2.4.21-60.EL for all the required headers.
  2. Copiate l'RPM kmod-xenpv corrispondente alla vostra architettura hardware e variante del kernel sul vostro sistema operativo guest.
  3. Utilizzate l'utilità rpm per installare i pacchetti RPM. Assicuratevi di aver identificato correttamente il pacchetto necessario per la variante e l'architettura del sistema operativo del vostro guest.
    [root@rhel3]# rpm -ivh kmod-xenpv*
    
  4. Use the commands below load the para-virtualized driver modules. %kvariant is the kernel variant the para-virtualized drivers have been build against and %release corresponds to the release version of the para-virtualized drivers.
    [root@rhel3]# mkdir -p /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# cp -R /lib/modules/2.4.21-52.EL[%kvariant]/extra/xenpv/%release \
    /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# depmod -ae
    [root@rhel3]# modprobe xen-vbd
    [root@rhel3]# modprobe xen-vnif
    

    Nota Bene

    Durante l'installazione dei moduli del driver verranno generati da insmod alcuni messaggi di avvertimento. Tali messaggi vengono generati poichè MODVERSIONS è abilitato su Red Hat Enterprise Linux 3. I suddetti messaggi possono essere ignorati.
  5. Verificate /etc/modules.conf ed assicuratevi di avere un alias per eth0 simile a quello di seguito riportato. Se desiderate configurare alcune interfacce multiple, aggiungete una riga supplementare per ogni interfaccia.
    alias eth0 xen-vnif
    
    Modificate /etc/rc.local ed aggiungete la riga:
    insmod /lib/modules/'uname -r'/extra/xenpv/%release/xen-vbd.o
    

    Nota Bene

    Sostituite “%release” con la versione attuale della release (per esempio 0.1-5.el) per i driver para-virtualizzati. Se aggiornate il pacchetto RPM del driver para-virtualizzato, assicuratevi si aggiornare la versione della release.
  6. Arrestate la macchina virtuale (utilizzate “#shutdown -h now” all'interno del guest).
  7. Edit the guest configuration file in /etc/xen/YourGuestName with a text editor, performing the following changes:
    • Rimuovere la voce “type=ioemu” da “vif=”.
    • Aggiungete qualsiasi partizione del disco, volumi o LUN sul guest in modo da poterli accedere tramite il driver del disco para-virtualizzato (xen-vbd).
    • For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
    • A typical disk entry resembles the following:
      <disk type='file' device='disk'>
        <driver name='file'/>
        <source file='/dev/hda6'/>
        <target dev='hda'/>
      </disk>
      
      Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
      <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/dev/hda6'/>
        <target dev='xvda'/>
      </disk>
      
      
    • Once complete, save the modified configuration file and restart the guest.
  8. Boot the virtual machine:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.

Attenzione

I driver para-virtualizzati non vengono aggiunti automaticamente e caricati sul sistema poichè il supporto weak-modules e modversions non è presente con Red Hat Enterprise Linux 3. Per inserire il modulo eseguite il seguente comando.
insmod xen_vbd.ko
Red Hat Enterprise Linux 3 richiede una creazione manuale dei file speciali per i dispositivi a blocchi che utilizzano xen-vbd. Le fasi di seguito riportate affronteranno il metodo attraverso il quale è possibile creare e registrare i dispositivi a blocchi para-virtualizzati.
Usate il seguente script per creare i file speciali dopo aver caricato il driver del dispositivo a blocchi para-virtualizzato.
#!/bin/sh
module="xvd"
mode="664"
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
# < mknod for as many or few partitions on xvd disk attached to FV guest >
# change/add xvda to xvdb, xvbd, etc. for 2nd, 3rd, etc., disk added in
# in xen config file, respectively.
mknod /dev/xvdb b $major 16
mknod /dev/xvdb1 b $major 17
mknod /dev/xvdb2 b $major 18
chgrp disk /dev/xvd*
chmod 0660 /dev/xvd*
Per ogni disco virtuale aggiuntivo aumentate il numero minore di 16. Nell'esempio seguente viene creato un dispositivo supplementare con un numero minore di 16.
# mknod /dev/xvdc b $major 16
# mknod /dev/xvdc1 b $major 17
In questo caso il dispositivo successivo avrà 32 e potrà essere creato tramite:
# mknod /dev/xvdd b $major 32
# mknod /dev/xvdd1 b $major 33
Ora è possibile verificare se le partizioni create sono disponibili.
[root@rhel3]# cat /proc/partitions
major   minor     #blocks   name

  3        0      10485760  hda
  3        1        104391  hda1
  3        2      10377990  hda2
202        16         64000  xvdb
202        17         32000  xvdb1
202        18        32000  xvdb2
253        0       8257536  dm-0
253        1       2031616  dm-1
Nell'output sopra riportato è possibile osservare come il dispositivo partizionato “xvdb” sia disponibile al sistema.
La procedura di seguito riportata aggiunge il nuovo dispositivo al guest e lo rende persistente dopo il riavvio. Tutti questi comandi sono eseguiti sul guest.
  1. Create le directory sulle quali montare l'immagine del dispositivo a blocchi.
    [root@rhel3]# mkdir /mnt/pvdisk_p1
    [root@rhel3]# mkdir /mnt/pvdisk_p2
    
  2. Montate i dispositivi sulle nuove directory.
    [root@rhel3]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel3]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verificate che i dispositivi siano stati montati correttamente.
    [root@rhel3]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Aggiornate il file /etc/fstab all'interno del guest per montare i dispositivi durante la sequenza d'avvio. Aggiungere le seguenti righe:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Suggerimento

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Un dom0 di Red Hat Enterprise Linux 5.2 non avrà bisogno di questo parametro per il guest.

Importante

I pacchetti RPM binari per (ia64) Itanium e le compilazioni non sono attualmente disponibili.

12.3.3. Installazione e configurazione dei driver para-virtualizzati su Red Hat Enterprise Linux 4

Questa sezione contiene le informazioni dettagliate per i driver para-virtualizzati in un sistema operativo guest di Red Hat Enterprise 4.

Nota Bene

Questi pacchetti non supportano l'avvio da un disco paravirtualizzato. L'avvio del kernel del sistema operativo guest ha bisogno di un driver IDE emulato, mentre qualsiasi altra applicazione dello spazio utente (non del sistema) e dati, possono usare il driver del dispositivo a blocchi paravirtualizzato.
Installazione del driver
Il seguente elenco affronta le fasi necessarie per installare un guest Red Hat Enterprise Linux 4 con driver para-virtualizzati.
  1. Copiate gli RPM kmod-xenpv, modules-init-tools e modversions corrispondenti alla vostra architettura hardware e variante del kernel sul vostro sistema operativo guest.
  2. Utilizzate l'utilità rpm per installare i pacchetti RPM. Assicuratevi di aver identificato correttamente il pacchetto necessario per l'architettura e la variante del vostro sistema operativo guest. Un module-init-tools aggiornato sarà necessario per questo pacchetto, esso è disponibile con il kernel di Red Hat Enterprise Linux4-6-z e versioni più recenti.
    [root@rhel4]# rpm -ivh modversions
    [root@rhel4]# rpm -Uvh module-init-tools
    [root@rhel4]# rpm -ivh kmod-xenpv*
    

    Nota Bene

    Sono disponibili diversi pacchetti per UP, SMP, Hugemem e per le architetture, quindi assicuratevi di avere gli RPM corretti per il vostro kernel.
  3. Execute cat /etc/modprobe.conf to verify you have an alias for eth0 like the one below. If you are planning to configure multiple interfaces add an additional line for each interface. If it does not look like the entry below change it.
    alias eth0 xen-vnif
    
  4. Arrestate la macchina virtuale (utilizzate “#shutdown -h now” all'interno del guest).
  5. Modificate il file di configurazione del guest in /etc/xen/YourGuestsName nel modo seguente:
    • Rimuovere la voce “type=ioemu” da “vif=”.
    • Aggiungete qualsiasi partizione del disco, volumi o LUN sul guest in modo da poterli accedere tramite il driver del disco para-virtualizzato (xen-vbd).
    • Per ogni dispositivo fisico aggiuntivo, LUN, partizione o volume, aggiungete una voce, simile a quella di seguito riportata, nella sezione “disk=” nel file di configurazione del guest. La voce originale “disk=” potrebbe anche somigliare alla seguente.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    • Una volta aggiunti i dispositivi fisici supplementari, LUN, partizioni o volumi; la voce del driver para-virtualizzato presente nel vostro file di configurazione XML dovrebbe essere simile alla seguente.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Nota Bene

      Utilizzate “tap:aio” per il dispositivo paravirtualizzato se usate una immagine basata sul file.
  6. Avviate la macchina virtuale utilizzando il comando virsh:
    # virsh start YourGuestName
Al primo riavvio del guest virtuale, kudzu vi chiederà se "Mantenere o cancellare il dispositivo di rete Realtek" e di "Configurare il dispositivo xen-bridge". A questo punto dovreste configurare xen-bridge e cancellare il dispositivo di rete Realtek.

Suggerimento

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Un dom0 di Red Hat Enterprise Linux 5.2 non avrà bisogno di questo parametro per il guest.
Ora verificate che le partizioni da voi create siano disponibili.
[root@rhel4]# cat /proc/partitions
major    minor   #blocks   name

   3        0    10485760  hda
   3        1      104391  hda1
   3        2    10377990  hda2
 202        0       64000  xvdb
 202        1       32000  xvdb1
 202        2       32000  xvdb2
 253        0     8257536  dm-0
 253        1     2031616  dm-1
Nell'output sopra riportato potrete notare come il dispositivo partizionato “xvdb” sia disponibile al sistema.
La procedura di seguito riportata aggiunge il nuovo dispositivo al guest rendendolo persistente dopo il riavvio. Tutti questi comandi sono eseguiti sul guest.
  1. Create le directory sulle quali montare l'immagine del dispositivo a blocchi.
    [root@rhel4]# mkdir /mnt/pvdisk_p1
    [root@rhel4]# mkdir /mnt/pvdisk_p2
    
  2. Montate i dispositivi sulle nuove directory.
    [root@rhel4]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel4]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verificate che i dispositivi siano stati montati correttamente.
    [root@rhel4]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Aggiornate il file /etc/fstab all'interno del guest per poter montare i dispositivi durante la sequenza d'avvio. Aggiungere le seguenti righe:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Nota Bene

Questo pacchetto non è supportato per kernel e sistemi Red Hat Enterprise Linux 4-GA fino a Red Hat Enterprise Linux 4 update 2.

Nota importante

I pacchetti RPM binary IA64 e le compilazioni non sono attualmente disponibili.

Caricamento automatico del modulo

Il driver xen-vbd potrebbe non essere caricato automaticamente. Eseguire il seguente comando dal terminale del guest, sostituite %release con la versione della release corretta per i driver paravirtualizzati.
# insmod /lib/modules/'uname -r'/weak-updates/xenpv/%release/xen_vbd.ko

12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5

This section contains detailed instructions for the para-virtualized drivers in a Red Hat Enterprise Linux 5 guest operating system.

Nota Bene

Questi pacchetti non supportano l'avvio da un disco paravirtualizzato. L'avvio del kernel del sistema operativo guest necessita di un driver IDE emulato, mentre qualsiasi altra applicazione dello spazio utente (non del sistema) e dati, possono usare il driver del dispositivo a blocchi paravirtualizzato.
The procedure below covers the steps to enable the para-virtualized drivers for a Red Hat Enterprise Linux 5 guest.
Procedura 12.1. Enable para-virtualized drivers for a Red Hat Enterprise Linux Guest
  1. Arrestate la macchina virtuale (utilizzate “#shutdown -h now” all'interno del guest).
  2. Modificate il file di configurazione in /etc/xen/<Your GuestsName> nel modo seguente:
    1. Rimuovere la voce “type=ioemu” da “vif=”.
    2. Aggiungete qualsiasi partizione del disco, volumi o LUN sul guest in modo da poterli accedere tramite il driver del disco para-virtualizzato (xen-vbd).
    3. Per ogni dispositivo fisico aggiuntivo, LUN, partizione o volume, aggiungete una voce, simile a quella di seguito riportata, nella sezione “disk=” nel file di configurazione del guest. La voce originale “disk=” potrebbe anche somigliare alla seguente.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    4. Una volta aggiunti i dispositivi fisici supplementari, LUN, partizioni o volumi; la voce del driver para-virtualizzato presente nel vostro file di configurazione XML dovrebbe essere simile alla seguente.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Nota Bene

      Utilizzate “tap:aio” per il dispositivo paravirtualizzato se usate una immagine basata sul file.
  3. Avviate la macchina virtuale utilizzando il comando virsh:
    # virsh start YourGuestName
    
Per verificare se l'interfaccia di rete viene visualizzata correttamente dopo l'installazione dei driver para-virtualizzati, emettete il seguente comando sul guest. Esso dovrebbe mostrare le informazioni sull'interfaccia incluso l'indirizzo IP assegnato.
[root@rhel5]# ifconfig eth0
Ora verificate che le partizioni da voi create siano disponibili.
[root@rhel5]# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvdb
 202     1      32000   xvdb1
 202     2      32000   xvdb2
 253     0    8257536   dm-0
 253     1    2031616   dm-1
Nell'output sopra riportato potrete notare come il dispositivo partizionato “xvdb” sia disponibile al sistema.
La procedura di seguito riportata aggiunge il nuovo dispositivo al guest rendendolo persistente dopo il riavvio. Tutti questi comandi sono eseguiti sul guest.
  1. Create le directory sulle quali montare l'immagine del dispositivo a blocchi.
    [root@rhel5]# mkdir /mnt/pvdisk_p1
    [root@rhel5]# mkdir /mnt/pvdisk_p2
    
  2. Montate i dispositivi sulle nuove directory.
    [root@rhel5]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel5]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verificate che i dispositivi siano stati montati correttamente.
    [root@rhel5]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Aggiornate il file /etc/fstab all'interno del guest per poter montare i dispositivi durante la sequenza d'avvio. Aggiungere le seguenti righe:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Suggerimento

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Un dom0 di Red Hat Enterprise Linux 5.2 non avrà bisogno di questo parametro per il guest.
Hiding fake interfaces
Sometimes, activating the para-virtualized drivers does not delete the old virtualized network interfaces. To remove these interfaces from guests use the following procedure.
  1. Add the following lines to the /etc/modprobe.d/blacklist file. Blacklist 8139cp and 8139too for the RealTek 8139 and e1000 for the virtualized Intel e1000 NIC.
    8139cp
    8139too
    e1000
    
  2. Remove the old network scripts from the /etc/sysconfig/network-scripts directory.
  3. Reboot the guest. The default network interface should now use the para-virtualized drivers.

12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6

This section describes the use of para-virtualized drivers in a Red Hat Enterprise Linux 6 guest.
The para-virtualized drivers are enabled by default for a Red Hat Enterprise Linux 6 guest. The guest will automatically unplug any emulated devices that are presented to it, and will use the para-virtualized drivers instead.
Although the para-virtualized drivers are enabled by default, they can be disabled. Add the following to the guest kernel command line upon boot to disable the para-virtualized drivers:
xen_emul_unplug=never

12.4. Configurazione dei driver di rete para-virtualizzati

Once the para-virtualized network driver is loaded you may need to reconfigure the guest's network interface to reflect the driver and virtual Ethernet card change.
Eseguite le seguenti fasi per riconfigurare l'interfaccia di rete all'interno del guest.
  1. In virt-manager aprite la finestra della console per il guest ed eseguite il login come root.
  2. Su Red Hat Enterprise Linux 4 verificate che il file /etc/modprobe.conf contenga la riga “alias eth0 xen-vnif”.
    # cat /etc/modprobe.conf
    alias eth0 xen-vnif
    
  3. To display the present settings for eth0 execute “# ifconfig eth0”. If you receive an error about the device not existing you should load the modules manually as outlined in Sezione 36.4, «Caricamento manuale dei driver para-virtualizzati».
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:00:00:6A:27:3A  
              BROADCAST MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:846 (846.0 b)
    
  4. Start the network configuration utility(NetworkManager) with the command “# system-config-network”. Click on the “Forward” button to start the network card configuration.
  5. Select the 'Xen Virtual Ethernet Card (eth0)' entry and click 'Forward'.
    Configure the network settings as required.
  6. Complete the configuration by pressing the 'Apply' button.
  7. Press the 'Activate' button to apply the new settings and restart the network.
  8. A questo punto dovreste visualizzare la nuova interfaccia di rete con un indirizzo IP.
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:16:3E:49:E4:E0
              inet addr:192.168.78.180  Bcast:192.168.79.255  Mask:255.255.252.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:501209 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:46265452 (44.1 MiB)
    

12.5. Configurazione hardware para-virtualizzata aggiuntiva

Questa sezione affronterà il metodo attraverso il quale è possibile aggiungere uno storage di rete virtuale supplementare su di un sistema operativo guest. Per maggiori informazioni su come configurare la rete e le risorse di storage su Red Hat Enterprise Linux 5 Virtualization, consultare il documento disponibile su Emerging Technologies, Red Hat.com

12.5.1. Interfacce di rete virtualizzate

Eseguire le fasi di seguito riportate per la configurazione di dispositivi di rete aggiuntivi per il vostro guest.
Modificate il file di configurazione del vostro guest in /etc/xen/YourGuestName, sostituendo YourGuestName con il nome del vostro guest.
La voce originale potrebbe essere simile alla seguente.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0" ]
Aggiungere una ulteriore entry alla sezione “vif=” del file di configurazione, simile a quella riportata qui di seguito.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0",
    "mac=00:16:3e:2f:d5:a9,bridge=xenbr0" ]
Assicuratevi di generare un indirizzo MAC unico per la nuova interfaccia. Usate il seguente comando.
# echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
Dopo aver riavviato il guest eseguite nel sistema operativo guest le fasi riportate. Verificate che l'aggiornamento sia stato aggiunto al vostro /etc/modules.conf in Red Hat Enterprise Linux 3 o /etc/modprobe.conf in Red Hat Enterprise Linux 4 e Red Hat Enterprise Linux 5. Inserire un nuovo alias per ogni nuova interfaccia aggiunta.
alias eth1 xen-vnif
Ora eseguite il test di ogni interfaccia da voi aggiunta, per assicurarvi che esse siano disponibili all'interno del guest.
# ifconfig eth1
Il comando sopra riportato dovrebbe mostrare le proprietà di eth1, ripetere il comando per eth2 se avete aggiunto una terza interfaccia e così via.
Ora è possibile configurare le nuove interfacce utilizzando redhat-config-network su Red Hat Enterprise Linux 3, oppure system-config-network su Red Hat Enterprise Linux 4 e Red Hat Enterprise Linux 5.

12.5.2. Dispositivi di storage virtuali

Eseguire le fasi di seguito riportate per configurare i dispositivi di storage virtuali per il vostro guest.
Modificate il file di configurazione del vostro guest in /etc/xen/YourGuestName, sostituendo YourGuestName con il nome del vostro guest. La entry originale potrebbe somigliare alla seguente.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w"]
Aggiungete una voce supplementare per il vostro nuovo dispositivo fisico, LUN, partizione o volume, al parametro “disk=” del file di configurazione. Le entity relative allo storage che utilizzano il driver para-virtualizzato somigliano alla voce di seguito riportata. Il parametro “tap:aio” indica all'hypervisor di usare il driver para-virtualizzato.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w" ]
Se desiderate aggiungere nuove entry aggiungetele nella sezione disk=” separate da una virgola.

Nota Bene

You need to increment the letter for the 'xvd' device, that is for your second storage entity it would be 'xvdb' instead of 'xvda'.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage2.dsk,xvdb,w" ]
Verificate che le partizioni siano state create e siano disponibili.
# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvda
 202     1      64000   xvdb
 253     0    8257536   dm-0
 253     1    2031616   dm-1
Nell'output sopra citato è possibile visualizzare come la partizione o dispositivo “xvdb” risulta essere disponibile al sistema.
Montate i nuovi dispositivi e dischi sui mount point locali ed aggiornate /etc/fstab all'interno del guest, in modo da montare i dispositivi e le partizioni al momento dell'avvio.
# mkdir /mnt/pvdisk_xvda
# mkdir /mnt/pvdisk_xvdb
# mount /dev/xvda /mnt/pvdisk_xvda
# mount /dev/xvdb /mnt/pvdisk_xvdb
# df /mnt
Filesystem           1K-blocks      Used   Available Use%  Mounted on
/dev/xvda                64000        15       63985   1%  /mnt/pvdisk_xvda
/dev/xvdb                64000        15       63985   1%  /mnt/pvdisk_xvdb

Capitolo 13. Driver para-virtualizzati KVM

Para-virtualized drivers are available for virtualized Windows guests running on KVM hosts. These para-virtualized drivers are included in the virtio-win package. The virtio-win package supports block (storage) devices and network interface controllers.
As with the KVM module, the virtio-win drivers package is only available on hosts running Red Hat Enterprise Linux 5.4 and newer.
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.
The KVM para-virtualized drivers are automatically loaded and installed on the following versions of Red Hat Enterprise Linux:
  • Red Hat Enterprise Linux 4.8 and newer
  • Red Hat Enterprise Linux 5.3 and newer
  • Red Hat Enterprise Linux 6.
Those Red Hat Enterprise Linux versions detect and install the drivers so additional installation steps are not required.

Nota Bene

PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
Le seguenti versioni di Microsoft Windows presentano un supporto dei driver paravirtualizzati KVM:
  • Windows XP (32-bit only)
  • Windows Server 2003 (32-bit and 64-bit versions)
  • Windows Server 2008 (32-bit and 64-bit versions)
  • Windows 7 (32-bit and 64-bit versions)

13.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.
You can install the para-virtualized drivers on your guest by one of the following methods:
  • hosting the installation files on a network accessible to the guest,
  • using a virtualized CD-ROM device of the driver installation disk .iso file, or
  • using a virtualized floppy device to install the drivers during boot time (for Windows guests).
This guide describes installation from the para-virtualized installer disk as a virtualized CD-ROM device.
  1. Scaricare i driver

    The virtio-win package contains the para-virtualized block and network drivers for all supported Windows guests.
    If the Red Hat Enterprise Linux Supplementary channel entitlements are not enabled for the system, the download will not be available. Enable the Red Hat Enterprise Linux Supplementary channel to access the virtio-win package.
    Download the virtio-win package with the yum command.
    # yum install virtio-win
    
    The drivers are also available on the Red Hat Enterprise Linux Supplementary disc or from Microsoft (windowsservercatalog.com). Note that the Red Hat Enterprise Virtualization Hypervisor and Red Hat Enterprise Linux are created on the same code base so the drivers for the same version (for example, 5.5) are supported for both environments.
    Il pacchetto virtio-win installa una immagine del CD-ROM (il file virtio-win.iso) nella directory /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.
Installing drivers with a virtualized CD-ROM
This procedure covers installing the para-virtualized drivers with a virtualized CD-ROM after Windows is installed.
Follow Procedura 13.1, «Utilizzo di virt-manager per il montaggio di una immagine CD-ROM per un guest di Windows» to add a CD-ROM image with virt-manager and then install the drivers.
Procedura 13.1. Utilizzo di virt-manager per il montaggio di una immagine CD-ROM per un guest di Windows
  1. Open virt-manager and the virtualized guest

    Open virt-manager, select your virtualized guest from the list by double clicking the guest name.
  2. Open the hardware tab

    Click the Add Hardware button in the Hardware tab.
  3. Select the device type

    This opens a wizard for adding the new device. Select Storage from the dropdown menu.
    Click the Forward button to proceed.
  4. Select the ISO file

    Choose the File (disk image) option and set the file location of the para-virtualized drivers .iso image file. The location file is named /usr/share/virtio-win/virtio-win.iso.
    Se i driver sono stati salvati su CD-ROM fisici usare l'opzione Partizione disco normale.
    Set the Device type to IDE cdrom and click Forward to proceed.
  5. Disc assigned

    The disk has been assigned and is available for the guest once the guest is started. Click Finish to close the wizard or back if you made a mistake.
  6. Reboot

    Reboot or start the guest to add the new device. Virtualized IDE devices require a restart before they can be recognized by guests.
Once the CD-ROM with the drivers is attached and the guest has started, proceed with Procedura 13.2, «Windows installation».
Procedura 13.2. Windows installation
  1. Open My Computer

    On the Windows guest, open My Computer and select the CD-ROM drive.
  2. Select the correct installation files

    There are four files available on the disc. Select the drivers you require for your guest's architecture:
    • the para-virtualized block device driver (RHEV-Block.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • the para-virtualized network device driver (RHEV-Network.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • or both the block and network device drivers.
    Double click the installation files to install the drivers.
  3. Install the block device driver

    1. Start the block device driver installation

      Double click RHEV-Block.msi or RHEV-Block64.msi.
      Press Next to continue.
    2. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    3. Finish

      Press Finish to complete the installation.
  4. Install the network device driver

    1. Start the network device driver installation

      Double click RHEV-Network.msi or RHEV-Network64.msi.
      Press Next to continue.
    2. Performance setting

      This screen configures advanced TCP settings for the network driver. TCP timestamps and TCP window scaling can be enabled or disabled. The default is, 1, for window scaling to be enabled.
      TCP window scaling is covered by IETF RFC 1323. The RFC defines a method of increasing the receive window size to a size greater than the default maximum of 65,535 bytes up to a new maximum of 1 gigabyte (1,073,741,824 bytes). TCP window scaling allows networks to transfer at closer to theoretical network bandwidth limits. Larger receive windows may not be supported by some networking hardware or operating systems.
      TCP timestamps are also defined by IETF RFC 1323. TCP timestamps are used to better calculate Return Travel Time estimates by embedding timing information is embedded in packets. TCP timestamps help the system to adapt to changing traffic levels and avoid congestion issues on busy networks.
      ValueAction
      0Disable TCP timestamps and window scaling.
      1Enable TCP window scaling.
      2Enable TCP timestamps.
      3Enable TCP timestamps and window scaling.
      Press Next to continue.
    3. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    4. Finish

      Press Finish to complete the installation.
  5. Reboot

    Reboot the guest to complete the driver installation.
Change the device configuration to use the para-virtualized drivers (Sezione 13.3, «Utilizzo dei driver paravirtualizzati KVM per dispositivi esistenti») or install a new device which uses the para-virtualized drivers (Sezione 13.4, «Utilizzo dei driver paravirtualizzati KVM per nuovi dispositivi»).

13.2. Installing drivers with a virtualized floppy disk

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 third party, selezionate il tasto in questione e seguite le istruzioni presenti sulla schermata.
    2. Windows Server 2008

      Quando il programma d'installazione richiede il driver fate clic su Carica driver, indicare al programma d'installazione l'unità A: e selezionate il driver più idoneo all'architettura e al sistema operativo guest.

13.3. Utilizzo dei driver paravirtualizzati KVM per dispositivi esistenti

Modify an existing hard disk device attached to the guest to use the virtio driver instead of virtualized IDE driver. This example edits libvirt configuration files. Alternatively, virt-manager, virsh attach-disk or virsh attach-interface can add a new device using the para-virtualized drivers Sezione 13.4, «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='vda' bus='ide'/>
    </disk>
    
  2. Modificate 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='vda' bus='virtio'/>
    </disk>
    

13.4. 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. Selezionate Aggiungi Hardware.
  4. Nella scheda Aggiungi Hardware virtuale selezionare Storage o Rete per il tipo di dispositivo.
    1. New disk devices
      Selezionare il dispositivo di storage o l'immagine basata sul file. Selezionate Virtio Disk come Tipo di dispositivo e premere Avanti.
    2. New network devices
      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.

Capitolo 14. PCI passthrough

This chapter covers using PCI passthrough with Xen and KVM hypervisors.
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
The VT-d or AMD IOMMU extensions must be enabled in BIOS.
Procedura 14.1. Preparing an Intel system for PCI passthrough
  1. Enable the Intel VT-d extensions

    The Intel VT-d extensions provides hardware support for directly assigning a physical devices to guest. The main benefit of the feature is to improve the performance as native for device access.
    The VT-d extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
    These extensions are often called various terms in BIOS which differ from manufacturer to manufacturer. Consult your system manufacturer's documentation.
  2. Activate Intel VT-d in the kernel

    Activate Intel VT-d in the kernel by appending the intel_iommu=on parameter to the kernel line of the kernel line in the /boot/grub/grub.conf file.
    The example below is a modified grub.conf file with Intel VT-d activated.
    default=0
    timeout=5
    splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Server (2.6.18-190.el5)
       root (hd0,0)
       kernel /vmlinuz-2.6.18-190.el5 ro root=/dev/VolGroup00/LogVol00 intel_iommu=on
       initrd /initrd-2.6.18-190.el5.img
  3. Ready to use

    Reboot the system to enable the changes. Your system is now PCI passthrough capable.
Procedura 14.2. Preparing an AMD system for PCI passthrough
  • Enable AMD IOMMU extensions

    The AMD IOMMU extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
AMD systems only require that the IOMMU is enabled in the BIOS. The system is ready for PCI passthrough once the IOMMU is enabled.

PCI passthrough with Xen

Xen and KVM require different kernel arguments to enable PCI passthrough. The previous instructions are for KVM. For both AMD and Intel systems, PCI passthrough on Xen requires the iommu=on parameter to the hypervisor command line. Modify the /boot/grub/grub.conf file as follows to enable PCI passthrough:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=on
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 
   module /initrd-2.6.18-190.el5xen.img

14.1. Adding a PCI device with virsh

These steps cover adding a PCI device to a fully virtualized guest under the Xen or KVM hypervisors using hardware-assisted PCI passthrough. Refer to Sezione 14.4, «PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux» for details on adding a PCI device to a para-virtualized Xen guest.

Importante

The VT-d or AMD IOMMU extensions must be enabled in BIOS.
This example uses a USB controller device with the PCI identifier code, pci_8086_3a6c, and a fully virtualized guest named win2k3.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Information on the domain, bus and function are available from output of the virsh nodedev-dumpxml command:
    # virsh nodedev-dumpxml pci_8086_3a6c
    <device>
      <name>pci_8086_3a6c</name>
      <parent>computer</parent>
      <capability type='pci'>
        <domain>0</domain>
        <bus>0</bus>
        <slot>26</slot>
        <function>7</function>
        <id='0x3a6c'>82801JD/DO (ICH10 Family) USB2 EHCI Controller #2</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
  3. Detach the device from the system. Attached devices cannot be used and may cause various errors if connected to a guest without detaching first.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  4. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
    For example, if bus = 0, slot = 26 and function = 7 run the following:
    $ printf %x 0
    0
    $ printf %x 26
    1a
    $ printf %x 7
    7
    The values to use:
    bus='0x00'
    slot='0x1a'
    function='0x7'
  5. Run virsh edit (or virsh attach device) and add a device entry in the <devices> section to attach the PCI device to the guest. Only run this command on offline guests. Red Hat Enterprise Linux does not support hotplugging PCI devices at this time.
    # virsh edit win2k3
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
          <address domain='0x0000' bus='0x00' slot='0x1a' function='0x7'/>
      </source>
    </hostdev>
  6. Once the guest system is configured to use the PCI address, we need to tell the host system to stop using it. The ehci driver is loaded by default for the USB PCI controller.
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/ehci_hcd
  7. Detach the device:
    $ virsh nodedev-dettach pci_8086_3a6c
  8. Verify it is now under the control of pci_stub:
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/pci-stub
  9. Set a sebool to allow the management of the PCI device from the guest:
    # setsebool -P virt_use_sysfs 1
  10. Start the guest system :
    # virsh start win2k3
    
The PCI device should now be successfully attached to the guest and accessible to the guest operating system.

14.2. Adding a PCI device with virt-manager

PCI devices can be added to guests using the graphical virt-manager tool. The following procedure adds a 2 port USB controller to a virtualized guest.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Detach the PCI device

    Detach the device from the system.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  3. Power off the guest

    Power off the guest. Hotplugging PCI devices into guests is presently unsupported and may fail or crash.
  4. Open the hardware settings

    Open the virtual machine and select the Hardware tab. Click the Add Hardware button to add a new device to the guest.
  5. Add the new device

    Select Physical Host Device from the Hardware type list. The Physical Host Device represents PCI devices. Click Forward to continue.
  6. Select a PCI device

    Select an unused PCI device. Note that selecting PCI devices presently in use on the host causes errors. In this example a PCI to USB interface device is used.
  7. Confirm the new device

    Click the Finish button to confirm the device setup and add the device to the guest.
The setup is complete and the guest can now use the PCI device.

14.3. PCI passthrough with virt-install

To use PCI passthrough with the virt-install parameter, use the additional --host-device parameter.
  1. Identify the PCI device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
  2. Add the device

    Use the PCI identifier output from the virsh nodedev command as the value for the --host-device parameter.
    # virt-install \
     -n hostdev-test -r 1024 --vcpus 2 \
     --os-variant fedora11 -v --accelerate \
     -l http://download.fedoraproject.org/pub/fedora/linux/development/x86_64/os \
     -x 'console=ttyS0 vnc' --nonetworks --nographics  \
     --disk pool=default,size=8 \
     --debug --host-device=pci_8086_10bd 
    
  3. Complete the installation

    Complete the guest installation. The PCI device should be attached to the guest.

14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux

PCI passthrough is used to allow a Xen guest exclusive access to a PCI device, rather than sharing with other guests or with dom0. PCI passthrough for para-virtualized Xen guests is supported on all Red Hat Enterprise Linux 5 systems, however PCI passthrough with fully virtualized guests is only supported on Red Hat Enterprise Linux 5.4 and newer.

Avvertimento

PCI passthrough to para-virtualized guests is considered insecure and is not supported for Red Hat Enterprise Linux 6 guests.
Limitations of Xen PCI passthrough:
Any guest using PCI passthrough will no longer be available for save, restore, or migration capabilities, as it will be tied to a particular non-virtualized hardware configuration.
A guest which has access to a non-virtualized PCI device via PCI passthrough also has the potential to access the DMA address space of dom0, which is a potential security concern.
To link a PCI device to a guest the device must first be hidden from the host. If the host is using the device the device cannot be assigned to the guest.
Procedura 14.3. Example: attaching a PCI device
  1. Given a network device which uses the bnx2 driver and has a PCI id of 0000:09:00.0, the following lines added to /etc/modprobe.conf hides the device from dom0. Either the bnx2 module must be reloaded or the host must be restarted.
    install bnx2 /sbin/modprobe pciback; /sbin/modprobe --first-time --ignore-install bnx2
    options pciback hide=(0000:09:00.0)
  2. Multiple PCI identifiers can be added to /etc/modprobe.conf to hide multiple devices.
    options pciback hide=(0000:09:00.0)(0000:0a:04.1)
  3. Use one of the following methods to add the passed-through device to the guest's configuration file:

Capitolo 15. SR-IOV

15.1. Introduction

The PCI-SIG (PCI Special Interest Group) developed the Single Root I/O Virtualization (SR-IOV) specification. The PCI-SIG Single Root IOV specification is a standard for a type of PCI passthrough which natively shares a single device to multiple guests. SR-IOV does not require hypervisor involvement in data transfer and management by providing an independent memory space, interrupts, and DMA streams for virtualized guests.
SR-IOV enables a Single Root Function (for example, a single Ethernet port), to appear as multiple, separate, physical devices. A physical device with SR-IOV capabilities can be configured to appear in the PCI configuration space as multiple functions, each device has its own configuration space complete with Base Address Registers (BARs).
SR-IOV uses two new PCI functions:
  • Physical Functions (PFs) are full PCIe devices that include the SR-IOV capabilities. Physical Functions are discovered, managed, and configured as normal PCI devices. Physical Functions configure and manage the SR-IOV functionality by assigning Virtual Functions.
  • Virtual Functions (VFs) are simple PCIe functions that only process I/O. Each Virtual Function is derived from a Physical Function. The number of Virtual Functions a device may have is limited by the device hardware. A single Ethernet port, the Physical Device, may map to many Virtual Functions that can be shared to virtualized guests.
The hypervisor can map one or more Virtual Functions to a virtualized guest. The Virtual Function's configuration space is mapped, by the hypervisor, to the virtualized guest's configuration space.
Each Virtual Function can only be mapped once as Virtual Functions require real hardware. A virtualized guest can have multiple Virtual Functions. A Virtual Function appears as a network card in the same way as a normal network card would appear to an operating system.
The SR-IOV drivers are implemented in the kernel. The core implementation is contained in the PCI subsystem, but there must also be driver support for both the Physical Function (PF) and Virtual Function (VF) devices. With an SR-IOV capable device one can allocate VFs from a PF. The VFs appear as PCI devices which are backed on the physical PCI device by resources (queues, and register sets).
Advantages of SR-IOV
SR-IOV devices can share a single physical port with multiple virtualized guests.
Virtual Functions have near-native performance and provide better performance than para-virtualized drivers and emulated access. Virtual Functions provide data protection between virtualized guests on the same physical server as the data is managed and controlled by the hardware.
These features allow for increased virtualized guest density on hosts within a data center.
Disadvantages of SR-IOV
Live migration is presently unsupported. As with PCI passthrough, identical device configurations are required for live (and offline) migrations. Without identical device configurations, guest's cannot access the passed-through devices after migrating.

15.2. Using SR-IOV

This section covers attaching Virtual Function to a guest as an additional network device.
SR-IOV requires Intel VT-d support.

SR-IOV with Xen

Xen requires additional kernel arguments to use SR-IOV. Modify the /boot/grub/grub.conf file to enable SR-IOV. To enable SR-IOV with Xen for Intel systems append the pci_pt_e820_access=on parameter to the kernel.
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5xen)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=1
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 pci_pt_e820_access=on
   module /initrd-2.6.18-192.el5xen.img
Procedura 15.1. Attach an SR-IOV network device
  1. Enable Intel VT-d in BIOS and in the kernel

    Enable Intel VT-D in BIOS. Refer to Procedura 14.1, «Preparing an Intel system for PCI passthrough» for more information on enabling Intel VT-d in BIOS and the kernel, or refer to your system manufacturer's documentation for specific instructions.
  2. Verify support

    Verify if the PCI device with SR-IOV capabilities are detected. This example lists an Intel 82576 network interface card which supports SR-IOV. Use the lspci command to verify if the device was detected.
    # lspci
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    

    Nota

    Note that the output has been modified to remove all other devices.
  3. Start the SR-IOV kernel modules

    If the device is supported the driver kernel module should be loaded automatically by the kernel. Optional parameters can be passed to the module using the modprobe command. The Intel 82576 network interface card uses the igb driver kernel module.
    # modprobe igb [<option>=<VAL1>,<VAL2>,]
    # lsmod |grep igb
    igb    87592  0
    dca    6708    1 igb
    
  4. Activate Virtual Functions

    The max_vfs parameter of the igb module allocates the maximum number of Virtual Functions. The max_vfs parameter causes the driver to spawn, up to the value of the parameter in, Virtual Functions. For this particular card the valid range is 0 to 7.
    Remove the module to change the variable.
    # modprobe -r igb
    Restart the module with the max_vfs set to 1 or any number of Virtual Functions up to the maximum supported by your device.
    # modprobe igb max_vfs=1
    
  5. Inspect the new Virtual Functions

    Using the lspci command, list the newly added Virtual Functions attached to the Intel 82576 network device.
    # lspci | grep 82576
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    03:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    
    The identifier for the PCI device is found with the -n parameter of the lspci command.
    # lspci -n | grep 03:00.0
    03:00.0 0200: 8086:10c9 (rev 01)
    # lspci -n | grep 03:10.0
    03:10.0 0200: 8086:10ca (rev 01)
    
    The Physical Function corresponds to 8086:10c9 and the Virtual Function to 8086:10ca.
  6. Find the devices with virsh

    The libvirt service must find the device to add a device to a guest. Use the virsh nodedev-list command to list available host devices.
    # virsh nodedev-list | grep 8086
    pci_8086_10c9
    pci_8086_10c9_0
    pci_8086_10ca
    pci_8086_10ca_0
    [output truncated]
    
    The serial numbers for the Virtual Functions and Physical Functions should be in the list.
  7. Get advanced details

    The pci_8086_10c9 is one of the Physical Functions and pci_8086_10ca_0 is the first corresponding Virtual Function for that Physical Function. Use the virsh nodedev-dumpxml command to get advanced output for both devices.
    # virsh nodedev-dumpxml pci_8086_10ca
    # virsh nodedev-dumpxml pci_8086_10ca_0
    <device>
      <name>pci_8086_10ca_0</name>
      <parent>pci_8086_3408</parent>
      <driver>
        <name>igbvf</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>3</bus>
        <slot>16</slot>
        <function>1</function>
        <product id='0x10ca'>82576 Virtual Function</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
    
    This example adds the Virtual Function pci_8086_10ca_0 to the guest in Passo 8. Note the bus, slot and function parameters of the Virtual Function, these are required for adding the device.
  8. Add the Virtual Function to the guest

    1. Shut down the guest.
    2. Use the output from the virsh nodedev-dumpxml pci_8086_10ca_0 command to calculate the values for the configuration file. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
      The example device has the following values: bus = 3, slot = 16 and function = 1. Use the printf utility to convert decimal values to hexadecimal values.
      $ printf %x 3
      3
      $ printf %x 16
      10
      $ printf %x 1
      1
      This example would use the following values in the configuration file:
      bus='0x03'
      slot='0x10'
      function='0x01'
    3. Open the XML configuration file with the virsh edit command. This example edits a guest named MyGuest.
      # virsh edit MyGuest
      
    4. The default text editor will open the libvirt configuration file for the guest. Add the new device to the devices section of the XML configuration file.
      <hostdev mode='subsystem' type='pci' managed='yes'>
            <source>
              <address bus='0x03' slot='0x10' function='0x01'/>
            </source>
      </hostdev>
      
    5. Save the configuration.
  9. Restart

    Restart the guest to complete the installation.
    # virsh start MyGuest
    
The guest should start successfully and detect a new network interface card. This new card is the Virtual Function of the SR-IOV device.

15.3. Troubleshooting SR-IOV

This section contains some issues and solutions for problems which may affect SR-IOV.
Error starting the guest
Start the configured vm , an error reported as follows:
# virsh start test
error: Failed to start domain test
error: internal error unable to start guest: char device redirected to
/dev/pts/2
get_real_device: /sys/bus/pci/devices/0000:03:10.0/config: Permission denied
init_assigned_device: Error: Couldn't get real device (03:10.0)!
Failed to initialize assigned device host=03:10.0
This error is often caused by a device which is already assigned to another guest or to the host itself.

Capitolo 16. Gestione dell'ora del guest KVM

La virtualizzazione pone alcune limitazioni durante la gestione dell'ora da parte del guest. I guest che utilizzano il Time Stamp Counter (TSC) come sorgente possono riscontrare alcuni problemi poichè alcune CPU non sono in possesso di un Time Stamp Counter costante. I guest in esecuzione senza una gestione accurata possono avere effetti molto seri su alcune applicazioni della rete e processi, poichè i guest interessati verranno eseguiti più velocemente o più lentamente rispetto all'ora esatta.
KVM risolve questo problema fornendo ai guest un orologio paravirtualizzato. Alternativamente alcuni guest possono usare altri mezzi per l'orologio di x86 per la gestione dell'ora nelle versioni future dei suddetti sistemi operativi.
Al momento solo Red Hat Enterprise Linux 5.4 ed i guest più recenti supportano completamente l'orologio paravirtualizzato.
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 suddetti problemi sono presenti su altre piattaforme di virtualizzazione ed è consigliato sempre eseguire un test sulla gestione dell'ora.

NTP

Il demone Network Time Protocol (NTP) deve essere 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 vostra CPU possiede un constant Time Stamp Counter
La vostra 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 visualizzate qualsiasi output ciò indicherà la presenza del bit constant_tsc nella vostra 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.

Nota Bene

Queste informazioni sono rivolte solo alle AMD revision F cpu
Se la CPU non possiede il bit constant_tsc, disabilitate 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 oppure da una migrazione su di un host con un TSC più veloce. Per interrompere uno stato deep C, il quale è in grado di arrestare TSC, aggiungere sull'host "processor.max_cstate=1" alle opzioni d'avvio del kernel nel file grub.conf:
term Red Hat Enterprise Linux Server (2.6.18-159.el5)
        root (hd0,0)
	kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet processor.max_cstate=1
Disabilitate 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 paravirtualizzatoI 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 64I parametri aggiuntivi non sono necessari
3.9 x86I parametri aggiuntivi non sono necessari
Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
Windows utilizza sia il Real-Time Clock (RTC) che il Time Stamp Counter (TSC). Per i guest Windows può essere usato il Real-Time Clock al posto di TSC come mezzo di gestione dell'ora, risolvendo così le problematiche che ne possono derivare.
Per abilitare il Real-Time Clock per PMTIMER clocksource (il PMTIMER generalemente utilizza TSC), aggiungere la seguente riga alle impostazioni d'avvio di Windows. Tali impostazioni vengono conservate nel file boot.ini. Aggiungere la seguente riga al file boot.ini:
/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.
Using the Real-Time Clock with Windows Vista, Windows Server 2008 and Windows 7 guests
Windows utilizza sia il Real-Time Clock (RTC) che il Time Stamp Counter (TSC). Per i guest Windows può essere usato il Real-Time Clock al posto di TSC come mezzo di gestione dell'ora, risolvendo così le problematiche che ne possono derivare.
The boot.ini file is no longer used from Windows Vista and newer. Windows Vista, Windows Server 2008 and Windows 7 use the Boot Configuration Data Editor (bcdedit.exe) to modify the Windows boot parameters.
This procedure is only required if the guest is having time keeping issues. Time keeping issues may not affect guests on all host systems.
  1. Open the Windows guest.
  2. Open the Accessories menu of the start menu. Right click on the Command Prompt application, select Run as Administrator.
  3. Confirm the security exception, if prompted.
  4. Set the boot manager to use the platform clock. This should instruct Windows to use the PM timer for the primary clock source. The system UUID ({default} in the example below) should be changed if the system UUID is different than the default boot device.
    C:\Windows\system32>bcdedit /set {default} USEPLATFORMCLOCK on
    The operation completed successfully
This fix should improve time keeping for Windows Vista, Windows Server 2008 and Windows 7 guests.

Parte IV. Amministrazione

Capitolo 17. Pratiche consigliate per il server

Di seguito vengono riportati i compiti ed i suggerimenti in grado di rendere affidabile e sicuro il vostro Red Hat Enterprise Linux 5 server host (dom0).
  • Eseguire SELinux in modalità enforcing. Per fare questo eseguire il comando di seguito riportato.
    # 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 state utilizzando una directory diversa per le immagini della vostra macchina virtuale, assicuratevi di aggiungere la directory nella vostra 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 18. Sicurezza per la virtualizzazione

Quando implementate le tecnologie per la virtualizzazione sulla vostra infrastruttura corporativa, assicuratevi 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 vostra organizzazione potrete creare un piano d'impiego che contenga le specifiche operative ed i servizi necessari sui vostri 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.
  • Enable Security-Enhanced Linux (SELinux) on the hypervisor. Read Sezione 18.2, «SELinux e virtualizzazione» for more information on using SELinux and virtualization.
  • Utilizzate 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 permettete ad utenti normali di accedere al dom0. Se abilitate il loro accesso potrete correre il rischio di rendere dom0 vulnerabile. Ricordate, dom0 risulta essere privilegiato e conferire account non privilegiati potrebbe compromettere il livello di sicurezza.

18.1. Storage security issues

Administrators of virtualized guests can change the partitions the host boots in certain circumstances. To prevent this administrators should follow these recommendations:
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Use partitions (for example, /dev/sdb1) or LVM volumes.

18.2. SELinux e virtualizzazione

Security Enhanced Linux was developed by the NSA with assistance from the Linux community to provide stronger security for Linux. SELinux limits an attackers abilities and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. It is because of these benefits that Red Hat recommends all Red Hat Enterprise Linux systems should run with SELinux enabled and in enforcing mode.
SELinux prevents guest images from loading if SELinux is enabled and the images are not correctly labeled. SELinux requires that image files have the virt_image_t label applied to them. The /var/lib/libvirt/images directory has this label applied to it and its contents by default. This does not mean that images must be stored in this directory; images can be stored anywhere, provided they are labeled with virt_image_t.
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 18.1. Creazione e montaggio di un volume logico su di un guest virtualizzato con SELinux abilitato
  1. Create 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. Formattate 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. Create una nuova directory per il montaggio del nuovo volume logico. Questa directory può essere posizionata in qualsiasi luogo del file system. È consigliato non conservarla all'interno di directory molto importanti (/etc, /var, /sys) o nelle home directory /home o /root). In questo esempio viene usata una directory chiamata /virtstorage
    # mkdir /virtstorage
    
  4. Come montare un volume logico.
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the correct SELinux type for a Xen folder.
    semanage fcontext -a -t xen_image_t "/virtstorage(/.*)?"
    
    Alternativamente impostate il tipo corretto di SELinux per una cartella KVM.
    semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    
    Se utilizzate 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. Label the device node (for example, /dev/volumegroup/NewVolumeName with the correct label:
    # semanage fcontext -a -t xen_image_t /dev/volumegroup/NewVolumeName
    # restorecon /dev/volumegroup/NewVolumeName
    

18.3. SELinux

Questa sezione contiene le informazioni da considerare durante l'utilizzo di SELinux con l'utilizzo della virtualizzazione. Quando implementate alcune modifiche che riguardano il sistema oppure desiderate aggiungere alcuni dispositivi, sarà necessario aggiornare di conseguenza la vostra 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 directory come xen_image_t utilizzate in altre parti.
KVM and SELinux
There are several SELinux booleans which affect KVM. These booleans are listed below for your convenience.
KVM SELinux Booleans
SELinux BooleanDescription
allow_unconfined_qemu_transitionDefault: off. This boolean controls whether KVM guests can be transitioned to unconfined users.
qemu_full_networkDefault: on. This boolean controls full network access to KVM guests.
qemu_use_cifsDefault: on. This boolean controls KVM's access to CIFS or Samba file systems.
qemu_use_commDefault: off. This boolean controls whether KVM can access serial or parallel communications ports.
qemu_use_nfsDefault: on. This boolean controls KVM's access to NFS file systems.
qemu_use_usbDefault: on. This boolean allows KVM to access USB devices.

18.4. Virtualization firewall information

Various ports are used for communication between virtualized guests and management utilities.

Guest network services

Any network service on a virtualized guest must have the applicable ports open on the guest to allow external access. If a network service on a guest is firewalled it will be inaccessible. Always verify the guests network configuration first.
  • ICMP requests must be accepted. ICMP packets are used for network testing. You cannot ping guests if ICMP packets are blocked.
  • Port 22 should be open for SSH access and the initial installation.
  • Ports 80 or 443 (depending on the security settings on the RHEV Manager) are used by the vdsm-reg service to communicate information about the host.
  • Ports 5634 to 6166 are used for guest console access with the SPICE protocol.
  • Port 8002 is used by Xen for live migration.
  • Ports 49152 to 49216 are used for migrations with KVM. Migration may use any port in this range depending on the number of concurrent migrations occurring.
  • Enabling IP forwarding (net.ipv4.ip_forward = 1) is required for virtual bridge devices. Note that installing libvirt enables this variable so it will be enabled when the virtualization packages are installed unless it was manually disabled.

Nota

Note that enabling IP forwarding is not required for physical bridge devices. When a guest is connected through a physical bridge, traffic only operates at a level that does not require IP configuration such as IP forwarding.

Capitolo 19. 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:
Tabella 19.1. Parametri di configurazione di xend
Item Descrizione
(console-limit)
Determines the console server's memory buffer limit and assigns that limit on a per domain basis.
(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)
Se abilitato in presenza di un arresto inaspettato 'crash' crea un dump file (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 default è /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 directory /etc/xen/scripts/.
(xend-http-server)
Abilita il server per l'http stream packet management (il default è 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 default è no).
(xend-unix-path)
Determina la posizione dove il comando xend-unix-server esegue l'output dei dati (il default è /var/lib/xend/xend-socket)
(xend-port)
Determina la porta utilizzata dal server di gestione http (il default è 8000).
(xend-relocation-port)
Determina la porta utilizzata dal server di riposizionamento (il default è 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.

Dopo aver impostato i parametri operativi, verificate la corretta esecuzione di xend, ed in caso contrario, inizializzate il demone. Al prompt del comando avviate il demone xend inserendo quanto segue:
service xend start
Utilizzate xend per arrestare il demone:
service xend stop
Questo comando arresterà l'esecuzione del demone.
Per riavviare il demone utilizzate xend:
service xend restart
Per riavviare il demone.
Controllare lo stato del demone xend.
service xend status
The output displays the daemon's status.

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 20. Migrazione live di Xen

The Xen hypervisor supports Virtualization Migration for para-virtualized guests and fully virtualized guests. Migration is only supported on Red Hat Enterprise Linux 5.1 and newer systems. Migration can be performed offline or live.
  • Le migrazioni offline sospendono il guest virtualizzato sull'host originale, lo trasferiscono sull'host di destinazione e ripristinano le funzioni una volta che il trasferimento è stato completato. Questo tipo di migrazione usa il comando virsh migrate.
    # virsh migrate GuestName libvirtURI
  • A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. The Xen hypervisor estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until Xen predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
    La migrazione live utilizza --live per il comando virsh migrate.
    # virsh migrate--live GuestName libvirtURI

nota di supporto Itanium®

Il processo di migrazione non è attualmente supportato sull'architettura Itanium®.
Per abilitare il processo di migrazione con Xen è necessario apportare alcune modifiche al file di configurazione /etc/xen/xend-config.sxp. Per default il processo di migrazione è disabilitato a causa di alcuni problemi sulla sicurezza dell'host. L'apertura della porta usata per la migrazione potrebbe causare la possibilità da parte di host ed utenti non autorizzati di inizializzare un processo di migrazione o di collegarsi alle porte utilizzate. Non vi è alcun processo di autenticazione e autorizzazione per le richieste di migrazione ed il solo meccanismo di controllo è basato sugli hostname ed indirizzi IP. Per questo motivo è importante prestare particolare attenzione in modo da assicurare che la porta non venga utilizzata da un host non autorizzato.

Sicurezza del processo di migrazione con la virtualizzazione

I filtri dell'hostname e l'indirizzo IP garantiscono solo un livello minimo di sicurezza. Entrambi questi attributi possono essere compromessi se l'utente malizioso è a conoscenza dell'indirizzo e dell'hostname del client che esegue la migrazione. Il metodo migliore per rendere il processo di migrazione più sicuro, è quello di isolare la rete dai collegamenti interni ed esterni non autorizzati.
Come abilitare la migrazione
Modificate le seguenti voci in /etc/xen/xend-config.sxp per abilitare la migrazione. Modificate i valori, quando necessario, e rimuovere i commenti # che precedono i seguenti parametri:
(xend-relocation-server yes)
Il valore predefinito in grado di disabilitare la migrazione è no. Modificate il valore di xend-relocation-server ed impostatelo su yes se desiderate abilitare tale processo.
(xend-relocation-port 8002)
Il parametro (xend-relocation-port), specifica che la porta xend dovrebbe usare l'interfaccia di riposizionamento, se xend-relocation-server è stato impostato su yes
Il valore predefinito di questa variabile dovrebbe funzionare per la maggior parte delle installazioni. Se modificate il suddetto valore assicuratevi di utilizzare una porta non ancora usata sul server di riposizionamento.
Questa porta impostata dal parametro xend-relocation-port deve essere aperta su entrambi i sistemi.
(xend-relocation-address '')
(xend-relocation-address) è l'indirizzo sul quale xend dovrebbe essere in ascolto per i collegamenti relocation-socket, se xend-relocation-server è stato impostato.
The default is to listen on all active interfaces. The (xend-relocation-address) parameter restricts the migration server to only listen to a specific interface. The default value in /etc/xen/xend-config.sxp is an empty string(''). This value should be replaced with a single, valid IP address. For example:
(xend-relocation-address '10.0.0.1')
(xend-relocation-hosts-allow '')
The (xend-relocation-hosts-allow 'hosts') parameter controls which hostnames can communicate on the relocation port.
Unless you are using SSH or TLS, the guest's virtual memory is transferred in raw form without encryption of the communication. Modify the xend-relocation-hosts-allow option to restrict access to the migration server.
Se il valore risulta vuoto, come riportato nell'esempio nel quale è presente una riga vuota all'interno di apici singoli, tutti i collegamenti saranno abilitati. Tale comportamento assume che il collegamento arrivi su di una porta e interfaccia sulle quali è in ascolto il server di riposizionamento, controllate altresì xend-relocation-port e xend-relocation-address.
In caso contrario il parametro (xend-relocation-hosts-allow) dovrebbe essere una sequenza di espressioni regolari separate da spazi. Qualsiasi host con un fully-qualified domain name o un indirizzo IP che corrisponde ad una delle suddette espressioni regolari verrà accettato.
Esempio di attributo (xend-relocation-hosts-allow):
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Dopo aver configurato i parametri presenti all'interno del vostro file di configurazione sarà necessario riavviare il servizio di Xen.
# service xend restart

20.1. Un esempio di migrazione live

Di seguito viene riportato un esempio su come impostare un ambiente di base per una migrazione live. Questa configurazione utilizza NFS per lo storage condiviso. NFS è idoneo per ambienti di prova, ma per un ambiente di produzione è consigliato implementare una configurazione di storage condiviso più robusta utilizzando un Fibre Channel o iSCSI e GFS.
La seguente configurazione consiste in due server (et-virt07 e et-virt08), entrambi utilizzano eth1 come interfaccia di rete predefinita e per questo motivo essi utilizzano xenbr1 come bridge per il networking di Xen. In questo esempio viene usato un disco SCSI collegato localmente (/dev/sdb) su et-virt07 per uno storage condiviso che utilizza NFS.
Impostazione per migrazioni live
Create e montate la directory usata per la migrazione:
# mkdir /var/lib/libvirt/images
# mount /dev/sdb /var/lib/libvirt/images

Importante

Assicuratevi di aver esportato la directory usando le opzioni corrette. Se state esportando la directory predefinita /var/lib/libvirt/images/, assicuratevi di esportare solo /var/lib/libvirt/images/ e non /var/lib/xen/, poichè questa directory viene usata dal demone xend e da altri tool. La condivisione di /var/lib/xen/ potrebbe causare un comportamento imprevedibile.
# cat /etc/exports
/var/lib/libvirt/images  *(rw,async,no_root_squash)
Verificate che l'esportazione sia stata eseguita via NFS:
# showmount -e et-virt07
Export list for et-virt07:
/var/lib/libvirt/images *
Installazione del guest
Il comando d'installazione nell'esempio usato per installare il guest:
# virt-install -p -f /var/lib/libvirt/images/testvm1.dsk -s 5 -n\
testvm1 --vnc -r 1024 -l http://example.com/RHEL5-tree\
Server/x86-64/os/ -b xenbr1
For step by step installation instructions, refer to Capitolo 8, Procedure per l'installazione del sistema operativo guest.
Verifica dell'ambiente per la migrazione
Assicuratevi che i bridge di rete virtualizzati siano stati configurati correttamente e che abbiano lo stesso nome su entrambi gli host:
[et-virt08 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
[et-virt07 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
Controllate che i parametri di riposizionamento siano stati configurati su entrambi gli host:
[et-virt07 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
[et-virt08 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
Assicuratevi che il server di riposizionamento sia stato avviato e sia in ascolto sulla porta designata per le migrazioni di Xen (8002):
[et-virt07 ~]# lsof -i :8002
COMMAND  PID  USER   FD   TYPE  DEVICE SIZE NODE NAME
python 3445 root 14u IPv4 10223 TCP *:teradataordbms (LISTEN)
[et-virt08 ~]# lsof -i :8002
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
python 3252 root 14u IPv4 10901 TCP *:teradataordbms (LISTEN)
That the default /var/lib/libvirt/images directory is available and mounted with networked storage on both hosts. Shared, networked storage is required for migrations.
[et-virt08 ~]# df /var/lib/libvirt/images
Filesystem           1K-blocks      Used Available Use% Mounted on
et-virt07:/var/lib/libvirt/images    70562400   2379712  64598336   4% /var/lib/libvirt/images
[et-virt08 ~]# file /var/lib/libvirt/images/testvm1.dsk 
/var/lib/libvirt/images/testvm1.dsk: x86 boot sector; partition 1: ID=0x83,
active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x8e, 
starthead 0, startsector 208845, 10265535 sectors, code offset 0x48
[et-virt08 ~]# touch /var/lib/libvirt/images/foo
[et-virt08 ~]# rm -f /var/lib/libvirt/images/foo
Verifica di Salva e ripristina del guest
Avviate la macchina virtuale (se la macchina virtuale non è stata avviata):
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
[et-virt07 ~]# virsh start testvm1
Domain testvm1 started
Verificate che la macchina virtuale sia in esecuzione:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Salvate la macchina virtuale sull'host locale:
[et-virt07 images]# time virsh save testvm1 testvm1.sav
real    0m15.744s
user    0m0.188s
sys     0m0.044s
[et-virt07 images]# ls -lrt testvm1.sav
-rwxr-xr-x 1 root root 1075657716 Jan 12 06:46 testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Ripristinate la macchina virtuale sull'host virtuale:
[et-virt07 images]# virsh restore testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Start the live migration of domain-id from et-virt08 to et-virt07. The hostname you are migrating to and <domain-id> must be replaced with valid values. This example uses the et-virt08 host which must have SSH access to et-virt07
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Verify the virtual machine is no longer present on et-virt08
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verify the virtual machine has been migrated to et-virt07:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        running
Test del progresso e inizializzazione della migrazione live
Create the following script inside the virtual machine to log date and hostname during the migration. This script performs I/O tasks on the guest's file system.
#!/bin/bash

while true
do
touch /var/tmp/$$.log
echo `hostname` >>  /var/tmp/$$.log
	echo `date`     >>  /var/tmp/$$.log
	cat  /var/tmp/$$.log
	df /var/tmp
	ls -l  /var/tmp/$$.log
	sleep 3
	done
Ricordate, lo script è solo usato per il test e non è necessario per la migrazione live in un ambiente di produzione.
Verificate che la macchina virtuale sia in esecuzione su et-virt08 prima di provare a migrarla su et-virt07:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Iniziate una migrazione live per et-virt07. È possibile aggiungere il comando time per controllare la durata del processo di migrazione:
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
eseguite lo script all'interno del guest:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:33 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 02:26 /var/tmp/2279.log
Fri Jan 12 02:26:45 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:48 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:51 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:54:57 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 744 Jan 12 06:55 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Verificate che la macchina virtuale sia stata arrestata su et-virt08:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verificate che la macchina virtuale sia stata avviata su et-virt07:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Eseguite un altro ciclo di migrazione da et-virt07 a et-virt08. Iniziate una migrazione da et-virt07 aet-virt08:
[et-virt07 images]# xm migrate --live testvm1 et-virt08
Verificate che la macchina virtuale sia stata arrestata:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Prima di iniziare la migrazione iniziate un semplice scirpt nel guest e notate il cambiamento dell'ora durante la migrazione del guest:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 248 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 310 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:06 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 372 Jan 12 02:30 /var/tmp/2418.log
Dopo il completamento del comando usato per la migrazione su et-virt07, verificate su et-virt08 che la macchina virtuale sia stata avviata:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
ed eseguite un altro ciclo:
[et-virt08 ~]# time virsh migrate --live testvm1 et-virt07
real    0m10.378s
user    0m0.068s
sys     0m0.052s
A questo punto avete eseguito con successo un test di migrazione live e offline.

20.2. Configurazione della migrazione live del guest

Questa sezione affronta le fasi necessarie per la migrazione di guest Xen su altri server che eseguono Red Hat Enterprise Linux. In aggiunta, il processo di migrazione viene eseguito attraverso un metodo offline (utilizzando il comando xm migrate ), è da notare che è possibile eseguire una migrazione live dallo stesso comando. Tuttavia sono presenti altre modifiche aggiuntive riguardanti il file di configurazione xend-config . Questo esempio identifica le voci da modificare in modo da eseguire una migrazione corretta:
(xend-relocation-server yes)
The default for this parameter is 'no', which keeps the relocation/migration server deactivated (unless on a trusted network) and the domain virtual memory is exchanged in raw form without encryption.
(xend-relocation-port 8002)
Questo parametro imposta la porta usata da xend per la migrazione. Usate questo valore a meno che il vostro ambiente di rete ha bisogno di un valore personalizzato. Decommentatelo per abilitarlo.
(xend-relocation-address )
Questo parametro è l'indirizzo in ascolto per i collegamenti socket di riposizionamento dopo aver abilitato xend-relocation-server . L'hypervisor Xen è in ascolto solo per il traffico di rete dei processi di migrazione su interfacce specifiche.
(xend-relocation-hosts-allow )
Questo parametro controlla l'host che comunica con la porta di riposizionamento. Se il valore è vuoto allora tutti i collegamenti in ingresso saranno permessi. È necessario eseguire una modifica implementando alcune sequenze di espressioni regolari separate da spazi per esempio:
(xend-relocation-hosts-allow- '^localhost\\.localdomain$' )>
Valori accettati includono i fully-qualified domain names, gli indirizzi IP o le espressioni regolari separate da spazi.
Dopo la configurazione riavviate l'host per caricare le nuove impostazioni.

Capitolo 21. Migrazione Live KVM

Questo capitolo descrive la migrazione dei guest, in esecuzione su di un hypervisor KVM, su un host KVM.
Migration is the process of moving a virtualized guest from one host to another. Migration is a key feature of virtualization as software is completely separated from hardware. Migration is useful for:
  • Bilanciamento del carico - i guest possono essere spostati su un altro host con un livello di utilizzo minore quando l'host risulta essere sovraccarico.
  • Failover hardware - quando i dispositivi hardware su di un host falliscono i guest possono essere riposizionati in modo sicuro in modo da disabilitare l'host e ripararlo.
  • Risparmio energetico - i guest possono essere distribuiti su altri host e sistemi host disalimentati per risparmiare energia e ridurre i costi durante periodi di utilizzo bassi.
  • Migrazione geografica - è possibile riposizionare i guest in modo da avere una latenza minore o in circostanze in cui è necessario eseguire tale processo.
Migrations can be performed live or offline. To migrate guests the storage must be shared. Migration works by sending the guests memory to the destination host. The shared storage stores the guest's default file system. The file system image is not sent over the network from the source host to the destination host.
Una migrazione offline sospende il guest e successivamente sposta una immagine della memoria dei guest sull'host di destinazione. Il guest viene ripristinato sull'host di destinazione e la memoria usata dal guest sull'host sorgente viene liberata.
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 tenta 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.

21.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 Red Hat Enterprise Linux della stessa versione con gli stessi aggiornamenti.
  • Le porte interessate per entrambi i sistemi dovranno essere 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
Configure shared storage and install a guest on the shared storage. For shared storage instructions, refer to Parte V, «Virtualization Storage Topics».

21.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.
For advanced and more robust shared storage instructions, refer to Parte V, «Virtualization Storage Topics»
  1. Esportare la directory dell'immagine di libvirt

    Aggiungete la directory dell'immagine predefinita al file /etc/exports:
    /var/lib/libvirt/images *.example.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 installate i pacchetti NFS:
      # yum install nfs
      
    2. Aprite le porte per NFS in iptables ed aggiungete NFS nel file /etc/hosts.allow.
    3. Avviate il servizio NFS:
      # service nfs start
      
  3. Montare lo storage predefinito sulla destinazione

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

    Le posizioni devono essere uguali sia sul sorgente che sulla destinazione

    Qualsiasi directory 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 directory non risulta essere la stessa il processo di migrazione fallirà.

21.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
Il parametro GuestName rappresenta il nome del guest che si desidera migrare.
Il parametro DestinationURL è l'URL o l'hostname del sistema di destinazione. Il suddetto sistema deve avere la stessa versione di Red Hat Enterprise Linux, usare lo stesso hypervisor e libvirt deve essere in esecuzione.
Una volta inserito il comando vi sarà richiesta la password root del sistema di destinazione.
Esempio: migrazione live con virsh
In questo esempio viene eseguita una migrazione da test1.example.com a test2.example.com. Modificare gli hostname per il vostro ambiente. In questo esempio viene riportata una migrazione di una macchina virtuale chiamata RHEL4test.
This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: Requisiti per una migrazione).
  1. Verificate che il guest sia in esecuzione

    Dal sistema sorgente, test1.example.com, verificare che RHEL4test sia in esecuzione:
    [root@test1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
  2. Migrazione del guest

    Eseguire il seguente comando per una migrazione live del guest per la destinazione test2.example.com. Aggiungere /system alla fine dell'URL di destinazione per indicare a libvirt la necessità di avere un accesso completo.
    # virsh migrate --live RHEL4test qemu+ssh://test2.example.com/system
    Una volta inserito il comando vi sarà richiesta la password root del sistema di destinazione.
  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.example.com, verificare che RHEL4test sia in esecuzione:
    [root@test2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
La migrazione live è ora conclusa.

Altri metodi di networking

libvirt supports a variety of networking methods including TLS/SSL, unix sockets, SSH, and unencrypted TCP. Refer to Capitolo 22, Gestione remota dei guest virtualizzati for more information on using other methods.

21.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.
    Fate 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.
    Fate clic sulla scheda Storage.
  3. Aggiungere un nuovo gruppo di storage. Nella parte bassa a sinistra della finestra fate 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.
    Fate 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.
    Fate clic su Fine.
  5. Creare un nuovo volume nel gruppo di storage condiviso, cliccare 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 eseguitela.
    A questo punto verrà visualizzata la finestra della Macchina Virtuale.
  8. Nella finestra del Virtual Machine Manager, fate clic con il pulsante destro del mouse sulla macchina virtuale e selezionate Migra, successivamente selezionare la posizione desiderata per la migrazione.
  9. Fate clic su Si per confermare la migrazione.
    The Virtual Machine Manager displays the virtual machine in its new location.
    The VNC connection displays the remote host's address in its title bar.

Capitolo 22. Gestione remota dei guest virtualizzati

Questa sezione affronta il modo attraverso il quale è possibile gestire in modo remoto i guest virtualizzati utilizzando ssh o TLS e SSL.

22.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.
Fate attenzione alle problematiche che si possono verificare usando SSH per la gestione remota delle vostre macchine:
  • è necessario avere un log in root per le macchine remote per poter gestire le macchine virtuali,
  • il processo d'impostazione per il collegamento iniziale potrebbe essere lento,
  • there is no standard or trivial way to revoke a user's key on all hosts or guests, and
  • e ssh non interagisce bene con un numero molto elevato di macchine remote.
Configuring password less or password managed SSH access for virt-manager
The following instructions assume you are starting from scratch and do not already have SSH keys set up. If you have SSH keys set up and copied to the other systems you can skip this procedure.

The user is important for remote management

SSH keys are user dependent. Only the user who owns the key may access that key.
virt-manager must run as the user who owns the keys to connect to the remote host. That means, if the remote systems are managed by a non-root user virt-manager must be run in unprivileged mode. If the remote systems are managed by the local root user then the SSH keys must be own and created by root.
You cannot manage the local host as an unprivileged user with virt-manager.
  1. Optional: Changing user

    Change user, if required. This example uses the local root user for remotely managing the other hosts and the local host.
    $ su -
  2. Generating the SSH key pair

    Generate a public key pair on the machine virt-manager is used. This example uses the default key location, in the ~/.ssh/ directory.
    $ ssh-keygen -t rsa
    
  3. Coping the keys to the remote hosts

    Remote login without a password, or with a passphrase, requires an SSH key to be distributed to the systems being managed. Use the ssh-copy-id command to copy the key to root user at the system address provided (in the example, root@example.com).
    # ssh-copy-id -i ~/.ssh/id_rsa.pub root@example.com root@example.com's password: Now try logging into the machine, with "ssh 'root@example.com'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting 
    
    Repeat for other systems, as required.
  4. Optional: Add the passphrase to the ssh-agent

    Add the passphrase for the SSH key to the ssh-agent, if required. On the local host, use the following command to add the passphrase (if there was one) to enable password-less login.
    # ssh-add ~/.ssh/id_rsa.pub
The SSH key was added to the remote system.
Il demone libvirt (libvirtd)
The libvirt daemon provide an interface for managing virtual machines. You must have the libvirtd daemon installed and running on every remote host that needs managing.
$ ssh root@somehost
# chkconfig libvirtd on
# service libvirtd start
Dopo aver configurato sia libvirtd che SSH, dovreste essere in grado di accedere in modo remoto alle vostre macchine virtuali. A questo punto sarà possibile accedere anche ai vostri guest con VNC.
Accessing remote hosts with virt-manager
Remote hosts can be managed with the virt-manager GUI tool. SSH keys must belong to the user executing virt-manager for password-less login to work.
  1. Start virt-manager.
  2. Open the File->Add Connection menu.
  3. Input values for the hypervisor type, the connection, Connection->Remote tunnel over SSH, and enter the desired hostname, then click connection.

22.2. Gestione remota attraverso TLS e SSL

You can manage virtual machines using TLS and SSL. TLS and SSL provides greater scalability but is more complicated than ssh (refer to Sezione 22.1, «Gestione remota con SSH»). TLS and SSL is the same technology used by web browsers for secure connections. The libvirt management connection opens a TCP port for incoming connections, which is securely encrypted and authenticated based on x509 certificates. In addition the VNC console for each guest virtual machine will be setup to use TLS with x509 certificate authentication.
This method does not require shell accounts on the remote machines being managed. However, extra firewall rules are needed to access the management service or VNC console. Certificate revocation lists can revoke users' access.
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 a conoscenza del certificato TLS/SSL. Se siete in possesso di un server per la gestione del certificato potrete saltare le prime fasi.
Impostazione del server di libvirt
Per maggiori informazioni su come creare i certificati consultate 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.
The /etc/xen/vnc directory needs the following 3 files:
  • ca-cert.pem - The CA certificate
  • server-cert.pem - The Server certificate signed by the CA
  • server-key.pem - The server private key
This provides encryption of the data channel. It might be appropriate to require that clients present their own x509 certificate as a form of authentication. To enable this remove the commenting on the (vnc-x509-verify 1) parameter.
Impostazione client virsh e virt-manager
L'impostazione per i client non è attualmente molto consistente. Per abilitare l'API di gestione libvirt tramite TLS, i certificati client e CA devono essere posizionati in /etc/pki. Per informazioni consultate http://libvirt.org/remote.html
In the virt-manager user interface, use the 'SSL/TLS' transport mechanism option when connecting to a 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, di seguito sono riportati i file interessati:
  • 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.

22.3. Modalità di trasporto

Per una gestione remota libvirt supporta le seguenti modalità di trasporto:
Transport Layer Security (TLS)
Il socket TCP/IP autenticato e cifrato del Transport Layer Security TLS 1.0 (SSL 3.1) è generalmente in ascolto attraverso una 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. Questo parametro non è supportato.
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) è il seguente:
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
È necessario fornire il metodo di trasporto o l'hostname per considerare una posizione esterna.
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/
    
  • Connect to a remote Xen hypervisor on host towada using TLS. The no_verify=1 tells libvirt not to verify the server's certificate.
    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 viene in questo caso 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
Extra parameters can be appended to remote URIs. The table below Tabella 22.1, «Parametri URI aggiuntivi» covers the recognized parameters. All other parameters are ignored. Note that parameter values must be URI-escaped (that is, a question mark (?) is appended before the parameter and special characters are converted into the URI format).
Tabella 22.1. Parametri URI aggiuntivi
Nome Modalità di trasporto Descrizione Esempio di utilizzo
nome 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 comando netcat può essere usato per eseguire un collegamento con i sistemi remoti. Il parametro netcat predefinito utilizza il comando nc. Per il trasporto SSH, libvirt crea un comando SSH utilizzando il seguente formato:
								command -p port [-l username] hostname
								netcat -U socket
I parametri port, username e hostname possono essere specificati come parte dell'URI remoto. command, netcat e socket sono disponibili da altri parametri aggiuntivi.
netcat=/opt/netcat/bin/nc
no_verify tls If set to a non-zero value, this disables client checks of the server's certificate. Note that to disable server checks of the client's certificate or IP address you must change the libvirtd configuration. 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). Usatelo quando non siete in possesso di un accesso ad un terminale - per esempio in programmi grafici che utilizzano libvirt. no_tty=1

Parte V. Virtualization Storage Topics

Introduction to storage administration for virtualization

This part covers using shared, networked storage with virtualization on Red Hat Enterprise Linux.
The following methods are supported for virtualization:
  • Fibre Channel
  • iSCSI
  • NFS
  • GFS2
Networked storage is essential for live and offline guest migrations. You cannot migrate guests without shared storage.

Capitolo 23. Using shared storage with virtual disk images

This chapter covers the use of shared and network storage devices for virtual disks.

23.1. Using iSCSI for storing virtual disk images

This section demonstrates how to set up an iSCSI target on Red Hat Enterprise Linux and how to configure iSCSI on a libvirt KVM host using virsh, and finally how to provision a guest on iSCSI using virt-install.

Importante

Setting up a Red Hat Enterprise Linux server as an iSCSI target is not recommended. The example used in this section should not be used in production, and is provided as an example which should only be referred to for basic shared storage testing and educational purposes.

23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux

  1. Install and enable the iSCSI target service

    Install and enable the iSCSI target service with the following commands:
    # yum install scsi-target-utils
    # chkconfig tgtd on
    # service tgtd start
    

    Importante

    The scsi-target-utils package required for this example is provided only in the Cluster Storage add-on for Red Hat Enterprise Linux 5, and may not be available for your system. Contact your support agent to activate this add-on if you are currently unable to install this package.
  2. Allocate storage for the LUNs

    The iSCSI target service is not dependent on a particular type of exported LUN. The LUNs can be plain files, LVM volumes, or block devices. There is however a performance overhead if using the LVM and/or file system layers as compared to block devices. The guest providing the iSCSI service in this example has no spare block or LVM devices, so raw files will be used.
    This example demonstrates the creation of two LUNs; one is a 10GB thin-provisioned (sparse file) LUN, and the other has 500MB, of which are fully-allocated. The following commands will achieve this configuration. Be aware that your environment will be different and this is provided only as an example:
    # mkdir -p /var/lib/tgtd/kvmguest
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/rhelx86_64.img bs=1M seek=10240 count=0
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/shareddata.img bs=1M count=512
    # restorecon -R /var/lib/tgtd
    
  3. Export the iSCSI target and LUNs

    For Red Hat Enterprise Linux 5, a series of tgtadm commands is required to create a target and associate the storage volumes created earlier. First, the following command adds a target using an iSCSI Qualified Name (IQN):
    # tgtadm --lld iscsi --op new --mode target --tid 1 --targetname \ 
    iqn.2004-04.rhel:rhel5:iscsi.kvmguest
    
    Now the storage volumes must be associated with LUNs in the iSCSI target with these two commands:
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 \
    --backing-store /var/lib/tgtd/kvmguest/rhelx86_64.img
    
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 \
    --backing-store /var/lib/tgtd/kvmguest/shareddata.img
    

    Importante

    Add the previous 3 tgtadm commands to the end of the /etc/rc.local file to ensure normal operation upon restarting of the system.
    To confirm the successful operation of the previous commands, query the iSCSI target setup:
    tgtadm --lld iscsi --op show --mode target
    Target 1: iqn.2004-04.rhel:rhel5:iscsi.kvmguest
        System information:
            Driver: iscsi
            State: ready
        I_T nexus information:
        LUN information:
            LUN: 0
                Type: controller
                SCSI ID: IET     00010000
                SCSI SN: beaf10
                Size: 0 MB, Block size: 1
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: null
                Backing store path: None
                Backing store flags: 
            LUN: 1
                Type: disk
                SCSI ID: IET     00010001
                SCSI SN: beaf11
                Size: 10737 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/rhelx86_64.img
                Backing store flags: 
            LUN: 2
                Type: disk
                SCSI ID: IET     00010002
                SCSI SN: beaf12
                Size: 537 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/shareddata.img
                Backing store flags: 
        Account information:
        ACL information:
    
  4. Allow client access to the target

    Finally, this example command allows access to all clients without any authentication:
    # tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address ALL
    

Two common mistakes

The two most common problems encountered when configuring the iSCSI target are SELinux and iptables. If adding plain files as LUNs in an iSCSI target, ensure the files are labelled system_u:object_r:tgtd_var_lib_t:s0. TCP port 3260 must also be open in your iptables configuration.

23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install

The previous section described how to set up an iSCSI target. This section demonstrates how to configure iSCSI on a libvirt KVM instance using virsh, and then how to provision a guest using virt-install.
  1. Defining the storage pool

    All libvirt storage is managed through storage pools, of which there are many possible types: SCSI, NFS, ext4, plain directory and iSCSI. All libvirt objects are configured via XML description files, and storage pools are no different in this regard. For an iSCSI storage pool there are three important pieces of information to provide:
    • The target path - this determines how libvirt will expose device paths for the pool. Paths like /dev/sda and /dev/sdb are not an ideal choice as they can change between reboots, and can change across machines within a cluster; in other words, the names are assigned on a first come, first served basis by the kernel. It is strongly recommended to use the /dev/disk/by-path format. This results in a consistent naming scheme across all machines.
    • The host name - this is simply the fully-qualified DNS name of the iSCSI server.
    • The source path - this is the iSCSI qualified name (IQN) seen in the previous setup procedure (iqn.2004-04.rhel:rhel5:iscsi.kvmguest).
    Although your environment will likely be different, the following text is what an iSCSI configuration will look like:
    <pool type='iscsi'>
        <name>kvmguest</name>
        <source>
            <host name='myiscsi.example.com'/>
            <device path='iqn.2004-04.rhel:rhel5:iscsi.kvmguest'/>
        </source>
        <target>
            <path>/dev/disk/by-path</path>
        </target>
    </pool>
    
    Save this XML code to a file named iscsirhel5.xml and load it into libvirt using the pool-define command:
    # virsh pool-define iscsirhel5.xml
    Pool kvmguest defined from iscsirhel5.xml
    
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    kvmguest             inactive   no
    
  2. Starting the storage pool

    The configuration is saved, but the iSCSI target has not yet been logged into, so no LUNs will be visible on the host at this point. Use the pool-start command the make the LUNs visible with the vol-list command.
    # virsh pool-start kvmguest
    Pool kvmguest started
    
    # virsh vol-list kvmguest
    Name                 Path
    -----------------------------------------
    10.0.0.1             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    10.0.0.2             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2
    
  3. Querying LUN information

    Further information about each LUN can be obtained using the vol-info and vol-dumpxml commands:
    # virsh vol-info /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    
    Name:           10.0.0.1
    Type:           block
    Capacity:       10.00 GB
    Allocation:     10.00 GB
    
    
    # virsh vol-dumpxml /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    <volume>
      <name>10.0.0.1</name>
      <key>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1</key>
      <source>
      </source>
      <capacity>10737418240</capacity>
      <allocation>10737418240</allocation>
      <target>
        <path>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2</path>
        <format type='unknown'/>
        <permissions>
          <mode>0660</mode>
          <owner>0</owner>
          <group>6</group>
          <label>system_u:object_r:fixed_disk_device_t:s0</label>
        </permissions>
      </target>
    </volume>
    
  4. Activating the storage at boot time

    If everything is configured properly, the pool can be set to start automatically upon booting of the host:
    # virsh pool-autostart kvmguest
    Pool kvmguest marked as autostarted
    
  5. Provisioning a guest on iSCSI

    The virt-install command can be used to install new guests from the command line. The --disk argument can take the name of a storage pool, followed by the name of any contained volumes. Continuing this example, the following command will begin the installation of a guest with two disks; the first disk is the root file system, the second disk can be shared between multiple guests for common data:
    # virt-install --accelerate --name rhelx86_64 --ram 800 --vnc --disk \ vol=kvmguest/10.0.0.1 --disk vol=kvmguest/10.0.0.2,perms=sh --pxe
    
    Once this rhelx86_64 guest is installed, the following command and output shows the XML that virt-install used to associate the guest with the iSCSI LUNs:
    # virsh dumpxml rhelx86_64
    
    <domain type='kvm' id='4'>
      <name>rhelx86_64</name>
      <uuid>ad8961e9-156f-746f-5a4e-f220bfafd08d</uuid>
      <memory>819200</memory>
      <currentMemory>819200</currentMemory>
      <vcpu>1</vcpu>
      <os>
        <type arch='x86_64' machine='rhel'>hvm</type>
        <boot dev='network'/>
      </os>
      <features>
        <acpi/>
        <apic/>
        <pae/>
      </features>
      <clock offset='utc'/>
      <on_poweroff>destroy</on_poweroff>
      <on_reboot>destroy</on_reboot>
      <on_crash>destroy</on_crash>
      <devices>
        <emulator>/usr/libexec/qemu-kvm</emulator>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1'/>
          <target dev='hda' bus='ide'/>
          <alias name='ide0-0-0'/>
          <address type='drive' controller='0' bus='0' unit='0'/>
        </disk>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2'/>
          <target dev='hdb' bus='ide'/>
          <shareable/>
          <alias name='ide0-0-1'/>
          <address type='drive' controller='0' bus='0' unit='1'/>
        </disk>
        <controller type='ide' index='0'>
          <alias name='ide0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
        </controller>
        <interface type='network'>
          <mac address='52:54:00:0a:ca:84'/>
          <source network='default'/>
          <target dev='vnet1'/>
          <alias name='net0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
        </interface>
        <serial type='pty'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </serial>
        <console type='pty' tty='/dev/pts/28'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </console>
        <input type='mouse' bus='ps2'/>
        <graphics type='vnc' port='5901' autoport='yes' keymap='en-us'/>
        <video>
          <model type='cirrus' vram='9216' heads='1'/>
          <alias name='video0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
        </video>
      </devices>
    </domain>
    
    There are two important items of note in this output:
    • The guest uses the large /dev/disk/by-path paths to refer to the LUNs. As described earlier, this is so that file names and paths will remain constant.
    • The second disk has the <shareable/> flag set. Critical for the disk to be safely shared between guests, this ensures that the SELinux labelling will be appropriate for multiple guests to access the disk and that all I/O caching is disabled on the host.
For migration of guests between hosts to succeed, some form of shared storage is required. Although NFS is often used for this purpose, the lack of SELinux labelling for NFS means there is limited sVirt protection between guests. This lack of sVirt support could allow one guest to use another guest's disks, which is usually undesirable.
Using iSCSI provides full sVirt isolation between guests to the same degree of non-shared storage.

Parte VI. Virtualization Reference Guide

Capitolo 24. Tool per la virtualizzazione

Di seguito viene riportato un elenco di tool per la gestione della virtualizzazione, del debugging ed il networking utili per i sistemi che eseguono Xen.
Tool 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
Tool 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 25. Gestione dei guest con virsh

virsh è un tool dell'interfaccia della linea di comando per la gestione dei guest e dell'hypervisor.
Il tool virsh è stato creato considerando l'API di gestione libvirt e funziona come alternativa al tool xm e al graphical guest Manager (virt-manager). Gli utenti non privilegiati possono usare virsh per operazioni di sola lettura. Utilizzate 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:
Tabella 25.1. Comandi di gestione delle risorse
Comando Descrizione
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 Displays the guest's ID.
domuuid Displays the guest's UUID.
dominfo Mostra le informazioni del guest.
domname Displays the guest's name.
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.

Le seguenti opzioni del comando virsh sono utilizzate per gestire le risorse dell'hypervisor e del guest:
Tabella 25.2. Opzioni di gestione delle risorse
Comando Descrizione
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.

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

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 inserite il comando sopra riportato con -readonly.
Creazione dump XML di una macchina virtuale (file di configurazione)
Output a guest's XML configuration file with virsh:
# virsh dumpxml {domain-id, domain-name or domain-uuid}
This command outputs the guest's XML configuration file to standard out (stdout). You can save the data by piping the output to a file. An example of piping the output to a file called guest.xml:
# virsh dumpxml GuestID > guest.xml
This file guest.xml can recreate the guest (refer to Editing a guest's configuration file. You can edit this XML configuration file to configure additional devices or to deploy additional guests. Refer to Sezione 33.1, «Come utilizzare i file di configurazione XML con virsh» for more information on modifying files created with 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
Guests can be created from XML configuration files. You can copy existing XML from previously created guests or use the dumpxml option (refer to Creazione dump XML di una macchina virtuale (file di configurazione)). To create a guest with virsh from an XML file:
# virsh create configuration_file.xml
Editing a guest's configuration file
Instead of using the dumpxml option (refer to Creazione dump XML di una macchina virtuale (file di configurazione)) guests can be edited either while they run or while they are offline. The virsh edit command provides this functionality. For example, to edit the guest named 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}
When a guest is in a suspended state, it consumes system RAM but not processor resources. Disk and network I/O does not occur while the guest is suspended. This operation is immediate and the guest can be restarted with the resume (Ripristino di un guest) option.
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
This stops the guest you specify and saves the data to a file, which may take some time given the amount of memory in use by your guest. You can restore the state of the guest with the restore (Ripristino di un guest) option. Save is similar to pause, instead of just pausing a guest the present state of the guest is saved.
Ripristino di un guest
Restore a guest previously saved with the virsh save command (Come salvare un guest) using virsh:
# virsh restore filename
This restarts the saved guest, which may take some time. The guest's name and UUID are preserved but are allocated for a new id.
Come arrestare un guest
Per arrestare un guest usando il comando virsh:
# virsh shutdown {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_shutdown parameter in the guest's configuration file.
Riavvio di un guest
Riavvio di un guest con il comando virsh:
#virsh reboot {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_reboot element in the guest's configuration file.
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}
This command does an immediate ungraceful shutdown and stops the specified guest. Using virsh destroy can corrupt guest file systems . Use the destroy option only when the guest is unresponsive. For para-virtualized guests, use the shutdown option(Come arrestare un guest) instead.
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
Using virsh with the guest's domain ID, domain name or UUID you can display information on the specified guest:
# 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 vcpu cpulist
The domain-id parameter is the guest's ID number or name.
Il parametro vcpu denota il numero di CPU virtualizzate assegnate al guest. Il parametro vcpu deve essere fornito.
Il parametro cpulist è un elenco di numeri dell'identificatore della CPU fisica separati da virgole. Il parametro cpulist determina su quale CPU fisica le VCPU possono essere eseguite.
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
To modify a guest's memory allocation with virsh :
# virsh setmem {domain-id or domain-name} count
Specificate 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. Un valore di memoria massima più alto non interesserà il guest attivo. Se il nuovo valore è più basso, la memoria disponibile verrà ridotta ed il guest potrà arrestarsi inaspettatamente.
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.
Il parametro GuestName rappresenta il nome del guest che si desidera migrare.
Il parametro DestinationURL rappresenta l'URL o l'hostname del sistema di destinazione. Il sistema di desitnazione necessita di:
  • stessa versione di Red Hat Enterprise Linux,
  • stesso hypervisor (KVM o Xen), e
  • il servizio libvirt deve essere avviato.
Una volta inserito il comando vi verrà richiesta la password root del sistema di destinazione.
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 26. Gestione dei guest con Virtual Machine Manager (virt-manager)

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 vostro 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,
  • collegamenti alle console grafiche e di testo, e
  • alle migrazioni live e offline.

26.1. The Add Connection window

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 26.1. Finestra di collegamento del Virtual Machine Manager

26.2. Finestra principale del Virtual Machine Manager

This main window displays all the running guests and resources used by guests. Select a virtualized guest by double clicking the guest's name.
Finestra principale del Virtual Machine Manager
Figura 26.2. Finestra principale del Virtual Machine Manager

26.3. The guest Overview tab

The Overview tab displays graphs and statistics of a guest's live resource utilization data available from virt-manager. The UUID field displays the globally unique identifier for the virtual machines.
The Overview tab
Figura 26.3. The Overview tab

26.4. Console grafica della macchina virtuale

This window displays a virtual machine's graphical console. Para-virtualized and fully virtualized guests use different techniques to export their local virtual framebuffers, but both technologies use VNC to make them available to the Virtual Machine Manager's console window. If your virtual machine is set to require authentication, the Virtual Machine Graphical console prompts you for a password before the display appears.
Finestra console grafica
Figura 26.4. Finestra console grafica

Nota sulla sicurezza e su VNC

VNC is considered insecure by many security experts, however, several changes have been made to enable the secure usage of VNC for virtualization on Red Hat enterprise Linux. The guest machines only listen to the local host (dom0)'s loopback address (127.0.0.1). This ensures only those with shell privileges on the host can access virt-manager and the virtual machine through VNC.
Remote administration can be performed following the instructions in Capitolo 22, Gestione remota dei guest virtualizzati. TLS can provide enterprise level security for managing guest and host systems.
Your local desktop can intercept key combinations (for example, Ctrl+Alt+F11) to prevent them from being sent to the guest machine. You can use the virt-manager sticky key capability to send these sequences. To use this capability, you must press any modifier key (Ctrl or Alt) 3 times and the key you specify gets treated as active until the next non-modifier key is pressed. You can then send Ctrl-Alt-F11 to the guest by entering the key sequence 'Ctrl Ctrl Ctrl Alt+F1'.

Nota

Due to a limitation of virt-manager, it is not possible to use this sticky key feature to send a Sysrq key combination to a guest.

26.5. Avvio di virt-manager

Per avviare la sessione virt-manager aprite il menu Applicazioni fate clic su Tool del sistema e selezionate Virtual Machine Manager(virt-manager).
Apparirà la finestra principale del virt-manager.
Avvio di virt-manager
Figura 26.5. Avvio di virt-manager

Alternatively, virt-manager can be started remotely using ssh as demonstrated in the following command:
ssh -X host's address[remotehost]# virt-manager
Using ssh to manage virtual machines and hosts is discussed further in Sezione 22.1, «Gestione remota con SSH».

26.6. Ripristino di una macchina salvata

Dopo aver avviato il Virtual Machine Manager, tutte le macchine virtuali sul vostro sistema verranno visualizzate nella finestra principale. Domain0 è il vostro 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, selezionate Ripristina una macchina salvata.
    Ripristino di una macchina virtuale
    Figura 26.6. Ripristino di una macchina virtuale

  2. Apparirà la finestra principale di Ripristina macchina virtuale.
  3. Andate nella directory corretta e selezionate il file della sessione salvata.
  4. Fate 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 26.7. Una sessione del virtual machine manager ripristinata

26.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 vostro sistema.
To view a virtual system's details:
  1. Nella finestra principale del Virtual Machine Manager, selezionate la macchina virtuale che desiderate visualizzare.
    Selezione di una macchina virtuale da visualizzare
    Figura 26.8. Selezione di una macchina virtuale da visualizzare

  2. From the Virtual Machine Manager Edit menu, select Machine Details (or click the Details button on the bottom of the Virtual Machine Manager main window).
    Displaying the overview window
    Figura 26.9. Displaying the overview window

    On the Virtual Machine window, click the Overview tab.
    The Overview tab summarizes CPU and memory usage for the virtualized guest you specified.
    Visualizzazione panoramica dettagli del guest
    Figura 26.10. Visualizzazione panoramica dettagli del guest

  3. On the Virtual Machine window, click the Hardwaretab.
    Visualizzazione informazioni hardware del guest
    Figura 26.11. Visualizzazione informazioni hardware del guest

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

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

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

  7. On the Hardware tab, click on NIC to view or change the current network configuration.
    Visualizzazione configurazione di rete
    Figura 26.15. Visualizzazione configurazione di rete

26.8. Monitoraggio dello stato

Status status monitoring preferences can be modified with virt-manager's preferences window.
To configure status monitoring:
  1. Dal menu Modifica, selezionate Preferenze.
    Modifica preferenze del guest
    Figura 26.16. Modifica preferenze del guest

    The Preferences window appears.
  2. From the Stats tab specify the time in seconds or stats polling options.
    Configurazione monitoraggio dello stato
    Figura 26.17. Configurazione monitoraggio dello stato

26.9. Visualizzazione degli identificatori del guest

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

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

26.10. Displaying a guest's status

Per visualizzare lo stato di tutte le macchine virtuali sul vostro sistema:
  1. Dal menu Visualizza, selezionate la casella Stato.
    Selecting a virtual machine's status
    Figura 26.20. Selecting a virtual machine's status

  2. Il Virtual Machine Manager elenca lo stato di tutte le macchine virtuali presenti sul vostro sistema.
    Displaying a virtual machine's status
    Figura 26.21. Displaying a virtual machine's status

26.11. Visualizzazione delle CPU virtuali

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

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

26.12. Visualizzazione utilizzo della CPU

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

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

26.13. Visualizzazione utilizzo della memoria

Per visualizzare l'uso della memoria per tutte le macchine virtuali sul vostro sistema:
  1. Dal menu Visualizza, selezionate la casella Utilizzo memoria.
    Selezione utilizzo della memoria
    Figura 26.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 vostro sistema.
    Visualizzazione utilizzo della memoria
    Figura 26.27. Visualizzazione utilizzo della memoria

26.14. Gestione di una rete virtuale

Per configurare una rete virtuale sul vostro sistema:
  1. Dal menu Modifica, selezionate Dettagli host.
    Selecting a host's details
    Figura 26.28. Selecting a host's details

  2. Ciò aprirà il menu Dettagli host. A questo punto fate clic sulla scheda Reti virtuali.
    Configurazione rete virtuale
    Figura 26.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 in modo da voi desiderato.

26.15. Creazione di una rete virtuale

Per creare una rete virtuale sul vostro sistema:
  1. Open the Host Details menu (refer to Sezione 26.14, «Gestione di una rete virtuale») and click the Add button.
    Configurazione rete virtuale
    Figura 26.30. Configurazione rete virtuale

    In tal modo aprirete il menu Crea una nuova rete virtuale. Per continuare fate clic su Avanti.
    Creazione di una nuova rete virtuale
    Figura 26.31. Creazione di una nuova rete virtuale

  2. Inserite il nome appropriato per la vostra rete virtuale e successivamente fate clic su Avanti.
    Come nominare la vostra rete virtuale
    Figura 26.32. Come nominare la vostra rete virtuale

  3. Inserite uno spazio per l'indirizzo IPv4 per la vostra rete virtuale e fate clic su Avanti.
    Scelta di uno spazio per l'indirizzo IPv4
    Figura 26.33. Scelta di uno spazio per l'indirizzo IPv4

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

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

    Se selezionate Inoltro ad una rete fisica, scegliete se la Destinazione debba essere NAT per qualsiasi dispositivo fisico o NAT per il dispositivo fisico eth0.
    Fate clic su Avanti per continuare.
  6. Ora sarete in grado di creare una rete. Controllate la configurazione della vostra rete e fate clic su Fine.
    Pronti per creare la rete
    Figura 26.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 26.37. È ora disponibile la nuova rete virtuale

Capitolo 27. Riferimento rapido del comando xm

Il comando xm è in grado di gestire l'hypervisor Xen. È possibile eseguire la maggior parte delle operazioni con i tool di libvirt, virt-manager o il comando virsh. Il comando xm non possiede la funzione di controllo per la presenza di errori dei tool di libvirt e non dovrebbe essere usato per compiti supportati dai tool di lbvirt.
Sono presenti alcune operazioni che non possono essere eseguite tramite il comando virt-manager. Alcune opzioni per altre implementazioni Xen del comando xm non funzionano in Red Hat Enterprise Linux 5. L'elenco di seguito riportato fornisce una panoramica delle opzioni del comando disponibili e non.

Avvertenza

È consigliato utilizzare virsh o virt-manager e non xm. Il comando xm non è in grado di gestire bene il controllo degli errori o gli errori relativi alla configurazione, con una conseguente instabilità del sistema o errori nelle macchine virtuali. La modifica manuale dei file di configurazione di Xen è pericolosa ed è sconsigliata.
Opzioni di gestione di base
Di seguito sono riportati i comandi xm di base comunemente usati:
  • xm help [--long]: visualizza le opzioni disponibili ed il testo d'aiuto.
  • utilizzare il comando xm list per elencare i domini attivi:
    $ xm list
    Name                                ID  Mem(MiB)   VCPUs      State      Time(s)
    Domain-0                            0     520       2         r-----     1275.5
    r5b2-mySQL01                       13     500       1         -b----       16.1
    
  • xm create [-c] DomainName/ID: start a virtual machine. If the -c option is used, the start up process will attach to the guest's console.
  • xm console DomainName/ID: attach to a virtual machine's console.
  • xm destroy DomainName/ID: termina una macchina virtuale, simile al power off.
  • xm reboot DomainName/ID: riavvia una macchina virtuale, viene eseguito attraverso il processo normale di arresto ed avvio del sistema.
  • xm shutdown DomainName/ID: arresta una macchina virtuale, esegue una procedura normale di arresto.
  • xm pause
  • xm unpause
  • xm save
  • xm restore
  • xm migrate
Opzioni di gestione delle risorse
Utilizzare i seguenti comandi xm per gestire le risorse:
  • xm mem-set
  • utilizzare xm vcpu-list per elencare le affinità delle CPU virtualizzate:
    $ xm vcpu-list
    Name                          ID  VCPUs   CPU State  Time(s)  CPU Affinity
    Domain-0                       0    0      0    r--   708.9    any cpu
    Domain-0                       0    1      1   -b-    572.1    any cpu
    r5b2-mySQL01                  13    0      1   -b-     16.1    any cpu
    
  • xm vcpu-pin
  • xm vcpu-set
  • utilizzate il comando xm sched-credit per visualizzare i parametri dello scheduler per un determinato dominio:
    $ xm sched-credit -d 0
    {'cap': 0, 'weight': 256}
    $ xm sched-credit -d 13
    {'cap': 25, 'weight': 256}
    
Opzioni di monitoring e di troubleshooting
Utilizzate i seguenti comandi xm per il monitoring ed il troubleshooting:
  • xm top
  • xm dmesg
  • xm info
  • xm log
  • utilizzate i seguenti comandi xm uptime per visualizzare l'uptime dei guest e degli host:
    $ xm uptime
    Name                       ID  Uptime
    Domain-0                    0  3:42:18
    r5b2-mySQL01               13  0:06:27
    
  • xm sysrq
  • xm dump-core
  • xm rename
  • xm domid
  • xm domname
Opzioni correnti non supportate
xm vnet-list non è attualmente supportato.

Capitolo 28. Configurazione dei parametri d'avvio del kernel di Xen

GNU Grand Unified Boot Loader (o GRUB) è un programma per l'avvio dei vari sistemi operativi o dei kernel. GRUB permette all'utente di passare gli argomenti al kernel. Il file di configurazione di GRUB (posizionato all'interno di /boot/grub/grub.conf), viene usato per creare un elenco di sistemi operativi da avviare nell'interfaccia del menu di GRUB. Quando installate l'RPM kernel-xen, uno script aggiunge la voce kernel-xen al file di configurazione di GRUB il quale avvia kernel-xen per impostazione predefinita. Modificate il file grub.conf per modificare il kernel predefinito o per aggiungere i parametri del kernel supplementari.
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Se impostate le voci relative a Grub di Linux in modo da riflettere questo esempio, il boot loader carica l'hypervisor, l'immagine initrd ed il kernel di Linux. Poichè la voce del kernel si trova sopra le altre voci, il kernel viene caricato prima nella memoria. Il boot loader invia, e riceve, gli argomenti della linea di comando da e per l'hypervisor, ed il kernel di Linux. Il seguente esempio mostra come limitare la memoria del kernel di linux di Dom0 a 800 MB:
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5 dom0_mem=800M
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
È possibile utilizzare i parametri di GRUB per poter configurare l'hypervisor per la Virtualizzazione:
mem
Ciò limita la quantità di memoria disponibile per il kernel dell'hypervisor.
com1=115200, 8n1
Abilita la prima porta seriale nel sistema in modo da comportarsi come console seriale (com2 viene assegnata per la porta successiva, e così via).
dom0_mem
Ciò limita la memoria disponibile per l'hypervisor.
dom0_max_vcpus
Limita la quantità di CPU visibile al domain0 di Xen.
acpi
Cambia l'hypervisor ACPI in hypervisor e domain0. Le opzioni del parametro ACPI includono:
/*   ****  Linux config options: propagated to domain0  ****/
/*   "acpi=off":      Disables both ACPI table parsing and interpreter.   */
/*   "acpi=force":    Overrides the disable blacklist.                    */
/*   "acpi=strict":   Disables out-of-spec workarounds.                   */
/*   "acpi=ht":       Limits ACPI from boot-time to enable HT.            */
/*   "acpi=noirq":    Disables ACPI interrupt routing.                    */
noacpi
Disabilita ACPI per le interrupt delivery.

Capitolo 29. Configurazione di ELILO

ELILO è il bootloader usato sui sistemi basati su EFI, ed in paticolare su Itanium®. Simile a GRUB, il bootloader sui sistemi x86 e x86-64, ELILO permette agli utenti di selezionare il kernel installato da caricare durante la sequenza d'avvio del sistema e di passare gli argomenti al kernel. Il file di configurazione di ELILO, posizionato nella partizione boot di EFI e collegato con un link simbolico a /etc/elilo.conf, contiene un elenco di opzioni globali e di stanza dell'immagine. Quando installate l'RPM kernel-xen uno script di post-installazione sarà in grado di aggiungere la stanza dell'immagine appropriata su elilo.conf.

ELILO

Questa sezione su ELILO è relativa ai sistemi che eseguono il kernel Xen su architetture intel Itanium.
Il file di configurazione di ELILO presenta due sezioni:
  • Opzioni globali che interessano il comportamento di ELILO, e le voci totali presenti. Generalmente non è necessario modificare i loro valori predefiniti.
  • Stanza dell'immagine che definisce una selezione d'avvio insieme alle opzioni associate.
Here is a sample image stanza in elilo.conf:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="-- rhgb quiet"
The image parameter indicates the following lines apply to a single boot selection. This stanza defines a hypervisor (vmm), initrd, and command line arguments (read-only, root and append) to the hypervisor and kernel. When ELILO is loaded during the boot sequence, the image is labeled linux.
ELILO traduce read-only nella opzione della linea di comando del kernel ro, causando un montaggio del file system root in sola-lettura fino a quando initscripts monta l'unità root in modalità lettura-scrittura. ELILO copia la riga "root" sulla linea di comando del kernel. Le suddette righe verranno unite con la riga "append" per dar luogo ad una linea di comando completa:
"-- root=/dev/VolGroup00/rhel5_2 ro rhgb quiet"
I simboli -- vengono usati per delimitare gli argomenti dell'hypervisor e del kernel. Gli argomenti dell'hypervisor vengono prima seguiti del delimitatore --, e successivamente dagli argomenti del kernel. L'hypervisor generalmente non presenta alcun argomento.

Note tecniche

ELILO passa l'intera linea di comando all'hypervisor, il quale a sua volta divide il contenuto passando le opzioni del kernel al kernel in questione.
Per personalizzare l'hypervisor inserite i parametri prima del delimitatore --. Esempio di parametro di memoria dell'hypervisor (mem) e del parametro quiet per il kernel:
append="dom0_mem=2G -- quiet"
Parametri dell'hypervisor di ELILO
ParametroDescrizione
mem=Il parametro mem definisce l'utilizzo massimo della RAM dell'hypervisor. Qualsiasi RAM aggiuntiva presente nel sistema verrà ignorata. Il parametro può essere specificato con un suffisso B, K, M o G i quali rappresentano rispettivamente bytes, kilobytes, megabytes e gigabytes. Se non viene specificato alcun suffisso l'unità predefinita è kilobytes.
dom0_mem=dom0_mem= imposta la quantità di RAM da assegnare a dom0. Vengono rispettati gli stessi suffissi così come il parametro mem. Il valore predefinito in Red Hat Enterprise Linux 5.2 su Itanium® è 4G.
dom0_max_vcpus=dom0_max_vcpus= imposta il numero delle CPU da assegnare all'hypervisor. L'impostazione predefinita in Red Hat Enterprise Linux 5.2 su Itanium® è 4.
com1=<baud>,DPS,<io_base>,<irq>com1= imposta i parametri per la prima riga seriale. Per esempio, com1=9600,8n1,0x408,5. Le opzioni io_base e irq possono essere omesse, lasciandole così come valori predefiniti standard. Il parametro baud può essere impostato come auto in modo da preservare i parametri del bootloader. Il parametro com1 può essere omesso se i parametri seriali sono stati impostati come opzioni globali in ELILO o nella configurazione di EFI.
com2=<baud>,DPS,<io_base>,<irq>Imposta i parametri per la seconda riga seriale. Consultate la descrizione del parametro com1 sopra riportato.
console=<specifier_list>console è un elenco delle preferenze delimitato da virgole, per le opzioni della console. Le opzioni includono vga, com1 e com2. Questa impostazione dovrebbe essere omessa poichè l'hypervisor cercherà di identificare le impostazioni della console EFI.

Per maggiori informazioni sui parametri ELILO

Un elenco completo dei parametri ELILO è disponibile su XenSource.
Esempio modificato della configurazione, il quale mostra una sintassi usata per aggiungere i parametri per l'assegnazione della cpu e della memoria sull'hypervisor:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="dom0_mem=2G dom0_max_vcpus=2 --"
Altresì questo esempio rimuove i parametri del kernel "rhgb quiet" in modo da generare sulle console gli output del kernel e initscript . Da notare come il doppio trattino rimane invariato in modo da poter interpretare correttamente come argomento dell'hypervisor la riga da aggiungere.

Capitolo 30. libvirt configuration reference

This chapter provides is a references for various parameters of libvirt XML configuration files
Tabella 30.1. libvirt configuration files
Item Description
pae
Specifies the physical address extension configuration data.
apic
Specifies the advanced programmable interrupt controller configuration data.
memory
Specifies the memory size in megabytes.
vcpus
Specifies the numbers of virtual CPUs.
console
Specifies the port numbers to export the domain consoles to.
nic
Specifies the number of virtual network interfaces.
vif
Lists the randomly-assigned MAC addresses and bridges assigned to use for the domain's network addresses.
disk
Lists the block devices to export to the domain and exports physical devices to domain with read only access.
dhcp
Enables networking using DHCP.
netmask
Specifies the configured IP netmasks.
gateway
Specifies the configured IP gateways.
acpi
Specifies the advanced configuration power interface configuration data.

Capitolo 31. File di configurazione di Xen

Red Hat Enterprise Linux uses libvirt configuration files for most tasks. Some users may need Xen configuration files which contain the following standard variables. Configuration items within these files must be enclosed in single quotes('). These configuration files reside in the /etc/xen directory.
The table below, Tabella 31.1, «Riferimento del file di configurazione di Xen», is formatted output from xm create --help_config.
Tabella 31.1. Riferimento del file di configurazione di Xen
Parameter
Description
vncpasswd=NAME Password per console VNC su di un dominio HVM.
vncviewer=no | yes Genera un vncviewer in ascolto per un server vnc in un dominio. L'indirizzo del vncviewer viene passato al dominio sulla riga di comando del kernel utilizzando VNC_SERVER=<host>:<port>. La porta usata da vnc è 5500 + DISPLAY. Se possibile scegliere un valore che corrisponde ad una porta disponibile. Solo valido quando vnc=1.
vncconsole=no | yes Spawn a vncviewer process for the domain's graphical console. Only valid when vnc=1.
name=NAME Nome del dominio. Deve essere unico.
bootloader=FILE Percorso per il bootloader.
bootargs=NAME Argomenti da passare al bootloader.
bootentry=NAME Sconsigliato. Entry da avviare tramite il bootloader. Usare bootargs.
kernel=FILE Percorso per l'immagine del kernel.
ramdisk=FILE Percorso per la ramdisk.
features=FEATURES Caratteristiche da abilitare nel kernel del guest
builder=FUNCTION Funzione da usare per creare il dominio.
memory=MEMORY Memoria del dominio in MB.
maxmem=MEMORY Memoria massima del dominio in MB.
shadow_memory=MEMORY Memoria shadow del dominio in MB.
cpu=CPU CPU contenente VCPU0.
cpus=CPUS CPUS sulla quale eseguire il dominio.
pae=PAE Disabilita o abilita PAE del dominio HVM.
acpi=ACPI Disabilita o abilita ACPI del dominio HVM.
apic=APIC Disabilita o abilita APIC del dominio HVM.
vcpus=VCPUs Numero di CPUS virtuali nel dominio.
cpu_weight=WEIGHT Set the new domain's cpu weight. WEIGHT is a float that controls the domain's share of the cpu.
restart=onreboot | always | never Sconsigliato. Utilizzate on_poweroff, on_reboot, e on_crash. Se il dominio deve essere riavviato dopo l'uscita, - onreboot: riavvia all'uscita con shutdown code reboot - always: riavvia sempre dopo l'uscita, ignora codice d'uscita - never: non riavviare mai dopo l'uscita, ignora codice d'uscita.
on_poweroff=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'poweroff'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_reboot=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'reboot'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_crash=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'crash'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
blkif=no | yes Rende il dominio un backend del dispositivo a blocchi.
netif=no | yes Rende il dominio un backend dell'interfaccia di rete.
tpmif=no | yes Rende il dominio un backend dell'interfaccia TPM.
disk=phy:DEV,VDEV,MODE[,DOM] Aggiunge un dispositivo a disco ad un dominio. Il dispositivo fisico è DEV, il quale viene esportato sul dominio come VDEV. Il disco è di sola lettura se MODE è r, lettura-scrittura se MODE è w. Se DOM è stato specificato, esso definisce il dominio del driver backend da usare per il disco. L'opzione può essere ripetuta per aggiungere più di un disco.
pci=BUS:DEV.FUNC Aggiunge un dispositivo PCI ad un dominio utilizzando i parametri dati (in esadecimale). Per esempio pci=c0:02.1a. L'opzione può essere ripetuta per aggiungere più di un dispositivo pci.
ioports=FROM[-TO] Aggiunge un intervallo I/O legacy utilizzando i parametri dati (in hex). Per esempio ioports=02f8-02ff. L'opzione può essere ripetuta per aggiungere più di un intervallo i/o.
irq=IRQ Aggiunge un IRQ (interruzione della riga) ad un dominio. Per esempio irq=7. Questa opzione può essere ripetuta per aggiungere più di un IRQ.
usbport=PATH Aggiunge una porta USB fisica ad un dominio, come specificato dal percorso di quella porta. Questa opzione può essere ripetuta per aggiungere più di una porta.
vfb=type={vnc,sdl}, vncunused=1, vncdisplay=N,
vnclisten=ADDR, display=DISPLAY,
xauthority=XAUTHORITY, vncpasswd=PASSWORD,
keymap=KEYMAP
Make the domain a framebuffer backend. The backend type should be either sdl or vnc. For type=vnc, connect an external vncviewer. The server will listen on ADDR (default 127.0.0.1) on port N+5900. N defaults to the domain id. If vncunused=1, the server will try to find an arbitrary unused port above 5900. For type=sdl, a viewer will be started automatically using the given DISPLAY and XAUTHORITY, which default to the current user's ones.
vif=type=TYPE, mac=MAC, bridge=BRIDGE, ip=IPADDR,
script=SCRIPT, backend=DOM, vifname=NAME
Aggiunge una interfaccia di rete con l'indirizzo MAC dato ed il bridge. vif viene configurato richiamando lo script di configurazione definito. Se il tipo non è stato specificato, il default sarà netfront e non il dispositivo ioemu. Se mac non è stato specificato verrà usato un indirizzo MAC randomico. Se non specificato il backend di rete seleziona il proprio indirizzo MAC. Se bridge non è stato specificato verrà utilizzato il primo bridge disponibile. Se non è stato specificato lo script allora sarà implementato lo script predefinito. Se non è stato specificato il backend, allora verrà utilizzato il dominio del driver backend predefinito. Se vifname non è stato specificato, l'interfaccia virtuale backend avrà come nome vifD.N, dove D è l'id del dominio e N è l'id dell'interfaccia. Questa opzione può essere ripetuta per aggiungere più di un vif. Specificando vifs aumenterete il numero delle interfacce in modo desiderato.
vtpm=instance=INSTANCE,backend=DOM Aggiunge l'interfaccia TPM. Dal lato del backend utilizzare l'istanza data come istanza TPM virtuale. Il numero specificato è il solo numero preferito per l'istanza. Lo script hotplug determinerà il numero dell'istanza che verrà assegnato al dominio. L'associazione tra macchina virtuale ed il numero dell'istanza TPM è disponibile in /etc/xen/vtpm.db. Utilizzate il backend nel dominio specificato.
access_control=policy=POLICY,label=LABEL Aggiunge una etichetta di sicurezza ed un riferimento alla politica di sicurezza che la definisce. Il riferimento ssid locale viene calcolato al momento dell'avvio/ripristino del dominio. Al momento, la politica viene anche controllata con la politica attiva. In questo modo la migrazione attraverso il salvataggio/recupero viene soddisfatta e le etichette locali vengono automaticamente create in modo corretto sul sistema dove il dominio viene avviato/ripristinato.
nics=NUM SCONSIGLIATO. Utilizzare invece le voci vif vuote. Imposta il numero di interfacce di rete. Utilizzare l'opzione vif per definire i parametri dell'interfaccia, in caso contrario verrano utilizzati i valori predefiniti. Specificando vifs aumenterete il numero di interfacce in base alle vostre necessità.
root=DEVICE Imposta il parametro root sulla riga di comando del kernel. Utilizzare un dispositivo, es. /dev/sda1, o /dev/nfs per NFS root.
extra=ARGS Imposta argomenti supplementari da aggiungere alla riga di comando del kernel.
ip=IPADDR Imposta l'indirizzo IP dell'interfaccia del kernel.
gateway=IPADDR Imposta il gateway IP del kernel.
netmask=MASK Imposta la maschera di rete IP del kernel.
hostname=NAME Imposta l'hostname IP del kernel.
interface=INTF Imposta il nome dell'interfaccia IP del kernel.
dhcp=off|dhcp Imposta l'opzione dhcp del kernel.
nfs_server=IPADDR Imposta l'indirizzo del server NFS per NFS root.
nfs_root=PATH Imposta il percorso della directory root NFS.
device_model=FILE Percorso del programma per il modello di dispositivo.
fda=FILE Percorso per fda
fdb=FILE Percorso per fdb
serial=FILE Percorso per seriale, pty o vc
localtime=no | yes È stato impostato RTC su orario locale?
keymap=FILE Disposizione tastiera impostata utilizzata
usb=no | yes Emulare dispositivi USB?
usbdevice=NAME Nome di un dispositivo USB da aggiungere
stdvga=no | yes Use std vga or Cirrus Logic graphics
isa=no | yes Simulare solo un sistema ISA
boot=a|b|c|d Dispositivo d'avvio predefinito
nographic=no | yes I modelli del dispositivo devono usare i grafici?
soundhw=audiodev I modelli del dispositivo devono utilizzare il dispositivo audio?
vnc Il modello del dispositivo deve utilizzare VNC?
vncdisplay Display VNC da usare
vnclisten Indirizzo per il server VNC sul quale eseguire l'ascolto.
vncunused Trova una porta non utilizzata per il server VNC. Valida solo quando vnc=1.
sdl Il modello del dispositivo deve usare SDL?
display=DISPLAY Display X11 da usare
xauthority=XAUTHORITY Authority X11 da usare
uuid xenstore UUID (universally unique identifier) da usare. Se questa opzione non è stata impostata verrà generato un valore randomico, in modo simile agli indirizzi MAC per le interfacce di rete virtuali. Esso deve essere un valore unico su tutto il cluster.

Tabella 31.3, «Valori predefiniti del parametro di configurazione» lists all configuration parameters available, the Python parser function which sets the value and default values. The setter function gives an idea of what the parser does with the values you specify. It reads these as Python values, then feeds them to a setter function to store them. If the value is not valid Python, you get an obscure error message. If the setter rejects your value, you should get a reasonable error message, except it appears to get lost somehow, along with your bogus setting. If the setter accepts, but the value is incorrect the application may fail.
Tabella 31.2. Le funzioni di Python che impostano i valori del parametro
Funzione del parser Argomenti validi
set_bool
Valori accettati:
  • yes
  • y
  • no
  • yes
set_float
Accepts a floating point number with Python's float(). For example:
  • 3.14
  • 10.
  • .001
  • 1e100
  • 3.14e-10
set_int
Accepts an integer with Python's int().
set_value
accetta qualsiasi valore di Python.
append_value
accetta qualsiasi valore di Python e lo aggiunge al valore precedente conservato in un array.

Tabella 31.3. Valori predefiniti del parametro di configurazione
Parameter Funzione del parser Valore predefinito
name setter default value
vncpasswd set_value None
vncviewer set_bool None
vncconsole set_bool None
name set_value None
bootloader set_value None
bootargs set_value None
bootentry set_value None
kernel set_value None
ramdisk set_value ''
features set_value ''
builder set_value 'linux'
memory set_int 128
maxmem set_int None
shadow_memory set_int 0
cpu set_int None
cpus set_value None
pae set_int 0
acpi set_int 0
apic set_int 0
vcpus set_int 1
cpu_weight set_float None
restart set_value None
on_poweroff set_value None
on_reboot set_value None
on_crash set_value None
blkif set_bool 0
netif set_bool 0
tpmif append_value 0
disk append_value []
pci append_value []
ioports append_value []
irq append_value []
usbport append_value []
vfb append_value []
vif append_value []
vtpm append_value []
access_control append_value []
nics set_int -1
root set_value ''
extra set_value ''
ip set_value ''
gateway set_value ''
netmask set_value ''
hostname set_value ''
interface set_value "eth0"
dhcp set_value 'off'
nfs_server set_value None
nfs_root set_value None
device_model set_value ''
fda set_value ''
fdb set_value ''
serial set_value ''
localtime set_bool 0
keymap set_value ''
usb set_bool 0
usbdevice set_value ''
stdvga set_bool 0
isa set_bool 0
boot set_value 'c'
nographic set_bool 0
soundhw set_value ''
vnc set_value None
vncdisplay set_value None
vnclisten set_value None
vncunused set_bool 1
sdl set_value None
display set_value None
xauthority set_value None
uuid set_value None

Parte VII. Suggerimenti e trucchi

Capitolo 32. Suggerimenti e trucchi

Questo capitolo contiene i suggerimenti ed i consigli utili per migliorare le prestazioni relative alla virtualizzazione, scalabilità e stabilità.

32.1. Avvio automatico dei guest

This section covers how to make virtualized guests start automatically during the host system's boot phase.
Questo esempio utilizza virsh per impostare un guest, TestServer, per un avvio automatico all'avvio dell'host.
# virsh autostart TestServer
Domain TestServer marked as 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
Domain TestServer unmarked as autostarted
Il guest non esegue più automaticamente un avvio con l'host.

32.2. Come selezionare un hypervisor tra KVM e Xen

Questa sezione affronta il metodo attraverso il quale è possibile smistarsi da un hypervisor KVM ad uno Xen.
Red Hat 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.

Avvertenza

Questa procedura è solo disponibile per la versione Intel 64 o AMD64 di Red Hat Enterprise Linux 5.4 o versione più recente. Nessun'altra configurazione o versione di Red Hat Enterprise Linux è supportata. KVM non è disponibile in versioni precedenti a Red Hat Enterprise Linux 5.4.

32.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. Installate il pacchetto KVM

    Installate il pacchetto kvm se non precedentemente fatto.
    # yum install kvm
    
  2. Verificate 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.18-159.el5xen
    
    Il kernel attuale, "2.6.18-159.el5xen", è in esecuzione sul sistema. Se il kernel predefinito, "2.6.18-159.el5", è 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 Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      Da notare il parametro default=1. Tale parametro indica al boot loader GRUB di avviare la seconda voce, il kernel Xen. Modificate 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 Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Eseguite un riavvio per caricare il nuovo kernel

    Riavviate il sistema. Il computer eseguirà un riavvio con il kernel predefinito. Il modulo KVM dovrebbe essere caricato automaticamente con il kernel. Verificate 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.

32.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

    Installate 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. Verificate quale kernel è in esecuzione

    Utilizzate il comando uname per determinare quale kernel è in esecuzione.
    $ uname -r
    2.6.18-159.el5
    
    Il kernel attuale, "2.6.18-159.el5", è in esecuzione sul sistema. Questo è il kernel predefinito. Se il kernel presenta xen alla fine (per esempio 2.6.18-159.el5xen) 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 Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.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 Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Eseguite un riavvio per caricare il nuovo kernel

    Riavviate il sistema. Il computer eseguirà il riavvio con il kernel Xen. Eseguite una verifica con il comando uname:
    $ uname -r
    2.6.18-159.el5xen
    
    Se xen è presente alla fine dell'output allora il kernel in esecuzione sarà Xen.

32.3. Utilizzo di qemu-img

Il tool 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 di seguito riportati.
Formattazione e creazione di nuove immagini o dispositivi
Create il nuovo filename dell'immagine del disco con una dimensione size e formato format.
# 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 diverso dell'immagine.
Comando di formattazione:
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
Converte il filename 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 esso 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 (oltre 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. Usatelo 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 vostro file system supporta gli holes (per esempio in ext2 o ext3 su Linux o NTFS su Windows), allora solo i settori scritti riserveranno lo spazio. Utilizzate 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. Usatelo 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.

32.4. Overcommitting Resources

The KVM hypervisor supports overcommitting CPUs and memory. Overcommitting is the process of allocating more virtualized CPUs or memory than there are physical resources on the system. CPU overcommit allows under-utilized virtualized servers or desktops to run on fewer servers which saves power and money.

Supporto Xen

Memory overcommitting is not supported for the Xen hypervisor, however CPU overcommitting is supported.
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.
When using KVM, virtual machines operate as Linux processes. Guests on the KVM hypervisor do not have blocks of physical RAM assigned to them, instead they function as processes. Each process in a Linux system is allocated memory when it requests more memory. In a similar way, KVM allocates memory for guests when the guest requests more or less memory. The guest only uses slightly more physical memory than the virtualized operating system appears to use.
When physical memory is nearly completely used or a process is inactive for some time, Linux moves the process's memory to swap. Swap is usually a partition on a hard disk drive or solid state drive which Linux uses to extend virtual memory. Swap is significantly slower than RAM.
As KVM virtual machines are Linux processes, memory used by virtualized guests can be put into swap if the guest is idle or not in heavy use. Memory can be committed over the total size of the swap and physical RAM. This can cause issues if virtualized guests use their total RAM. Without sufficient memory and swap space for the virtual machine processes, the system can run completely out of memory, leading to the failure of one or more virtual machine processes.

Avvertenza

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 desiderate eseguire l'overcommit della memoria con KVM. Un rapporto consigliato è 50% (0.5). La formula usata è la seguente:
(0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
Red Hat Knowledgebase presenta un articolo su come determinare in modo sicuro ed efficiente la dimensione per la partizione swap.
Overcommitting guests by swapping out temporarily unused guest memory can be very slow, due to the IO latency introduced by disk seek times. However, Red Hat Enterprise Linux virtualization with KVM can often avoid this disk IO penalty by merging multiple pages with identical content into the same physical pages. This is done by the KSM (Kernel Samepage Merging) kernel process, which scans memory to find identical pages. The KSM kernel process uses CPU time to avoid disk IO. This tradeoff is often beneficial in workloads with many smaller, similar guests.
È 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 il vostro ambiente.
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 cinque 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.

32.5. Modifica di /etc/grub.conf

This section describes how to safely and correctly change your /etc/grub.conf file to use the virtualization kernel. You must use the xen kernel to use the Xen hypervisor. Copy your existing xen kernel entry make sure you copy all of the important lines or your system will panic upon boot (initrd will have a length of '0'). If you require xen hypervisor specific values you must append them to the xen line of your grub entry.
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 Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

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

Your grub.conf could look very different if it has been manually edited before or copied from an example. Read Capitolo 28, Configurazione dei parametri d'avvio del kernel di Xen for more information on using virtualization and grub.
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 Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro
	root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.6. Verifica delle estensioni per la virtualizzazione

Usate questa sezione per determinare la presenza sul vostro 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 idonee?

Se le estensioni per la virtualizzazione hardware non sono presenti è possibile usare Xen para-virtualization con il pacchetto kernel-xen di Red Hat.
  1. Eseguite il seguente comando per la verifica della disponibilità delle estensioni per la virtualizzazione della CPU:
    $ grep -E 'svm|vmx' /proc/cpuinfo
    
  2. Analyze the output.
    • 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
      
    If any output is received, the processor has the hardware virtualization extensions. However in some circumstances manufacturers disable the virtualization extensions in BIOS.
    Il contenuto di "flags:" potrebbe apparire numerose volte per ogni hyperthread, core o CPU sul sistema.
    The virtualization extensions may be disabled in the BIOS. If the extensions do not appear or full virtualization does not work refer to Procedura 35.1, «Come abilitare le estensioni di virtualizzazione nel BIOS».
  3. For users of the KVM hypervisor

    If the kvm package is installed. I As an additional check, verify that the kvm modules are loaded in the kernel:
    # lsmod | grep kvm
    
    If the output includes kvm_intel or kvm_amd then the kvm hardware virtualization modules are loaded and your system meets requirements. sudo

Additional output

If the libvirt package is installed, the virsh command can output a full list of virtualization system capabilities. Run virsh capabilities as root to receive the complete list.

32.7. Accessing data from a guest disk image

There are various methods for accessing the data from guest image files. One common method is to use the kpartx tool, covered by this section, to mount the guest file system as a loop device which can then be accessed.
The kpartx command creates device maps from partition tables. Each guest storage image has a partition table embedded in the file.
The libguestfs and guestfish packages, available from the EPEL repository, allow advanced modification and access to guest file systems. The libguestfs and guestfish packages are not covered in this section at this time.

Avvertenza

Guests must be offline before their files can be read. Editing or reading files of an active guest is not possible and may cause data loss or damage.
Procedura 32.1. Accessing guest image data
  1. Install the kpartx package.
    # yum install kpartx
    
  2. Use kpartx to list partition device mappings attached to a file-based storage image. This example uses a image file named guest1.img.
    # kpartx -l /var/lib/libvirt/images/guest1.img
    loop0p1 : 0 409600 /dev/loop0 63
    loop0p2 : 0 10064717 /dev/loop0 409663
    guest1 is a Linux guest. The first partition is the boot partition and the second partition is an EXT3 containing the root partition.
  3. Add the partition mappings to the recognized devices in /dev/mapper/.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
    1. Test that the partition mapping worked. There should be new devices in the /dev/mapper/ directory
      # ls /dev/mapper/
      loop0p1
      loop0p2
      
      The mappings for the image are named in the format loopXpY.
  4. Mount the loop device which to a directory. If required, create the directory. This example uses /mnt/guest1 for mounting the partition.
    # mkdir /mnt/guest1
    # mount /dev/mapper/loop0p1 /mnt/guest1 -o loop,ro
  5. The files are now available for reading in the /mnt/guest1 directory. Read or copy the files.
  6. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/tmp
  7. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be started again.
Accessing data from guest LVM volumes
Many Linux guests use Logical Volume Management (LVM) volumes. Additional steps are required to read data on LVM volumes on virtual storage images.
  1. Add the partition mappings for the guest1.img to the recognized devices in the /dev/mapper/ directory.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
  2. In this example the LVM volumes are on a second partition. The volumes require a rescan with the vgscan command to find the new volume groups.
    # vgscan
    Reading all physical volumes . This may take a while...
    Found volume group "VolGroup00" using metadata type lvm2
  3. Activate the volume group on the partition (called VolGroup00 by default) with the vgchange -ay command.
    # vgchange -ay VolGroup00
    2 logical volumes in volume group VolGroup00 now active.
  4. Use the lvs command to display information about the new volumes. The volume names (the LV column) are required to mount the volumes.
    # lvs
    LV VG Attr Lsize Origin Snap% Move Log Copy%
    LogVol00 VolGroup00 -wi-a- 5.06G
    LogVol01 VolGroup00 -wi-a- 800.00M
  5. Mount /dev/VolGroup00/LogVol00 in the /mnt/guestboot/ directory.
    # mount /dev/VolGroup00/LogVol00 /mnt/guestboot
  6. The files are now available for reading in the /mnt/guestboot directory. Read or copy the files.
  7. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/
  8. Disconnect the volume group VolGroup00
    # vgchange -an VolGroup00
    
  9. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be restarted.

32.8. Setting KVM processor affinities

This section covers setting processor and processing core affinities with libvirt for KVM guests.
By default, libvirt provisions guests using the hypervisor's default policy. For most hypervisors, the policy is to run guests on any available processing core or CPU. There are times when an explicit policy may be better, in particular for systems with a NUMA (Non-Uniform Memory Access) architecture. A guest on a NUMA system should be pinned to a processing core so that its memory allocations are always local to the node it is running on. This avoids cross-node memory transports which have less bandwidth and can significantly degrade performance.
On a non-NUMA systems some form of explicit placement across the hosts’ sockets, cores and hyperthreads may be more efficient.
Identifying CPU and NUMA topology
The first step in deciding what policy to apply is to determine the host’s memory and CPU topology. The virsh nodeinfo command provides information about how many sockets, cores and hyperthreads there are attached a host.
# virsh nodeinfo
CPU model:           x86_64
CPU(s):              8
CPU frequency:       1000 MHz
CPU socket(s):       2
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         8179176 kB
This system has eight CPUs, in two sockets, each processor has four cores.
The output shows that that the system has a NUMA architecture. NUMA is more complex and requires more data to accurately interpret. Use the virsh capabilities to get additional output data on the CPU configuration.
# virsh capabilities
<capabilities>
  <host>
    <cpu>
      <arch>x86_64</arch>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='2'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
          </cpus>
        </cell>
        <cell id='1'>
          <cpus num='4'>
            <cpu id='4'/>
            <cpu id='5'/>
            <cpu id='6'/>
            <cpu id='7'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
    </secmodel>
  </host>

 [ Additional XML removed ]

</capabilities>
The output shows two NUMA nodes (also know as NUMA cells), each containing four logical CPUs (four processing cores). This system has two sockets, therefore we can infer that each socket is a separate NUMA node. For a guest with four virtual CPUs, it would be optimal to lock the guest to physical CPUs 0 to 3, or 4 to 7 to avoid accessing non-local memory, which are significantly slower than accessing local memory.
If a guest requires eight virtual CPUs, as each NUMA node only has four physical CPUs, a better utilization may be obtained by running a pair of four virtual CPU guests and splitting the work between them, rather than using a single 8 CPU guest. Running across multiple NUMA nodes significantly degrades performance for physical and virtualized tasks.
Decide which NUMA node can run the guest
Locking a guest to a particular NUMA node offers no benefit if that node does not have sufficient free memory for that guest. libvirt stores information on the free memory available on each node. Use the virsh freecell command to display the free memory on all NUMA nodes.
# virsh freecell
0: 2203620 kB
1: 3354784 kB
If a guest requires 3 GB of RAM allocated, then the guest should be run on NUMA node (cell) 1. Node 0 only has 2.2GB free which is probably not sufficient for certain guests.
Lock a guest to a NUMA node or physical CPU set
Once you have determined which node to run the guest on, refer to the capabilities data (the output of the virsh capabilities command) about NUMA topology.
  1. Extract from the virsh capabilities output.
    <topology>
      <cells num='2'>
        <cell id='0'>
        <cpus num='4'>
          <cpu id='0'/>
          <cpu id='1'/>
          <cpu id='2'/>
          <cpu id='3'/>
        </cpus>
      </cell>
      <cell id='1'>
        <cpus num='4'>
          <cpu id='4'/>
          <cpu id='5'/>
          <cpu id='6'/>
          <cpu id='7'/>
        </cpus>
      </cell>
      </cells>
    </topology>
  2. Observe that the node 1, <cell id='1'>, has physical CPUs 4 to 7.
  3. The guest can be locked to a set of CPUs by appending the cpuset attribute to the configuration file.
    1. While the guest is offline, open the configuration file with virsh edit.
    2. Locate where the guest's virtual CPU count is specified. Find the vcpus element.
      <vcpus>4</vcpus>
      The guest in this example has four CPUs.
    3. Add a cpuset attribute with the CPU numbers for the relevant NUMA cell.
      <vcpus cpuset='4-7'>4</vcpus>
  4. Save the configuration file and restart the guest.
The guest has been locked to CPUs 4 to 7.
Automatically locking guests to CPUs with virt-install
The virt-install provisioning tool provides a simple way to automatically apply a 'best fit' NUMA policy when guests are created.
The cpuset option for virt-install can use a CPU set of processors or the parameter auto. The auto parameter automatically determines the optimal CPU locking using the available NUMA data.
For a NUMA system, use the --cpuset=auto with the virt-install command when creating new guests.
Tuning CPU affinity on running guests
There may be times where modifying CPU affinities on running guests is preferable to rebooting the guest. The virsh vcpuinfo and virsh vcpupin commands can perform CPU affinity changes on running guests.
The virsh vcpuinfo command gives up to date information about where each virtual CPU is running.
In this example, guest1 is a guest with four virtual CPUs is running on a KVM host.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            3
State:          running
CPU time:       0.5s
CPU Affinity:   yyyyyyyy
VCPU:           1
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           2
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           3
CPU:            2
State:          running
CPU Affinity:   yyyyyyyy
The virsh vcpuinfo output (the yyyyyyyy value of CPU Affinity) shows that the guest can presently run on any CPU.
To lock the virtual CPUs to the second NUMA node (CPUs four to seven), run the following commands.
# virsh vcpupin guest1 0 4
# virsh vcpupin guest1 1 5
# virsh vcpupin guest1 2 6
# virsh vcpupin guest1 3 7
The virsh vcpuinfo command confirms the change in affinity.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            4
State:          running
CPU time:       32.2s
CPU Affinity:   ----y---
VCPU:           1
CPU:            5
State:          running
CPU time:       16.9s
CPU Affinity:   -----y--
VCPU:           2
CPU:            6
State:          running
CPU time:       11.9s
CPU Affinity:   ------y-
VCPU:           3
CPU:            7
State:          running
CPU time:       14.6s
CPU Affinity:   -------y

32.9. Come generare un nuovo indirizzo MAC unico

In some case you will need to generate a new and unique MAC address for a guest. There is no command line tool available to generate a new MAC address at the time of writing. The script provided below can generate a new MAC address for your guests. Save the script to your guest as macgen.py. Now from that directory you can run the script using ./macgen.py and it will generate a new MAC address. A sample output would look like the following:
$ ./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 di seguito riportato.
#!/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 ""

32.10. Come limitare la larghezza di banda della rete per un guest Xen

In some environments it may be required to limit the network bandwidth available to certain guests. This can be used to implement basic Quality of Service on a host running multiple virtual machines. By default, the guest can use any bandwidth setting available which your physical network card supports. The physical network card must be mapped to one of virtual machine's virtual network interfaces. In Xen the “rate” parameter part of the VIF entries can throttle virtualized guests.
Questo elenco affronta le variabili
rate
The rate= option can be added to the VIF= entry in a virtual machine configuration file to limit a virtual machine's network bandwidth or specify a specific time interval for a time window.
time window
Il time window è facoltativo all'opzione rate=:
Il time window predefinito è 50ms.
Un time window più piccolo fornisce un numero minore di sequenze di trasmissioni aumentando però la latenza e la velocità di erogazione 'replenishment rate'.
Il valore predefinito di 50ms del time window è il valore ideale tra latenza e throughput ed in molti casi non richiederà alcuna modifica.
Esempi di valori e di utilizzo del parametro rate.
rate=10Mb/s
Limita il traffico di rete in uscita dal guest a 10MB/s.
rate=250KB/s
Limita il traffico di rete in uscita dal guest a 250KB/s.
rate=10MB/s@50ms
Limita la larghezza di banda a 10MB/s e fornisce al guest 50KB ad ogni 50ms.
Nella configurazione della macchina virtuale una voce semplice VIF somiglierà a quanto di seguito riportato:
vif = [ 'rate=10MB/s , mac=00:16:3e:7a:55:1c, bridge=xenbr1']
This rate entry would limit the virtual machine's interface to 10MB/s for outgoing traffic

32.11. Configurazione delle affinità del processore Xen

Xen può assegnare CPU virtuali ad associati con una o più CPU host. Tale comportamento può essere utilizzato per assegnare risorse reali ad uno o più guest virtualizzati. Questo approccio permette a Red Hat Enterprise Linux di utilizzare in modo ottimale le risorse del processore al momento di utilizzare un dual-core, un hyperthreading oppure di altre tecnologie CPU avanzate. Xen credit scheduler ribilancia automaticamente le cpu virtuali tra le cpu fisiche per massimizzare l'utilizzo del sistema. Il Red Hat Enterprise Linux permette al credit scheduler di spostare le CPU in modo desiderato fino a quando la CPU virtuale corrisponde ad una CPU fisica.
Se state eseguendo un compito intensivo I/O è consigliato utilizzare un hyperthread o un intero core processor per l'esecuzione di domain0.
Da notare che ciò non è necessario per KVM poichè KVM utilizza il Linux kernel scheduler predefinito.
Le affinità della CPU possono essere impostate con virsh o virt-manager:
To set CPU affinities using virsh refer to Configurazione affinità CPU virtuale for more information.
To configure and view CPU information with virt-manager refer to Sezione 26.11, «Visualizzazione delle CPU virtuali» for more information.

32.12. Come modificare l'hypervisor Xen

Managing host systems often involves changing the boot configuration file /boot/grub/grub.conf. Managing several or more hosts configuration files quickly becomes difficult. System administrators often prefer to use the 'cut and paste' method for editing multiple grub.conf files. If you do this, ensure you include all five lines in the Virtualization entry (or this will create system errors). Hypervisor specific values are all found on the 'xen' line. This example represents a correct grub.conf virtualization entry:
# 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 Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0, 0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
    module /vmlinuz-2.6.17-1.2519.4.21el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img
For example, to change the memory entry on your hypervisor (dom0) to 256MB at boot time, edit the 'xen' line and append it with this entry: 'dom0_mem=256M'. This example is the grub.conf with the hypervisor's memory entry modified.
# boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grubs/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed =115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0,0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
    module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.13. Very Secure ftpd

vsftpd fornisce l'accesso necessario agli alberi d'installazione per i guest paravirtualizzati (per esempio ai repositori di Red Hat Enterprise Linux 5), o altri dati. Se non avete ancora installato vsftpd durante l'installazione del server, è possibile ottenere il pacchetto RPM dalla vostra 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 vostra directory corrente).
  1. To configure vsftpd, edit /etc/passwd using vipw and change the ftp user's home directory to the directory where you are going to keep the installation trees for your para-virtualized guests. An example entry for the FTP user would look like the following:
    ftp:x:14:50:FTP User:/xen/pub:/sbin/nologin
    
  2. Verificate 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
    
  3. Eseguite chkconfig --levels 345 vsftpd on per avviare vsftpd automaticamente per i runlevel 3, 4 e 5.
  4. Utilizzate il comando chkconfig --list vsftpd per verificare che vsftpd 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
    
  5. utilizzate service vsftpd start vsftpd per l'avvio del servizio vsftpd:
    $service vsftpd start vsftpd
    Starting vsftpd for vsftpd:                  [  OK  ]
    

32.14. Come configurare la persistenza LUN

This section covers how to implement LUN persistence in guests and on the host machine with and without multipath.
Implementazione persistenza LUN senza multipath
Se il vostro sistema non utilizza multipath allora usate udev per l'implementazione della persistenza LUN. Prima di implementare la persistenza LUN nel vostro sistema, assicuratevi 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, commentate la seguente riga:
# options=-b
Successivamente sostituitela 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 utilizzate 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 modificate 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"
Sostituite 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.

32.15. 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

32.16. Pulizia di vecchi file di configurazione Xen

Over time you will see a number of files accumulate in /var/lib/xen, the usually named vmlinuz.****** and initrd.******. These files are the initrd and vmlinuz files from virtual machines which either failed to boot or failed for some other reason. These files are temporary files extracted from virtual machine's boot disk during the start up sequence. These files should be automatically removed after the virtual machine is shut down cleanly. Then you can safely delete old and stale copies from this directory.

32.17. Come configurare un server VNC

Per configurare un server VNC usate l'applicazione Remote Desktop in Sistema, Preferenze. Alternativamente potete eseguire il comando vino-preferences.
Seguite le fasi di seguito indicate per una sessione dedicata al server VNC:
  1. Modificate il file ~/.vnc/xstartup per avviare la sessione di GNOME quando vncserver è stato avviato. Quando eseguite per la prima volta vncserver, vi verrà richiesto di inserire la password che desiderate usare per la vostra sessione VNC.
  2. Un esempio di file xstartup:
    #!/bin/sh
    # Uncomment the following two lines for normal desktop:
    # unset SESSION_MANAGER
    # exec /etc/X11/xinit/xinitrc
    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    #xsetroot -solid grey
    #vncconfig -iconic &
    #xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    #twm &
    if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    	eval `dbus-launch --sh-syntax –exit-with-session`
    	echo "D-BUS per-session daemon address is: \
    	$DBUS_SESSION_BUS_ADDRESS"
    fi
    exec  gnome-session
    

32.18. Come clonare i file di configurazione del guest

You can copy an existing configuration file to create an all new guest. You must modify the name parameter of the guests' configuration file. The new, unique name then appears in the hypervisor and is viewable by the management utilities. You must generate an all new UUID as well by using the uuidgen command. Then for the vif entries you must define a unique MAC address for each guest (if you are copying a guest configuration from an existing guest, you can create a script to handle it). For the xen bridge information, if you move an existing guest configuration file to a new host, you must update the xenbr entry to match your local networking configuration. For the Device entries, you must modify the entries in the 'disk=' section to point to the correct guest image.
You must also modify these system configuration settings on your guest. You must modify the HOSTNAME entry of the /etc/sysconfig/network file to match the new guest's hostname.
Modificate l'indirizzo HWADDR del file /etc/sysconfig/network-scripts/ifcfg-eth0 in modo da corrispondere all'output generato dal file ifconfig eth0, e se utilizzate gli indirizzi IP statici, modificate la voce IPADDR.

32.19. Duplicazione di un guest esistente e dei relativi file di configurazione

This section outlines copying an existing configuration file to create a new guest. There are key parameters in your guest's configuration file you must be aware of, and modify, to successfully duplicate a guest.
name
Il nome del vostro guest come conosciuto dall'hypevisor e mostrato nelle utilità di gestione. Questa voce dovrebbe essere unica sul vostro 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
  • The MAC address must define a unique MAC address for each guest. This is automatically done if the standard tools are used. If you are copying a guest configuration from an existing guest you can use the script Sezione 32.9, «Come generare un nuovo indirizzo MAC unico».
  • Se desiderate muovere o duplicare un file di configurazione esistente del guest sul nuovo host assicuratevi di modificare la voce xenbr, in modo che essa corrisponda alla vostra configurazione di networking locale (è possibile ottenere le informazioni del bridge usando il comando brctl show).
  • Voci del dispositivo, assicuratevi di modificare le voci presenti nella sezione disk=, in modo da indicare l'immagine del guest corretto.
Modificate ora le impostazioni della configurazione del sistema sul vostro guest:
/etc/sysconfig/network
Modify the HOSTNAME entry to the guest's new hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • Modificate l'indirizzo HWADDR con l'output di ifconfig eth0
  • Modificate la voce IPADDR se usate un indirizzo IP statico.

Capitolo 33. Creazione script libvirt personalizzati

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 32, Suggerimenti e trucchi is recommended reading for programmers thinking of writing new applications which use libvirt.

33.1. Come utilizzare i file di configurazione XML con virsh

virsh can handle XML configuration files. You may want to use this to your advantage for scripting large deployments with special options. You can add devices defined in an XML file to a running para-virtualized guest. For example, to add a ISO file as hdc to a running guest create an XML file:
# 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>
Run virsh attach-device to attach the ISO as hdc to a guest called "satellite" :
# virsh attach-device satellite satelliteiso.xml

Parte VIII. Troubleshooting

Introduzione al Troubleshooting ed alla soluzione 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 vostro 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 consultate le Note di rilascio di Red Hat Enterprise Linux per la vostra versione ed architettura hardware. Le Note di rilascio sono disponibili nella sezione di documentazione del sito web di Red Hat, www.redhat.com/docs/manuals/enterprise/.

Se non ci sono altre soluzioni...

Consultate il Red Hat Global Support Services (https://www.redhat.com/apps/support/). Il nostro staff è pronto ad assistervi nella risoluzione dei vostri problemi.

Indice

34. Risoluzione problematiche di Xen
34.1. Debugging e troubleshooting di Xen
34.2. Panoramica sui file di log
34.3. Descrizioni del file di log
34.4. Posizioni importanti della directory
34.5. Troubleshooting con i log
34.6. Troubleshooting con console seriale
34.7. Accesso alla console del guest para-virtualizzato
34.8. Accesso alla console del guest completamente virtualizzato
34.9. Problematiche comuni di Xen
34.10. Errori durante la creazione di un guest
34.11. Troubleshooting con console seriali
34.11.1. Output della console seriale per Xen
34.11.2. Output della console seriale di Xen dei guest paravirtualizzati
34.11.3. Output console seriali da guest completamente virtualizzati
34.12. File di configurazione di Xen
34.13. Interpretazione dei messaggi d'errore di Xen
34.14. Disposizione delle directory di log
35. Troubleshooting
35.1. Come identificare lo storage e le partizioni disponibili
35.2. Dopo aver riavviato i guest basati sul guest la console si arresta
35.3. I dispositivi ethernet virtualizzati non vengono rilevati dai tool di networking
35.4. Errori del dispositivo loop
35.5. Errore nella creazione del dominio causato da una memoria insufficiente
35.6. Errore immagine del kernel errata
35.7. Immagine del kernel errata - kernel non-PAE su di una piattaforma PAE
35.8. Il guest a 64 bit completamente virtualizzato non riesce ad avviarsi
35.9. Mancanza della voce localhost con conseguente errore di virt-manager
35.10. Errore del microcodice durante l'avvio del guest
35.11. Messaggi di avviso relativi a Python durante l'avvio di una macchina virtuale
35.12. Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS
35.13. Prestazioni del KVM networking
36. Troubleshoot dei driver paravirtualizzati Xen
36.1. Directory e file di log di Red Hat Enterprise Linux 5 Virtualization
36.2. I guest para-virtualizzati non vengono caricati sul sistema operativo guest di Red Hat Enterprise Linux 3
36.3. Visualizzazione di un messaggio di avvertimento su Red Hat Enterprise Linux 3 durante l'installazione dei driver para-virtualizzati.
36.4. Caricamento manuale dei driver para-virtualizzati
36.5. Verifica caricamento corretto dei driver para-virtualizzati
36.6. Il sistema presenta un throughput limitato con driver para-virtualizzati

Capitolo 34. Risoluzione problematiche di Xen

Questo capitolo affronta i concetti essenziali attraverso i quali effettuare il troubleshooting di Xen. Gli argomenti relativi al troubleshooting affrontati in questo capitolo includono:
  • tool per il troubleshooting di Linux e della virtualzzazione.
  • tecniche di troubleshooting per l'identificazione dei problemi.
  • Posizione dei file di log e spiegazione delle informazioni presenti nei log.
Questo capitolo conferisce al lettore la conoscenza necessaria per identificare i problemi relativi alle tecnologie di vertualizzazione. Per eseguire un processo di Troubleshooting è necessario avere una certa esperienza e pratica le quali sono difficili da sviluppare attraverso una semplice lettura di un testo. A tal proposito è consigliato sperimentare e testare la virtualizzazione su Red Hat Enterprise Linux in modo da sviluppare le vostre capacità di troubleshooting.
If you cannot find the answer in this document there may be an answer online from the virtualization community. Refer to Sezione A.1, «Risorse online» for a list of Linux virtualization websites.

34.1. Debugging e troubleshooting di Xen

Questa sezione riassume le applicazioni del System Administrator, le utilità per il networking, ed i tool per il debugging. È possibile implementare i suddetti tool standard per il System Administrator insieme ai log, per l'ausilio al processo di troubleshooting:
Comandi utili e applicazioni per il troubleshooting
xentop
xentop visualizza le informazioni real-time di un sistema host e dei domini del guest.
xm
Utilizzo di dmesg e log
  • vmstat
  • iostat
  • lsof
I comandi iostat, mpstat e sar sono tutti forniti dal pacchetto sysstat.
È possibile utilizzare i suddetti log e tool avanzati per il Debugging, per un ausilio al processo di troubleshooting:
  • XenOprofile
  • systemtap
  • crash
  • sysrq
  • sysrq t
  • sysrq w
Questi tool possono assistervi durante il processo di troubleshooting dei problemi di networking relativi alla virtualizzazione.
  • ifconfig
  • tcpdump
    The tcpdump command 'sniffs' network packets. tcpdump is useful for finding network abnormalities and problems with network authentication. There is a graphical version of tcpdump named wireshark.
  • brctl
    brctl è un tool per il networking che controlla e configura la configurazione del bridge di ethernet nel kernel linux di Virtualizzazione. È necessario avere un accesso root prima di eseguire i seguenti comandi:
    # brctl show 
    
    bridge-name    bridge-id          STP  enabled  interfaces  
    -----------------------------------------------------------------------------
    xenbr0             8000.feffffff       no        vif13.0
    xenbr1             8000.ffffefff       yes       pddummy0
    xenbr2             8000.ffffffef       no        vif0.0
    
    # brctl showmacs xenbr0
    
    port-no           mac-addr                  local?       aging timer
    
    1                 fe:ff:ff:ff:ff:           yes            0.00
    2                 fe:ff:ff:fe:ff:           yes            0.00
    
    
    # brctl showstp xenbr0
    xenbr0 
    bridge-id              8000.fefffffffff
    designated-root        8000.fefffffffff
    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
    
Di seguito sono elencati altri comandi utili per il troubleshooting della virtualizzazione su Red Hat Enterprise Linux 5. Tutte le utilità menzionate sono disponibili nei repositori del Server di Red Hat Enterprise Linux 5:
  • strace è un comando usato per seguire le chiamate del sistema e gli eventi ricevuti ed usati da un altro sistema.
  • vncviewer: connect to a VNC server running on your server or a virtual machine. Install vncviewer using the yum install vnc command.
  • vncserver: avvia un desktop remoto sul vostro server. Conferisce la possibilità di eseguire le interfacce utente grafiche, come virt-manager, tramite una sessione remota. Installate vncserver usando il comando yum install vnc-server.

34.2. Panoramica sui file di log

When deploying Red Hat Enterprise Linux 5 with Virtualization into your network infrastructure, the host's Virtualization software uses many specific directories for important configuration, log files, and other utilities. All the Xen logs files are standard ASCII files, and accessible with a text editor:
  • La directory di configurazione di Xen è /etc/xen/. Questa directory contiene il demone xend insieme ad altri file di configurazione della macchina virtuale. Anche i file per lo script di networking risiedono nella directory scripts.
  • Le informazioni del kernel di Xen sono archiviate nella directory /var/log/xen.
  • La directory predefinita per tutte le immagini basate sul file è /var/lib/libvirt/images.
  • Le informazioni del kernel di Xen sono conservate nella directory /proc/xen/.

34.3. Descrizioni del file di log

Xen presenta il demone xend ed il processo qemu-dm , le due utilità che scrivono i file di log multipli sulla directory /var/log/xen/:
  • xend.log è il file di log che contiene tutti i dati raccolti dal demone xend, sia se si tratta di un evento normale del sistema, che di un'azione inizializzata da un operatore. Tutte le operazioni della macchina virtuale (come la creazione, l'arresto e la distruzione ecc.) appaiono qui. xend.log rappresenta generalmente il luogo dove poter controllare inizialmente gli eventi o problemi relativi alle prestazioni. Contiene voci dettagliate e condizioni relative ai messaggi d'errore.
  • xend-debug.log è il file di log che contiene i record degli errori relativi ad un evento di xend, insieme ai sottosistemi di Virtualizzazione (come ad esempio framebuffer, script di Python, ecc).
  • xen-hotplug-log è il file di log che contiene i dati degli eventi hotplug. Se un dispositivo o uno script di rete non risultano online, l'evento viene visualizzato qui.
  • qemu-dm.[PID].log è il file di log creato dal processo qemu-dm per ogni guest completamente virtualizzato. Se utilizzate il suddetto file di log è necessario ripristinare il PID del processo qemu-dm in questione tramite l'utilizzo del comando ps, così facendo verranno esaminati gli argomenti per poter isolare il processo qemu-dm sulla macchina virtuale. Da notare che è necessario sostituire il simbolo [PID] con il processo qemu-dm del PID.
Se incontrate un errore con il Virtual Machine Manager, ricontrollate i dati generati nel file virt-manager.log che risiedono nella directory /.virt-manager . Da notare che ogni qualvota si riavvia il Virtual Machine Manager, esso sovrascriverà i contenuti del file di log esistente. Assicuratevi di eseguire il backup del file virt-manager.log , prima di riavviare il Virtual Machine manager dopo aver incontrato un errore.

34.4. Posizioni importanti della directory

Sono disponibili una serie di utilità e file di log in grado di assistervi durante la verifica degli errori ed il troubleshooting con Xen:
  • Le immagini del guest virtualizzato risiedono nella directory /var/lib/libvirt/images.
  • Quando riavviate il demone xend, verrà aggiornato xend-database il quale risiede nella directory /var/lib/xen/xend-db.
  • I dump della macchina virtuale (da voi eseguiti con il comando xm dump-core), risiedono nella directory /var/lib/xen/dumps.
  • La directory /etc/xen contiene i file di configurazione da voi utilizzati per gestire le risorse del sistema. Il file di configurazione del demone xend è /etc/xen/xend-config.sxp. È possibile modificare questo file per implementare le modifiche relative a tutto il sistema e per la configurazione del networking. Tuttavia la modifica manuale dei file in /etc/xen/ non è consigliata.
  • Le cartelle proc  rappresentano un'altra risorsa usata per raccogliere informazioni relative al sistema. Le suddette voci risiedono nella directory /proc/xen:
/proc/xen/capabilities
/proc/xen/balloon
/proc/xen/xenbus/

34.5. Troubleshooting con i log

When encountering installation issues with Xen, refer to the host system's two logs to assist with troubleshooting. The xend.log file contains the same basic information as when you run the xm log command. This log is found in the /var/log/ directory. Here is an example log entry for when you create a domain running a kernel:
[2006-12-27 02:23:02 xend] ERROR (SrvBase: 163) op=create: Error creating domain: (0, 'Error')
Traceback (most recent call list)
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvBase.py" line 107 in_perform val = op_method (op,req)
File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py line 71 in op_create
raise XendError ("Error creating domain: " + str(ex))
XendError: Error creating domain: (0, 'Error')
L'altro file di log, xend-debug.log , è molto utile per gli amministratori di sistema poichè esso contiene informazioni ancora più dettagliate rispetto a xend.log . Di seguito viene riportato lo stesso error data relativo allo stesso problema di creazione del dominio del kernel:
ERROR: Will only load images built for Xen v3.0
ERROR: Actually saw: GUEST_OS=netbsd, GUEST_VER=2.0, XEN_VER=2.0; LOADER=generic, BSD_SYMTAB'
ERROR: Error constructing guest OS
Se desiderate contattare l'assistenza clienti, ed in particolare lo staff di supporto tecnico, vi preghiamo di includere una copia di entrambi i file di log.

34.6. Troubleshooting con console seriale

The serial console is helpful in troubleshooting difficult problems. If the Virtualization kernel crashes and the hypervisor generates an error, there is no way to track the error on a local host. However, the serial console allows you to capture it on a remote host. You must configure the host to output data to the serial console. Then you must configure the remote host to capture the data. To do this, you must modify these options in the grub.conf file to enable a 38400-bps serial console on com1 /dev/ttyS0:
title Red Hat Enterprise Linux (2.6.18-8.2080_xen0)
	root (hd0,2)
	kernel /xen.gz-2.6.18-8.el5 com1=38400,8n1 
	module /vmlinuz-2.618-8.el5xen ro root=LABEL=/rhgb quiet console=xvc console=tty xencons=xvc 	
	module /initrd-2.6.18-8.el5xen.img
sync_console è in grado di assistervi nella determinazione del problema che causa la sospensione con l'output dell'asynchronous hypervisor console. "pnpacpi=off" risolve il problema che interrompe l'input sulla console seriale. I parametri "console=ttyS0" e "console=tty" indicano che gli errori del kernel vengono registrati sia con la console VGA normale che con la console seriale. Successivamente potrete installare ed impostare ttywatch, in modo da catturare i dati sull'host remoto collegato tramite un cavo null-modem standard. Per esempio, sarà possibile digitare sull'host remoto:

troubleshooting sulla console seriale Itanium

To access the hypervisor via a serial console on the Itanium® architecture you must enable the console in ELILO. For more information on configuring ELILO, refer to Capitolo 29, Configurazione di ELILO.
ttywatch --name myhost --port /dev/ttyS0
Questo comando esegue il pipe dell'output da /dev/ttyS0 nel file /var/log/ttywatch/myhost.log .

34.7. Accesso alla console del guest para-virtualizzato

Para-virtualized guest operating systems automatically has a virtual text console configured to transmit data to the host operating system. Connect to a guest's virtual console with the following command:
# virsh console [guest name, ID or UUID]
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.8. Accesso alla console del guest completamente virtualizzato

Fully virtualized guest operating systems automatically has a text console configured for use, but the difference is the kernel guest is not configured. To enable the guest virtual serial console to work with the Full Virtualized guest, you must modify the guest's grub.conf file, and include the 'console =ttyS0 console=tty0' parameter. This ensures that the kernel messages are sent to the virtual serial console (and the normal graphical console). To use the guest's serial console, you must edit the libvirt configuration file configuration file. On the host, access the serial console with the following command:
# virsh console
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.9. Problematiche comuni di Xen

Quando cercherete di avviare il servizio xend non accadrà nulla. Digitate virsh list e ricevete quanto segue:
Error: Error connecting to xend: Connection refused. Is xend running?
A questo punto provate ad eseguire xend start manualmente, ma ricevete più errori:
Error: Could not obtain handle on privileged command interfaces (2 = No such file or directory)
Traceback (most recent call last:)
File "/usr/sbin/xend/", line 33 in ?
from xen.xend.server. import SrvDaemon
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py" , line 26 in ?
from xen.xend import XendDomain
File "/usr//lib/python2.4/site-packages/xen/xend/XendDomain.py" , line 33, in ?
		
from xen.xend import XendDomainInfo
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line37, in ?
import images
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line30, in ?
xc = xen.lowlevel.xc.xc ()
RuntimeError: (2, 'No such file or directory' )
Molto probabilmente avete eseguito il riavvio del vostro host in un kernel diverso dal kernel kernel-xen. Per correggere questo problema è necessario selezionare il kernel kernel-xen al momento dell'avvio (oppure impostare il kernel kernel-xen come default all'interno del vostro file grub.conf).

34.10. Errori durante la creazione di un guest

Durante la creazione di un guest è possibile ricevere un messaggio d'errore "Invalid argument". Tale messaggio generalmente indica che l'immagine del kernel che state cercando di avviare, è incompatibile con l'hypervisor. Un esempio di tale comportamento si verifica se cercate di eseguire un kernel non-PAE FC5 su di un hypervisor FC6 solo PAE.
Se eseguite yum update e ricevete un nuovo kernel, il kernel predefinito grub.conf si smista sul kernel bare-metal invece di un kernel di Virtualizzazione.
To correct this problem you must modify the default kernel RPM that resides in the /etc/sysconfig/kernel/ directory. You must ensure that kernel-xen parameter is set as the default option in your grub.conf file.

34.11. Troubleshooting con console seriali

I kernel di Linux sono in grado di eseguire un output delle informazioni per le porte seriali. Questo è utile per il debugging dei kernel panic e delle problematiche hardware con dispositivi video o server headless. Le sottosezioni qui presenti riportano le fasi necessarie per l'impostazione degli output della console seriale per le macchine che eseguono i kernel di virtualizzazione di Red Hat Enterprise Linux e dei relativi guest virtualizzati.

34.11.1. Output della console seriale per Xen

By default, the serial console for the Xen hypervisor is disabled and no data is output from serial ports.
Per ricevere le informazioni relative al kernel su di una porta seriale modificare il file /boot/grub/grub.conf impostando i parametri appropriati del dispositivo seriale.
Se la console seriale è situata su com1, modificare /boot/grub/grub.conf inserendo le righe com1=115200,8n1, console=tty0 e console=ttyS0,115200 dove indicato.
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com1=115200,8n1
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
				console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Se la console seriale è situata su com2, modificare /boot/grub/grub.conf inserendo le righe com2=115200,8n1 console=com2L, console=tty0 e console=ttyS0,115200 dove indicato.
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com2=115200,8n1 console=com2L
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
	console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Salvate le modifiche e riavviate l'host. L'hypervisor esegue l'output di dati seriali sul sistema seriale (com1, com2 e così via) selezionato nelle fasi precedenti.
Da notare che nell'esempio dove si utilizza la porta com2 viene usato il parametro console=ttyS0 sulla riga vmlinuz. L'utilizzo di ogni porta come console=ttyS0 non è un comportamento Linux standard ed è specifico all'ambiente Xen.

34.11.2. Output della console seriale di Xen dei guest paravirtualizzati

Questa sezione descrive come configurare una console seriale virtualizzata per i guest paravirtualizzati di Red Hat Enterprise Linux.
L'output della console seriale dei guest paravirtualizzati può essere ricevuto usando "virsh console" o la finestra "Console Seriale" di virt-manager. Impostate la console seriale virtuale usando questa procedura:
  1. Eseguite il log in sul vostro guest paravirtualizzato.
  2. Modificate /boot/grub/grub.conf nel modo seguente:
    Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
    	root (hd0, 0) kernel /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=xvc0 
    	initrd /boot/initrd-2.6.18-92.el5xen.img
    
  3. Riavviate il guest paravirtualizzato.
A questo punto dovreste ottenere alcuni messaggi del kernel sulla "Console seriale" e "virsh console" di virt-manager.
Registrazione output della console seriale del dominio paravirtualizzato
Il demone (xend) può essere configurato per registrare l'output dalle console seriali dei guest paravirtualizzati.
Per configurare xend modificate /etc/sysconfig/xend. Cambiate la voce:
# Log all guest console output (cf xm console)
#XENCONSOLED_LOG_GUESTS=no
to:
# Log all guest console output (cf xm console)
XENCONSOLED_LOG_GUESTS=yes
Riavviate l'host in modo da attivare la registrazione dell'output della console seriale del guest.
I log dalle console seriali del guest sono conservati nel file /var/log/xen/console.

34.11.3. Output console seriali da guest completamente virtualizzati

Questa sezione contiene le informazioni necessarie per abilitare un output della console seriale per guest completamente virtualizzati.
È possibile visualizzare gli output di console seriali di guest completamente virtualizzati tramite il comando "virsh console".
Fate attenzione alle limitazioni delle console seriali del guest completamente virtualizzato. Le attuali limitazioni includono:
  • registrazione dell'output con xend non disponibile.
  • l'output dei dati può essere interrotto o confuso.
La porta seriale è chiamata ttyS0 su Linux o COM1 su Windows.
È necessario configurare il sistema operativo virtualizzato in modo da eseguire un output delle informazioni per la porta seriale virtuale.
Per l'output delle informazioni del kernel da un guest Linux completamente virtualizzato in un dominio, modificare il file /boot/grub/grub.conf inserendo la riga "console=tty0 console=ttys0,115200".
title Red Hat Enterprise Linux Server (2.6.18-92.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/volgroup00/logvol00
	console=tty0 console=ttys0,115200
	initrd /initrd-2.6.18-92.el5.img
Riavviare il guest.
Visualizzate i messaggi della console seriale tramite il comando "virsh console".

Nota Bene

I messaggi della console seriale dei domini completamente virtualizzati non sono registrati in /var/log/xen/console poichè essi sono per i guest paravirtualizzati.

34.12. File di configurazione di Xen

When you create guests with the virt-manager or virt-install tools on Red Hat Enterprise Linux 5, the guests configuration files are created automatically in the /etc/xen directory.

Warning

Red Hat advises users not to manually edit Xen configuration files. Xen configuration files have limited error checking and many unsupported variables. Editing Xen configuration files may damage your guests, make guests unbootable or cause data loss.
The example below is a typical a para-virtualized guest configuration file:
name = "rhel5vm01"
memory = "2048"
disk = ['tap:aio:/var/lib/libvirt/images/rhel5vm01.dsk,xvda,w',]
vif = ["type=ieomu, mac=00:16:3e:09:f0:12 bridge=xenbr0', 
"type=ieomu, mac=00:16:3e:09:f0:13 ]
vnc = 1
vncunused = 1
uuid = "302bd9ce-4f60-fc67-9e40-7a77d9b4e1ed"
bootloader = "/usr/bin/pygrub"
vcpus=2
on_reboot = "restart"
on_crash = "restart"
Da notare che serial="pty" rappresenta il valore di default per il file di configurazione. Questo è l'esempio di file di configurazione per un guest completamente virtualizzato:
name = "rhel5u5-86_64"
builder = "hvm"
memory = 500
disk = ['/var/lib/libvirt/images/rhel5u5-x86_64.dsk.hda,w']
vif = [ 'type=ioemu, mac=00:16:3e:09:f0:12, bridge=xenbr0', 'type=ieomu, mac=00:16:3e:09:f0:13, bridge=xenbr1']
uuid = "b10372f9-91d7-ao5f-12ff-372100c99af5'
device_model = "/usr/lib64/xen/bin/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader/"
vnc = 1
vncunused = 1
apic = 1
acpi = 1
pae = 1
vcpus =1
serial ="pty" # enable serial console
on_boot = 'restart'

File di configurazione di Xen

La modifica dei file di configurazione di Xen non è supportata. Utilizzare virsh dumpxml e virsh create (o virsh edit) per modificare i file di configurazione di libvirt (basati su xml), i quali sono in grado di controllare la presenza di errori e svolgere controlli sulla sicurezza.

34.13. Interpretazione dei messaggi d'errore di Xen

Se recivete il seguente errore:
failed domain creation due to memory shortage, unable to balloon domain0
Un dominio può fallire se non è disponibile sufficiente RAM. Domain0 non è in grado di diminuire il suo valore in modo tale da fornire spazio sufficiente per il guest appena creato. Per questo errore potete controllare il file xend.log:
[2006-12-21] 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 Kib free; 0 to scrub; need 1048576; retries: 20
[2006-12-21] 20:33:31 xend. XendDomainInfo 3198] ERROR (XendDomainInfo: 202
Domain construction failed
Potete controllare la quantità di memoria utilizzata da domain0 usando il comando xm list domain0. Se dom0 non viene diminuito, è possibile utilizzare il comando virsh setmem dom0 NewMemSize per controllare la memoria.
Se recivete il seguente errore:
wrong kernel image: non-PAE kernel on a PAE
Questo messaggio indica il tentativo di eseguire una immagine kernel del guest non supportata sul vostro hypervisor. Ciò si può verificare durante il tentativo di avvio di un kernel del guest paravirtualizzato non-PAE su di un host di Red Hat Enterprise Linux 5. Il pacchetto kernel-xen di Red Hat supporta solo i kernel del guest con architetture PAE e a 64bit.
Digitare questo comando:
# xm create -c va-base

Using config file "va-base"
Error: (22, 'invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERRORs
(XendDomainInfo:202) Domain construction failed

Traceback (most recent call last)
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 195 in create vm.initDomain()
File " /usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1363 in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1449]
XendDlomainInfo.destroy: domain=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1457]
XendDlomainInfo.destroy:Domain(1)
Se desiderate eseguire un kernel non-PAE a 32-bit, avrete bisogno di eseguire il vostro guest come macchina virtuale completamente virtualizzata. Per guest paravirtualizzati, se desiderate eseguire un guest a 32bit PAE, allora è necessario essere in possesso di un hypervisor a 32bit PAE. Per guest paravirtualizzati,per eseguire un guest PAE a 64 bit allora sarà necessario avere un hypervisor PAE a 64 bit. Per guest full virtualizzation è necessario eseguire un guest a 64 bit con un hypervisor a 64 bit. L'hypervisor a 32bit PAE presente con Red Hat Enterprise Linux 5 i686, supporta solo sistemi operativi completamente virtualizzati a 32 bit e paravirtualizzati a 32bit PAE. L'hypervisor a 64bit supporta solo guest paravirtualizzati a 64 bit.
Ciò accade quando il guest HVM completamente virtualizzato viene spostato su di un sistema Red Hat Enterprise Linux 5. Il vostro guest potrebbe non eseguire l'avvio, a questo punto visualizzerete un errore sulla schermata della console. Controllate la voce PAE sul vostro file di configurazione, ed assicuratevi che pae sia uguale a 1 'pae=1'. È consigliato utilizzare una distribuzione a 32bit.
Se recivete il seguente errore:
Unable to open a connection to the Xen hypervisor or daemon
Ciò accade quando l'applicazione virt-manager non può essere lanciata. Questo errore si verifica quando non vi è alcuna voce localhost nel file di configurazione /etc/hosts . Controllate il file e verificate se la voce localhost è stata abilitata. Di seguito viene riportato un esempio di voce locahost incorretta:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
Ecco un esempio di una voce localhost corretta:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
localhost.localdomain. localhost
Se ricevete il seguente errore (in xen-xend.logfile ):
Bridge xenbr1 does not exist!
This happens when the guest's bridge is incorrectly configured and this forces the Xen hotplug scripts to timeout. If you move configuration files between hosts, you must ensure that you update the guest configuration files to reflect network topology and configuration modifications. When you attempt to start a guest that has an incorrect or non-existent Xen bridge configuration, you will receive the following errors:
# xm create mySQL01

Using config file " mySQL01"
Going to boot Red Hat Enterprise Linux Server (2.6.18.-1.2747 .el5xen)
kernel: /vmlinuz-2.6.18-12747.el5xen
initrd: /initrd-2.6.18-1.2747.el5xen.img
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
In aggiunta xend.log visualizza i seguenti errori:
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:143) Waiting for devices vif
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:149) Waiting for 0
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status

[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=2
[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(2)
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status
To resolve this problem, open the guest's configuration file found in the /etc/xen directory. For example, editing the guest mySQL01
# vim /etc/xen/mySQL01
Locate the vif entry. Assuming you are using xenbr0 as the default bridge, the proper entry should resemble the following:
# vif = ['mac=00:16:3e:49:1d:11, bridge=xenbr0',]
Se ricevete i seguenti errori python:
# xm shutdown win2k3xen12
# xm create win2k3xen12

Using config file "win2k3xen12".

/usr/lib64/python2.4/site-packages/xenxm/opts.py:520: Deprecation Warning:
Non ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details

execfile (defconfig, globs, locs,)
Error: invalid syntax 9win2k3xen12, line1)
In caso di presenza di un file di configurazione invalido (o errato) Python genererà questi tipi di messaggi. Per risolvere il suddetto problema, è necessario modificare il file di configurazione errato, oppure generarne uno nuovo.

34.14. Disposizione delle directory di log

La struttura di base delle directory in un ambiente Red Hat Enterprise Linux 5 Virtualization è la seguente:
La directory /etc/xen/ contiene
  • i file di configurazione usati dal demone xend
  • la directory scripts la quale contiene gli script per il Virtualization networking.
/var/log/xen/
  • directory che contiene tutti i file di log relativi a Xen.
/var/lib/libvirt/images/
  • La directory predefinita per i file d'immagine della macchina virtuale.
  • Se state usando una directory diversa per le vostre immagini della macchina virtuale, assicuratevi di aggiungere la directory alla vostra policy SELinux e rietichettatela prima di inziare l'installazione.
/proc/xen/
  • Informazioni relative a Xen nel file system /proc.

Capitolo 35. Troubleshooting

Questo capitolo affronta i problemi e le soluzioni comuni della virtualizzazione di Red Hat Enterprise Linux.

35.1. Come identificare lo storage e le partizioni disponibili

Verificate di aver caricato il driver a blocchi e che i dispositivi e le partizioni siano disponibili al guest. Per fare questo eseguite "cat /proc/partitions" come di seguito riportato.
# cat /proc/partitions
major minor  #blocks   name 
 202    16  104857600  xvdb
   3     0    8175688  hda

35.2. Dopo aver riavviato i guest basati sul guest la console si arresta

Occasionally, a Xen guest's console freezes when the guest boots. The console still displays messages but the user cannot log in.
Per corregere questa problematica aggiungere la seguente riga al file /etc/inittab:
1:12345:respawn:/sbin/mingetty xvc0
Dopo aver salvato il file eseguite il riavvio. La sessione della console dovrebbe ora essere interattiva come previsto.

35.3. I dispositivi ethernet virtualizzati non vengono rilevati dai tool di networking

I tool di networking non sono in grado di identificare la scheda di networking Xen Virtual Ethernet all'interno del sistema operativo guest. Per effettuare una verifica eseguire quanto di seguito riportato (per Red Hat Enterprise Linux 4 e Red Hat Enterprise Linux 5):
cat /etc/modprobe.conf
O (per Red Hat Enterprise Linux 3):
cat /etc/modules.conf
L'output dovrebbe contenere la riga ed una stringa simile per ogni interfaccia aggiuntiva.
alias eth0 xen-vnif
Per correggere questo problema sarà necessario aggiungere le righe relative all'alias (per esempio alias eth0 xen-vnif) per ogni interfaccia paravirtualizzata per il guest.

35.4. Errori del dispositivo loop

Se utilizzate le immagini del guest basate sul file, allora potrebbe esser necessario aumentare il numero di dispositivi loop configurati. La configurazione predefinita permette fino ad un massimo di otto dispositivi loop attivi. Se avete bisogno di un numero superiore a otto guest basati sul file o dispositivi loop, il numero di dispositivi loop configurati potrà essere modificato in /etc/modprobe.conf. Modificate /etc/modprobe.conf ed aggiungete 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 vostro sistema. Per impostare i loop device backed guest per un guest paravirtualizzato usate i comandi phy: block device o tap:aio. Per implementare i loop device backed guest per un sistema completamente virtualizzato utilizzate i comandi phy: device o file: file .

35.5. Errore nella creazione del dominio causato da una memoria insufficiente

This may cause a domain to fail to start. The reason for this is there is not enough memory available or dom0 has not ballooned down enough to provide space for a recently created or started guest. In your /var/log/xen/xend.log, an example error message indicating this has occurred:
[2006-11-21 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 KiB free;
	0 to scrub; need 1048576; retries: 20.
[2006-11-21 20:33:52 xend.XendDomainInfo 3198] ERROR (XendDomainInfo:202) Domain construction failed
You can verify the amount of memory currently used by dom0 with the command “xm list Domain-0”. If dom0 is not ballooned down you can use the command “xm mem-set Domain-0 NewMemSize” where NewMemSize should be a smaller value.

35.6. Errore immagine del kernel errata

I guest paravirtualizzati non possono usare il kernel kernel-xen. Utilizzare solo il kernel standard per guest paravirtualizzati.
Attempting to boot any kernel other than the Xen kernel as a para-virtualized guest results in the following error message:
# xm create testVM
Using config file "./testVM".
Going to boot Red Hat Enterprise Linux Server (2.6.18-1.2839.el5)
kernel: /vmlinuz-2.6.18-1.2839.el5
initrd: /initrd-2.6.18-1.2839.el5.img
Error: (22, 'Invalid argument')
In the above error you can see that the kernel line shows that the system is trying to boot a non kernel-xen kernel. The correct entry in the example is ”kernel: /vmlinuz-2.6.18-1.2839.el5xen”.
La soluzione a tale problema è quella di verificare l'installazione di un kernel-xen nel vostro guest il quale dovrebbe essere il kernel predefinito per il processo d'avvio nel vostro file di configurazione /etc/grub.conf.
Se avete installato kernel-xen sarà possibile avviare il guest:
xm create -c GuestName
Where GuestName is the name of the guest. The previous command will present you with the GRUB boot loader screen and allow you to select the kernel to boot. You will have to choose the kernel-xen kernel to boot. Once the guest has completed the boot process you can log into the guest and edit /etc/grub.conf to change the default boot kernel to your kernel-xen. Simply change the line “default=X” (where X is a number starting at '0') to correspond to the entry with your kernel-xen line. The numbering starts at '0' so if your kernel-xen entry is the second entry you would enter '1' as the default,for example “default=1”.

35.7. Immagine del kernel errata - kernel non-PAE su di una piattaforma PAE

If you to boot a non-PAE kernel, para-virtualized guest the error message below will display. It indicates you are trying to run a guest kernel on your Hypervisor which at this time is not supported. The Xen hypervisor presently only supports PAE and 64 bit para-virtualized guest kernels.
# xm create -c va-base 
Using config file "va-base".
Error: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERROR (XendDomainInfo:202) Domain construction failed
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 195, in  create vm.initDomain()
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 1363, in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(1)
If you need to run a 32 bit or non-PAE kernel you will need to run your guest as a fully-virtualized virtual machine. The rules for hypervisor compatibility are:
  • i guest para-virtualizzati devono corrispondere al tipo di architettura del vostro hypervisor. Per eseguire un guest PAE a 32 bit è necessario avere un hypervisor PAE a 32 bit.
  • per eseguire un guest para-virtualizzato a 64 bit il vostro hypervisor deve avere una versione a 64 bit.
  • per i guest completamente virtualizzati il vostro hypervisor deve essere a 32 o 64 bit per guest a 32 bit. È possibile eseguire un guest a 32 bit (PAE e non-PAE) su di un hypervisor a 32 o 64 bit.
  • per eseguire un guest completamente virtualizzato a 64 bit anche il vostro hypervisor dovrà essere a 64 bit.

35.8. Il guest a 64 bit completamente virtualizzato non riesce ad avviarsi

If you have moved the configuration file to a Red Hat Enterprise Linux 5 causing your fully-virtualized guest to fail to boot and present the error, Your CPU does not support long mode. Use a 32 bit distribution. This problem is caused by a missing or incorrect pae setting. Ensure you have an entry “pae=1” in your guest's configuration file.

35.9. Mancanza della voce localhost con conseguente errore di virt-manager

L'applicazione virt-manager potrebbe non lanciare e visualizzare un errore del tipo “Unable to open a connection to the Xen hypervisor/daemon”. Tale comportamento è generalmente dovuto a causa di una voce localhost mancante all'interno del file /etc/hosts. Verificate la presenza della voce localhost, e se mancante su /etc/hosts, inserite una nuova voce per localhost. Un /etc/hosts incorretto dovrebbe somigliare al seguente:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
La voce corretta dovrebbe somigliare alla seguente:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
localhost.localdomain localhost

35.10. Errore del microcodice durante l'avvio del guest

During the boot phase of your virtual machine you may see an error message similar to:
Applying Intel CPU microcode update: FATAL: Module microcode not found.
ERROR: Module microcode does not exist in /proc/modules
As the virtual machine is running on virtual CPUs there is no point updating the microcode. Disabling the microcode update for your virtual machines will stop this error:
/sbin/service microcode_ctl stop
/sbin/chkconfig --del microcode_ctl

35.11. Messaggi di avviso relativi a Python durante l'avvio di una macchina virtuale

Talvolta Python genera alcuni messaggi simili a quello di seguito riportato, i suddetti messaggi vengono spesso generati a causa di un file di configurazione invalido o incorretto. Un file di configurazione che contiene caratteri non-ascii causerà tali errori. Per poter evitare questo tipo di problema correggete il file di configurazione in questione o generatene uno nuovo.
Altresì, la presenza di un file di configurazione non corretto all'interno della vostra directory di lavoro corrente potrebbe causare la generazione di questi tipi di messaggi. “xm create” andrà alla ricerca di un file di configurazione prima nella directory corrente e successivamente in /etc/xen
# xm shutdown win2k3xen12
# xm create win2k3xen12
Using config file "win2k3xen12".
/usr/lib64/python2.4/site-packages/xen/xm/opts.py:520: DeprecationWarning:
Non-ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
execfile(defconfig, globs, locs)
Error: invalid syntax (win2k3xen12, line 1)

35.12. 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, se disabilitate, all'interno del vostro BIOS.
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.
Per AMD-V, le estensioni di virtualizzazione non possono essere disabilitate nel BIOS.
The virtualization extensions are sometimes disabled in BIOS, usually by laptop manufacturers. Refer to Sezione 35.12, «Come abilitare le estensioni hardware per la virtualizzazione VT e AMD-V nel BIOS» for instructions on enabling disabled virtualization extensions.
Come prima cosa verificate 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 35.1. Come abilitare le estensioni di virtualizzazione nel BIOS
  1. Reboot the computer and open the system's BIOS menu. This can usually be done by pressing the delete key, the F1 key or Alt and F4 keys depending on the system.
  2. Select Restore Defaults or Restore Optimized Defaults, and then select Save & Exit.
  3. Spegnete la macchina e cessatene l'alimentazione.
  4. Enabling the virtualization extensions in BIOS

    Note: BIOS steps

    Many of the steps below may vary depending on your motherboard, processor type, chipset and OEM. Refer to your system's accompanying documentation for the correct information on configuring your system.
    1. Power on the machine and open the BIOS (as per Step 1).
    2. Open the Processor submenu The processor settings menu may be hidden in the Chipset, Advanced CPU Configuration or Northbridge.
    3. Enable Intel Virtualization Technology (also known as Intel VT) or AMD-V depending on the brand of the processor. The virtualization extensions may be labeled Virtualization Extensions, Vanderpool or various other names depending on the OEM and system BIOS.
    4. Enable Intel VTd or AMD IOMMU, if the options are available. Intel VTd and AMD IOMMU are used for PCI passthrough.
    5. Select Save & Exit.
  5. Spegnete la macchina e cessatene l'alimentazione.
  6. Eseguite 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.

35.13. Prestazioni del KVM networking

Per impostazione predefinita viene assegnato alle macchine virtuali un Realtek 8139 (rtl8139) NIC (network interface controller) virtuale.
Il rtl8139 virtualized NIC funziona bene nella maggior parte degli ambienti. Tuttavia questo dispositivo può subire una degradazione delle prestazioni su alcune reti, per esempio una rete ethernet di 10 Gigabit.
Una risoluzione a questo problema è rappresentata dall'implementazione di un diverso tipo di NIC virtualizzato. Per esempio Intel PRO/1000 (e1000) o virtio (il driver di rete paravirtualizzato).
Per selezionare il driver e1000:
  1. Arrestate il sistema operativo guest.
  2. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name):
    # virsh edit GUEST
    Il comando virsh edit utilizza la variabile della shell $EDITOR per determinare l'editor da utilizzare.
  3. Andate alla ricerca della sezione dell'interfaccia di rete della configurazione. Questa sezione assomiglia a quanto di seguito riportato:
    <interface type='network'>
      [output truncated]
      <model type='rtl8139' />
    </interface>
    
  4. Change the type attribute of the model element from 'rtl8139' to 'e1000'. This will change the driver from the rtl8139 driver to the e1000 driver.
    <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  5. Salvate le modifiche ed uscite dall'editor di testo
  6. Riavviate il sistema operativo guest.
Alternativamente installate nuovi guest virtualizzati con un diverso driver di rete. Tale operazione potrebbe essere necessaria se avete problemi durante l'installazione dei guest attraverso un collegamento di rete. Questo metodo ha bisogno di almeno una macchina virtuale precedentemente creata (possibilmente installata da un CD o DVD) da usare come modelli di riferimento.
  1. Create un modello di riferimento XML da una macchina virtuale esistente:
    # virsh dumpxml GUEST > /tmp/guest.xml
    
  2. Copiate ed incollate il file XML ed aggiornate i campi unici: nome della macchina virtuale, UUID, immagine del disco, indirizzo MAC, e qualsiasi altro parametro unico. È possibile cancellare le righe relative all'indirizzo MAC e dell'UUID con virsh che genererà un indirizzo MAC e UUID.
    # cp /tmp/guest.xml /tmp/new-guest.xml
    # vi /tmp/new-guest.xml
    
    Aggiungere la riga del modello nella sezione dell'interfaccia di rete:
     <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  3. Create la nuova macchina virtuale:
    # virsh define /tmp/new-guest.xml
    # virsh start new-guest
    
Le prestazioni della rete dovrebbero essere migliori con il driver e1000 o virtio. (BZ#517181)

Capitolo 36. Troubleshoot dei driver paravirtualizzati Xen

Questo capitolo affronta le problematiche che si possono incontrare con host Xen e guest Red Hat Enterprise Linux completamente virtualizzati utilizzando i driver paravirtualizzati.

36.1. Directory e file di log di Red Hat Enterprise Linux 5 Virtualization

/var/log/xen/
directory che contiene tutti i file di log generata dal demone xend e dal processo qemu-dm.
xend.log
  • Questo file di log viene usato da xend per registrare qualsiasi evento generato da eventi precedenti normali del sistema o da eventi iniziati dall'operatore.
  • Operazioni della macchina virtuale come ad esempio, crea, arresta e distruggi sono tutte registrate su questo file di log.
  • Generalmente questo file di log rappresenta il primo luogo da controllare al verificarsi di un problema. In molti casi sarete in grado di identificare la causa principale attraverso una scansione del file di log e delle voci presenti, prima di analizzare il messaggio di errore vero e proprio.
xend-debug.log
  • Registra gli eventi d'errore da xend e dai suoi sottosistemi (come ad esempio gli script Python e framebuffer.)
xen-hotplug.log
  • Registra gli eventi da eventi hotplug.
  • Le notifiche di eventi dei dispositivi non disponibili online o dei bridge di rete non disponibili online, verranno registrati in questo file
qemu-dm.PID.log
  • Questo file viene creato dal processo qemu-dm il quale viene avviato per ogni guest completamente virtualizzato.
  • Il PID viene sostituito con il PID del processo relativo a qemu-dm
  • È possibile ripristinare il PID per un dato processo qemu-dm utilizzando il comando ps. Controllando gli argomenti del processo sarà possibile identificare la macchina virtuale alla quale appartiene il processo qemu-dm.
If you are troubleshooting a problem with the virt-manager application you can also review the logfile generated by it. The logfile for virt-manager will be in a directory called .virt-manager in the user's home directory whom ran virt-manager. This directory will usually be ~/.virt-manager/virt-manager.

Nota

Il file di log viene sovrascritto ogni qualvolta avvierete virt-manager. Se state eseguendo la risoluzione di un problema con virt-manager, assicuratevi di salvare il file di log prima di riavviare virt-manager dopo il verificarsi di un errore.
/var/lib/libvirt/images/
la directory standard per le immagini guest basate sul file.
/var/lib/xen/xend-db/
directory che contiene il database xend generato ogni qualvolta il demone viene riavviato.
/etc/xen/
Conserva un certo numero di file di configurazione per l'hypervisor Xen.
  • /etc/xen/xend-config.sxp è il file di configurazione principale per il demone xend. xend-config.sxp viene usato per abilitare/disabilitare la migrazione ed altre funzioni non configurate da libvirt. Usare i tool di libvirt per tutte le altre funzioni.
/var/lib/xen/dump/
Conserva i dump generati dalle macchine virtuali o durante l'utilizzo del comando xm dump-core.
/proc/xen/
Conserva le informazioni relative a xen-kernel nei seguenti file:
  • /proc/xen/capabilities
  • /proc/xen/privcmd
  • /proc/xen/balloon
  • /proc/xen/xenbus
  • /proc/xen/xsd_port
  • /proc/xen/xsd_kva

36.2. I guest para-virtualizzati non vengono caricati sul sistema operativo guest di Red Hat Enterprise Linux 3

Red Hat Enterprise Linux 3 utilizza gli RPM del kernel di architetture specifiche, e per questo motivo i driver para-virtualizzati potrebbero non essere caricati se l'RPM del driver para-virtualizzato non corrisponde all'architettura installata del kernel.
When the para-virtualized driver modules are inserted, a long list of unresolved modules will be displayed. A shortened excerpt of the error can be seen below.
# insmod xen-platform-pci.o 
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
xen-platform-pci.o: unresolved symbol __ioremap_R9eac042a
xen-platform-pci.o: unresolved symbol flush_signals_R50973be2
xen-platform-pci.o: unresolved symbol pci_read_config_byte_R0e425a9e
xen-platform-pci.o: unresolved symbol __get_free_pages_R9016dd82
[...]
The solution is to use the correct RPM package for your hardware architecture for the para-virtualized drivers.

36.3. Visualizzazione di un messaggio di avvertimento su Red Hat Enterprise Linux 3 durante l'installazione dei driver para-virtualizzati.

L'installazione dei driver para-virtualizzati su di un kernel Red Hat Enterprise Linux 3 precedente alla versione 2.4.21-52, potrebbe generare un messaggio d'errore il quale indica che i moduli sono stati compilati con una versione più recente rispetto alla versione del kernel in esecuzione.
Questo messaggio, come di seguito riportato, può essere ignorato.
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
Warning: loading xen-platform-pci.o will taint the kernel: forced load
See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module xen-platform-pci loaded, with warnings
La parte più importante del suddetto messaggio è rappresentata dalla riga finale la quale dovrebbe indicare la presenza di alcuni messaggi d'avvertimento durante il caricamento del modulo.

36.4. Caricamento manuale dei driver para-virtualizzati

Se per qualche motivo i driver para-virtualizzati non vengono caricati automaticamente durante il processo d'avvio, allora eseguite il caricamento manuale.
Tale operazione vi permetterà di riconfigurare le entity dello storage e della rete, o di identificare il motivo per il quale il caricamento automatico non ha avuto successo. Le fasi di seguito riportate dovrebbero caricare i moduli del driver para-virtualizzato.
Identificate i moduli del driver para-virtualizzato presenti sul vostro sistema.
# cd /lib/modules/`uname -r`/
# find . -name 'xen_*.ko' -print
Annotate la posizione e caricate i moduli manualmente. Sostituite {LocationofPV-drivers} con la posizione corretta da voi annotata dell'output del comando.
# insmod \
/lib/modules/'uname -r'/{LocationofPV-drivers}/xen_platform_pci.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_balloon.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vnif.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vbd.ko

36.5. Verifica caricamento corretto dei driver para-virtualizzati

Uno dei compiti iniziali è quello di verificare che i driver siano stati effettivamente caricati sul vostro sistema.
After the para-virtualized drivers have been installed and the guest has been rebooted you can verify that the drivers have loaded. First you should confirm the drivers have logged their loading into /var/log/messages
# grep -E "vif|vbd|xen" /var/log/messages
                    xen_mem: Initialising balloon driver
                    vif vif-0: 2 parsing device/vif/0/mac
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    xen-vbd: registered block device major 202
You can also use the lsmod command to list the loaded para-virtualized drivers. It should output a list containing the xen_vnif, xen_vbd, xen_platform_pci and xen_balloon modules.
# lsmod|grep xen
xen_vbd                19168  1 
xen_vnif               28416  0 
xen_balloon            15256  1 xen_vnif
xen_platform_pci       98520  3 xen_vbd,xen_vnif,xen_balloon,[permanent]

36.6. Il sistema presenta un throughput limitato con driver para-virtualizzati

If network throughput is still limited even after installing the para-virtualized drivers and you have confirmed they are loaded correctly (refer to Sezione 36.5, «Verifica caricamento corretto dei driver para-virtualizzati»). To fix this problem, remove the 'type=ioemu' part of 'vif=' line in your guest's configuration file.

Glossary

Questo glossario intende definire i termini usati nella Installation Guide.
Bare-metal
The term bare-metal refers to the underlying physical architecture of a computer. Running an operating system on bare-metal is another way of referring to running an unmodified version of the operating system on the physical hardware. Examples of operating systems running on bare metal are dom0 or a normally installed operating system.
Completamente virtualizzato
See Full virtualization.
dom0
Also known as the host or host operating system.
dom0 refers to the host instance of Red Hat Enterprise Linux running the Xen hypervisor. Domain0 facilitates virtualized devices and virtualization for the guest operating systems. Dom0 runs on and manages the physical hardware and resource allocation for itself and the guest operating systems.
Domains
domU and dom0 are both domains. A domain is a term for a guest or virtual machine on the Xen hypervisor. The term domains has a similar meaning to virtual machines and the two are technically interchangeable.
domU
domU refers to the guest operating systems which run on the host system (the dom0 domain).
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.
Full virtualization
Xen and KVM can use full virtualization. Full virtualization uses hardware features of the processor to provide total abstraction of the underlying physical system (bare metal) and create a new virtual machine in which the guest operating systems can run. No modifications are needed in the guest operating system. The guest operating system and any applications on the guest are not aware of the virtualized environment and run normally. Para-virtualization requires a modified version of the Linux operating system.
Hardware Virtual Machine
See Full virtualization.
Host
The host operating system, also known as dom0.
The host operating system environment runs the virtualization software for Fully Virtualized and Para virtualized guest systems.
Hypervisor
The hypervisor is the software layer that abstracts the hardware from the operating system permitting multiple operating systems to run on the same hardware. The hypervisor runs on a host operating system allowing other virtualized operating systems to run on the host's hardware.
The Kernel-based Virtual Machine (KVM) and Xen) hypervisors are provided with Red Hat Enterprise Linux 5.
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.
Indirizzo 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.
Itanium®
Architettura del processore Intel Itanium®.
Kernel SamePage Merging
Il modulo Kernel SamePage Merging (KSM) viene usato dall'hypervisor KVM per abilitare i guest KVM in modo da condividere le stesse pagine della memoria. Le pagine condivise sono generalmente librerie comuni o altri dati identici frequentemente usati. KSM è in grado di aumentare le prestazioni di determinati guest attraverso la conservazione delle suddette librerie nella cache per diversi guest, e l'aumento della densità del guest.
Kernel-based Virtual Machine
KVM (Kernel-based Virtual Machine) is a Full virtualization solution for Linux on AMD64 and Intel 64 hardware. VM is a Linux kernel module built for the standard Red Hat Enterprise Linux kernel. KVM can run multiple, unmodified virtualized guest Windows and Linux operating systems. KVM is a hypervisor which uses the libvirt virtualization tools (virt-manager and 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).
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.
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:
  • Bilanciamento del carico - i guest possono essere spostati su un altro host con un livello di utilizzo minore quando l'host risulta essere sovraccarico.
  • Failover hardware - quando i dispositivi hardware su di un host falliscono i guest possono essere riposizionati in modo sicuro permettendo la disabilitazione dell'host e la sua riparazione.
  • Risparmio energetico - i guest possono essere distribuiti su altri host e sistemi host disalimentati per risparmiare energia e ridurre i costi durante periodi di utilizzo bassi.
  • Migrazione geografica - è possibile riposizionare i guest in modo da avere una latenza minore o in circostanze in cui è necessario eseguire tale processo.
Lo storage 'networked' condiviso viene usato per il salvataggio delle immagini del guest. Senza la migrazione dello storage condiviso tale operazione non è possibile.
Una migrazione offline sospende il guest e successivamente sposta l'immagine della memoria dei guest sull'host di destinazione. A questo punto il guest viene ripristinato sull'host di destinazione, liberando così la memoria usata dal guest sull'host sorgente.
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.
A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. KVM estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until KVM predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
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.
Para-virtualization
Para-virtualization uses a special kernel, sometimes referred to as the Xen kernel or the kernel-xen package. Para-virtualized guest kernels are run concurrently on the host while using the host's libraries and devices. A para-virtualized installation can have complete access to all devices on the system which can be limited with security settings (SELinux and file controls). Para-virtualization is faster than full virtualization. Para-virtualization can effectively be used for load balancing, provisioning, security and consolidation advantages.
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
See Para-virtualization.
PCI passthrough
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
phy device
The phy device parameter allows guest's to access physical disks. Physical disks includes:
  • LVM volumes (for example, /dev/VolGroup00/LogVol02),
  • disk partitions (for example, /dev/sda5), and
  • whole block devices (for example, /dev/sda).
Physical mode provides the best performance as the hypervisor bypasses extra layers of software on the host at the price of slightly less flexibility in managing the device.
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.
Sistema guest
Also known as guests, virtual machines, virtual servers or domU.
tap:aio
The tap:aio parameter sets the Xen hypervisor to use an advanced access mode designed for safety and performance. File-based, are accessed using a kernel thread and a user-space process. The tap:aio method respects guest flush requests which makes it safer than the file driver. The virtualization tools use tap:aio by default for accessing file-based guest disks on the Xen Hypervisor.
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
Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer on top of an operating system, to abstract hardware. The hypervisor allows multiple operating systems to run on the same physical system by giving the guest operating system virtualized hardware. There are various methods for virtualizing operating systems:
  • Hardware-assisted virtualization is the technique used for full virtualization with Xen and KVM.
  • Para-virtualization is a technique used by Xen to run Linux guests.
  • 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. Esso, nel formato QEMU, non è supportato da Red Hat Enterprise Linux.
Red Hat Enterprise Linux 5 supports hardware-assisted, full virtualization with the Xen and KVM hypervisors and software para-virtualization with the Xen hypervisor for hosting Red Hat Enterprise Linux guests.
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.
Xen
Red Hat Enterprise Linux supports the Xen hypervisor and the KVM hypervisor. Both hypervisors have different architectures and development approaches. The Xen hypervisor runs underneath a Red Hat Enterprise Linux operating system which acts as a host managing system resources and virtualization APIs. The host is sometimes referred to as dom0, or Domain0.

Risorse aggiuntive

Per saperne di più sulla virtualizzazione e Red Hat Enterprise Linux consultate 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 Red Hat. Il sito gestisce i binari dell'upstream del progetto Xen ed il codice sorgente insieme alle informazioni, architetture, panoramiche, alla documentazione ed ai link relativi riguardanti Xen e le tecnologie ad esso associate.
  • Il sito web di Xen Community
  • 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 Red Hat Enterprise 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.

Colophon

Questo manuale è stato scritto in un formato DocBook XML v4.3.
This book is based on the work of Jan Mark Holzer, Chris Curran and Scott Radvan.
Altri crediti vanno a:
  • Don Dutile redattore tecnico per la sezione dei driver para-virtualizzati.
  • Barry Donahue redattore tecnico per la sezione dei driver para-virtualizzati.
  • Rick Ring redattore tecnico per la sezione Virtual Machine Manager.
  • Michael Kearey redattore tecnico per le sezioni relative all'utilizzo dei file di configurazione XML con virsh ed unità floppy virtualizzate.
  • Marco Grigull redattore tecnico per la compatibilità software e la sezione relativa alle prestazioni.
  • Eugene Teo redattore tecnico per la sezione Gestione dei guest con virsh.
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:
  • Cinese semplificato
    • Leah Wei Liu
  • Cinese tradizionale
    • Chester Cheng
    • Terry Chuang
  • Giapponese
    • Kiyoto Hashida
  • Coreano
    • Eun-ju Kim
  • Francese
    • Sam Friedmann
  • Tedesco
    • Hedda Peters
  • Italiano
    • Francesco Valente
  • Portoghese brasiliano
    • Glaucia de Freitas
    • Leticia de Lima
  • Spagnolo
    • Angela Garcia
    • Gladys Guerrero
  • Russo
    • Yuliya Poyarkova