Product SiteDocumentation Site

Red Hat Enterprise Linux 5

Guide de virtualisation

Virtualization Documentation

Édition 5.8

Red Hat Engineering Content Services

Note légale

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

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

Préface
1. A propos de cet ouvrage
2. Conventions d'écriture
2.1. Conventions typographiques
2.2. Conventions pour citations mises en avant
2.3. Notes et avertissements
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. Prérequis et limitations pour la virtualisation avec Red Hat Enterprise Linux
1. Prérequis de système
2. Support et restrictions Xen
3. Support et restrictions KVM
4. Hyper-V restrictions and support
5. Limites en matière de virtualisation
5.1. Limitations générales pour la virtualisation
5.2. Limitations de KVM
5.3. Limitations Xen
5.4. Limites des applications
II. Installation
6. Installer les paquetages de virtualisation
6.1. Installation de Xen avec une nouvelle installation de Red Hat Enterprise Linux
6.2. Installation de paquetages Xen sur un système Red Hat Enterprise Linux existant
6.3. Installer KVM avec une nouvelle installation de Red Hat Enterprise Linux.
6.4. Installation de paquetages KVM sur un système Red Hat Enterprise Linux existant
7. Vue d'ensemble pour l'installation d'invités virtualisés
7.1. Création d'invités avec virt-install
7.2. Création d'invités avec virt-manager
7.3. Installation des invités PXE
8. Procédure d'installation du système d'exploitation des invités
8.1. Installer Red Hat Enterprise Linux 5 en tant qu'invité partiellement virtualisé.
8.2. Installer Red Hat Enterprise Linux en tant qu'invité totalement virtualisé.
8.3. Installer Windows XP en tant qu'invité totalement virtualisé
8.4. Installation de Windows Server 2003 en tant qu'invité totalement virtualisé
8.5. Installation de Windows Server 2008 en tant qu'invité totalement virtualisé
III. Configuration
9. Virtualized storage devices
9.1. Création d'un contrôleur de lecteur de disquettes virtualisé.
9.2. Ajout de périphériques de stockage aux invités
9.3. Configurer le stockage persistant dans Red Hat Enterprise Linux 5
9.4. Ajoutez les périphériques DVD et CD-ROM virtualisés à un invité.
10. Configuration du réseau
10.1. Traduction d'adresse de réseau (de l'anglais Network Address Translation, ou NAT) avec libvirt
10.2. Réseaux reliés par ponts avec libvirt
11. Réseaux Xen pré-Red Hat Enterprise Linux 5.4
11.1. Configurer les ponts de réseau d'invités multiples en utilisant plusieurs cartes Ethernet
11.2. Configuration de réseau pour ordinateur portable Red Hat Enterprise Linux 5.0
12. Pilotes para-virtualisés Xen
12.1. Prérequis de système
12.2. Support et restrictions en paravirtualisation
12.3. Installation de pilotes paravirtualisés
12.3.1. Etapes habituelles d'installation
12.3.2. Installation et configuration de pilotes paravirtualisés sur Red Hat Enterprise Linux 3
12.3.3. Installation et configuration des pilotes paravirtualisés dans 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. Configuration du pilote du réseau paravirtualisé
12.5. Configuration du matériel supplémentaire de paravirtualisation
12.5.1. Interfaces de réseau virtualisées
12.5.2. Périphériques de stockage virtualisés
13. Pilotes para-virtualisés KVM
13.1. INstallation des pilotes paravirtualisés Windows KVM
13.2. Installing drivers with a virtualized floppy disk
13.3. Utilisation de pilotes paravirtualisés KVM pour des périphériques existants.
13.4. Utilisation de pilotes paravirtualisés KVM pour de nouveaux périphériques.
14. Passe-système PCI
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. Gestion du temps de l'invité KVM
IV. Administration
17. Guides des meilleures pratiques
18. Sécurité pour la virtualisation
18.1. Storage security issues
18.2. SELinux et virtualisation
18.3. SELinux
18.4. Virtualization firewall information
19. Gestion des invités au moyen de xend
20. Migration Xen en direct
20.1. Test de migration live
20.2. Configurer la migration live de l'invité
21. Migration en direct KVM (Live Migration)
21.1. Besoins pour une migration live
21.2. Exemple de mémoire partagée : NFS pour une migration simple
21.3. Migration KVM live avec virsh
21.4. Migration avec virt-manager
22. Gestion de machines virtuelles à distance
22.1. Gestion à distance avec SSH
22.2. Gestion à distance par TLS et SSL
22.3. Modes de Transport
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. Guide de référence de virtualisation
24. Outils de virtualisation
25. Gestion d'invités au moyen de virsh
26. Gestion des invités avec le gestionnaire de machines virtuelles (virt-manager)
26.1. The Add Connection window
26.2. La fenêtre principale du gestionnaire de machines virtuelles apparaît.
26.3. The guest Overview tab
26.4. La console graphique d'une machine virtuelle
26.5. Démarrage de virt-manager
26.6. Restauration d'une machine enregistrée
26.7. Affichage des informations invité
26.8. Statut de contrôle
26.9. Affichage des identifiants d'invités
26.10. Displaying a guest's status
26.11. Affichage des processeurs virtuels
26.12. Affiche de l'utilisation CPU
26.13. Affichage de l'utilisation mémoire
26.14. Nommage du système virtuel
26.15. Création d'un réseau virtuel
27. Aide-mémoire des commandes xm
28. Configuration des paramètres d'amorçage du noyau Xen
29. Configurer ELILO
30. libvirt configuration reference
31. Fichiers de configuration Xen
VII. Conseils et astuces
32. Conseils et astuces
32.1. Démarrer les invités automatiquement
32.2. Changer entre les hyperviseurs Xen et KVM
32.2.1. De Xen à KVM
32.2.2. De KVM à Xen
32.3. Utilisation de qemu-img
32.4. Overcommitting Resources
32.5. Modification de /etc/grub.conf
32.6. Vérification des extensions de virtualisation
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. Générer une nouvelle adresse MAC unique
32.10. Limiter la bande passante de réseau pour un invité Xen
32.11. Configuration des affinités de processeur Xen
32.12. Modification de l'hyperviseur Xen
32.13. Very Secure ftpd
32.14. Configurer la persistence LUN
32.15. Désactiver la surveillance du disque SMART pour les invités
32.16. Nettoyer les anciens fichiers de configuration Xen
32.17. Configurer le serveur VNC
32.18. Cloner les fichiers de configuration d'un invité
32.19. Dupliquer un invité déjà existant et son fichier de configuration
33. Création de scripts personnalisés libvirt
33.1. Utilisation de fichiers de configuration XML à l'aide de virsh
VIII. Résolution de pannes
34. Résolution de pannes Xen
34.1. Débogage et résolution de pannes dans Xen
34.2. Vue d'ensemble sur les fichiers journaux
34.3. Descriptions des fichiers journaux
34.4. Emplacements importants dans les répertoires
34.5. Résolution des pannes avec les fichiers journaux
34.6. Résolution des pannes avec la console série
34.7. Accès à la console de l'invité paravirtualisé
34.8. Accès à la console de l'invité pleinement virtualisé
34.9. Problèmes Xen communs
34.10. Erreurs de création d'invités
34.11. Résolution de pannes avec la console série
34.11.1. Sortie de console série pour Xen
34.11.2. Sortie de console série Xen depuis les invités parvirtualisés
34.11.3. Sorties de console série depuis des invités totalement virtualisés
34.12. Fichiers de configuration Xen
34.13. Interprétation des messages d'erreur Xen
34.14. La disposition des répertoires de journaux
35. Résolution de pannes
35.1. Indentifier les partitions et zônes de stockage disponibles
35.2. La console se bloque après le redémarrage des invités basés-Xen
35.3. Les périphériques Ethernet virtualisés ne sont pas détectés par les outils de réseau.
35.4. Erreurs de périphérique en boucle
35.5. Création de domaine mise en échec, pour manque de mémoire
35.6. Erreur de mauvaise image du noyau
35.7. Error de mauvaise image de noyau - noyau non-PAE sur une plateforme PAE
35.8. Invité 64 bits totalement virtualisé échoue au démarrage
35.9. Une saisie localhost manquante provoque l'échec de virt-manager
35.10. Erreur de microcode pendant le démarrage de l'invité
35.11. Messages de dépréciation Python lorsque vous démarrez une machine virtuelle.
35.12. Activation des extensions de matériel de virtualisation VT et AMD-V dans BIOS
35.13. Performance réseau KVM
36. Résolution des pannes de pilotes paravirtualisés Xen
36.1. Journalisation et répertoires de Red Hat Enterprise Linux 5 Virtualization.
36.2. L'invité paravirtualisé n'a pas réussi à télédécharger dans un système d'exploitation d'invité Red Hat Enterprise Linux 3.
36.3. Un message d'avertissement est affiché lorsque vous installez les pilotes paravirtualisés sur Red Hat Enterprise Linux 3
36.4. Charger manuellement les pilotes paravirtualisés
36.5. Vérifier que les pilotes paravirtualisés ont été chargés avec succès
36.6. Le système possède une vitesse de traitement limitée avec les pilotes paravirtualisés.
Glossary
A. Ressources supplémentaires
A.1. Ressources en ligne
A.2. Documentation installée
B. Colophon

Préface

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

1. A propos de cet ouvrage

This book is divided into 8 parts:
  • Prérequis de système
  • Installation
  • Configuration
  • Administration
  • Storage
  • Référence
  • Conseils et astuces
  • Résolution de pannes
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 Section 4, « What is Virtualization? » and the Glossary for more details on these terms.

2. Conventions d'écriture

Ce manuel utilise plusieurs conventions pour souligner l'importance de certains mots ou expressions, mais aussi en vue d'attirer l'attention sur certains passages d'informations précis.
Pour les éditions sur support papier et numérique (PDF), ce manuel utilise des caractères issus de Liberation Fonts. La police de caractères Liberation Fonts est également utilisée pour les éditions HTML si elle est installée sur votre système. Sinon, des polices de caractères alternatives équivalentes sont utilisées. Notez que Red Hat Enterprise Linux 5 et versions supérieures contiennent la police Liberation Fonts par défaut.

2.1. Conventions typographiques

Quatre conventions typographiques sont utilisées pour attirer l'attention sur certains mots et expressions. Ces conventions et les circonstances auxquelles elles s'appliquent sont les suivantes.
Caractères gras à espacement fixe
Utilisée pour surligner certaines entrées du système, comme les commandes de console, les noms de fichiers et les chemins d'accès. Également utilisé pour surligner les touches et les combinaisons de touches. Par exemple :
Pour consulter le contenu du fichier mon_nouvel_ouvrage_littéraire qui se situe dans votre dossier courant, saisissez la commande cat mon_nouvel_ouvrage_littéraire à la demande du terminal et appuyez sur Entrée pour exécuter la commande.
L'exemple ci-dessus contient un nom de fichier, une commande-console et un nom de touche, tous présentés sous forme de caractères gras à espacement fixe et tous bien distincts grâce au contexte.
Les combinaisons de touches sont différenciées des noms de touches par le caractère « plus » (« + ») qui fait partie de chaque combinaison de touches. Ainsi :
Appuyez sur Entrée pour exécuter la commande.
Appuyez sur Ctrl+Alt+F2 pour passer au premier terminal virtuel. Appuyer sur Ctrl+Alt+F1 pour retournez à votre session X-Windows.
Le premier paragraphe surligne la touche précise sur laquelle il faut appuyer. Le second surligne deux combinaisons de touches (chacun étant un ensemble de trois touches à presser simultanément).
Si le code source est mentionné, les noms de classes, les méthodes, les fonctions, les noms de variables et les valeurs de retour citées dans un paragraphe seront présentées comme ci-dessus, en caractères gras à espacement fixe. Par exemple :
Les classes de fichiers comprennent le nom de classe filesystem pour les noms de fichier, file pour les fichiers et dir pour les dossiers. Chaque classe correspond à un ensemble de permissions associées.
Caractères gras proportionnels
Cette convention marque le surlignage des mots ou phrases que l'on rencontre sur un système, comprenant des noms d'application, des boîtes de dialogue textuelles, des boutons étiquettés, des cases à cocher et des boutons d'options mais aussi des intitulés de menus et de sous-menus. Par exemple :
Sélectionnez SystèmePréférencesSouris à partir de la barre du menu principal pour lancer les Préférences de la souris. À partir de l'onglet Boutons, cliquez sur la case à cocher Pour gaucher puis cliquez sur Fermer pour faire passer le bouton principal de la souris de la gauche vers la droite (ce qui permet l'utilisation de la souris par la main gauche).
Pour insérer un caractère spécial dans un fichier gedit, choisissez ApplicationsAccessoiresTable de caractères à partir de la barre du menu principal. Ensuite, sélectionnez Rechercher Rechercher… à partir de la barre de menu de Table de caractères, saisissez le nom du caractère dans le champ Rechercher puis cliquez sur Suivant. Le caractère que vous recherchez sera surligné dans la Table de caractères. Double-cliquez sur le caractère surligné pour l'insérer dans le champ Texte à copier, puis cliquez sur le bouton Copier. Maintenant, revenez à votre document et sélectionnez ÉditionColler à partir de la barre de menu de gedit.
Le texte ci-dessus contient des noms d'applications, des noms de menus et d'autres éléments s'appliquant à l'ensemble du système, des boutons et textes que l'on trouve dans une interface graphique. Ils sont tous présentés sous la forme gras proportionnel et identifiables en fonction du contexte.
Italique gras à espacement fixe ou Italique gras proportionnel
Qu'ils soient en caractères gras à espacement fixe ou à caractères gras proportionnels, l'ajout de l'italique indique la présence de texte remplaçable ou variable. Les caractères en italique indiquent la présence de texte que vous ne saisissez pas littéralement ou de texte affiché qui change en fonction des circonstances. Par exemple :
Pour se connecter à une machine distante en utilisant ssh, saisissez ssh nom d'utilisateur@domain.name (nom.domaine) après l'invite de commande de la console. Si la machine distante est exemple.com et que votre nom d'utilisateur pour cette machine est john, saisissez ssh john@example.com.
La commande mount -o remount système de fichiers monte le système de fichiers nommé. Ainsi, pour monter /home dans le système de fichiers, la commande est mount -o remount /home.
Pour connaître la version d'un paquet actuellement installé, utilisez la commande rpm -q paquet. Elle vous permettra de retourner le résultat suivant : version-de-paquet.
Notez les mots en caractères italiques et gras au dessus de — nom d'utilisateur, domain.name, système fichier, paquet, version et mise à jour. Chaque mot est un paramètre substituable de la ligne de commande, soit pour le texte que vous saisissez suite à l'activation d'une commande, soit pour le texte affiché par le système.
Mis à part l'utilisation habituelle de présentation du titre d'un ouvrage, les caractères italiques indiquent l'utilisation initiale d'un terme nouveau et important. Ainsi :
Publican est un système de publication DocBook.

2.2. Conventions pour citations mises en avant

Les sorties de terminaux et les citations de code source sont mis en avant par rapport au texte avoisinant.
Les sorties envoyées vers un terminal sont en caractères Romains à espacement fixe et présentées ainsi :
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Les citations de code source sont également présentées en romains à espacement fixe mais sont présentés et surlignés comme suit :
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. Notes et avertissements

Enfin, nous utilisons trois styles visuels pour attirer l'attention sur des informations qui auraient pu être normalement négligées :

Remarque

Une remarque est une forme de conseil, un raccourci ou une approche alternative par rapport à une tâche à entreprendre. L'ignorer ne devrait pas provoquer de conséquences négatives, mais vous pourriez passer à côté d'une astuce qui vous aurait simplifiée la vie.

Important

Les blocs d'informations importantes détaillent des éléments qui pourraient être facilement négligés : des modifications de configurations qui s'appliquent uniquement à la session actuelle ou des services qui ont besoin d'être redémarrés avant toute mise à jour. Si vous ignorez une case étiquetée « Important », vous ne perdrez aucunes données mais cela pourrait être source de frustration et d'irritation.

Avertissement

Un avertissement ne devrait pas être ignoré. Ignorer des avertissements risque fortement d'entrainer des pertes de données.

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.
Vous avez peut-être déjà investi énormément dans les technologies rapidement émergeantes de la virtualisation. Si c'est le cas, considérez quelques unes des idées ci-dessous pour exploiter encore plus cette technologie. Sinon, c'est le moment de vous y mettre.
La virtualisation offre une gamme d'outils d'amélioration de la flexibilité et de diminution des coûts, qui sont des critères importants pour chaque entreprise et pour toute organisation informatique. Les solutions virtuelles sont de plus en plus disponibles et riches en possibilités.
Comme la virtualisation peut offrir des avantages remarquables à votre organisation dans des domaines multiples, vous devriez établir des pilotes, développer une expertise et mettre la technologie de virtualisation en oeuvre dès maintenant.
Virtualisation pour innover
Par essence, la virtualisation augmente la flexibilité par découplage d'un réseau d'un système d'exploitation et des services et applications que ce système supporte, d'une plateforme de matériel physique spécifique. Cela permet la mise en place d'environnements virtuels multiples sur une plateforme de matériel en commun.
Les organisations qui cherchent à innover trouvent que la possibilité de créer de nouveaux systèmes et services sans avoir à installer du matériel supplémentaire (et de supprimer rapidement ces systèmes et services lorsqu'ils ne sont plus nécessaires) peut représenter un progrès important en matière d'innovation.
Parmi les approches possibles, on peut considérer l'établissement rapide des systèmes de développement de création de logiciels personnalisés, la possibilité de mettre en place des environnement test, la capacité de provisionner des solutions alternatives de logiciels et de les comparer, sans investissement lourd en matériel, le support pour les environnements de développement agile et de prototypage rapide, et la possibilité d'établir rapidement les nouveaux services de production à la demande.
Ces environnements peuvent être créés in situ ou provenir de l'extérieur, comme avec la proposition Amazon EC2. Comme le coût de créer un nouvel environnement virtuel peut être moindre, et qu'on peut utiliser le materiel existant, l'innovation peut être facilitée et accélérée avec un investissement minimal.
La virtualisation est un excellent tremplin innovateur pour la formation et l'apprentissage dans des environnements virtuels. Ces services sont des applications idéales de la technologie virtuelle. Un étudiant peut commencer un cours dans un environnement connu standard. Le travail de la classe peut être séparé du réseau de production. Les étudiants peuvent mettre en place des environnements informatiques uniques sans pour autant monopoliser les ressources de matériel.
Au fur et à mesure que les environnements virtuels continuent de se développer, il est de plus en plus probable qu'on assiste à une augmentation de la virtualisation pour permettre aux environnements portables d'être adaptés par rapport aux besoins d'un utilisateur particulier. Ces environnements peuvent être déplacés de façon dynamique vers un environnement accessible ou de traitement local de l'information, indépendamment du lieu où l'utilisateur se trouve. Les environnements virtuels de l'utilisateur peuvent être stockés sur le réseau ou bien être transportés par l'intermédiaire d'une mémoire protable.
Appliance Operating System est un concept avoisinant, un système d'exploitation orienté paquetage d'applications, conçu pour être opéré dans un environnement virtuel. L'approche du paquetage est orientée vers des coûts de support et de développement moindres, et l'application est exécutée dans un environnement sûr et familier. Une solution Appliance Operating System bénéficie aux développeurs d'application et aux consommateurs également.
La façon dont ces applications de technologie virtuelle s'appliquent à votre entreprise, variera. Si vous utilisez déjà cette technologie dans un ou plusieurs des secteurs mentionnés plus haut, considérez un investissement supplémentaire pour une solution qui nécessite un développement rapide. Si vous n'avez pas encore commencé à virtualiser, commencer par le training et l'apprentissage pour développer des aptitudes, puis passez au développement et aux tests d'applications. Les entreprises qui possèdent le plus d'expérience en matière de virtualisation devraient considérer la mise en place d'environnements portables virtuels ou de software applications (applications pouvant fonctionner sur machines virtuelles ou du matériel standard, souvent disponibles par abonnement).
Virtualisation pour réduire les coûts
La virtualisation peut également être utilisée dans un souci d'économie. Un des avantages provient de la consolidation de serveurs dans un plus petit nombre de plateformes de matériel plus puissantes opérant un ensemble d'environnements virtuels. Non seulement les coûts seront réduits par la réduction du montant de matériel et de capacité inutilisée, mais la performance de l'application peut être également améliorée par le fait que les invités évoluent sur du matériel plus puissant.
De plus, on peut ajouter de la capacité de matériel d'une manière non-perturbante et on peut migrer les charges de travail vers les ressources disponibles de façon dynamique.
Suivant les besoins de l'organisation, il est possible de créer un environnement virtuel pour éviter le désastre. L'introduction de la virtualisation peut réduire énormément le besoin de répliquer des environnements de matériel identiques et peut aussi permettre de tester des scénarios catastrophiques à moindre coût.
La virtualisation procure une excellente solution pour répondre aux charges de travail saisonnières. Si vous avez des charges de travail complémentaires dans votre organisation, vous pouvez allouer de façon dynamique des ressources aux applications qui exigent les plus hauts besoins. Si vous faites l'expérience de charges de travail que vous êtes en mesure de provisionner au sein de votre organisation, vous pouvez peut-être acheter de la capacité sur demande en externe ou de l'implémenter en utilisant la technologie virtuelle.
Les économies provenant de la consolidation de serveurs est impressionante. Si vous n'exploitez pas la virtualisation dans ce dessein, vous devriez initier un programme dès maintenant. Lorsque vous aurez davantage d'expérience en virtualisation, explorez les avantages des environnements virtuels de recouvrement de désastres et les avantages de pouvoir équilibrer les charges de travail.
Virtualisation comme solution standard
Indépendemment des besoins de l'entreprise, vous devriez étudier la virtualisation en tant que partie intégrante de votre système et de votre portfolio d'applications qui va devenir une technologie pervasive. Nous nous attendons à ce que les distributeurs de systèmes d'exploitation incluent la virtualisation comme un composant standard, et à ce que les distributeurs de matériel construisent des capacités de virtualisation dans leurs plateformes, et que les distributeurs de virtualisation étendent leurs gamme de services.
Si vous n'avez pas l'intention d'incorporer la virtualisation en tant que solution d'architecture, c'est le moment d'identifier un projet pilote, lui allouer des plateformes de matériel sous-utilisées, et de développer une expertise dans cette technologie flexible et à moindre coût; puis, augmenter le nombre d' architectures où incorporer des solutions virtuelles. Malgré les avantages importants qu'il existe à virtualiser des services existants, construire de nouvelles applications dans le cadre d'une stratégie virtuelle intégrée peut vous apporter d'autres bénéfices au niveau de la gestion de la disponibilité.
Vous pouvez en savoir plus sur les solutions de virtualisation Red Hat en cliquant sur http://www.redhat.com/products/

Partie I. Prérequis et limitations pour la virtualisation avec Red Hat Enterprise Linux

Prérequis du système, restrictions de support et limitations

Ces chapitres décrivent les prérequis du système, les restrictions de support, et les limitations de la virtualisation sur Red Hat Enterprise Linux.

Chapitre 1. Prérequis de système

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 Chapitre 6, Installer les paquetages de virtualisation.
Prérequis minimums de système
  • 6 Go d'espace disque disponible
  • 2 Go de 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 Section 32.4, « Overcommitting Resources ».
Prérequis pour paravirtualisation Xen
Les invités paravirtualisés ont besoin du medium d'aborescence d'installation Red Hat Enterprise Linux 5, disponible sur le réseau en utilisant les protocoles NFS, FTP ou HTTP.
Prérequis pour virtualisation totale Xen
La virtualisation totale avec l'hyperviseur Xen nécessite :
  • an Intel processor with the Intel VT extensions, or
  • un processeur AMD avec les extensions AMD-V, ou
  • un processeur Intel Itanium.
Refer to Section 32.6, « Vérification des extensions de virtualisation » to determine if your processor has the virtualization extensions.
Prérequis KVM
L'hyperviseur KVM nécessite :
  • un processeur Intel avec les extensions Intel VT et Intel 64, ou
  • un processeur AMD avec les extensions AMD-V et AMD64.
Refer to Section 32.6, « Vérification des extensions de virtualisation » to determine if your processor has the virtualization extensions.
Support de stockage
Les méthodes de stockage d'invités prises en charge sont :
  • Files on local storage
  • Physical disk partitions
  • Locally connected physical LUNs
  • LVM partitions
  • iSCSI and Fibre Channel based LUNs

Le stockage d'invités basé sur fichiers

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 Section 18.2, « SELinux et virtualisation » for details.

Chapitre 2. Support et restrictions 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:

Note

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

support Itanium®

Virtualization with the Xen hypervisor on the Intel Itanium architecture requires the guest firmware image package, refer to Installer l'hyperviseur Xen avec yum for more information.

Chapitre 3. Support et restrictions 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 Section 32.6, « Vérification des extensions de virtualisation ».
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:

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

Note

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.

Chapitre 5. Limites en matière de virtualisation

Ce chapitre couvre les limitations supplémentaires des paquetages de virtualistion dans Red Hat Enterprise Linux.

5.1. Limitations générales pour la virtualisation

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.
Autres limitations
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.
Test avant le déploiement
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. Limitations de KVM

Les limitations suivantes s'appliquent à l'hyperviseur KVM :
Bit TSC constant
Systems without a Constant Time Stamp Counter require additional configuration. Refer to Chapitre 16, Gestion du temps de l'invité KVM for details on determining whether you have a Constant Time Stamp Counter and configuration steps for fixing any related issues.
Overcommiter la mémoire
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.
Overcommiter les CPU
Seuls 10 CPU virtuels par processeur physique sont pris en charge. Tout nombre de CPU virtuels overcommités supérieur au nombre de coeurs de processeurs physique pourrait causer des problèmes avec certains invités virtualisés.
Overcommitting CPUs has some risk and can lead to instability. Refer to Section 32.4, « Overcommitting Resources » for tips and recommendations on overcommitting CPUs.
Périphériques SCSI virtualisés
SCSI emulation is presently not supported. Virtualized SCSI devices are disabled in KVM.
Périphériques IDE virtualisés
KVM est limité à un maximum de quatre périphériques IDE virtualisés (émulés) par invité.
Périphériques paravirtualisés
Les périphériques paravirtualisés, qui utilisent les pilotes virtio sont des périphériques PCI. Actuellement, les invités sont limités à un maximum de 32 périphériques PCI. certains périphériques PCI sont critiques à l'exécution de l'invité et ne peuvent donc pas être supprimés. Les périphériques nécessaires par défaut sont :
  • le pont hôte,
  • les ponts ISA et USB (les pont ISA et USB sont le même périphérique),
  • la carte graphique (utilisant le pilote Cirrus ou qxl), et
  • le périphérique balloon memory.
Sur les 32 périphériques PCI pour un invité, 4 ne peuvent pas être supprimés. Cela signifie qu'il n'y a que 28 fentes PCI disponibles pour des périphériques supplémentaires par invité. Chaque invité peut utiliser jusqu'à 28 périphériques supplémentaires faits de n'importe quelle combinaison de réseau paravirtualisé, périphériques paravirtualisés, ou autres appareils PCI utilisant VT-d.
Limitations de migration
Une migration en direct est uniquement possible avec des CPU provenant du même fournisseur (c'est-à-dire d'Intel à Intel, ou d'AMD à AMD uniquement).
L'octet No eXecution (NX) doit être réglé sur on ou sur off sur les deux CPU pour une migration en direct.
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. Limitations Xen

Remarque

All limitations in this chapter are limitations for Red Hat Enterprise Linux 5.8 except where noted. Older versions may have fewer limitations.
Limitations de l'hôte 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.

Contourner la limite de périphériques paravirtualisés

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 hôte n'a pas de limite quant au nombre de périphériques phy qu'il peut contenir s'il possède suffisamment de ressources.
LVM, ou tout autre outil de partitionnement logique similaire, peut être utilisé sur un périphérique de traitement par blocs afin de créer des partitions logiques supplémentaires sur un périphérique de traitement par blocs paravirtualisé unique.
Limites en matière de paravirtualisation Xen
  • 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 maximum de 15 périphériques réseau par invité virtualisé.
Limites en matière de virtualisation totale Xen
  • For x86 guests, a maximum of 16GB memory per guest.
  • Un maximum de quatre périphériques IDE virtualisés (émulés) par invité.
    Les périphériques utilisant les pilotes paravirtualisés pour des invités totalement virtualisés n'ont pas cette limitation.
  • 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.

    Utilisation de plus de 8 périphériques en boucle.

    Par défaut, Red Hat Enterprise Linux limite le nombre de périphériques en boucle disponibles. Ce nombre peut être augmenté en modifiant la limite du noyau.
    Dans /etc/modprobe.conf, ajouter la ligne suivante :
    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 maximum de 15 périphériques réseau par invité virtualisé.
  • Un maximum de 15 périphériques SCSI virtualisés par invité virtualisé.
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. Limites des applications

Certains aspects de la virtualisation la rendent incompatible pour certains types d'applications.
Les applications avec des prérequis de hauts débits d'E/S devraient utiliser les pilotes paravirtualisés pour les invités totalement virtualisés. Sans les pilotes paravirtualisés, certaines applications peuvent devenir instables sous hautes charges d'E/S.
Les applications suivantes doivent être évitées en raison de leur haute exigence E/S:
  • serveur kdump
  • serveur 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.

Partie II. Installation

Chapitre 6. Installer les paquetages de virtualisation

Avant d'utiliser la virtualisation, les paquetages de virtualisation doivent être installés sur Red Hat Enterprise Linux. Les paquetages de virtualisation peuvent être installés soit pendant la séquence d'installation, soit après celle-ci, en utilisant la commande yum et le Red Hat Network (RHN).
Vous pouvez installer les deux hyperviseurs KVM et Xen sur un seul et même système. L'hyperviseur Xen utilise le paquetage kernel-xen, et l'hyperviseur KVM utilise le noyau par défaut de Red Hat Enterprise Linux avec le module de noyau kvm. Xen et KVM utilisent un noyau différent et un seul hyperviseur peut être actif à la fois. Red Hat recommande de n'installer qu'un seul hyperviseur, celui que vous souhaitez utiliser pour la virtualisation.
To change hypervisor from Xen to KVM or KVM to Xen refer to Section 32.2, « Changer entre les hyperviseurs Xen et KVM ».

6.1. Installation de Xen avec une nouvelle installation de Red Hat Enterprise Linux

Cette section couvre l'installation d'outils de virtualisation et de paquetages Xen faisant partie d'une nouvelle installation de Red Hat Enterprise Linux.

Besoin d'aide pour l'installation ?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.
  1. Démarrer un installation interactive de Red Hat Enterprise Linux à partir du CD-ROM, du DVD, ou PXE d'installation de 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.
    Sélectionner le groupe de paquetages Virtualization et le bouton radio Customize Now.
  4. Sélectionner le groupe de paquetages Virtualization. Le groupe de paquetages Virtualization sélectionne l'hyperviseur Xen, virt-manager, libvirt et virt-viewer, ainsi que toutes les dépendances pour l'installation.
  5. Personnaliser les paquetages (si nécessaire)

    Personnaliser le groupe Virtualization si vous avez besoin d'autres paquetages de virtualisation.
    Press the Close button then the Forward button to continue the installation.

Remarque

Des droits d'accès à la virtualisation RHN valides sont nécessaires pour recevoir les mises à jour des paquetages de virtualisation.
Installation de paquetages Xen avec des fichiers Kickstart
Cette section décrit comment utiliser un fichier Kickstart pour installer Red Hat Enterprise Linux avec les paquetages de l'hyperviseur Xen. Les fichiers Kickstart permettent des installations automatiques, à grande échelle, sans que l'utilisateur ait besoin d'installer chaque système individuellement. Les étapes de cette section vont vous aider à créer et à utiliser un fichier Kickstart pour installer Red Hat Enterprise Linux avec les paquetages de virtualisation.
Dans la section %packages de votre fichier Kickstart, ajouter le groupe de paquetages suivant :
%packages
@xen

Pour les systèmes 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. Installation de paquetages Xen sur un système Red Hat Enterprise Linux existant

Cette section décrit les étapes nécessaires pour installer les paquetages de virtualisation sur un système Red Hat Enterprise Linux fonctionnel.
Ajouter des paquetages sur votre liste de privilèges Red Hat Network
Cette section décrit comment activer les droits d'accès à Red Hat Network (RHN) pour les paquetages de virtualisation. Ces droits devront être activés afin de pouvoir installer et mettre à jour les paquetages de virtualisation sur Red Hat Enterprise Linux. Vous aurez aussi besoin d'avoir un compte Red Hat Network valide afin de pouvoir installer des paquetages de virtualisation sur Red Hat Enterprise Linux.
De plus, vos machines doivent être enregistrées sur RHN. Pour enregistrer une installation non-enregistrée de Red Hat Enterprise Linux, exécuter la commande rhn_register et suivre les invites.
Si vous ne possédez pas d'abonnement Red Hat valide, visitez Red Hat online store.
Procédure 6.1. Ajouter les droits d'accès à la virtualisation avec RHN
  1. Connectez-vous à RHN en utilisant votre mot de passe et votre identifiant RHN.
  2. Sélectionner les systèmes sur lesquels vous souhaitez installer la virtualisation.
  3. Dans la section System Properties les privilèges en cours sont listés dans Entitlements. Utiliser le lien (Edit These Properties) pour changer vos privilèges.
  4. Sélectionner la case Virtualization.
Votre système est maintenant en mesure de recevoir les paquetages de virtualisation. La prochaine section couvre l'installation de ces paquetages.
Installer l'hyperviseur Xen avec yum
Pour utiliser la virtualisation sur Red Hat Enterprise Linux, vous aurez besoin des paquetages xen et kernel-xen. Le paquetage xen contient l'hyperviseur ainsi que des outils basiques de virtualisation. Le paquetage kernel-xen comprend un noyau linux modifié qui opère comme un invité de machine virtuelle sur l'hyperviseur.
Pour installer les paquetages xen et kernel-xen , exécuter:
# yum install xen kernel-xen
Les invités totalement virtualisés sur architecture Itanium® ont besoin du paquetage de l'image du microprogramme de l'invité (xen-ia64-guest-firmware) du DVD d'installation supplémentaire. Ce paquetage peut aussi être installé à partir de RHN à l'aide de la commande yum :
# yum install xen-ia64-guest-firmware
It is advised to install additional virtualization packages for management and configuration. Paquetages de virtualisation recommandés : lists the recommended packages.
Installer les autres paquetages de virtualisation recommandés :
# yum install virt-manager libvirt libvirt-python python-virtinst

6.3. Installer KVM avec une nouvelle installation de Red Hat Enterprise Linux.

Cette section couvre l'installation d'outils de virtualisation et du paquetage KVM dans le cadre d'une nouvelle installation de Red Hat Enterprise Linux.

Besoin d'aide pour l'installation ?

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

Un numéro d'installation valide est nécessaire

Les paquetages de virtualisation ne peuvent pas être sélectionnés lors de l'installation sans numéro d'installation valide.
  1. Démarrer un installation interactive de Red Hat Enterprise Linux à partir du CD-ROM, du DVD, ou PXE d'installation de Red Hat Enterprise Linux.
  2. Vous devez saisir un numéro d'installation valide lors de l'invite pour recevoir accès à la virtualisation et à d'autres paquetages "Advanced Platform".
  3. Complete all steps up to the package selection step.
    Sélectionner le groupe de paquetages Virtualization et le bouton radio Customize Now.
  4. Sélectionner les groupes de paquetages KVM. Dé-sélectionner le groupe de paquetages Virtualization. Ceci sélectionnera l'hyperviseur KVM, virt-manager, libvirt et virt-viewer pour l'installation.
  5. Personnaliser les paquetages (si nécessaire)

    Personnaliser le groupe Virtualization si vous avez besoin d'autres paquetages de virtualisation.
    Press the Close button then the Forward button to continue the installation.

Remarque

Des droits d'accès à la virtualisation RHN valides sont nécessaires pour recevoir les mises à jour des paquetages de virtualisation.
Installation de paquetages KVM avec des fichiers Kickstart
Cette section décrit comment utiliser un fichier Kickstart pour installer Red Hat Enterprise Linux avec les paquetages de l'hyperviseur KVM. Les fichiers Kickstart permettent des installations automatiques, à grande échelle, sans que l'utilisateur ait besoin d'installer chaque système individuellement. Les étapes de cette section vont vous aider à créer et à utiliser un fichier Kickstart pour installer Red Hat Enterprise Linux avec les paquetages de virtualisation.
Dans la section %packages de votre fichier Kickstart, ajouter le groupe de paquetages suivant :
%packages
@kvm
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.4. Installation de paquetages KVM sur un système Red Hat Enterprise Linux existant

Cette section décrit les étapes nécessaires pour installer l'hyperviseur KVM sur un système fonctionnel Red Hat Enterprise Linux 5.4 ou plus récent.
Ajouter des paquetages sur votre liste de privilèges Red Hat Network
Cette section décrit comment activer les droits d'accès à Red Hat Network (RHN) pour les paquetages de virtualisation. Ces droits devront être activés afin de pouvoir installer et mettre à jour les paquetages de virtualisation sur Red Hat Enterprise Linux. Vous aurez aussi besoin d'avoir un compte Red Hat Network valide afin de pouvoir installer des paquetages de virtualisation sur Red Hat Enterprise Linux.
De plus, vos machines doivent être enregistrées sur RHN. Pour enregistrer une installation non-enregistrée de Red Hat Enterprise Linux, exécuter la commande rhn_register et suivre les invites.
Si vous ne possédez pas d'abonnement Red Hat valide, visitez Red Hat online store.
Procédure 6.2. Ajouter les droits d'accès à la virtualisation avec RHN
  1. Connectez-vous à RHN en utilisant votre mot de passe et votre identifiant RHN.
  2. Sélectionner les systèmes sur lesquels vous souhaitez installer la virtualisation.
  3. Dans la section System Properties les privilèges en cours sont listés dans Entitlements. Utiliser le lien (Edit These Properties) pour changer vos privilèges.
  4. Sélectionner la case Virtualization.
Votre système est maintenant en mesure de recevoir les paquetages de virtualisation. La prochaine section couvre l'installation de ces paquetages.
Installation de l'hyperviseur KVM avec yum
Pour utiliser la virtualisation sur Red Hat Enterprise Linux, vous aurez besoin du paquetage kvm. Le paquetage kvm contient le module du noyau KVM offrant l'hyperviseur KVM sur le noyau par défaut de Red Hat Enterprise Linux.
Pour installer le paquetage kvm, exécuter :
# yum install kvm
Maintenant, installer les paquetages additionnels de gestion de la virtualisation.
Installer les autres paquetages de virtualisation recommandés :
# yum install virt-manager libvirt libvirt-python python-virtinst

Chapitre 7. Vue d'ensemble pour l'installation d'invités virtualisés

Une fois l'installation de vos paquetages de virtualisation sur le système hôte réalisée, vous pouvez créer des systèmes d'exploitation invités. Ce chapitre décrit les processus général pour l'installation de systèmes d'exploitation sur des machines virtualisées. Vous pouvez créer des invités en utilisant le bouton Nouveau dans virt-manager ou l'interface de ligne de commande virt-install. Ces deux méthodes sont couvertes dans ce chapitre.
Detailed installation instructions are available for specific versions of Red Hat Enterprise Linux, other Linux distributions and Windows. Refer to Chapitre 8, Procédure d'installation du système d'exploitation des invités for those procedures.

7.1. Création d'invités avec virt-install

Vous pouvez utiliser la commande virt-install pour créer des invités virtualisés depuis la ligne de commande. virt-install peut être utilisée de manière interactive, ou avec un script, pour automatiser la création des machines virtuelles. En utilisant virt-install avec les fichiers Kickstart, on peut réaliser une installation de machines virtuelles automatisée.
L'outil virt-install offre un certain nombre d'options que l'on peut passer sur la ligne de commande. Pour voir une liste complète des options, exécutez :
$ virt-install --help
La page man virt-install documente toutes les options de commande et les variables importantes.
qemu-img est une commande apparentée qui peut être utilisée avant virt-install afin de configurer les options de stockage.
An important option is the --vnc option which opens a graphical window for the guest's installation.
Exemple 7.1. Utilisation de virt-install avec KVM pour créer un invité Red Hat Enterprise Linux 3
Cet exemple crée un invité Red Hat Enterprise Linux 3 à partir d'un CD-ROM, avec un réseau virtuel, et une image de périphérique de traitement par blocs, basée sur fichiers de 5 Go, cet invité est nommé rhel3support. L'exemple utilise l'hyperviseur 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

Exemple 7.2. Utilisation de virt-install pour créer un invité 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. Création d'invités avec virt-manager

virt-manager, aussi connu sous le nom de Virtual Machine Manager, est un outil graphique pour la création et la gestion d'invités virtualisés.
Procédure 7.1. Création d'un invité virtualisé avec 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 fenêtre principale virt-manager va vous permettre de créer une nouvelle machine virtuelle. Utiliser le bouton Nouveau pour créer un nouvel invité. Ceci ouvre l'assistant comme montré dans la capture d'écran :
  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:
    Vérifier les informations sur l'installation puis cliquer sur Suivant.
  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

    La fenêtre Choosing a virtualization method apparaît. Choisir entre Paravirtualisation et Virtualisation totale.
    La virtualisation totale requiert un système avec un processeur Intel® VT ou AMD-V. Si les extensions de virtualisation ne sont pas présentes, le bouton radio Virtualisation totale ou le bouton Enable kernel/hardware acceleration ne sera pas sélectionnable. L'option Paravirtualisation sera en gris si kernel-xen n'est pas le noyau en cours d'exécution.
    Seule la virtualisation totale sera disponible si vous êtes connecté à un hyperviseur KVM.
    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 Chapitre 10, Configuration du réseau 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 Section 18.2, « SELinux et virtualisation » 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.
    Allouer de l'espace supplémentaire si l'invité a besoin de plus d'espace pour des applications ou autres données. Par exemple, les serveurs web ont besoin de plus d'espace pour les fichiers de journalisation.
    Choisir la taille appropriée pour l'invité sur le type de stockage sélectionné et cliquer sur Suivant.

    Note

    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.
    Les invités ont besoin de suffisamment de mémoire physique (RAM) afin de fonctionner de manière efficace et effective. Choisir une valeur de mémoire qui convient au système d'exploitation de votre invité et aux prérequis des applications. La plupart des systèmes d'exploitation nécessitent au moins 512 Mo de RAM pour fonctionner correctement. Rappelez-vous que les invités utilisent la mémoire physique. Exécuter trop d'invités ou ne pas laisser suffisamment de mémoire pour le système hôte provoque une utilisation significative de la mémoire virtuelle. La mémoire virtuelle, bien plus lente, offrira une performance et un temps de réponse dégradé. Assurez-vous bien d'allouer suffisamment de mémoire afin que l'hôte et tous les invités puissent opérer de manière effective.
    Assigner suffisamment de CPU virtuels pour l'invité virtualisé. Si l'invité exécute une application multi-thread, assigner le nombre de CPU virtualisés nécessité pour que l'invité puisse s'exécuter de manière efficace. Ne pas assigner plus de CPU virtuels que le nombre de processeurs physiques (ou hyper-threads) disponibles sur le système hôte.Il est possible d'allouer trop de processeurs virtuels, toutefois, ceci a un effet négatif significatif sur la perfomance de l'hôte et de l'invité car le contexte du processeur échange d'overheads.
    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.
    Une fenêtre VNC s'ouvre en montrant le début du processus d'installation du système d'exploitation de l'invité.
This concludes the general process for creating guests with virt-manager. Chapitre 8, Procédure d'installation du système d'exploitation des invités contains step-by-step instructions to installing a variety of common operating systems.

7.3. Installation des invités PXE

Cette section couvre les étapes requises pour installer des invités avec PXE. L'installation d'invités PXE requiert un périphérique réseau partagé, aussi nommé pont réseau. Les procédures figurant ci-dessous couvrent la création de ponts et les étapes requises pour utiliser le pont pour une installation PXE.
  1. Création d'un nouveau pont

    1. Créer un nouveau fichier de script réseau dans le répertoire /etc/sysconfig/network-scripts/. Cet exemple crée un fichier nommé ifcfg-installation qui fait un pont nommé installation.
      # cd /etc/sysconfig/network-scripts/
      # vim ifcfg-installation
      DEVICE=installation
      TYPE=Bridge
      BOOTPROTO=dhcp
      ONBOOT=yes
      

      Avertissement

      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. Il n'y a aucune interface ajoutée au nouveau pont. Utiliser la commande brctl show pour voir les détails sur les ponts réseau du système.
      # brctl show
      bridge name     bridge id               STP enabled     interfaces
      installation    8000.000000000000       no
      virbr0          8000.000000000000       yes
      
      Le pont virbr0 est le pont par défaut utilisé par libvirt pour le NAT (de l'anglais, Network Address Translation) sur le périphérique Ethernet par défaut.
  2. Ajouter une interface au nouveau pont

    Modifier le fichier de configuration pour l'interface. Ajouter le paramètre BRIDGE au fichier de configuration avec le nom du pont créé lors des étapes précédentes.
    # Intel Corporation Gigabit Network Connection
    DEVICE=eth1
    BRIDGE=installation
    BOOTPROTO=dhcp
    HWADDR=00:13:20:F7:6E:8E
    ONBOOT=yes
    
    Redémarrer ou relancer le réseau après avoir modifié le fichier de configuration.
    # service network restart
    
    Vérifier que l'interface est attachée à l'aide de la commande brctl show :
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    installation    8000.001320f76e8e       no              eth1
    virbr0          8000.000000000000       yes
    
  3. Configuration de la sécurité

    Configurer iptables afin de permettre à tout le trafic d'être transféré à travers le pont.
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
    # service iptables save
    # service iptables restart
    

    Désactiver iptables sur les ponts

    Autrement, empêcher le trafic ponté d'être traité par les règles iptables. Ajouter les lignes suivantes dans /etc/sysctl.conf :
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    
    Recharger les paramètres du noyau configurés avec sysctl.
    # sysctl -p /etc/sysctl.conf
    
  4. Redémarrer libvirt avant l'installation

    Redémarrer le démon libvirt.
    # service libvirtd reload
    
Le pont est configuré, vous pouvez maintenant commencer une installation.
Installation PXE avec virt-install
Pour virt-install, ajouter le paramètre d'installation --network=bridge:installation, où installation est le nom de votre pont. Pour des installation PXE, utiliser le paramètre --pxe.
Exemple 7.3. Installation PXE avec 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 \

Installation PXE avec virt-manager
The steps below are the steps that vary from the standard virt-manager installation procedures. For the standard installations refer to Chapitre 8, Procédure d'installation du système d'exploitation des invités.
  1. Sélectionner PXE

    Sélectionner PXE comme méthode d'installtion.
  2. Sélectionner le pont

    Sélectionner Shared physical device, puis sélectionner le pont créé lors de la procédure précédente.
  3. Démarrer l'installation

    L'installation est prête à commencer.
Une requête DHCP est envoyée et les processus d'installation de l'invité démarreront si un serveur PXE valide est trouvé.

Chapitre 8. Procédure d'installation du système d'exploitation des invités

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 Chapitre 7, Vue d'ensemble pour l'installation d'invités virtualisés.

Important

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. Installer Red Hat Enterprise Linux 5 en tant qu'invité partiellement virtualisé.

Cette section décrit l'installation de Red Hat Enterprise Linux 5 en tant qu'invité paravirtualisé. La paravirtualisation est plus rapide que la virtualisation totale et supporte tous les avantages de la virtualisation totale. La paravirtualisation requiert la prise en charge d'un noyau spécifique, le noyau kernel-xen.

Note importante sur la paravirtualisation

La paravirtualisation ne fonctionne qu'avec l'hyperviseur Xen. La paravirtualisation ne fonctionne pas avec l'hyperviseur KVM.
Assurez-vous bien d'avoir un accès super-utilisateur (root) avant de procéder à l'installation.
Cette méthode installe Red Hat Enterprise Linux à partir d'un serveur distant. Les instructions d'installation présentées dans cette section sont similaires à une installation à partir du CD-ROM d'installation minimale "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 Section 7.2, « Création d'invités avec virt-manager ».
Créer un invité paravirtualisé avec l'outil basé sur la ligne de commande virt-install. L'option --vncmontre l'installation graphique. Le nom de l'invité dans l'exemple est rhel5PV, le fichier de l'image de disque est rhel5PV.dsk et le miroir local de l'arbre d'installation est ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/. Remplacer ces valeurs par des valeurs précises pour votre système et pour votre réseau.
# 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/

Automatisation de l'installation

Red Hat Enterprise Linux peut être installé sans interface graphique ou sans entrée manuelle. Utilisez les fichiers Kickstart pour automatiser le processus d'installation.
L'utilisation d'une méthode ou de l'autre ouvrira cette fenêtre, affichant les premières phases d'initialisation de votre invité :
Une fois que votre invité aura procédé au premier amorçage, le processus d'installation standard pour Red Hat Enterprise Linux commencera. Pour la plupart des systèmes, les réponses par défaut sont acceptables.
Procédure 8.1. Procédure d'installation d'invité Red Hat Enterprise Linux paravirtualisé
  1. Sélectionner la langue et cliquer sur Valider.
  2. Sélectionner la configuration du clavier et cliquer sur Valider.
  3. Assign the guest's network address. Choose to use DHCP (as shown below) or a static IP address:
  4. Si vous avez sélectionné DHCP pour votre invité, le processus d'installation va maintenant essayer d'acquérir une adresse 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. Saisissez une adresse IP valide, puis veillez à ce que l'adresse IP que vous saisissez puisse atteindre le serveur d'installation qui fournit l'aborescence d'installation.
    2. Saisir un masque Subnet valide, une passerelle par défaut et le nom de l'adresse du serveur.
    Sélectionner la langue et cliquer sur Valider.
  6. Ceci est un exemple de configuration d'adresse IP statique :
  7. Le processus d'installation va maintenant récupérer les fichiers du serveurs nécessaires :
Une fois les étapes initiales réalisées, le processus d'installation graphique commence.
Si vous installez une version Beta ou un modèle plus ancien, vous aurez besoin de confirmer que vous souhaitez réellement installer le système d'exploitation. Cliquez sur Install Anyway, puis sur Valider :
Procédure 8.2. Processus d'installation graphique
  1. Saisir un code d'enregistrement valide. Si vous possédez une clé de susbscription RHN valide, alors veuillez saisir le champ Installation Number :

    Remarque

    Si vous ne procédez pas à l'étape d'enregistrement, veuillez confirmer les détails de votre compte Red Hat Network après l'installation à l'aide de la commande rhn_register. La commande rhn_register nécessite d'avoir un accès super-utilisateur.
  2. L'installation va maintenant confirmer si vous souhaitez effacer toutes les données sur le stockage que vous avez sélectionné pour l'installation :
    Cliquer sur Valider pour continuer.
  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. Confirmer le stockage sélectionné pour l'installation.
    Cliquer sur Valider pour continuer.
  5. Configurer les paramètres de réseau et de nom d'hôte. Ces paramètres sont remplis avec les données entrées auparavant lors du processus d'installation. Changer ces paramètres si nécessaire.
    Cliquer sur Valider pour continuer.
  6. Sélectionner le fuseau horaire qui convient à votre environnement :
  7. Saisir un mot de passe pour l'invité :
    Cliquer sur Suivant pour continuer.
  8. Sélectionner les paquetages de logiciel à installer. cliquer sur le bouton Customize Now. Vous devrez installer le paquetage kernel-xen dans le répertoire System. Le paquetage kernel-xen est requis pour la paravirtualisation.
    Click Forward.
  9. Les dépendances et prérequis d'espace sont calculés.
  10. After the installation dependencies and space requirements have been verified click Forward to start the actual installation.
  11. Tous les paquetages de logiciel sélectionnés sont installés automatiquement.
  12. Une fois l'installation terminée, vous devrez réinitialiser votre invité :
  13. Votre invité ne va pas redémarrer. Tout au contraire, il va se fermer :
  14. Boot the guest. The guest's name was chosen when you used the virt-install in Section 8.1, « Installer Red Hat Enterprise Linux 5 en tant qu'invité partiellement virtualisé. ». If you used the default example the name is rhel5PV.
    Utiliser virsh pour redémarrer l'invité :
    # virsh reboot rhel5PV
    Autrement, ouvrez virt-manager, sélectionnez le nom de votre invité, cliquez sur Ouvrir, puis sur Exécuter.
    A VNC window displaying the guest's boot processes now opens.
  15. Le démarrage de l'invité lance l'écran de configuration First Boot. Cet assistant vous conduira vers des choix de configuration de base pour votre invité :
  16. Veuillez lire et accepter les termes et conditions de la licence :
    Cliquer sur Suivant dans la fenêtre des termes et conditions.
  17. Configurer le pare-feu.
    Cliquer sur Suivant pour continuer.
    1. Si vous désactivez le pare-feu, vous aurez besoin de confirmer votre choix une fois de plus. Cliquez sur Valider pour confirmer et continuer. Il est recommandé de ne pas désactiver votre pare-feu.
  18. Configurer SELinux. Il est fortement conseillé d'exécuter SELinux en mode enforcing. Vous pourrez choisir d'exécuter SELinux en mode permissif ou de le désactiver complètement :
    Cliquer sur Suivant pour continuer.
    1. Si vous choisissez de désactiver SELinux, cette fenêtre d'avertissement apparaîtra. Cliquez sur Valider pour désactiver SELinux.
  19. Disable kdump. The use of kdump is unsupported on para-virtualized guests.
    Cliquer sur Suivant pour continuer.
  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.
    Cliquer sur Suivant pour continuer.
  21. Paramétrer des mises à jour de logiciel. Si vous possédez un abonnement Red Hat Network, ou si vous souhaitez en essayer un, vous pouvez utiliser l'écran ci-dessous pour enregistrer votre invité nouvellement installé dans RHN.
    Cliquer sur Suivant pour continuer.
    1. Confirmer vos choix pour RHN :
    2. Vous verrez sans doute un écran supplémentaire si vous n'avez pas configuré l'accès RHN. Si l'accès RHN n'est pas configuré, vous ne recevrez pas de mises à jour des logiciels.
      Cliquer sur Suivant.
  22. Créer un compte d'utilisateur normal (non-root). Il est recommandé de créer un compte d'utilisateur normal pour une utilisation normale et pour plus de sécurité. Entrez le nom d'utilisateur, le nom, et le mot de passe.
    Cliquer sur Suivant.
  23. Si un périphérique audio est détecté et que vous avez besoin de son, calibrez-le. Complétez le processus et cliquez sur Suivant.
  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. L'invité peut maintenant reconfigurer tout paramètre que vous avez pu changer et va continuer avec le processus d'initialisation :
  26. La fenêtre de connexion Red Hat Enterprise Linux s'affiche. Connectez-vous à l'aide de votre nom d'utilisateur créé lors des précédentes étapes.
  27. Vous avez maintenant installé avec succès un invité paravirtualisé Red Hat Enterprise Linux.

8.2. Installer Red Hat Enterprise Linux en tant qu'invité totalement virtualisé.

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.
Procédure 8.3. Création d'un invité Red Hat Enterprise Linux 5 totalement virtualisé avec virt-manager.
  1. Ouvrir virt-manager

    Démarrer virt-manager. Lancer l'application Gestionnaire de machines virtuelles à partir du menu Applications et du sous-menu Outils de système. Sinon, exécuter la commande virt-manager en tant que super-utilisateur.
  2. Sélectionner l'hyperviseur

    Sélectionner l'hyperviseur. Si installé, sélectionner Xen ou KVM, pour cet exemple, sélectionner KVM. Remarquez que KVM est actuellement nommé qemu.
    Connect to a hypervisor if you have not already done so. Open the File menu and select the Add Connection... option. Refer to Section 26.1, « The Add Connection window ».
    Une fois la connexion à un hyperviseur sélectionnée, le bouton Nouveau devient disponible. Presser le bouton Nouveau.
  3. Démarrer l'assistant de nouvelle machine virtuelle

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Nommer la machine virtuelle

    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. Choisir une méthode de virtualisation

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (Étape 4) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Sélectionner la méthode d'installation

    Red Hat Enterprise Linux peut être installé à l'aide de l'une des méthodes suivantes :
    • local install media, soit une image ISO ou un média optique physique.
    • Sélectionner Network install tree si l'arbre d'installation pour Red Hat Enterprise Linux est hébergé quelque part sur votre réseau via HTTP, FTP, ou NFS.
    • PXE peut être utilisé si vous possédez un serveur PXE configuré pour démarrer le média d'installation Red Hat Enterprise Linux. La configuration d'un serveur pour démarrer en PXE une installation Red Hat Enterprise Linux n'est pas couverte dans ce guide. Cependant, la plupart des étapes de l'installation sont les mêmes après le démarrage du média.
    Set OS Type to Linux and OS Variant to Red Hat Enterprise Linux 5 as shown in the screenshot.
    Press Forward to continue.
  7. Trouver le média d'installation

    Sélectionner la location de l'image ISO, du lecteur de CD-ROM ou de DVD. Cet exemple utilise une image de fichier ISO du DVD d'installation Red Hat Enterprise Linux.
    1. Cliquez sur le bouton Suivant.
    2. Chercher la location du fichier ISO et sélectionner l'image ISO. Cliquer sur Ouvrir pour confirmer votre sélection.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Fichiers image et 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 Section 18.2, « SELinux et virtualisation » for details.
  8. Installation du stockage

    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.

    Migration

    Live and offline migrations require guests to be installed on shared network storage. For information on setting up shared storage for guests refer to Partie V, « Virtualization Storage Topics ».
  9. Installation de réseau

    Sélectionnez Réseau virtuel ou Périphérique physique partagé.
    L'option de réseau virtuel utilise NAT (de l'anglais Network Address Translation) pour partager le périphérique réseau par défaut avec l'invité partagé. Utiliser l'option réseau virtuel pour les réseaux sans fil.
    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. Allocation de mémoire et CPU

    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.
    Les invités virtualisés ont besoin de suffisamment de mémoire physique (RAM) afin d'être exécutés de manière efficace et effective. Choisir une valeur de mémoire qui correspond aux prérequis de votre système d'exploitation invité et de vos applications. Rappelez-vous que les invités utilisent la mémoire physique. L'exécution de trop d'invités ou le fait de ne pas allouer assez de mémoire pour le système hôte résulte en une utilisation importante de la mémoire virtuelle et provoque des permutations. La mémoire virtuelle est significativement plus lente, causant ainsi une performance et un temps de réponse dégradé. Assurez-vous bien d'allouer suffisamment de mémoire pour permettre à tous les invités et à tous les hôtes d'opérer de manière effective.
    Assigner suffisamment des CPU virtuels pour l'invité virtualisé. Si l'invité exécute une application multi-thread, assigner le nombre de CPU virtuels dont il a besoin pour fonctionner efficacement. Ne pas assigner plus de CPU virtuels que le nombre le processeurs physiques (ou hyper-threads) disponibles sur le système hôte. Il est possible d'allouer trop de processeurs virtuels, cependant, trop en allouer a un effet négatif significatif sur la performance de l'invité et de l'hôte en raison du contexte de processeur qui permute le surchargement.
    Press Forward to continue.
  11. Vérifier et démarrer l'installation de l'invité

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

    Compléter la séquence d'installation de Red Hat Enterprise Linux 5. La séquence d'installation est couverte dans le Guide d'installation, référez-vous à Red Hat Documentation pour voir le Guide d'installation Red Hat Enterprise Linux
Un invité Red Hat Enterprise Linux 5 totalement virtualisé est maintenant installé.

8.3. Installer Windows XP en tant qu'invité totalement virtualisé

Windows XP peut être installé en tant qu'invité totalement virtualisé. Cette section décrit l'installation de Windows XP en tant qu'invité totalement virtualisé sur 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.
Avant de commencer cette procédure, assurez-vous bien d'avoir accès en tant que super-utilisateur.

support Itanium®

Actuellement, les hôtes Red Hat Enterprise Linux sur l'architecture Itanium® ne prennent pas en charge les invités totalement virtualisés Windows XP. Seul Windows Server 2003 pour systèmes basés-Itanium est pris en charge pour les systèmes Itanium.
  1. Démarrage de 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. Nommer votre système virtuel

    Entrez le Nom du système et cliquez sur le bouton Suivant.
  3. Choisir une méthode de virtualisation

    If you selected KVM or Xen earlier (step Étape 1 ) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Windows peut uniquement être installé à l'aide de la virtualisation totale.
  4. Choisir une méthode d'installation

    L'écran permet de spécifier la méthode d'installation ainsi que le type de système d'exploitation.
    Sélectionner Windows à partir de la liste OS Type, et Microsoft Windows XP à partir de la liste de OS Variant.
    L'installation d'invités avec PXE est prise en charge dans Red Hat Enterprise Linux 5.2. L'installation PXE n'est pas couverte dans ce chapitre.

    Fichiers image et 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 Section 18.2, « SELinux et virtualisation » for details.
    Cliquez sur Suivant pour continuer.
  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.
    Cliquez sur Suivant pour continuer.
  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 Section 18.2, « SELinux et virtualisation » for details.
    Allouer de l'espace supplémentaire si l'invité en a besoin pour des applications ou autres données. Par exemple, les serveurs web nécessitent de l'espace supplémentaire pour les fichiers de journalisation.
    Choisir la taille appropriée pour l'invité sur le type de stockage sélectionné, puis cliquer sur le bouton Suivant.

    Note

    Il est recommandé d'utiliser le répertoire par défaut pour les images de machines virtuelles, qui est /var/lib/libvirt/images/ . Si vous utilisez une location différente (comme /images/ dans cet exemple), veillez à ce qu'elle soit ajoutée à votre politique SELinux et qu'elle soit renommée avant de continuer l'installation (vous trouverez plus loin dans le document des informations sur la façon de modifier la politique SELinux)
  7. Installation du réseau

    Sélectionner Réseau virtuel ou Périphérique physique partagé.
    L'option de réseau virtuel utilise NAT (de l'anglais, Network Translation Address) pour partager le périphérique réseau par défaut avec l'invité virtualisé. Utiliser l'option de réseau virtuel pour les réseaux sans fil.
    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.
    Les invités virtualisés requièrent un certain montant de mémoire physique (RAM) pour pouvoir s'exécuter de manière efficace et effective. Choisir une valeur de mémoire qui convient à votre système d'exploitation invité et aux prérequis d'applications. La plupart des système d'exploitation requièrent au moins 512 Mo de RAM afin de fonctionner correctement. Ne pas oublier que les invités utilisent de la mémoire physique (RAM). L'exécution de trop d'invités ou ne pas accorder suffisamment de mémoire pour le système hôte résulte en une utilisation significative de la mémoire virtuelle et en permutation. La mémoire virtuelle est significativement plus lente dégradant ainsi la performance et le temps de réponse du système. Assurez-vous bien d'allouer suffisamment de mémoire pour que l'hôte et tous les invités puissent opérer de manière effective.
    Assigner suffisamment de CPU virtuels pour l'invité virtualisé. Si l'invité exécute une application multithread, assigner le nombre de CPU virtualisés que l'invité nécessite afin de s'exécuter de manière efficace. Ne pas assigner plus de CPU virtuels qu'il n'y a de processeurs physiques (ou d'hyperthreads) disponibles sur le système hôte. Il est possible d'assigner trop de processeurs virtuels, cependant, ceci a un effet négatif important sur les performances de l'hôte et de l'invité à cause du contexte du processeur effectuant des permutations.
  9. Avant que l'installation ne continue, vous verrez l'écran récapitulatif. Cliquer sur Terminer pour procéder à l'installation de l'invité :
  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. L'installation va se dérouler avec l'installation Windows ordinaire :
  12. Partitionner le disque dur lors de l'invite.
  13. Une fois que le disque aura été formaté, Windows commencera à copier les fichiers sur le disque dur :
  14. Les fichiers sont copiés sur le périphérique de stockage, Windows est maintenant en train de redémarrer.
  15. Redémarrer votre invité Windows :
    # virsh start WindowsGuest
    WindowsGuest est le nom de votre machine virtuelle.
  16. Lorsque la fenêtre de la console s'ouvre, vous verrez la phase d'installation de Windows.
  17. Si votre installation semble être bloquée pendant la phase de'installation, vous pouvez redémarrer l'invité en utilisant virsh reboot WindowsGuestName. Quand vous redémarrerez la machine virtuelle, vous verrez le message Setup is being restarted :
  18. Une fois que l'installation est terminée, vous verrez l'écran d'initialisation de Windows:
  19. Maintenant, vous pouvez continuer l'installation standard Windows:
  20. Le processus d'installation est terminé.

8.4. Installation de Windows Server 2003 en tant qu'invité totalement virtualisé

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 Section 8.3, « Installer Windows XP en tant qu'invité totalement virtualisé ».

support Itanium®

Actuellement, les hôtes Red Hat Enterprise Linux sur l'architecture Itanium® ne prennent pas en charge les invités totalement virtualisés Windows. Cette section s'applique uniquement aux hôtes x86 et 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. Après avoir lancé l'installation de votre invité, vous devrez rapidement appuyer sur F5. Si vous ne pressez pas F5 à temps, vous devrez relancer l'installation. Appuyer sur F5 vous permet de choisir un différent HAL ou Type d'ordinateur. Choisir Standard PC pour le Type d'ordinateur. Changer le Type d'ordinateur est nécessaire pour les invités virtualisés Windows Server 2003.
  3. Terminer l'installation comme prévu.
  4. Windows Server 2003 est maintenant installé en tant qu'invité totalement virtualisé.

8.5. Installation de Windows Server 2008 en tant qu'invité totalement virtualisé

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.
Procédure 8.4. Installation de Windows Server 2008 avec virt-manager
  1. Ouvrir virt-manager

    Démarrer virt-manager. Lancer l'application Virtual Machine Manager à partir du menu Applications, et du sous-menu Outils de système. Autrement, exécuter la commande virt-manager en tant que super-utilisateur.
  2. Sélectionner l'hyperviseur

    Sélectionner l'hyperviseur. Si déjà installé, sélectionner Xen ou KVM. Pour cet exemple, sélectionner KVM. Remarquez que KVM est actuellement nommé qemu.
    Une fois l'option sélectionnée, le bouton New devient disponible. Cliquer sur le bouton New.
  3. Lancer l'assistant de nouvelle machine virtuelle

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Nommer la machine virtuelle

    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. Choisir une méthode de virtualisation

    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. Sélectionner la méthode d'installation

    Pour toutes les versions de Windows, vous devez utiliser local install media, soit une image ISO, soit un média optique physique.
    PXE peut être utilisé si vous possédez un serveur PXE configuré pour une installation réseau Windows. L'installation PXE Windows n'est pas couverte dans ce guide.
    Set OS Type to Windows and OS Variant to Microsoft Windows 2008 as shown in the screenshot.
    Press Forward to continue.
  7. Localiser le média d'installation

    Sélectionner l'emplacement de l'image ISO, ou le périphérique CD-ROM ou DVD. Cet exemple se sert d'une image de fichier ISO du CD d'installation de Windows Server 2008.
    1. Cliquez sur le bouton Browse.
    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.

    Fichiers image et 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 Section 18.2, « SELinux et virtualisation » for details.
  8. Installation du stockage

    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. Installation du réseau

    Sélectionner Virtual network ou Shared physical device.
    L'option de réseau virtuel utilise NAT (Network Address Translation) pour partager le périphérique réseau par défaut avec l'invité virtualisé. Utiliser l'option de réseau virtuel pour les réseaux sans fil.
    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. Allocation mémoire et CPU

    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.
    Les invités virtualisés requièrent suffisamment de mémoire physique (RAM) pour s'exécuter de manière efficace et effective. Choisir une valeur de mémoire qui convient aux prérequis du système d'exploitation et des applications de votre invité. Rappelez-vous que les invités utilisent de la RAM physique. L'exécution de trop d'invités ou le manque de mémoire pour le système hôte résulte en une utilisation excessive de la mémoire virtuelle et en "swapping". La mémoire virtuelle est significativement plus lente, ce qui dégrade la performance et le temps de réponse du système. Assurez-vous bien d'allouer suffisamment de mémoire pour que tous les invités et que l'hôte puissent opérer de manière effective.
    Assigner suffisamment de CPU virtuels pour l'invité virtualisé. Si l'invité exécute une application multithread, assigner le nombre de CPU virtualisé que l'invité nécessitera afin de fonctionner de manière efficace. Ne pas assigner plus de CPU qu'il n'y a de processeurs physiques (ou d'hyperthreads) disponibles sur le système hôte. Il est possible d'allouer plus de processeurs virtuels, toutefois, ceci aura un effet négatif et important sur la performance de l'invité et de l'hôte, à cause du contexte du processeur changeant d'overheads.
    Press Forward to continue.
  11. Vérifier et démarrer l'installation de l'invitéXen

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Installation de 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.

Partie III. Configuration

Configuration de la virtualisation dans 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.

Table des matières

9. Virtualized storage devices
9.1. Création d'un contrôleur de lecteur de disquettes virtualisé.
9.2. Ajout de périphériques de stockage aux invités
9.3. Configurer le stockage persistant dans Red Hat Enterprise Linux 5
9.4. Ajoutez les périphériques DVD et CD-ROM virtualisés à un invité.
10. Configuration du réseau
10.1. Traduction d'adresse de réseau (de l'anglais Network Address Translation, ou NAT) avec libvirt
10.2. Réseaux reliés par ponts avec libvirt
11. Réseaux Xen pré-Red Hat Enterprise Linux 5.4
11.1. Configurer les ponts de réseau d'invités multiples en utilisant plusieurs cartes Ethernet
11.2. Configuration de réseau pour ordinateur portable Red Hat Enterprise Linux 5.0
12. Pilotes para-virtualisés Xen
12.1. Prérequis de système
12.2. Support et restrictions en paravirtualisation
12.3. Installation de pilotes paravirtualisés
12.3.1. Etapes habituelles d'installation
12.3.2. Installation et configuration de pilotes paravirtualisés sur Red Hat Enterprise Linux 3
12.3.3. Installation et configuration des pilotes paravirtualisés dans 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. Configuration du pilote du réseau paravirtualisé
12.5. Configuration du matériel supplémentaire de paravirtualisation
12.5.1. Interfaces de réseau virtualisées
12.5.2. Périphériques de stockage virtualisés
13. Pilotes para-virtualisés KVM
13.1. INstallation des pilotes paravirtualisés Windows KVM
13.2. Installing drivers with a virtualized floppy disk
13.3. Utilisation de pilotes paravirtualisés KVM pour des périphériques existants.
13.4. Utilisation de pilotes paravirtualisés KVM pour de nouveaux périphériques.
14. Passe-système PCI
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. Gestion du temps de l'invité KVM

Chapitre 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. Création d'un contrôleur de lecteur de disquettes virtualisé.

Les contrôleurs de lecteurs de disquettes sont nécessaires pour un certain nombre de systèmes d'exploitation, et tout particulièrement pour l'installation de pilotes. à l'instant présent un lecteur de disquettes physique ne peut pas être accédé depuis un invité virtuel. Toutefois, la création et l'accès aux images de disquettes depuis un lecteur de disquettes virtualisé est pris en charge. Cette section couvre la création d'un lecteur de disquettes virtuel.
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

Remarque sur les pilotes para-virtualisés

The para-virtualized drivers can map physical floppy devices to fully virtualized guests. For more information on using para-virtualized drivers read Chapitre 13, Pilotes para-virtualisés KVM.
Cet exemple utilise un invité créé avec virt-manager exécutant une installation Red Hat Enterprise Linux totalement virtualisée avec une image située dans /var/lib/libvirt/images/rhel5FV.img. L'hyperviseur Xen est utilisé dans cet exemple.
  1. Créez le fichier de configuration XML pour votre image d'invité en utilisant la commande virsh sur un invité en cours d'exécution.
    # 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 Chapitre 33, Création de scripts personnalisés libvirt.
  2. Créez une image du lecteur de disquettes pour l'invité.
    # 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. Relancez l'invité à l'aide du fichier de configuration XML.
    # virsh create rhel5FV.xml
    
Le lecteur de disquettes est maintenant disponible dans l'invité et est stocké sous forme d'un fichier image dans l'hôte.

9.2. Ajout de périphériques de stockage aux invités

Cette section couvre l'ajout de périphériques de stockage à l'invité virtualisé. Un stockage supplémentaire ne peut seulement être ajouté une fois que les invités ont été créés. Le protocole et les périphériques de stockage pris en charge incluent :
  • des partitions disque dur locales,
  • des volumes logiques,
  • Fibre Channel ou iSCSI directement connecté sur l'hôte.
  • Les conteneurs de fichiers placés dans le système de gestion de fichiers de l'hôte.
  • Les systèmes de gestion de fichiers NFS montés directement par la machine virtuelle.
  • Stockage iSCSI directement accessible par l'invité.
  • Systèmes de fichiers groupés (GFS).
Ajout de stockage basé sur fichiers à un invité
Le stockage basé sur les fichiers, ou les conteneurs basés sur les fichiers sont des fichiers sur le système de fichiers de l'hôte agissants comme des disques durs virtualisés pour des invités virtuels. Pour ajouter un conteneur basé sur fichiers, suivez les étapes ci-dessous :
  1. Créer un conteneur-fichier vide ou en utiliser un déjà existant (comme un fichier ISO).
    1. Créez un fichier dispersé en utilisant la commande dd. Les fichiers dispersés ne sont pas recommandés suite à des problèmes liés à l'intégrité des données et à la performance. Les fichiers dispersés sont créés bien plus rapidement et peuvent être utilisés en tant que tests mais pas ne devraient pas être utilisés dans un environnement de production.
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
      
    2. Les fichiers non dispersés, pré-alloués sont recommandés pour les images de stockage basées sur les fichiers. Créez un fichier non dispersé, puis exécutez :
      # 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. Vider la configuration pour l'invité. Dans cet exemple, l'invité est appelé Guest1 et le fichier est sauvegardé dans le répertoire de base de l'utilisateur.
    # virsh dumpxml Guest1 > ~/Guest1.xml
    
  3. Ouvrez le fichier de configuration (dans cet exemple, Guest1.xml) dans un éditeur de texte. Puis trouvez les éléments <disk>. Voici un exemple d'élément de disque :
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    
  4. Ajoutez de la mémoire de stockage en dupliquant ou en écrivant un nouvel élément <disk>. Veillez à bien spécifier un nom de périphérique pour les attributs du périphérique virtuel de traitement par blocs. Ces attributs doivent être uniques pour chaque fichier de configuration d'invité. L'exemple suivant est une section d'un fichier de configuration qui contient un conteneur de stockage basé sur fichiers supplémentaire nommé FileName.img.
    <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. Redémarrez l'invité à partir du fichier de configuration mis à jour.
    # 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. Cliquez sur n pour une nouvelle partition.
      # fdisk /dev/sdb
      Command (m for help):
      
    2. Cliquez sur p pour une partition primaire.
      Command action
         e   extended
         p   primary partition (1-4)
      
    3. Choisissez un numéro de partition disponible. Dans cet exemple, la première partition est choisie en saisissant 1.
      Partition number (1-4): 1
      
    4. Saisissez le premier cylindre par défaut en cliquant sur Enter.
      First cylinder (1-400, default 1):
      
    5. Sélectionnez la taille de la partition. Dans cet exemple, le disque entier est alloué en cliquant sur Enter.
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
      
    6. Sélectionnez le type de partition en cliquant sur t.
      Command (m for help): t
      
    7. Choisissez la partition que vous avez créé lors des étapes précédentes. Dans cet exemple, le numéro de la partition est le numéro 1.
      Partition number (1-4): 1
      
    8. Saisissez 83 pour une partition linux.
      Hex code (type L to list codes): 83
      
    9. Écrire les changements sur le disque et quitter.
      Command (m for help): w 
      Command (m for help): q
      
    10. Formattez la nouvelle partition avec le système de fichiers ext3.
      # mke2fs -j /dev/sdb1
      
  7. Montez le disque sur l'invité.
    # mount /dev/sdb1 /myfiles
    
L'invité a maintenant un périphérique de stockage virtuel basé sur fichiers supplémentaire.
Ajoutez des disques durs et autres périphériques de blocage à un invité
System administrators use additional hard drives for to provide more storage space or to separate system data from user data. This procedure, Procédure 9.1, « Ajout d'un périphérique physique de blocage à un invité virtualisé. », describes how to add a hard drive on the host to a virtualized guest.
La procédure fonctionne pour tous les périphériques physiques de traitement par blocs, ceci inclus les CD-ROM, DVD, et disquettes.

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.
Procédure 9.1. Ajout d'un périphérique physique de blocage à un invité virtualisé.
  1. Attachez physiquement le disque dur à l'hôte. Si le disque n'est pas accessible par défaut, veuillez configurer l'hôte.
  2. Configurez le périphérique avec multipath et persistance sur l'hôte si nécessaire.
  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.
    Ajoutez le paramètre --type floppy à la commande pour les lecteurs de disquettes.
    # 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. Configurer le stockage persistant dans Red Hat Enterprise Linux 5

Cette section sert aux systèmes à stockage externe ou en réseau ; autrement dit, pour les périphériques de stockage basé iSCSI ou Fibre Channel. Il est recommandé que les systèmes aient des noms de périphériques persistants configurés pour vos hôtes. Ceci facilite les migrations en direct et permet d'avoir un stockage et des noms de périphériques consistants pour de multiples systèmes virtualisés.
Les UUID (de l'anglais, Universally Unique Identifiers), sont une méthode standardisée d'identification d'ordinateurs et de périphériques dans des environnement de systèmes informatiques distribués. Cette section utilise les UUID pour identifier le numéros d'unités Logiques iSCSI ou Fibre Channel. Ces UUID persistent après les redémarrages, les déconnexions et même les changements de matériel. Une UUID est comparable à l'étiquettage d'un périphérique.
Systems which are not running multipath must use Configuration de chemin d'accès unique. Systems running multipath can use Configuration chemins d'accès-multiples.
Configuration de chemin d'accès unique
This procedure implements LUN device persistence using udev. Only use this procedure for hosts which are not using multipath.
  1. Modifiez le fichier /etc/scsi_id.config.
    1. Vérifiez que la ligne options=-b est bien mise en commentaire.
      # options=-b
      
    2. Ajoutez la ligne suivante :
      options=-g
      
      Cette option configure udev pour assumer que tous les périphériques SCSI attachés retourneront un UUID (UID unique).
  2. Exécutez la commande suivante pour afficher l'UUID d'un périphérique donné: scsi_id -g -s /block/sd*. Par exemple :
    # scsi_id -g -s /block/sd*
    3600a0b800013275100000015427b625e
    
    La sortie peut varier comme indiqué dans l'exemple ci-dessus. La sortie affiche l'UUID du périphérique /dev/sdc.
  3. Vérifier la sortie de l'UUID en regardant si la commande scsi_id -g -s /block/sd* est identique à celle de l'ordinateur qui accède au périphérique.
  4. Créez une règle pour nommer votre périphérique. Créez un fichier nommé 20-names.rules dans le répertoire /etc/udev/rules.d. Ajoutez de nouvelles règles à ce fichier. Toutes les règles sont ajoutées au même fichier en utilisant le même format. Les règles suivent ce format :
    KERNEL=="sd[a-z]", BUS=="scsi", PROGRAM="/sbin/scsi_id -g -s /block/%k", RESULT="UUID", NAME="devicename"
    
    Remplacez UUID et devicename avec le UUID extrait ci-dessus, et le nom désiré pour le périphérique. Dans l'exemple ci-dessus, la règle ressemblerait à ce qui suit :
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="rack4row16"
    
    Le démon udev cherche maintenant tous les périphériques nommés /dev/sd* pour l'UUID dans la règle. Une fois qu'un périphérique correspondant est connecté au système, le nom de la règle lui est assigné. Un périphérique avec un UUID de 3600a0b800013275100000015427b625e apparaîtrait comme /dev/rack4row16.
  5. Ajoutez la ligne suivante à /etc/rc.local :
    /sbin/start_udev
    
  6. Copiez les changements des fichiers /etc/scsi_id.config, /etc/udev/rules.d/20-names.rules, et /etc/rc.local sur tous les hôtes correspondants.
    /sbin/start_udev
    
Les périphériques de stockages en réseau avec des règles configurées ont maintenant des noms persistants sur tous les hôtes où les fichiers ont étés mis à jour. Cela signifie que vous pouvez migrer les invités entre les hôtes qui utilisent un stockage partagé, et que les invités peuvent accéder aux périphériques de stockage dans leurs fichiers de configuration.
Configuration chemins d'accès-multiples
Le paquet multipath est utilisé pour les systèmes ayant plus d'un chemin d'accès physique depuis l'ordinateur vers les périphériques de stockage. multipath offre un certaine tolérance aux défauts, des basculements ainsi qu'une performance améliorée pour les périphériques attachés aux systèmes 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
Les pérphériques à chemins d'accès multiples seront créés dans le répertoire /dev/mpath. Dans l'exemple ci-dessous, 4 périphériques sont définis dans /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. Ajoutez les périphériques DVD et CD-ROM virtualisés à un invité.

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.

Chapitre 10. Configuration du réseau

Cette page offre une intrtoduction aux configurations réseau communes utilisées par des applications basées sur libvirt. Ces informations s'appliquent à tous les hyperviseurs, qu'il s'agisse de Xen, de KVM, ou d'un autre. Pour obtenir des informations supplémentaires, veuillez consulter la documentation d'architecture réseau libvirt.
Les deux configurations les plus communes sont "réseau virtuel" ou "périphérique physique partagé". La première est identique sur toutes les distributions et prête à utiliser. La seconde requiert une configuration manuelle spécifique à la distribution.
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. Traduction d'adresse de réseau (de l'anglais Network Address Translation, ou NAT) avec libvirt

L'une des méthodes les plus communément utilisées pour partager un réseau est le transfert de NAT (aussi connu sous le nom de réseaux virtuels).
Configuration de l'hôte
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
Si ce n'est pas le cas, un exemple du fichier de configuration peut être rechargé et activé :
# virsh net-define /usr/share/libvirt/networks/default.xml
Le réseau par défaut est défini dans /usr/share/libvirt/networks/default.xml
Marquez le réseau par défaut pour qu'il démarre automatiquement :
# virsh net-autostart default
Network default marked as autostarted
Démarrez le réseau par défaut :
# virsh net-start default
Network default started
Une fois que le réseau par défaut libvirt est en cours d'exécution, vous remarquerez un périphérique de pont isolé. Il n'y a aucune interface ajoutée à ce périphérique, car celui-ci utilise les transferts NAT et IP pour se connecter au monde extérieur. N'ajoutez pas de nouvelles interfaces.
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
libvirt ajoute des règles iptables qui permettent le mouvement en provenance et en direction des invités attachés au périphérique virbr0 dans les chaînes INPUT, FORWARD, OUTPUT et POSTROUTING. libvirt tente ensuite d'activer le paramètre ip_forward. Certaines autres applications peuvent désactiver ip_forward, ainsi la meilleure solution est d'ajotuer la ligne suivante à /etc/sysctl.conf.
 net.ipv4.ip_forward = 1
Configuration des invités
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>

Remarque

La définition d'une adresse MAC est optionnelle. Une adresse MAC est générée automatiquement si oubliée. Le paramétrage manuel d'une adresse MAC est utile dans certaines situations.
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
  </interface>

10.2. Réseaux reliés par ponts avec libvirt

Le réseautage par pont (aussi appelé partage de périphériques physiques) est utilisé afin de dédier un périphérique physique à une machine virtuelle. Le pontage est souvent utilisé sur des configurations avancées et sur des serveurs à multiples interfaces réseau.
Désactivez les scripts réseau Xen
Si votre système utilise un pont Xen, il est recommandé de désactiver le pont réseau Xen par défaut en modifiant /etc/xen/xend-config.sxp et en changeant la ligne :
 (network-script network-bridge)
To:
 (network-script /bin/true)
Désactivez 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

Remarque

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.
Création d'initscripts réseau
Créez ou modifiez les deux fichiers de configuration du réseau suivants. Cette étape peut être répétée (avec différents noms) pour des ponts réseau supplémentaires.
Allez sur le répertoire /etc/sysconfig/network-scripts :
# cd /etc/sysconfig/network-scripts
Ouvrez le script réseau du périphérique que vous souhaitez ajouter au pont. Dans cet exemple, ifcfg-eth0 définit l'interface réseau physique qui est paramétrée comme faisant partie d'un pont :
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
Créez un nouveau script réseau dans le répertoire /etc/sysconfig/network-scripts appelé ifcfg-br0 ou autre nom similaire. Le br0 est le nom du pont, ceci peut être ce que l'on veut, tant que le nom du fichier est le même que celui du paramètre DEVICE.
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.

Avertissement

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
Après la configuration, redémarrez le réseau ou la machine.
# service network restart
Configurez iptables afin de permettre à la totalité du trafic d'être transféré à travers le pont.
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Désactivez iptables sur les ponts

Autrement, pour empêcher le trafic à travers les ponts d'être traité par les règles iptables, ajoutez les lignes suivantes dans /etc/sysctl.conf :
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Rechargez les paramètres du noyau configurés avec sysctl.
# sysctl -p /etc/sysctl.conf
Redémarrez le démon libvirt.
# service libvirtd reload
Vous devriez maintenant avoir un "périphérique physique partagé", auquel les invités peuvent être attachés et avoir un accès LAN complet. Vérifiez votre nouveau pont :
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0
Remarquez que le pont est totalement indépendant du pont virbr0. Ne tentez pas d'attacher un périphérique physique à virbr0. Le pont virbr0 ne sert que pour la connectivité NAT (de l'anglais, Network Address Translation).

Chapitre 11. Réseaux Xen pré-Red Hat Enterprise Linux 5.4

Ce chapitre couvre des sujets spéciaux à propos des réseaux et des configurations de réseaux avec l'hyperviseur 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, Chapitre 7, Vue d'ensemble pour l'installation d'invités virtualisés.
Network configuration is also covered in the tool specific reference chapters for virsh (Chapitre 25, Gestion d'invités au moyen de virsh) and virt-manager (Chapitre 26, Gestion des invités avec le gestionnaire de machines virtuelles (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. Chapitre 12, Pilotes para-virtualisés Xen explains how to utilize para-virtualized network drivers.

11.1. Configurer les ponts de réseau d'invités multiples en utilisant plusieurs cartes Ethernet

Procédez à l'installation de ponts de réseau (avec l'hyperviseur Xen) :
  1. Configurez une autre interface de réseau en utilisant l'application system-config-network. Sinon, vous pouvez aussi créer un nouveau fichier de configuration nommé ifcfg-ethX dans le répertoire /etc/sysconfig/network-scripts/, dans lequel X sera n'importe quel chiffre qui n'est pas déjà en cours d'utilisation. Vous trouverez ci-dessous un exemple de fichier de configuration pour la seconde interface de réseau intitulée 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. Copiez le fichier /etc/xen/scripts/network-bridgevers /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. Configuration de réseau pour ordinateur portable Red Hat Enterprise Linux 5.0

Pour Red Hat Enterprise Linux 5.1 ou plus récent

Cette section décrit l'ajout manuel de ponts de réseaux. Cette procédure n'est ni requise, ni recommandée pour les versions de Red Hat Enterprise Linux plus récentes que la version 5.0. Pour les versions plus récentes, veuillez utiliser des adaptateurs "Virtual Network" lors de la création d'invités dans virt-manager. NetworkManager fonctionne avec des périphériques de réseaux virtuels par défaut sur Red Hat Enterprise Linux 5.1 et autres versions plus récentes.
Un exemple de fichier de configuration XML de virsh pour un périphérique de réseau virtuel :
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
</interface>
Dans les fichiers de configuration xm, les périphériques de réseau virtuels sont étiquettés "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.
Cette configuration va également vous permettre d'exécuter Xen en mode hors ligne lorsque vous n'avez pas de connexion active sur votre ordinateur portable. La solution la plus facile pour exécuter Xen sur un ordinateur portable est de suivre la procédure qui suit :
  • 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.
  • Vous aurez besoin d'utiliser des adresses IP statiques car DHCP ne répondra pas à l'interface fictive pour les requêtes DHCP. Vous pouvez compiler votre propre version de DHCP pour écouter les interfaces fictives. Cependant, vous souhaiterez peut-être utiliser dnsmasq pour les services DNS, DHCP et tftpboot dans l'environnement Xen. L'installation et la configuration sont expliquées plus loin dans cette section/chapitre.
  • Vous pouvez aussi configurer un déguisement NAT et IP afin de permettre l'accès au réseau à partir de vos invités.
Configurer une interface de réseau virtuelle
Procédez aux étapes suivantes de configuration sur votre hôte :
  1. créer une interface de réseau fictive 'dummy0' et lui assigner une adresse IP statique. Dans notre exemple I sélectionner 10.1.1.1 pour éviter des problèmes de routing dans notre environnement. Pour activer le support pour le périphérique fictif, ajouter les lignes suivantes à /etc/modprobe.conf
    alias dummy0 dummy
    options dummy numdummies=1
    
  2. Pour configurer le réseau de 'dummy0' modifier/créer /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. Associer xenbr0 à dummy0, de façon à pouvoir utiliser le réseau même lorsque vous n'êtes pas connecté à un réseau physique. Modifiez /etc/xen/xend-config.sxp pour inclure la saisie /etc/xen/xend-config.sxp :
    (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'installation de NAT dans l'hôte permettraaux invités d'accéder à internet, même sans fil, résolvant ainsi les problèmes de Xen et de cartes sans fil. Le script ci-dessous va activer NAT sur l'interface en cours d'utilisation pour votre connexion réseau.
Configuration NAT pour des invités virtualisés
NAT (de l'anglais, Network Address Translation / traduction de l'adresse réseau) permet à de multiples adresses réseau de se connecter à partir d'une seule adresse IP en interceptant des paquets et en les passant à des adresses IP privées. Vous pouvez copier le script suivant dans /etc/init.d/xenLaptopNAT et créer un lien symbolique dans /etc/rc3.d/S99xenLaptopNAT. Cela a pour effet de démarrer NAT automatiquement pendant la phase de lancement.

NetworkManager et NAT sans fil

Le script ci-dessous pourrait ne pas très bien fonctionner en réseau sans fil ou dans l'application NetworkManager à cause des délais au démarrage. Dans un tel cas, exécuter le script manuellement une fois que la machine est lancée.
#!/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
Configurer dnsmasq pour les services DNS, DHCP et tftpboot
L'une des difficultés pour exécuter une virtualisation sur un ordinateur portable (ou tout autre ordinateur qui n'est pas connecté à un réseau unique ou stable), est le changement des interfaces de réseau et leur disponibilité. En utilisant une interface de réseau fictive, vous construisez un environnement plus stable, mais cela entraîne de nouveaux problèmes pour offrir des services DHCP, DNS ou tftboot à vos machines virtualisées/invités. Le démon DHCP par défaut, procuré avec Red Hat Enterprise Linux et Fedora Core ne sera pas réceptif aux interfaces fictives. Vos informations transférées par DNS peuvent changer quand vous vous connectez à différents réseaux et VPN.
Une solution aux problèmes ci-dessus est d'utiliser dnsmasq, qui peut apporter tous les services mentionnés ci-dessus dans un seul paquetage, et vous permettra également de contrôler ses services en étant uniquement disponible aux requêtes provenant de l'interface fictive. Vous trouverez ci-dessous une façon de formuler la configuration dnsmasq sur un ordinateur portable exécutant une virtualisation :
  • Vous pouvez obtenir la dernière version de dnsmasq here.
  • 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 peut être utilisé comme script de répartition pour le NetworkManager (gestionnaire de réseau). Il sera exécuté à chaque fois que le NetworkManager détecte un changement de connexité et force un redémarrage/rechargement de dnsmasq. Il peut être copié dans /etc/NetworkManager/dispatcher.d/nm-dnsmasq
    • xenDNSmasq peut être utilisé comme script principal de démarrage ou de fermeture de /etc/init.d/xenDNSmasq
    • dnsmasq.conf est un exemple de fichier de configuration pour/etc/dnsmasq.conf
    • dnsmasq est une image binaire de /usr/local/sbin/dnsmasq
  • Une fois que vous avez dépaqueté et construit dnsmasq (l'installation par défaut sera le binaire dans /usr/local/sbin/dnsmasq), vous devrez modifier votre fichier de configuration dnsmasq. Le fichier est situé dans /etc/dnsmaqs.conf
  • Modifier la configuration pour répondre aux besoins locaux. Les paramètres suivants sont certainement ceux que vous souhaiterez modifier:
    • Le paramètre d'interface permet à dnsmasq d'écouter les demandes DHCP et DNS sur des interfaces spécifiques uniquement. Il peut s'agir d'interfaces fictives mais pas de vos interfaces publiques en plus de votre interface locale de bouclage. Répétez la ligne interface pour plus d'une interface. interface=dummy0 est une exemple qui écoute l'interface dummy0.
    • dhcp-range pour activer le serveur intégré DHCP, vous devez fournir le groupe d'adresses disponibles à louer et éventuellement la durée de location. Si vous avez plus d'un réseau, vous devrez répéter l'opération pour chaque réseau pour lequel vous souhaitez offrir le service DHCP. Par exemple (pour le réseau 10.1.1.* et une durée de 12h): dhcp-range=10.1.1.10,10.1.1.50,255.255.255.0,12h
    • dhcp-option pour remplacer la route par défaut fournie par dnsmasq, qui assume que le router est la même machine que celle qui exécute dnsmasq. Un exemple serait dhcp-option=3,10.1.1.1
  • Après avoir configuré dnsmasq, vous pourrez copier le script ci-dessous xenDNSmasq vers /etc/init.d
  • Si vous souhaitez démarrer dnsmasq automatiquement pendant le lancement du système, vous devrez l'enregistrer en utilisant chkconfig(8):
    chkconfig --add xenDNSmasq
    
    L'activer pour le démarrage automatique:
    chkconfig --levels 345 xenDNSmasq on
    
  • Pour configurer dnsmasq de façon à ce qu'il redémarre à chaque fois que NetworkManager détecte un changement de connexité, vous pouvez utiliser le script nm-dnsmasq.
    • Copier le script nm-dnsmasq dans /etc/NetworkManager/dispatcher.d/
    • Le répartiteur NetworkManager va exécuter le script (par ordre alphabétique si vous avez d'autres scripts dans le même répertoire) à chaque fois qu'il y a un changement de connexité.
  • dnsmasq détectera aussi les changements dans votre fichier /etc/resolv.conf et les rechargera automatiquement (par exemple, lorsque vous démarrez une session VNP).
  • Les deux scripts nm-dnsmasq et xenDNSmasq installeront également NAT si vos invités virtuels sont placés dans un réseau caché afin de leur permettre d'accéder au réseau public.

Chapitre 12. Pilotes para-virtualisés 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.

Autres pilotes para-virtualisés

Il existe d'autres pilotes paravirtualisés pour Windows avec hyperviseurs Xen et KVM.
Pour les invités Windows sur des hôtes Xen, veuillez vous référer au Guide des pilotes paravirtualisés Windows, qui couvre leur installation et leur gestion.
For Windows guests on KVM hosts, refer to Chapitre 13, Pilotes para-virtualisés KVM.
Les paquetages RPM destinés aux invités paravirtualisés incluent des modules de stockage et de mise en réseau de pilotes paravirtualisés pour les systèmes d'exploitation invités Red Hat Enterprise Linux. Ces pilotes permettent des débits de traitement des opérations E/S de haute performance dans des systèmes d'exploitation invités Red Hat Enterprise Linux non modifiés sur un hôte Red Hat Enterprise Linux 5.1 (ou version supérieure).
Les systèmes d'exploitation d'invités supportés sont:
  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5

Architecture de support pour les pilotes paravirtualisés

Les prérequis de système d'exploitation d'invité minimum sont dépendants de l'architecture. Seuls les invités x86 et x86-64 sont pris en charge.
Les pilotes ne sont pas supportés par les systèmes d'exploitation des invités Red Hat Enterprise Linux antérieurs à Red Hat Enterprise Linux 3.
Utiliser Red Hat Enterprise Linux 5 en tant que plateforme, permet aux administrateurs de systèmes de consolider les charges de travail de Linux et Window dans du matériel plus récent et plus performant, possédant des qualités de refroidissement et de puissance supérieures. Les systèmes d'exploitation d'invités Red Hat Enterprise Linux 4 (jusqu'à la version 6) et Red Hat Enterprise Linux 5 sont conscients de la technologie de virtualisation sous-jacente et peuvent interagir avec, de façon efficace, en utilisant des capacités et des interfaces spécifiques. Cette approche peut mener à une vitesse de traitement de l'information et à des critères de performance similaires aux opérations sur systèmes 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.
Les pilotes des périphériques paravirtualisés sont inclus dans les paquetages Red Hat Enterprise Linux. Ces pilotes apportent de nombreux avantages de performance spécifiques aux systèmes d'exploitation invitésparavirtualisés aux systèmes d'exploitation non modifiés, car seul le pilote du périphérique paravirtualisé (mais pas le reste du système d'exploitation) est conscient de la plateforme de virtualisation sous-jacente.
Après avoir installé les pilotes des périphériques de paravirtualisation, un lecteur de disques ou une carte réseau apparaîtront toujours comme un disque physique, normal ou comme une carte réseau du système d'exploitation. Cependant, le pilote du périphérique interacte maintenant directement avec la plateforme de virtualisation (sans émulation) pour fournir un accès réseau et un disque de façon efficace, permettant ainsi au disque et aux sous-systèmes du réseau d'opérer à des vitesses d'origine, même dans un environnement totalement virtualisé, sans pour autant avoir besoin de faire des changements dans les systèmes d'exploitation des invités existants.
Les pilotes paravirtualisés ont certains besoins spécifiques quant aux hôtes. Les hôtes 64 bit peuvent exécuter :
  • Des invités 32 bit.
  • Des invités 64 bit.
  • un mélange d'invités 32 et 64 bit.

12.1. Prérequis de système

Cette section détaille les besoins des pilotes paravirtualisés avec Red Hat Enterprise Linux.
Installation
Avant d'installer les pilotes paravirualisés, on doit remplir les critères suivants (voir la liste ci-dessous):

Red Hat Enterprise Linux 4.7, 5.3 et versions plus récentes

Toutes les versions de Red Hat Enterprise Linux entre 4.7 et 5.3 ont un module du noyau pour les pilotes paravirtualisés, le module pv-on-hvm, dans le paquetage du noyau par défaut. Cela signifie que les pilotes paravirtualisés sont disponibles pour Red Hat Enterprise Linux 4.7 et versions plus récentes ou pour Red Hat Enterprise Linux5.3 et versions plus récentes.
Vous aurez besoin des paquetages RPM suivants pour les pilotes paravirtualisés de chaque installation de système d'exploitation d'invité.
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. Support et restrictions en paravirtualisation

Cette section décrit les restrictions de support et les besoins pour utiliser les pilotes paravirtualisés sur Red Hat Enterprise Linux. Ce que nous supportons et les restrictions qui y sont attachées, peut être trouvé dans les sections qui suivent.
Systèmes d'exploitation invités supportés.
Le support pour les pilotes paravirtualisés est disponible pour les systèmes d'exploitation et versions suivantes:
  • Red Hat Enterprise Linux 5.1 et versions plus récentes.
  • Red Hat Enterprise Linux 4 Version 6 et versions plus récentes.
  • Red Hat Enterprise Linux 3 Version 9 et versions plus récentes.
Vous êtes supportés si vous opérez un système d'exploitation invité de 32 bit avec des pilotes paravirtualisés sur une Red Hat Enterprise Linux 5 Virtualization de 64 bit.
La table suivante indique les variantes de noyaux supportés par les pilotes paravirtualisés. Vous pouvez utiliser la commande indiquée ci-dessous pour identifier la révision de noyau exacte installée couramment sur votre hôte. Comparer la sortie par rapport à la table pour déterminer si c'est supporté.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Les variantes de noyaux Red Hat Enterprise Linux 5 i686 et x86_64 incluent le multitraitement symétrique, aucun RPM à noyau SMP séparé n'est nécessaire.
Veuillez noter les besoins des noyaux à processeur particuliers pour les invités Red Hat Enterprise Linux 3 dans la table ci-dessous.
Tableau 12.1. Les architectures de noyaux invités supportés pour les pilotes paravirtualisés
Architecture de noyau Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5
athlon Supporté (AMD)   
athlon-SMP Supporté (AMD)   
i32e Supporté (Intel)   
i686 Supporté (Intel) Supporté Supporté
i686-PAE Supporté
i686-SMP Supporté (Intel) Supporté  
i686-HUGEMEM Supporté (Intel) Supporté  
x86_64 Supporté (AMD) Supporté Supporté
x86_64-SMP Supporté (AMD) Supporté  
x86_64-LARGESMP Supporté  
Itanium (IA64) Supporté

Important

Le système hôte requiert Red Hat Enterprise Linux 5.1 ou version supérieure.

Trouver le noyau que vous utilisez

Inscrivez la sortie de commande ou mémorisez-la. Il s'agit de la valeur qui détermine quels paquetages et quels modules vous avez besoin de décharger.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Votre sortie doit ressembler à quelque chose comme cela:
kernel-PAE-2.6.18-53.1.4.el5.i686
Le nom du noyau est PAE (de l'anglais, Physical Address Extensions), la version de noyau est 2.6.18, la mise à jour est 53.1.4.el5 et l'architecture est i686. Le rpm du noyau doit toujours apparaître sous le format kernel-name-version-release.arch.rpm.
Restrictions importantes
Les pilotes de périphériques paravirtualisés peuvent être ajoutés après l'installation d'un système d'exploitation invité. Vous aurez besoin d'un hôte et d'un invité opérationnels avant que vous puissiez installer ces pilotes.

Périphériques en bloc paravirtualisés et GRUB.

GRUB ne peut pas actuellement accéder à des périphériques en bloc paravirtualisés. De ce fait, un invité ne peut pas être initialisé à partir d'un périphérique qui utilise les pilotes de périphériques en bloc paravirtualisés, ou plus spécifiquement, un disque qui contient le Master Boot Record (MBR), un disque qui contient un chargeur d'amorçage (GRUB), ou un disque qui contient les images du noyau initrd. Donc, tout disque qui contient un répertoire ou une partition /boot ne peut pas utiliser les pilotes de périphériques en bloc paravirtualisés.
Les dépendances de l'architecture de noyau variant Red Hat Enterprise Linux 3
Pour les systèmes d'exploitation invité Red Hat Enterprise Linux 3, vous devez utiliser le noyau spécifique au processeur et les RPM de pilote paravirtualisé, suivant les indications dans les tables ci-dessous. Si vous ne parvenez pas à installer le paquetage de pilote paravirtualisé correspondant, le chargement du module xen-pci-platform échouera.
La table ci-dessous montre le noyau d'hôte qu'il faut pour exécuter un invité Red Hat Enterprise Linux 3 si l'invité était compilé pour un processeur Intel.
Tableau 12.2. Architecture de noyau d'hôte requise pour les invités qui utilisent des pilotes paravirtualisés sur Red Hat Enterprise Linux 3 pour les processeurs Intel.
Type de noyau d'hôte Type de noyau d'hôte requis
ia32e (UP et SMP) x86_64
i686 i686
i686-SMP i686
i686-HUGEMEM i686

La table ci-dessous montre quel noyau d'hôte est requis pour exécuter un invité Red Hat Enterprise Linux 3 quand l'invité était compilé pour un processeur AMD.
Tableau 12.3. Architectures de noyau d'hôte requise pour des invités qui utilisent des pilotes paravirtualisés sur Red Hat Enterprise Linux 3 pour des processeurs AMD.
Type de noyau d'hôte Type de noyau d'hôte requis
athlon i686
athlon-SMP i686
x86_64 x86_64
x86_64-SMP x86_64

12.3. Installation de pilotes paravirtualisés

Les trois chapitres suivants décrivent comment installer et configurer vos invités totalement virtualisés pour qu'ils puissent exécuter Red Hat Enterprise Linux 5.1 ou versions supérieures sur des pilotes paravirtualisés.

Vérifier que votre architecture est prise en charge avant de continuer

Les pilotes paravirtualisés ne sont pris en charge que sur certaines combinaisons de versions et de matériel. Vérifier que les prérequis de votre matériel et de votre système d'exploitation sont respectés, avant de procéder à l'installation des pilotes paravirtualisés.

Maximiser les avantages des pilotes paravirtualisés pour les nouvelles installations

Si vous installez un nouveau système d'invités, en vue de gagner le plus de bénéfice possible de vos pilotes de périphériques paravirtualisés, vous devrez créer un invité avec deux disques au moins.
L'utilisation de pilotes paravirtualisés pour le disque qui contient le MBR, le chargeur d'amorçage (GRUB), et pour la partition /boot. Cette partition peut être très petite, car elle ne nécessite seulement d'avoir la capacité de contenir la partition /boot.
Utilisez le second disque et n'importe quel disque supplémentaire pour toutes les autres partitions ( par ex. /, /usr) ou bien pour les volumes logiques.
En utilisant cette méthode d'installation, quand les pilotes de blocs de périphériques paravirtualisés auront été installés, suite à l'installation de l'invité, on n'utilisera les pilotes de blocs de périphériques paravirtualisés uniquement pour initialiser l'invité et pour accéder à la partition /boot.

12.3.1. Etapes habituelles d'installation

La liste ci-dessous couvre les étapes principales communes à travers les versions de systèmes d'exploitation des invités.
  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 Section 12.2, « Support et restrictions en paravirtualisation ».
  2. Utiliser les commandes rpm ou yum pour installer les paquetages. L'utilitaire rpm installera les quatre nouveaux modules de noyaux suivants dans /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. Si l'invité en cours d'exécution ne supporte pas le chargement automatique des pilotes paravirtualisés (comme dans le cas de Red Hat Enterprise Linux 3), procédez aux étapes de post installation nécessaires pour copier les pilotes dans des locations spécifiques du système d'exploitation.
  4. Fermer le système d'exploitation de votre invité.
  5. Reconfigure the guest operating system's configuration file on the host to use the installed para-virtualized drivers.
  6. Supprimer la saisie “type=ioemu” pour le périphérique du réseau.
  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. Toute entité de stockage supplémentaire que vous souhaitez utiliser pour le pilote du périphérique de bloc paravirtualisé.
  11. Redémarrer votre invité :
    # 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. Installation et configuration de pilotes paravirtualisés sur Red Hat Enterprise Linux 3

Cette section contient des instructions détaillées sur les pilotes paravirtualisés des systèmes d'exploitation des invités dans Red Hat Enterprise 3.

Remarque

Ces paquetages ne supportent pas l'initialisation à partir d'un disque paravirtualisé. Le démarrage du noyau du système d'exploitation invité nécessite toujours l'utilisation du pilote IDE émulé, tandis que toute autre application (non-système) espace utilisateur et données, peut utiliser les pilotes de périphériques de traitement par blocs paravirtualisés.
Installation du pilote
La liste ci-dessous comprend les étapes d'installation des pilotes paravirtualisés pour les invités Red Hat Enterprise Linux 3.
  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. Copier le rpm kmod-xenpv correspondant à l'architecture de votre matériel et à la variante de noyau du système d'exploitation de votre invité.
  3. Utiliser la commande rpm pour installer les paquetages RPM. Veillez d'avoir bien identifié le paquetage dont vous avez besoin pour la variante et l'architecture du système d'exploitation de votre invité.
    [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
    

    Remarque

    Des avertissements seront générés par insmod au moment de l'installation des modules binaires du pilote, dû au fait que l'application MODVERSIONS de Red Hat Enterprise Linux 3 est activée. Ces avertissements peuvent être ignorés.
  5. Vérifier /etc/modules.conf et assurez-vous que vous avez un alias pour eth0 comme celui qui figure ci-dessous. Si vous envisagez de configurer plusieurs interfaces, ajouter une ligne supplémentaire pour chaque interface.
    alias eth0 xen-vnif
    
    Modifier /etc/rc.local et ajouter la ligne de commande:
    insmod /lib/modules/'uname -r'/extra/xenpv/%release/xen-vbd.o
    

    Remarque

    Substituter “%release” avec la dernière version (par exemple 0.1-5.el) pour les pilotes paravirtualisés. Si vous mettez à jour le paquetage RPM du pilote paravirtualisé, veillez à mettre à jour la version qui convient.
  6. Fermer la machine virtualisée (utiliser “#shutdown -h now” dans l'invité).
  7. Edit the guest configuration file in /etc/xen/YourGuestName with a text editor, performing the following changes:
    • Supprimez la saisie “type=ioemu” de “vif=”.
    • Ajouter toute partition de disque supplémentaire, tout volume ou LUN à l'invité de façon à ce qu'ils puissent être accédés par le pilote du disque paravirtualisé (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.

Attention

Les pilotes paravirtualisés ne sont pas ajoutés ou chargés automatiquement dans le système car le support de weak-modules et modversions n'est pas offert pour Red Hat Enterprise Linux 3. Pour insérrer le module, exécuter la commande ci-dessous.
insmod xen_vbd.ko
Red Hat Enterprise Linux 3 nécessite la création manuelle de fichiers spéciaux pour les périphériques en bloc xen-vbd. Les étapes suivantes expliquent comment créer et enregistrer les périphériques en bloc virtualisés.
Utiliser le script suivant pour créer les fichiers spéciaux après que le pilote des périphériques en bloc paravirtualisé soit chargé.
#!/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*
Pour chaque disque supplémentaire, augmenter le nombre mineur (minor number) de 16. Dans l'exemple qui suit, une périphérique supplémentaire, nombre mineur 16, est créé.
# mknod /dev/xvdc b $major 16
# mknod /dev/xvdc1 b $major 17
Cela permettrait de créer le prochain périphérique 32:
# mknod /dev/xvdd b $major 32
# mknod /dev/xvdd1 b $major 33
Vous devrez vérifier que les partitions que vous avez créées sont bien disponibles.
[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
Dans la sortie suivante, vous pouvez remarquer que le périphérique partitionné “xvdb” est disponible pour le système.
La procédure ci-dessous ajoute le nouveau périphérique à l'invité et le rend persistant après le redémarrage. Toutes ces commandes sont exécutées sur l'invité.
  1. Créer des répertoires pour y monter l'image du périphérique de traitement par blocs.
    [root@rhel3]# mkdir /mnt/pvdisk_p1
    [root@rhel3]# mkdir /mnt/pvdisk_p2
    
  2. Monter les périphériques sur les nouveaux dossiers.
    [root@rhel3]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel3]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Vérifier que les périphériques sont montés correctement.
    [root@rhel3]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Mettre à jour le fichier /etc/fstab dans l'invité pour monter les périphériques lors de la séquence de démarrage. Ajouter les lignes suivantes :
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Conseil de performance

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 Red Hat Enterprise Linux 5.2 dom0 n'aura pas besoin de ce paramètre de noyau pour cet invité.

Important

Les paquetages et versions RPM binaires Itanium (ia64) ne sont pas actuellement disponibles.

12.3.3. Installation et configuration des pilotes paravirtualisés dans Red Hat Enterprise Linux 4

Cette section contient des instructions détaillées pour les pilotes paravirtualisés des systèmes d'exploitation d'invités dans Red Hat Enterprise Linux 4.

Remarque

Ces paquetages ne supportent pas l'initialisation à partir d'un disque paravirtualisé. Le démarrage du noyau du système d'exploitation invité nécessite toujours l'utilisation du pilote IDE émulé, tandis que toute autre application (non-système) espace utilisateur ou données, peut utiliser les pilotes de périphériques de traitement par blocs paravirtualisés.
Installation du pilote
La liste ci-dessous comprend les étapes d'installation des pilotes paravirtualisés pour les invités qui possèdent des pilotes Red Hat Enterprise Linux 4.
  1. Copier les RPM kmod-xenpv, modules-init-tools et modversions correspondants à l'architecture de votre matériel et à la variante de noyau du système d'exploitation de votre invité.
  2. Utiliser la commande rpm pour installer les paquetages RPM. Veillez d'avoir bien identifié les paquetages dont vous avez besoin pour la variante et l'architecture de votre système d'exploitation invité. Il est nécessaire de faire une mise à jour du module-init-tools, disponible dans le noyau Red Hat Enterprise Linux 4-6-z et au delà.
    [root@rhel4]# rpm -ivh modversions
    [root@rhel4]# rpm -Uvh module-init-tools
    [root@rhel4]# rpm -ivh kmod-xenpv*
    

    Remarque

    Il existe divers paquetages pour UP, SMP, Hugemem et les architectures différentes, donc assurez-vous bien d'avoir les bons RPM qui conviennent à votre noyau.
  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. Fermer la machine virtualisée (utiliser “#shutdown -h now” dans l'invité).
  5. Modifier le fichier de configuration de l'invité dans /etc/xen/YourGuestsName des manières suivantes:
    • Supprimez la saisie “type=ioemu” de “vif=”.
    • Ajouter toute partition de disque supplémentaire, tout volume ou LUN à l'invité de façon à ce qu'ils puissent être accédés par le pilote du disque paravirtualisé (xen-vbd) .
    • Pour chaque périphérique physique supplémentaire, LUN, partition ou volume, ajouter une entrée similaire à celle qui apparaît ci-dessous dans la section “disk=” du fichier de configuration de l'invité. L'entrée de départ “disk=” pourrait également ressembler à l'entrée suivante.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    • Une fois que vous avez ajouté les périphériques physiques additionnels, LUN, partitions ou volumes, l'entrée de votre pilote paravirtualisé dans votre fichier de configuration XML devrait ressembler à ce qui suit.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Remarque

      Utiliser la commande “tap:aio” pour le périphérique paravirtualisé si une image basée-fichier est utilisée.
  6. Démarrer la machine virtuelle en utilisant la commande virsh :
    # virsh start YourGuestName
Au premier démarrage de l'invité virtuel, kudzu vous demandera "Conserver ou supprimer le périphérique Realtek Network " et "Configure le xen-bridge ". Vous devez configurer xen-bridge et effacer le périphérique de réseau Realtek.

Conseil de performance

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 Red Hat Enterprise Linux 5.2 dom0 n'aura pas besoin de ce paramètre de noyau pour cet invité.
Maintenant, vérifier que les partitions que vous avez créées sont bien disponibles.
[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
Dans la sortie ci-dessus, vous pouvez observer que le périphérique partitionné “xvdb” est disponible pour le système.
La procédure ci-dessous ajoute le nouveau périphérique à l'invité et le rend persistant après le redémarrage. Toutes commandes sont exécutées sur l'invité.
  1. Créer des répertoires pour y monter l'image du périphérique de traitement par blocs.
    [root@rhel4]# mkdir /mnt/pvdisk_p1
    [root@rhel4]# mkdir /mnt/pvdisk_p2
    
  2. Monter les périphériques sur les nouveaux dossiers.
    [root@rhel4]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel4]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Vérifier que les périphériques sont montés correctement.
    [root@rhel4]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Mettre à jour le fichier /etc/fstab dans l'invité pour monter les périphériques lors de la séquence de démarrage. Ajouter les lignes suivantes :
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Remarque

Ce paquetage n'est pas supporté par REd Hat Enterprise Linux 4-GA à travers la seconde mise à jour Red Hat Enterprise Linux 4 appliquable aux systèmes et aux noyaux.

Remarque importante

les paquetages et les versions IA64 binary RPM ne sont pas disponibles actuellement.

Chargement automatique de module

Si le pilote xen-vbd n'est pas chargé automatiquement, lancer la commande suivante dans l'invité. Substituer %version par la version qui convient pour les pilotes paravirtualisés.
# 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.

Remarque

Ces paquetages ne supportent pas l'initialisation à partir d'un disque paravirtualisé. Le démarrage du noyau du système d'exploitation invité nécessite toujours l'utilisation du pilote IDE émulé, tandis que toute autre application (non-système) espace utilisateur ou données, peut utiliser les pilotes de périphériques de traitement par blocs paravirtualisés.
The procedure below covers the steps to enable the para-virtualized drivers for a Red Hat Enterprise Linux 5 guest.
Procédure 12.1. Enable para-virtualized drivers for a Red Hat Enterprise Linux Guest
  1. Fermer la machine virtualisée (utiliser “#shutdown -h now” dans l'invité).
  2. Modifier le fichier de configuration de l'invité dans /etc/xen/YourGuestsName des manières suivantes:
    1. Supprimez la saisie “type=ioemu” de “vif=”.
    2. Ajouter toute partition de disque supplémentaire, tout volume ou LUN à l'invité de façon à ce qu'ils puissent être accédés par le pilote du disque paravirtualisé (xen-vbd) .
    3. Pour chaque périphérique physique supplémentaire, LUN, partition ou volume, ajouter une entrée similaire à celle qui apparaît ci-dessous dans la section “disk=” du fichier de configuration de l'invité. L'entrée de départ “disk=” pourrait également ressembler à l'entrée suivante.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    4. Une fois que vous avez ajouté les périphériques physiques additionnels, LUN, partitions ou volumes, l'entrée de votre pilote paravirtualisé dans votre fichier de configuration XML devrait ressembler à ce qui suit.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Remarque

      Utiliser la commande “tap:aio” pour le périphérique paravirtualisé si une image basée-fichier est utilisée.
  3. Démarrer la machine virtuelle en utilisant la commande virsh :
    # virsh start YourGuestName
    
Pour vérifier que l'interface de réseau est bien établie après avoir installé les pilotes paravirtualisés, donnez les instructions suivantes à l'invité. Cela devrait afficher l'information de l'interface, y compris l'adresse IP assignée.
[root@rhel5]# ifconfig eth0
Maintenant, vérifier que les partitions que vous avez créées sont bien disponibles.
[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
Dans la sortie ci-dessus, vous pouvez observer que le périphérique partitionné “xvdb” est disponible pour le système.
La procédure ci-dessous ajoute le nouveau périphérique à l'invité et le rend persistant après le redémarrage. Toutes ces commandes sont exécutées sur l'invité.
  1. Créer des répertoires pour y monter l'image du périphérique de traitement par blocs.
    [root@rhel5]# mkdir /mnt/pvdisk_p1
    [root@rhel5]# mkdir /mnt/pvdisk_p2
    
  2. Monter les périphériques sur les nouveaux dossiers.
    [root@rhel5]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel5]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Vérifier que les périphériques sont correctement montés.
    [root@rhel5]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Mettre à jour le fichier /etc/fstab dans l'invité pour monter les périphériques lors de la séquence démarrage. Ajouter les lignes suivantes :
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Conseil de performance

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 Red Hat Enterprise Linux 5.2 dom0 n'aura pas besoin de ce paramètre de noyau pour cet invité.
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. Configuration du pilote du réseau paravirtualisé

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.
Procédez aux étapes suivantes en vue de reconfigurer l'interface de réseau dans l'invité.
  1. Dans la commande virt-manager , ouvrir la fenêtre de la console pour l'invité et connectez en tant que root.
  2. Dans Red Hat Enterprise Linux 4 vérifier que le fichier /etc/modprobe.conf contienne la ligne de commande “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 Section 36.4, « Charger manuellement les pilotes paravirtualisés ».
    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. Vous devriez maintenant voir apparaître la nouvelle interface de réseau avec la nouvelle adresse IP qui lui est assignée.
    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. Configuration du matériel supplémentaire de paravirtualisation

Cette section explique comment ajouter une mémoire de stockage ou un réseau virtuel supplémentaire à un système d'exploitation d'un invité. Pour davantage de renseignements sur la façon de configurer les réseaux et les ressources de stockage sur Red Hat Enterprise Linux 5 Virtualization, lire le document Emerging Technologies, Red Hat.com

12.5.1. Interfaces de réseau virtualisées

Procéder aux étapes suivantes pour configurer les périphériques de réseau supplémentaires pour votre invité.
Modifier le fichier de configuration dans /etc/xen/YourGuestName en remplaçant YourGuestName par le nom de votre invité.
La saisie d'origine ressemble probablement à ce qui suit.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0" ]
Ajouter une saisie supplémentaire à celle qui suit ci-dessous “vif=” dans la section du fichier de configuration.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0",
    "mac=00:16:3e:2f:d5:a9,bridge=xenbr0" ]
Veillez à générer une adresse MAC unique pour la nouvelle interface. Vous pouvez utiliser la commande ci-dessous.
# echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
Après que l'invité ait été réinitialisé, procéder aux étapes suivantes dans le système d'exploitation de votre invité. Vérifier que la mise à jour a bien été effectuée dans /etc/modules.conf dans Red Hat Enterprise Linux 3 ou /etc/modprobe.conf dans Red Hat Enterprise Linux 4 et Red Hat Enterprise Linux 5. Ajouter un nouvel alias pour chaque interface que vous avez ajoutée.
alias eth1 xen-vnif
Maintenant testez chaque nouvelle interface que vous avez ajoutée et assurez-vous qu'elle soit disponible pour chaque invité.
# ifconfig eth1
La commande ci-dessus doit comporter les propriétés de eth1, répétez la commande pour eth2 si vous ajoutez une troisième interface, etc...
Vous pouvez maintenant configurer les nouvelles interfaces réseau avec redhat-config-network sur Red Hat Enterprise Linux 3 ou system-config-network sur Red Hat Enterprise Linux 4 et Red Hat Enterprise Linux 5.

12.5.2. Périphériques de stockage virtualisés

Procédez aux étapes suivantes pour configurer les périphériques de stockage virtualisés supplémentaire pour votre invité.
Modifiez votre fichier de configuration invité dans /etc/xen/YourGuestName en remplaçant YourGuestName par le nom de votre invité. La saisie d'origine ressemble certainement à celle qui suit.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w"]
Ajouter une saisie supplémentaire à votre nouveau périphérique physique, LUN, partition ou volume à la section “disk=” du fichier de configuration. La saisie de mise à jour de l'entité de stockage du pilote paravirtualisé ressemblerait à ce qui suit. Noter l'utilisation de “tap:aio”.pour le périphérique paravirtualisé si une image basée fichier est utilisée.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w" ]
Si vous souhaitez ajouter davantage d'informations, ajoutez les simplement dans la section “disk=” dans une liste avec une virgule de séparation.

Remarque

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" ]
Vérifier que les partitions ont bien été créées et qu'elles sont disponibles.
# 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
Dans la sortie ci-dessus, vous pouvez voir que la partition ou le périphérique est disponible pour le système.
Montez les nouveaux disques et périphériques sur les points de montage locaux et mettre à jour /etc/fstab dans les invités pour monter les périphériques et les partitions en cours d'initialisation.
# 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

Chapitre 13. Pilotes para-virtualisés 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.
Les pilotes paravirtualisés améliorent la performance des invités totalement virtualisés. Avec les pilotes paravirtualisés, les E/S de latence d'invités diminue et le débit augmente à des niveaux proches du bare-metal. Il est recommandé d'utiliser la pilotes paravirtualisés pour les invités totalement virtualisés exécutant des lourdes tâches et applications en E/S.
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.

Remarque

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.
Les versions suivantes de Microsoft Windows prennent en charge des pilotes KVM paravirtualisés :
  • 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. INstallation des pilotes paravirtualisés Windows KVM

Cette section couvre le processus d'installation pour les pilotes Windows KVM paravirtualisés. Ceux-ci peuvent être chargés lors de l'installation de Windows ou après que l'invité ait été installé.
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. Téléchargez les pilotes

    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.
    Le paquetage virtio-win installe une image CD-ROM, virtio-win.iso, dans le répertoire /usr/share/virtio-win/.
  2. Installez les pilotes paravirtualisés

    Il est recommandé d'installer les pilotes sur l'invité avant d'attacher ou de modifier un périphérique afin d'utiliser les pilotes paravirtualisés.
    Les pilotes doivent être installés avant que le périphérique ne soit modifié pour les périphériques de traitement par blocs stockant des systèmes de fichiers root ou pour les autres périphériques de traitement par blocs nécessaires au démarrage de l'invité. Si les pilotes ne sont pas installés sur l'invité et si le pilote est paramétré sur le pilote virtio, l'invité ne démarrera pas.
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 Procédure 13.1, « Utilisation de virt-manager pour monter une image CD-ROM pour un invité Windows » to add a CD-ROM image with virt-manager and then install the drivers.
Procédure 13.1. Utilisation de virt-manager pour monter une image CD-ROM pour un invité 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.
    Si les pilotes sont stockés sur un CD-ROM physique, utilisez l'option Partition de disque normal.
    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 Procédure 13.2, « Windows installation ».
Procédure 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 (Section 13.3, « Utilisation de pilotes paravirtualisés KVM pour des périphériques existants. ») or install a new device which uses the para-virtualized drivers (Section 13.4, « Utilisation de pilotes paravirtualisés KVM pour de nouveaux périphériques. »).

13.2. Installing drivers with a virtualized floppy disk

Cette procédure couvre l'installation de pilotes paravirtualisés lors d'une installation de Windows.
  • Une fois la première installation de Windows VM réalisée à l'aide du menu d'exécution unique, attachez viostor.vfd en tant que disquette.
    1. Windows Server 2003

      Veuillez saisir F6 à l'invite de Windows pour les pilotes de tierce-partie, puis suivez les instructions affichées à l'écran.
    2. Windows Server 2008

      Lorsque l'installeur demande le pilote, cliquez sur Charger le pilote, pointez l'installeur sur disque A : , puis choisissez le pilote qui convient au système d'exploitation et à l'architecture de votre invité.

13.3. Utilisation de pilotes paravirtualisés KVM pour des périphériques existants.

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 Section 13.4, « Utilisation de pilotes paravirtualisés KVM pour de nouveaux périphériques. ».
  1. Ci-dessous figure un périphérique de traitement par blocs basé sur fichiers utilisant le pilote IDE virtualisé. Ceci est une entrée typique pour un invité virtuel n'utilisant pas de pilotes paravirtualisés.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='ide'/>
    </disk>
    
  2. Changez l'entrée pour utiliser le périphérique paravirtualisé en remplaçant bus= par virtio.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='virtio'/>
    </disk>
    

13.4. Utilisation de pilotes paravirtualisés KVM pour de nouveaux périphériques.

Cette procédure couvre la création de nouveaux périphériques en utilisant les pilotes paravirtualisés KVM avec virt-manager.
Sinon, les commandes virsh attach-disk ou virsh attach-interface peuvent être utilisées pour attacher des périphériques en utilisant les pilotes paravirtualisés.

Installez d'abord les pilotes

Assurez-vous que les pilotes ont été installés sur l'invité Windows avant de continuer l'installation de nouveaux périphériques. Si les pilotes ne sont pas disponibles, le périphérique ne sera pas reconnu et ne fonctionnera pas.
  1. Ouvrez l'invité virtualisé en double-cliquant sur le nom de l'invité dans virt-manager.
  2. Ouvrez l'onglet Hardware.
  3. Cliquez sur le bouton Add Hardware.
  4. Dans l'onglet Ajout de matériel virtuel, sélectionnez Stockage ou Réseau pour le type de périphérique.
    1. New disk devices
      Sélectionnez le périphérique de stockage ou l'image basée sur fichier. Sélectionnez Disque Virtio en tant que Type de périphérique, puis cliquez sur Suivant.
    2. New network devices
      Sélectionnez Réseau virtuel ou Périphérique physique partagé. Sélectionnez virtio en tant que Type de périphérique, et cliquez sur Suivant.
  5. Cliquez sur Finir pour sauvegarder le périphérique.
  6. Redémarrez l'invité. L'invité Windows peut ne pas reconnaitre le périphérique jusqu'à ce qu'il soit redémarré.

Chapitre 14. Passe-système PCI

Ce chapitre couvre l'utilisation de passes-système PCI avec les hyperviseurs Xen et KVM.
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.
Procédure 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.
Procédure 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 Section 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.

Important

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.

Avertissement

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.
Procédure 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:

Chapitre 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
Procédure 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 Procédure 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)
    

    Note

    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 Étape 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.

Chapitre 16. Gestion du temps de l'invité KVM

La virtualisation pose un certain nombre de challenges pour garder trace du temps pour un invité. Les invités qui utilisent la fonctionnalité compteur d'horodatage (de l'anglais Time Stamp Counter, ou TSC) comme holroge source peuvent avoir des problèmes de synchronisation car certains CPU ne possèdent pas de compteurs d'horodatage constants. Les invités exécutés sans indications de temps précises peuvent avoir des problèmes avec certains processus et applications en réseau car l'invité s'exécutera plus rapidement ou plus lentement que le temps réel, et ne sera donc plus synchronisé.
KVM contourne ce problème en fournissant une horloge paravirtualisée aux invités. Autrement, certains invités peuvent utiliser d'autres sources d'horloge x86 pour garder trace du temps dans les futures versions de ces systèmes d'exploitation.
Actuellement, seul Red Hat Enterprise Linux 5.4 et autres versions plus récentes prennent totalement en charge l'horloge paravirtualisée.
Un certain nombre de problèmespeuvent être causés aux invités par des horloges ou compteurs inexacts :
  • Les horloges peuvent se désynchroniser du temps réel, entraînant des invalidations de sessions et affectant les réseaux.
  • Les invités ayant des horloges trop lentes peuvent avoir des problèmes avec les migrations.
Ces problèmes existent sur d'autres plate-formes de virtualisation, l'horodatage doit toujours être testé.

NTP

Le démon NTP (de l'anglais, Network Time Protocol) doit être exécuté sur l'hôte et les invités. Activez le service ntpd :
# service ntpd start
Ajoutez le service ntpd à la séquence de démarrage :
# chkconfig ntpd on
L'utilisation du service ntpd devrait minimiser les effets des variations de l'horloge dans tous les cas de figure.
Détermination de la présence de compteur d'horodatage constant dans votre CPU
Votre CPU possède un compteur d'horodatage constant si la balise constant_tsc est présente. Pour déterminer si votre CPU possède la balise constant_tsc, exécutez la commande suivante :
$ cat /proc/cpuinfo | grep constant_tsc
Si un message de sortie vous est retourné, il devrait y être inclus que le CPU contient constant_tsc. Si aucune sortie ne vous est retournée, veuillez suivre les instructions ci-dessous.
Configuration des hôtes sans compteur d'horodotage constant
Les systèmes sans compteur d'horodotage constant nécessitent une configuration supplémentaire. Les fonctionnalités de gestion de l'alimentation interfèrent avec la précision de l'heure et doivent être désactivées pour que les invités soient synchronisés avec KVM.

Remarque

Ces instructions sont pour la révision AMD F cpus uniquement.
Si le CPU ne possède pas constant_tsc, veuillez désactiver toutes les fonctionnalités de gestion de l'alimentation (BZ#513138). Chaque système possède un certain nombre de compteurs pour garder trace de l'heure. Le TSC n'est pas toujours stable sur l'hôte, ce qui peut parfois être causé par les changements de cpufreq, par un état deep C, ou par une migration vers un hôte ayant un TSC plus rapide. Pour arrêter les états deep C, qui peuvent provoquer l'arrêt du TSC, ajoutez "processor.max_cstate=1" aux options de démarrage du noyau dans le fichier grub.conf sur l'hôte :
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
Désactivez cpufreq (seulement nécessaire sur les hôtes n'ayant pas constant_tsc) en modifiant le fichier de configuration /etc/sysconfig/cpuspeed et en réglant les variables MIN_SPEED et MAX_SPEED sur les plus hautes fréquences disponibles. Les limites valides peuvent être trouvées dans les fichiers /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies.
Utilisation de l'horloge paravirtualisées avec des invités Red Hat Enterprise Linux.
Pour certains invités Red Hat Enterprise Linux, des paramètres de noyau supplémentaires sont nécessaires. Ces paramètres peuvent être réglés en les ajoutant à la fin de la ligne /kernel dans le fichier /boot/grub/grub.conf de l'invité.
Le tableau ci-dessous liste les versions de Red Hat Enterprise Linux et les paramètres requis pour les invités sur des systèmes qui ne possèdent pas de compteur d'horodatage (TSC) constant.
Red Hat Enterprise LinuxParamètres noyau supplémentaires de l'invité
5.4 AMD64/Intel 64 avec horloge paravirtualiséeParamètres supplémentaires non-requis
5.4 AMD64/Intel 64 sans horloge paravirtualiséedivider=10 notsc lpj=n
5.4 x86 avec horloge paravirtualiséeParamètres supplémentaires non-requis
5.4 x86 sans horloge paravirtualiséedivider=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 64Paramètres supplémentaires non-requis
3.9 x86Paramètres supplémentaires non-requis
Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
Windows utilise à la fois l'horloge en temps réel (de l'anglais Real-Time Clock, ou RTC), et le compteur d'horodatage (ou TSC). L'horloge en temps réel peut être utilisée à la place du TSC pour toutes les sources d'heures qui résoudront les problèmes de synchronisation d'invité(s).
Pour activer l'horloge en temps réel pour la source d'heure PMTIMER (PMTIMER utilise normalement TSC), ajoutez la ligne suivante aux paramètres de démarrage Windows. Les paramètres de démarrage Windows se trouvent dans le fichier boot.ini. Veuillez ajouter la ligne suivante au fichier boot.ini :
/use pmtimer
Pour obtenir des informations supplémentaires sur les paramètres de démarrage Windows et sur l'option pmtimer, veuillez vous référer aux options de changement disponibles pour les fichiers Boot.ini de Windows XP et de Windows Server 2003.
Using the Real-Time Clock with Windows Vista, Windows Server 2008 and Windows 7 guests
Windows utilise à la fois l'horloge en temps réel (de l'anglais Real-Time Clock, ou RTC), et le compteur d'horodatage (ou TSC). L'horloge en temps réel peut être utilisée à la place du TSC pour toutes les sources d'heures qui résoudront les problèmes de synchronisation d'invité(s).
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.

Partie IV. Administration

Chapitre 17. Guides des meilleures pratiques

Les tâches et conseils suivants peuvent vous assister à sécuriser et à assurer la fiabilité de votre serveur Red Hat Enterprise Linux 5 host (dom0).
  • Activez SELinux à fonctionner en mode exécutoire (enforcing mode). Vous pouvez faire cela en exécutant la commande ci-dessous.
    # setenforce 1
    
  • Supprimez ou désactivez les services inutiles suivants AutoFS, NFS, FTP, HTTP, NIS, telnetd, sendmail etc...
  • Ajouter uniquement le plus petit nombre possible de comptes d'utilisateurs possibles utiles à la gestion de la plateforme sur le serveur et supprimez les comptes utilisateur inutiles.
  • Evitez d'exécuter des applications qui ne sont pas essentielles sur votre hôte. L'exécution d'applications sur l'hôte peut avoir un impact sur la performance de la machine virtuelle et peut affecter la stabilité du serveur. Toute application susceptible de mettre le serveur en échec peut entraîner la mise en échec de toutes les machines virtuelles du serveur.
  • Utiliser un emplacement central pour les images et les installations de machines virtuelles. Les images de machines virtuelles doivent être stockées dans /var/lib/libvirt/images/. Si vous utilisez un répertoire distinct pour vos images de machines virtuelles, veillez à inclure votre répertoire dans votre politique SELinux et n'oubliez pas d'en changer le nom avant de démarrer l'installation.
  • Les images, sources et arborescences d'installation doivent être stockées dans un emplacement central, qui est normalement l'emplacement de votre serveur vsftpd.

Chapitre 18. Sécurité pour la virtualisation

Lors du déploiement de technologies de virtualisation sur votre infrastructure d'entreprise, il faut vous assurer que l'hôte ne puisse aucunement être compromis. L'hôte, dans l'hyperviseur Xen, est le domaine privilégié qui s'occupe de la gestion du système et gère toutes les machines virtuelles. Si l'hôte n'est pas sécurisé, tous les autres domaines du système sont vulnérables. Il y a différentes façons d'implémenter la sécurité sur les systèmes qui utilisent la virtualisation. Vous, ou votre organisation, devriez créer un plan de déploiement contenant les spécifications pour les opérations et qui spécifierait quels services seront nécessaires pour vos invités virtuels et pour vos serveurs hôtes ; ainsi que ce qui est nécessaire au support de ces services. Voici quelques problèmes de sécurité à prendre en considération lors de la réalisation d'un plan de déploiement :
  • N'exécutez que les services nécessaires sur les hôtes. Moins il y a de processus et services exécutés sur l'hôte, plus les niveaux de sécurité et de performance seront élevés.
  • Enable Security-Enhanced Linux (SELinux) on the hypervisor. Read Section 18.2, « SELinux et virtualisation » for more information on using SELinux and virtualization.
  • Utilisez un pare-feu pour contrôler le trafic vers domain0. Vous pouvez installer un pare-feu avec des règles d'exclusion par défaut qui vous aideront à sécuriser les attaques sur domain0. Il est également important de limiter les services exposés au réseau.
  • N'autorisez pas l'accès à domain0 aux utilisateurs normaux. Si vous autorisez l'accès à domain0 aux utilisateurs normaux, vous prenez le risque de rendre domain0 vulnérable. Rappelez-vous que domain0 est privilégié et que l'autorisation de comptes sans privilèges peut compromettre le niveau de sécurité.

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 et virtualisation

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.
Addition de stockage basé sur LVM avec SELinux en mode enforcing
La section suivante est un exemple d'addition d'un volume logique à un invité virtualisé avec SELinux activé. Ces instructions fonctionnent aussi pour les partitions de disque dur.
Procédure 18.1. Création et montage d'un volume logique sur un invité virtualisé avec SELinux activé.
  1. Créer un volume logique. Cet exemple crée un volume logique de 5 giga-octets nommé NewVolumeName sur le groupe de volumes nommé volumegroup.
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. Formatter le volume logique NewVolumeName avec un système de fichiers qui supporte les attributs étendus, tel que ext3.
    # mke2fs -j /dev/volumegroup/NewVolumeName
    
  3. Créer un nouveau répertoire pour le montage du nouveau volume logique. Ce répertoire peut se trouver n'importe où sur votre système de fichiers. Il est recommandé de ne pas l'installer sur les répertoires système importants (/etc, /var, /sys) ou dans les répertoires de base (/home ou /root). Cet exemple utilise un répertoire nommé /virtstorage
    # mkdir /virtstorage
    
  4. Monter le volume logique.
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the correct SELinux type for a Xen folder.
    semanage fcontext -a -t xen_image_t "/virtstorage(/.*)?"
    
    Autrement, paramétrez le type de SELinux correct pour un dossier KVM.
    semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    
    Si la politique visée est utilisée (la politique visée étant la politique par défaut), la commande ajoute une ligne au fichier /etc/selinux/targeted/contexts/files/file_contexts.local, rendant ainsi le changement persistant. La ligne ajoutée peut ressembler à ce qui suit :
    /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

Cette section contient des informations à prendre en considération lors du déploiement de virtualisation. Lorsque vous déployez des modifications de système ou que vous ajoutez des périphériques, vous devez mettre à jour votre politique SELinux en fonction de ces modifications. Pour configurer un volume LVM pour un invité, vous devez modifier le contexte SELinux pour le périphérique de traitement par blocs sous-jacent et pour le groupe de volume respectif.
# semanage fcontext -a -t xen_image_t -f -b /dev/sda2
# restorecon /dev/sda2
Le paramètre booléen xend_disable_t place xend dans un mode non confiné après le redémarrage du démon. Il est recommandé de désactiver la protection pour un démon unique plutôt que pour tout le système. De même il vaut mieux ne pas ré-étiqueter les répertoires comme xen_image_t que vous utiliserez ailleurs.
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.

Note

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.

Chapitre 19. Gestion des invités au moyen de xend

Le démon de contrôle des noeuds xend effectue des fonctions de gestion système associées aux machines virtuelles. Ce démon contrôle les ressources virtualisées, et xend doit être en cours d'exécution pour interagir avec les machines virtuelles. Avant de démarrer xend, vous devez spécifier les paramètres d'opération en modifiant le fichier de configuration xend /etc/xen/xend-config.sxp.Voici les paramètres que vous pouvez activer ou désactiver dans le fichier de configuration xend-config.sxp:
Tableau 19.1. Paramètres de configuration xend
Élément Description
(console-limit)
Determines the console server's memory buffer limit and assigns that limit on a per domain basis.
(min-mem)
Détermine le nombre minimum de mégaoctets réservés au domain0 (si vous entrez 0, la valeur ne change pas).
(dom0-cpus)
Détermine le nombre de CPU utilisés par domain0 (par défaut, au moins 1 CPU est assigné).
(enable-dump)
Si activé, Xen crée un fichier de vidage lorsqu'un échec se produit (la valeur par défaut est 0).
(external-migration-tool)
Détermine le script ou l'application qui s'occupe de la migration de périphériques externes. Les scripts doivent se trouver dans le répertoire /etc/xen/scripts/external-device-migrate.
(logfile)
Détermine l'emplacement du fichier journal (la valeur par défaut est /var/log/xend.log).
(loglevel)
Filtre les valeurs du mode de journalisation: DEBUG, INFO, WARNING, ERROR ou CRITICAL (la valeur par défaut est DEBUG).
(network-script)
Détermine le script qui active l'environnement de mise en réseau. Les scripts doivent se trouver dans le répertoire /etc/xen/scripts/.
(xend-http-server)
Active le serveur de gestion des paquets de flux http (par défaut ce paramètre est désactivé).
(xend-unix-server)
Active le serveur de sockets de domaine Unix. Un serveur de sockets est un point d'accès de communication qui traite les connexions réseau de bas niveau et accepte ou rejette les connexions entrantes. La valeur par défaut est réglée sur "Yes".
(xend-relocation-server)
Active le serveur de réadressage pour les migrations entre-machines (par défaut ce paramètre est désactivé).
(xend-unix-path)
Détermine l'emplacement où la commande xend-unix-server envoie les données (la valeur par défaut est /var/lib/xend/xend-socket)
(xend-port)
Détermine le port utilisé par le serveur de gestion http (la valeur par défaut est 8000).
(xend-relocation-port)
Détermine le port utilisé par le serveur de réadressage (la valeur par défaut est 8002).
(xend-relocation-address)
Détermine les adresses de l'hôte qui sont autorisées pour la migration. La valeur par défaut est la valeur de l'adresse xend-address.
(xend-address)
Détermine l'adresse à laquelle le serveur de sockets de domaine est lié. La valeur par défaut autorise toutes les connexions.

Après avoir configuré ces paramètres d'opération, vérifiez que xend est en cours d'exécution et, si ce n'est pas le cas, initialisez le démon. À l'invite de commande, vous pouvez démarrer le démon xend en saisissant ce qui suit:
service xend start
Vous pouvez utiliser xend pour arrêter le démon :
service xend stop
Cela arrête le démon en cours d'exécution.
Vous pouvez utiliser xend pour redémarrer le démon :
service xend restart
Le démon démarre une nouvelle fois.
Vous pouvez vérifier le statut du démon xend.
service xend status
The output displays the daemon's status.

Gestion des invités au moyen de xend au démarrage.

Utiliser la commande chkconfig pour ajouter le xend au fichier initscript.
chkconfig --level 345 xend
Le xend va maintenant démarrer aux niveaux d'exécution 3, 4 et 5.

Chapitre 20. Migration Xen en direct

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.
  • La migration hors-ligne suspend l'invité virtualisé sur l'hôte d'origine, le transfère sur l'hôte destinataire, puis le relance une fois le transfert terminé. La migration hors-ligne utilise la commande 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 migration en direct utilise l'option --live pour la commande virsh migrate.
    # virsh migrate--live GuestName libvirtURI

Note pour la prise en charge de Itanium®

La migration n'est pas actuellement prise en charge par l'architecture Itanium®.
Pour permettre une migration avec Xen, il faut procéder à quelques changements du fichier de configuration /etc/xen/xend-config.sxp. Par défaut, la migration est désactivée en raison des effets potentiellement indésirables affectant la sécurité en cas de mauvaise configuration. L'ouverture du port de migration permettrait à des hôtes non autorisés d'initier une migration ou une connexion à des ports de migration. Comme il n'existe pas de système d'authentification et d'autorisation spécifique aux requêtes de migration, et que le seul mécanisme de contrôle est basé sur les noms d'hôte et les adresses IP, il faut faire attention à ce que les ports de migration ne soient pas accessibles aux hôtes non autorisés.

Sécurité de la migration virtuelle

Les filtres pour noms d'hôtes et adresses IP n'offrent qu'un minimum de sécurité. Ces deux attributs peuvent tous deux être forgés si l'attaqueur connaît l'adresse ou le nom d'hôte du client à migrer. La meilleure méthode pour sécuriser la migration est d'isoler le réseau de connexions externes ou connexions internes non autorisées.
Activer la migration
Modifier les entrées suivantes dans /etc/xen/xend-config.sxp pour permettre la migration. Modifier les valeurs si nécessaire, et supprimer les commentaires (avec le symbole #) précédant les paramètres suivants :
(xend-relocation-server yes)
La valeur par défaut, qui désactive la migration, est no. Changer la valeur de xend-relocation-server sur yes afin d'activer la migration.
(xend-relocation-port 8002)
Le paramètre, (xend-relocation-port), spécifie le port xend qui doit être utilisé pour l'interface de relocation, si xend-relocation-server est configuré avec yes
La valeur par défaut de cette variable devrait fonctionner pour la plupart des installations. Si vous changez cette valeur, veillez à utiliser un port qui n'est pas utilisé sur le serveur de relocation.
Le port défini par le paramètre xend-relocation-port doit être ouvert sur les deux systèmes.
(xend-relocation-address '')
Sur l'adresse (xend-relocation-address), le xend écoute les commande de migrations sur la connexion relocation-socket pour voir si xend-relocation-server est installé.
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.
Si aucune valeur n'est indiquée, comme dans l'exemple ci-dessus, qui montre une chaîne de caractères vide entourée de guillemets, alors, toutes les connexions sont autorisées. Ceci suppose que la connexion parvienne au port et à l'interface que le serveur écoute. Voir également xend-relocation-port et xend-relocation-address.
Sinon, le paramètre (xend-relocation-hosts-allow) doit être une séquence d'expressions régulières séparées par des espaces. Tout hôte qui possède un nom de domaine totalement qualifié ou une adresse IP qui correspond à l'une de ces expressions régulières, sera accepté.
Voici un exemple d'un attribut (xend-relocation-hosts-allow) :
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Après avoir configuré les paramètres dans le fichier de configuration, redémarrer le service Xen.
# service xend restart

20.1. Test de migration live

Vous trouverez ci-dessous un exemple sur la manière d'installer un environnement simple de migraton live. Cette configuration utilise NFS pour le stockage partagé. NFS est approprié pour les environnements de démonstration mais l'est moins pour un environnement de production où une configuration de stockage partagé plus robuste, utilisant Fibre Channel ou iSCSI et NFS est recommandé.
La configuration ci-dessous consiste en deux serveurs (et-virt07 et et-virt08), utilisant tous les deux eth1 comme interface de réseau par défaut, et donc qui utilisent xenbr1 comme pont de réseau Xen. Nous utilisons un disque SCSI attaché localement (/dev/sdb) sur et-virt07 pour le stockage partagé en utilisant NFS.
Configuration pour migration live
Créer et monter le répertoire utilisé pour la migration:
# mkdir /var/lib/libvirt/images
# mount /dev/sdb /var/lib/libvirt/images

Important

Veillez à ce que le répertoire soit exporté avec les options qui conviennent. Si vous exportez le répertoire par défaut /var/lib/libvirt/images/, faites bien attention d'uniquement exporter /var/lib/libvirt/images/ et non pas /var/lib/xen/, car ce répertoire est utilisé par le démon xend ainsi que par d'les autoutils Xen. Partager /var/lib/xen/ risque d'entraîner un comportement ivisiictible.
# cat /etc/exports
/var/lib/libvirt/images  *(rw,async,no_root_squash)
Vérifiez qu'il est exporté par NFS:
# showmount -e et-virt07
Export list for et-virt07:
/var/lib/libvirt/images *
Installer l'invité
La commande installer dans l'exemple utilisé pour installer l'invité :
# 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 Chapitre 8, Procédure d'installation du système d'exploitation des invités.
Vérifier l'environnement pour la migration
Veillez à ce que les ponts de réseau virtualisés soient configurés correctement et possèdent le même nom sur chacun des deux hôtes :
[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
Vérifier que les paramètres de relocation ont bien été configurés sur les deux hôtes :
[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 '')
Assurez-vous que le serveur de réadressage a bien démarré et qu'il écoute le port consacré aux migrations 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
Vérification de sauvegarde et de restauration de l'invité
Démarrer la machine virtuelle (si ce n'est pas encore fait) :
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
[et-virt07 ~]# virsh start testvm1
Domain testvm1 started
Vérifier que la machine est en cours d'exécution:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Sauvegarder la machine sur l'hôte local:
[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
Restaurer la machine virtuelle sur l'hôte local:
[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
Tester le progrès et initier la migration 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
Attention: une script est uniquement utile pour des tests et ne saurait être utlisé pour des cas de migration live dans un environnement de production.
Vérifier que la machine virtuelle opère sur et-virt08 avant de la migrer vers et-virt07:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Initier une migration live vers et-virt07. Vous pouvez ajouter la commande time pour voir combien de temps la migration dure:
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
exécute le script à l'intérieur de l'invité:
# ./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
Vérifier que la machine virtuelle a bien été fermée sur et-virt08:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Vérifier que la machine virtuelle a démarré sur et-virt07:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Exécutez un autre cycle de migration de et-virt07 vers et-virt08. Initiater une migration de et-virt07 vers et-virt08:
[et-virt07 images]# xm migrate --live testvm1 et-virt08
Vérifier que la machine virtuelle a été fermée:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Avant d'initier la migration, commencer un script simple dans l'invité et notez le changement de temps lorsque vous migrez l'invité:
# ./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
Après que la commande de migration se termine sur et-virt07 vérifiez sur et-virt08 que la machine virtuelle a bien demarré:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
et a exécuté un autre cycle:
[et-virt08 ~]# time virsh migrate --live testvm1 et-virt07
real    0m10.378s
user    0m0.068s
sys     0m0.052s
A ce moment, vous aurez réussi le test de migration Live et hors ligne.

20.2. Configurer la migration live de l'invité

Cette section couvre les migrations hors-ligne des invité Xen vers d'autres erveurs exécutant red Hat Enterprise Linux. De plus, la migration est opérée selon une méthode hors-ligne (à l'aide de la commande xm migrate command). Une migration en direct peut être effectuée à partir de la même commande. Toutefois, il y a quelques modifications à apporter au fichier de configuration xend-config . Cet exemple identifie les entrées à modifier afin que la migration soit réussie :
(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)
Ce paramètre fixe le port que xend utilise pour migrer. Utiliser cette valeur sauf si l'environnement réseau requiert une valeur personnalisée. Supprimer le symbole de commentaire pour l'activer.
(xend-relocation-address )
Ce paramètre est l'adresse qui écoute les connexions de sockets de relocation, après l'activation de la commande xend-relocation-server . L'hyperviseur Xen n'écoute que le trafic réseau sur l'interface spécifiée.
(xend-relocation-hosts-allow )
Ce paramètre contrôle l'hôte qui communique avec le port de relocation. S'il n'y a pas de valeur, alors toutes les connexions entrantes sont autorisées. Vous devez modifier cela par des séquences d'expressions habituelles séparées par des espaces, par exemple :
(xend-relocation-hosts-allow- '^localhost\\.localdomain$' )>
Les valeurs acceptées incluent les noms de domaines pleinement qualifiés, les adresses IP, ou les expressions habituelles séparées par des espaces.
Une fois la configuration effectuée, redémarrer l'hôte pour charger les nouveaux paramètres.

Chapitre 21. Migration en direct KVM (Live Migration)

Ce chapitre couvre les invités exécutés sur un hyperviseur KVM migrant vers un autre hôte 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:
  • L'équilibrage de la charge - les invités peuvent être déplacés sur un hôte ayant une charge moindre lorsque le premier hôte se retrouve surchagé.
  • Les basculements entre matériel - lorsque les périphériques physiques sur l'hôte échouent, les invités peuvent être déplacés en toute sécurité afin que l'hôte puisse être éteint et réparé.
  • L'économie d'énergie - les invités peuvent être redistribués vers d'autre hôtes et les systèmes hôtes éteints afin d'économiser de l'énergie et de réduire les coûts lors des périodes d'utilisation creuses.
  • Les migrations géographiques - les invités peuvent être déplacés vers une nouvelle location pour un taux de latence plus bas ou lors de circonstances exceptionnelles.
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.
Une migration hors-ligne suspend l'invité, puis déplace l'image de la mémoire de l'un des invités vers l'hôte destinataire. L'invité est ensuite relancé sur l'hôte destinataire puis la mémoire utilisée par l'invité sur l'hôte source est libérée.
Le temps pris par une migration hors-ligne dépend de la bande passante et de la latence. Un invité avec 2 Go de mémoire prend en moyenne environ 10 secondes sur un lien Ethernet de 1 Go.
Une migration en direct permet à l'invité de s'exécuter sur l'hôte source et déplace la mémoire sans arrêter l'invité. Toute page de mémoire modifiée est surveillée et envoyée vers la destination une fois que l'image y a été envoyée. La mémoire est mise à jour avec les pages changées. Le processus continue jusqu'à ce que le temps d'attente autorisé à l'invité soit égal au temps prédit du transfert des quelques dernières pages. KVM fait une estimation du temps restant, puis tente de transférer un maximum de fichiers de pages depuis la source vers la destination, jusqu'à ce que KVM prédise que le nombre de pages restantes puisse être transféré lors d'un très court laps de temps pendant que l'invité virtualisé est mis sur pause. Les registres sont chargés sur le nouvel hôte et l'invité est relancé sur l'hôte destinataire. Si un invité ne peut pas être fusionné (ce qui arrive lorsque les invités sont soumis à des charges extrêmes), alors l'invité est mis sur pause puis une migration hors-ligne démarre.
Le temps pris par une migration hors-ligne dépend de la bande passante et de la latence. Si l'invité est lourdement utilisé ou a une bande passante basse, alors la migration prendra bien plus longtemps.

21.1. Besoins pour une migration live

Migrer des invités requiert :
Prérequis de migration
  • Un invité virtualisé installé sur un stockage partagé en réseau à l'aide de l'un des protocoles suivants :
    • Fibre Channel
    • iSCSI
    • NFS
    • GFS2
  • Deux systèmes Red Hat Enterprise Linux, ou plus, de la même version avec les mêmes mises à jour.
  • Les deux systèmes doivent avoir les ports correspondants ouverts.
  • La configuration réseau des deux systèmes doit être identique. Tous les pontages et configurations de réseaux doivent être exactement les mêmes sur les deux hôtes.
  • La mémoire partagée doit être monté au même endroit sur les systèmes source et destination. Le nom du répertoire monté doit aussi être identique.
Configuration du stockage en réseau
Configure shared storage and install a guest on the shared storage. For shared storage instructions, refer to Partie V, « Virtualization Storage Topics ».

21.2. Exemple de mémoire partagée : NFS pour une migration simple

Cet exemple utilise NFS pour partager des images d'invités avec d'autres hôtes HVM. Cet exemple n'est pas pratique pour de grandes installations, et ne sert que de démonstrationde techniques de migration et de légers déploiements. N'utilisez pas cet exemple pour migrer ou exécuter plus de quelques invités virtualisés.
For advanced and more robust shared storage instructions, refer to Partie V, « Virtualization Storage Topics »
  1. Exportez votre répertoire d'image libvirt

    Ajoutez le répertoire de l'image par défaut au fichier /etc/exports :
    /var/lib/libvirt/images *.example.com(rw,no_root_squash,async)
    
    Changez les paramètres de l'hôte comme votre environnement le requiert.
  2. Démarrez NFS

    1. S'ils ne le sont pas déjà installés, veuillez installer les paquets NFS :
      # yum install nfs
      
    2. Ouvrez les ports pour NFS dans iptables, puis ajoutez NFS au fichier /etc/hosts.allow.
    3. Démarrez le service NFS :
      # service nfs start
      
  3. Montez la mémoire partagée sur la destination

    Sur le système destinataire, montez le répertoire /var/lib/libvirt/images :
    # mount sourceURL:/var/lib/libvirt/images /var/lib/libvirt/images
    

    Les emplacements doivent être les mêmes sur la source et sur la destination

    Quelque soit le répertoire choisi pour les invités, il doit être le même sur l'hôte et sur l'invité. Ceci est valable pour tous les types de mémoires partagées. Le répertoire doit être le même, sinon la migration échouera.

21.3. Migration KVM live avec virsh

Un invité peut être migré vers un autre hôte avec la commande virsh. La commande migrate accepte les paramètres dans le format suivant :
# virsh migrate --live GuestName DestinationURL
Le paramètre GuestName représente le nom de l'invité que vous souhaitez migrer.
Le paramètre DestinationURL est l'URL ou le nom d'hôte du système destinataire. Le système destinataire doit exécuter la même version de Red Hat Enterprise Linux, utiliser le même hyperviseur, et doit avoir libvirt en cours d'exécution.
Une fois que la commande est saisie, le mot de passe root du système destinataire vous sera demandé.
Exemple : Migration live avec virsh
Cet exemple migre de test1.example.com à test2.example.com. Changez les noms d'hôtes pour votre environnement. Cet exemple migre une machine virtuelle nommée RHEL4test.
This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: Prérequis de migration).
  1. Vérifier que l'invité est en cours d'exécution :

    Depuis le système source, test1.example.com, vérifiez que RHEL4test est bien en cours d'exécution :
    [root@test1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
  2. Migrez l'invité

    Exécutez la commande suivante pour migrer l'invité en direct vers la destination test2.example.com. Ajoutez ensuite /system à la fin de l'URL de destination afin de dire à libvirt que vous avez besoin d'un accès total.
    # virsh migrate --live RHEL4test qemu+ssh://test2.example.com/system
    Une fois que la commande est saisie, le mot de passe root du système destinataire vous sera demandé.
  3. Attendez

    La migration peut prendre un certain temps selon la charge et la taille de l'invité. virsh ne rapporte que les erreurs. L'invité continue de s'exécuter sur l'hôte source jusqu'à ce que la migration soit complète.
  4. Vérifiez si l'invité est sur l'hôte destinataire

    À partir du système destinataire test2.example.com, vérifiez que RHEL4test est bien en cours d'exécution :
    [root@test2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
La migration live est maintenant complète.

Autres méthodes de mise en réseau

libvirt supports a variety of networking methods including TLS/SSL, unix sockets, SSH, and unencrypted TCP. Refer to Chapitre 22, Gestion de machines virtuelles à distance for more information on using other methods.

21.4. Migration avec virt-manager

Cette section traite de la migration d'invités basés KVM avec virt-manager.
  1. Connectez-vous sur les hôtes sources et sur les hôtes cibles. Cliquez sur Add Connection dans le menu File pour faire apparaître la fenêtre Add Connection.
    Saisissez les détails suivants :
    • Hypervisor : Sélectionnez QEMU.
    • Connection : Sélectionnez le type de connexion.
    • Hostname : Entrez le nom d'hôte.
    Cliquez sur Connect.
    Le gestionnaire de machines virtuelles affiche une liste des hôtes connectés.
  2. Ajoutez un pool de stockage avec le même NFS à l'hôte source et à l'hôte cible.
    Dans le menu Edit, cliquez sur Host Details pour afficher la fenêtre des détails de l'hôte.
    Cliquez sur l'onglet Storage.
  3. Ajoutez un nouveau pool de stockage. Dans le coin en bas à gauche de la fenêtre, cliquez sur le bouton + button. La fenêtre Ajouter un nouveau pool de stockage apparaîtra.
    Saisissez les détails suivants :
    • Name : Entrez le nom du pool de stockage.
    • Type : Sélectionnez netfs : Network Exported Directory.
    Cliquez sur Suivant.
  4. Saisissez les détails suivants :
    • Format : Sélectionnez le type de stockage. Il doit être de type NFS ou iSCSI pour des migrations live.
    • Host Name : Entrez l'adresse IP ou le nom de domaine complet du serveur mémoire.
    Cliquez sur Finish.
  5. Créez un nouveau volume dans le pool de stockage partagé, cliquez sur New Volume.
  6. Saisissez les détails, puis cliquez sur Create Volume.
  7. Créez une machine virtuelle à l'aide du nouveau volume, puis lancez la machine virtuelle.
    La fenêtre Machine virtuelle s'affiche.
  8. Dans la fenêtre du gestionnaire de machines virtuelles, faites un clic droit sur la machine virtuelle, sélectionnez Migrate, puis cliquez sur l'emplacement de la migration.
  9. Cliquez sur Yes pour confirmer la migration.
    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.

Chapitre 22. Gestion de machines virtuelles à distance

Cette section explique comment gérer à distance vos invités virtualisés utilisant ssh ou TLS et SSL.

22.1. Gestion à distance avec SSH

Le paquetage ssh offre un protocole de réseau crypté qui peut procurer des fonctions de gestion sécurisées vers des serveurs de virtualisation à distance. Cette méthode utilise la connexion de gestion libvirt traitée par transmission tunnel sur une connexion SSH pour gérer les machines distantes. L'authentification est réalisée en utilisant la cryptographie de clé publique SSH ainsi que des mots de passe ou phrases passe rassemblés par votre agent SSH local. En addition, la console VNC de chaque machine virtuelle invitée est traitée par transmission tunnel sur SSH.
SSH est normalement configuré par défaut., donc, vous ayez probablement déjà les clés SSH installées et aucun besoin de règles supplémentaires de pare-feu pour accéder au service de gestion ou à la console VNC.
Soyez conscients des problèmes en utilisant SSH pour gérer vos machines virtuelles à distance, c'est à dire:
  • vous aurez besoin d'un accès superutilisateur, ou root, sur la machine distante pour gérer les machines virtuelles,
  • le processus de connexion initial peut être lent,
  • there is no standard or trivial way to revoke a user's key on all hosts or guests, and
  • ssh n'est guère malléable quand il s'agit d'un grand nombre de machines éloignées.
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.
Le démon 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
Après que libvirtd et SSH soient configurés, vous devrez pouvoir accéder ou gérer à distance vos machines virtuelles. Vous devriez également pouvoir accéder à vos invités par la commande VNC à ce niveau.
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. Gestion à distance par TLS et SSL

You can manage virtual machines using TLS and SSL. TLS and SSL provides greater scalability but is more complicated than ssh (refer to Section 22.1, « Gestion à distance avec 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.
Etapes d'installation de TLS/SSL pour virt-manager
Le mini guide suivant assume que vous partez de zéro et que vous ne possédez aucune connaisssance sur les certificats TLS/SSL. Si vous avez la chance d'avoir un serveur en mesure de gérer les certificats, vous pouvez certainement éluder ces premières étapes.
installation du serveur libvirt
Pour davantage d'informations sur la création de certificats, voir le site libvirt, http://libvirt.org/remote.html.
Serveur VNC Xen
Le serveur VNC Xen peut avoir TLS activé en modifiant le fichier de configuration /etc/xen/xend-config.sxp. Supprimer le commentaire sur le paramètre de configuration (vnc-tls 1) dans le fichier de configuration.
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.
installation du client virt-manager et virsh
L'installation client est assez incohérente pour l'instant. Pour permettre la gestion API libvirt de TLS, les certificats client et CA doivent être placés dans /etc/pki. Pour davantage d'informations sur ce sujet veuillez consulter http://libvirt.org/remote.html
In the virt-manager user interface, use the 'SSL/TLS' transport mechanism option when connecting to a host.
Pour virsh, l'URI a le format suivant :
  • qemu://hostname.guestname/system pour KVM.
  • xen://hostname.guestname/ pour Xen.
Pour activer SSL et TLS pour VNC, il faut placer l'autorité de certificat et les certificats du client dans $HOME/.pki, c'est à dire les trois fichiers suivants:
  • CA ou ca-cert.pem - Le certificate CA.
  • libvirt-vnc ou clientcert.pem - Le certificat client signé par le CA.
  • libvirt-vnc ou clientkey.pem - La clé privée du client.

22.3. Modes de Transport

Pour la gestion à distance, libvirt prend en charge les modes de transports suivants :
TLS (Transport Layer Security)
Socket TCP/IP authentifié et crypté Transport Layer Security TLS 1.0 (SSL 3.1), habituellement en écoute sur un numéro de port public. Pour utiliser ceci, vous devrez générer des certificats client et serveur. Le port standard est 16514.
Sockets UNIX
Les sockets de domaine Unix sont uniquement accessible sur la machine locale. Les sockets ne sont pas cryptés, et utilisent des permissions UNIX ou SELinux pour l'authentification. Les noms de socket standards sont /var/run/libvirt/libvirt-sock et /var/run/libvirt/libvirt-sock-ro (pour les connections à lecture-seule).
SSH
Transporté sur une connexion à protocole SSH (Secure Shell). Nécessite l'installation de Netcat (paquetage nc). Le démon libvirt (libvirtd) doit être en cours d'exécution sur la machine distante. Le port 22 doit être ouvert pour permettre l'accès SSH. Vous devriez utiliser une sorte de gestion de clés ssh (par exemple, l'utilitaire ssh-agent), sinon vous devrez saisir un mot de passe.
ext
Le paramètre ext est utilisé pour tout programme externe qui peut se connecter aux machines distantes en utilisant des moyens autres que ceux de libvirt. Ce paramètre n'est pas pris en charge.
tcp
Socket TCP/IP non-crypté. N'est pas recommandé pour une utilisation en milieu de production, ceci est normalement déasctivé, mais un administrateur peut l'activer pour réaliser des tests ou pour une utilisation sur un réseau approuvé. Le port par défaut est le port 16509.
Le transport par défaut, si aucun autre n'est spécifié, est le tls.
URI distants
Un URI (de l'anglais, Uniform Resource Identifier) est utilisé par virsh et libvirt pour se connecter à un hôte distant. Les URI peuvent aussi être utilisés avec le paramètre --connect pour la commande virsh afin d'exécuter des commandes ou migrations uniques sur des hôtes distants.
Les URI libvirt prennent la forme générale (le contenu entre crochets, "[]", représente les fonctions optionnelles) :
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
Soit la méthode de transport, soit le nom de l'hôte doit être fourni(e) afin de cibler une location externe.
Exemples de paramètres de gestion à distance
  • Connecter à un hyperviseur Xen sur l'hôte appelé towada, à l'aide du transport SSH et du nom d'utilisateur SSH ccurran.
    xen+ssh://ccurran@towada/
    
  • Connecter à un hyperviseur Xen distant sur l'hôte appelé towada à l'aide de 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
    
  • Connecter à un hyperviseur KVM distant sur l'hôte towada à l'aide de SSH.
    qemu+ssh://towada/system
    
Tester les exemples
  • Connecter à l'hyperviseur KVM local avec un socket UNIX non-standard. Dans ce cas, le chemin d'accès complet vers le socket Unix est fourni explicitement.
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
    
  • Connecter au démon libvirt avec une connexion TCP/IP non-cryptée, avec l'adresse IP 10.1.1.10 sur le port 5000. Ceci utilise le pilote test avec les paramètres par défaut.
    test+tcp://10.1.1.10:5000/default
    
Paramètres URI supplémentaires
Extra parameters can be appended to remote URIs. The table below Tableau 22.1, « Paramètres URI supplémentaires » 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).
Tableau 22.1. Paramètres URI supplémentaires
Nom Mode de transport Description Exemple d'utilisation
name tous les modes Nom passé à la fonction à distance virConnectOpen. Le nom est normalement formé en supprimant le transport, le nom d'hôte, le numéro du port, le nom d'utilisateur ainsi que d'autres paramètres supplémentaires depuis l'URI distant, mais dans certains cas très complexes, il peut s'avérer qu'il vaille mieux de fournir le nom de manière explicite. name=qemu:///system
commande ssh et ext Commande externe. Ceci est requis pour le transport ext. Pour ssh, il s'agit par défaut de ssh. La commande est cherchée dans le PATH. command=/opt/openssh/bin/ssh
socket unix et ssh Chemin d'accès au socket de domaine UNIX, qui remplace celui par défaut. Pour le transport ssh, ceci est passé à la commande à distance netcat (voir netcat). socket=/opt/libvirt/run/libvirt/libvirt-sock
netcat ssh
La commande netcat peut être utilisée afin de se connecter à des systèmes distants. Le paramètre netcat par défaut utilise la commande nc. Pour le transport SSH, libvirt construit une commande SSH en utilisant la forme ci-dessous :
								command -p port [-l username] hostname
								netcat -U socket
Les paramètres port, username et hostname peuvent être spécifiés comme faisant partie de l'URI distant. command, netcat et socket proviennent d'autres paramètres supplémentaires.
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 Si réglé sur une valeur différente de zéro, ceci empêche ssh de demander un mot de passe si la connexion automatique à une machine distante n'est pas possible (pour l'utilisation de ssh-agent ou similaire). Utiliser ceci lorsque vous n'avez pas accès à un terminal - par exemple dans un programme graphique utilisant libvirt. no_tty=1

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

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

Important

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
    

    Important

    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
    

    Important

    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.

Partie VI. Guide de référence de virtualisation

Chapitre 24. Outils de virtualisation

Ci-dessous figure la liste des outils d'administration de la virtualisation, de débogage, et les outils de réseau qui sont utiles pour les systèmes exécutant Xen.
Outils d'administration de systèmes
  • vmstat
  • iostat
  • lsof
    # lsof -i :5900
    xen-vncfb 10635  root  5u  IPv4 218738  TCP grumble.boston.redhat.com:5900 (LISTEN)
    
  • qemu-img
Outils de débogage avancés
  • systemTap
  • crash
  • xen-gdbserver
  • sysrq
  • sysrq t
  • sysrq w
  • sysrq c
Réseautage
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
Outils KVM
  • ps
  • pstree
  • top
  • kvmtrace
  • kvm_stat
Outils Xen
  • xentop
  • xm dmesg
  • xm log

Chapitre 25. Gestion d'invités au moyen de virsh

virsh est un outil d'interface de ligne de commande utilisé pour gérer les invités et l'hyperviseur.
L'utilitaire virsh est construit sur l'API de gestion libvirt et opère comme une alternative à la commande xm et au gestionnaire graphique d'invités (virt-manager). virshpeut être utilisé en mode lecture seule par les utilisateurs non-privilégiés. Vous pouvez aussi utiliser virsh pour exécuter des scripts pour les machines invitées.
Aide-mémoire des commandes virsh
Les tableaux suivants offrent des aides-mémoire pour toutes les options de la ligne de commande virsh.
Tableau 25.1. Commande de gestion d'invités
Commande Description
help Impression des informations d'aide de base.
list Liste tous les invités.
dumpxml Affichage des fichiers de configuration pour l'invité.
create Création d'un invité depuis un fichier de configuration XML et démarrage du nouvel invité.
start Démarrage d'un invité inactif.
destroy Force un invité à s'arrêter.
define Affichage d'un fichier de configuration XML pour un invité.
domid Displays the guest's ID.
domuuid Displays the guest's UUID.
dominfo Affichage des informations des invités.
domname Displays the guest's name.
domstate Affichage de l'état d'un invité.
quit Quitter le terminal interactif.
reboot Redémarrage d'un invité.
restore Restauration d'un invité précédemment enregistré stocké dans un fichier.
resume Reprise d'un invité mis sur pause.
save Enregistre l'état présent d'un invité sur un fichier.
shutdown Arrêt gracieux d'un invité.
suspend Mise sur pause d'un invité.
undefine Supprime tous les fichiers associés à un invité.
migrate Migration d'un invité vers un autre hôte.

Les options de commande virsh suivantes gèrent l'invité et les ressources des hyperviseurs :
Tableau 25.2. Options de ressources de gestion
Commande Description
setmem Paramètre la mémoire allouée pour un invité.
setmaxmem Limite la quantité de mémoire maximum pour l'hyperviseur.
setvcpus Change le nombre de CPU virtuels assignés à un invité.
vcpuinfo Affichage des informations de CPU virtuels d'un invité.
vcpupin Configure l'affinité des CPU virtuels d'un invité.
domblkstat Affichage des statistiques de périphérique de traitement par blocs pour un invité en cours d'exécution.
domifstat Affichage des statistiques d'interface réseau pour un invité en cours d'exécution.
attach-device Attache un périphérique à un invité en utilisant une définition de périphérique dans un fichier XML.
attach-disk Attache un nouveau périphérique de disque à un invité.
attach-interface Attache une nouvelle interface réseau à un invité.
detach-device Détache un périphérique d'un invité, nécessite le même tyoe de description XML que la commande attach-device.
detach-disk Détache un périphérique de disque d'un invité.
detach-interface Détache une interface réseau d'un invité.

Diverses options virsh :
Tableau 25.3. Options diverses
Commande Description
version Affiche la version de virsh :
nodeinfo Affiche les informations relatives à l'hyperviseur

Connexion à un hyperviseur
Pour initier une session hyperviseur avec virsh :
# virsh connect {hostname OR URL}
<name> est le nom de la machine de l'hyperviseur. Si vous voulez initier une connexion en lecture-seule, exécutez la commande ci-dessus avec -readonly.
Création d'un vidage XML de machine virtuelle (fichier de configuration)
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 Section 33.1, « Utilisation de fichiers de configuration XML à l'aide de virsh » for more information on modifying files created with virsh dumpxml.
Exemple de sortie de 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>
Création d'un invité à partir d'un fichier de configuration
Guests can be created from XML configuration files. You can copy existing XML from previously created guests or use the dumpxml option (refer to Création d'un vidage XML de machine virtuelle (fichier de configuration)). 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 Création d'un vidage XML de machine virtuelle (fichier de configuration)) 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
Ceci ouvre un éditeur de texte. L'éditeur de texte par défaut est le paramètre shell $EDITOR (réglé par défaut sur vi).
Suspension d'une machine virtuelle
Suspension d'un invité avec la commande 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 (Reprise d'une machine virtuelle ) option.
Reprise d'une machine virtuelle
Restaurez un invité suspendu avec virsh à l'aide de l'option resume :
# virsh resume {domain-id, domain-name or domain-uuid}
Cette opération est immédiate et les paramètres de la machine virtuelle sont préservés dans un cycle suspend et resume.
Sauvegarder un invité
Sauvegardez sur un fichier l'état présent d'un invité en utilisant la commande 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 (Restauration d'un invité) option. Save is similar to pause, instead of just pausing a guest the present state of the guest is saved.
Restauration d'un invité
Restore a guest previously saved with the virsh save command (Sauvegarder un invité) 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.
Arrêt d'un invité
Arrêtez un invité en utilisant la commande 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.
Redémarrage d'une machine virtuelle
Redémarrer un invité en utilisant la commande 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.
Forcer l'arrêt d'un invité
Forcer un invité à s'arrêter avec la commande 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(Arrêt d'un invité) instead.
Obtenir l'ID du domaine d'un invité
Pour obtenir l'ID du domaine d'un invité :
# virsh domid {domain-name or domain-uuid}
Obtenir le nom du domaine d'un invité
Pour obtenir le nom du domaine d'un invité :
# virsh domname {domain-id or domain-uuid}
Obtenir l'UUID d'un invité
Pour obtenir l'identifiant UUID d'un invité :
# virsh domuuid {domain-id or domain-name}
Un exemple de sortie virsh domuuid :
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011
Affichage des informations invités
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}
Voici un exemple de sortie de 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
Affichage des informations de l'hôte
Pour afficher les informations relatives à l'hôte :
# virsh nodeinfo
Un exemple de sortie de 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
Voici les informations du noeud et les machines qui supportent le processus de virtualisation.
Affichage des machines virtuelles
Pour afficher la liste des invités et leurs états actuels avec la commande virsh:
# virsh list
Les autres options disponibles incluent :
l'option --inactive liste les invités inactifs (les invités qui ont été définis mais qui ne sont pas actuellement actifs), et
l'option --all, qui liste tous les invité. Par exemple :
# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  1 Domain202            paused
  2 Domain010            inactive
  3 Domain9600           crashed
La sortie de virsh list est catégorisée comme étant un des six états (listés ci-dessous).
  • Le statut running fait référence aux invités qui sont actuellement actifs sur un CPU.
  • Les invités listés en tant que blocked sont bloqués, et ne sont pas en cours d'exécution ou ne peuvent pas être exécutés. Ceci est provoqué par un invité attendant des E/S (un statut d'attente traditionnel) ou par des invités en mode veille.
  • L'état paused liste les domaines qui sont en pause. Ceci arrive lorsqu'un administrateur utilise le bouton pause dans virt-manager, xm pause ou virsh suspend. Lorsqu'un invité est mis sur pause, il consomme de la mémoire ainsi que d'autres ressources, mais il est inéligible pour la planification et les ressources CPU de l'hyperviseur.
  • L'état shutdown sert aux invités en train de s'éteindre. L'invité reçoit un signal d'arrêt et devrait être en train de procéder à un arrêt gracieux de ses opérations. Ceci peut ne pas fonctionner sur tous les systèmes d'exploitation ; certains systèmes ne répondent pas à ces signaux.
  • Les domaines de l'état dying sont hors-service, ce qui est un état dans lequel le domaine ne s'est pas complètement arrêté ou dans lequel il est en échec.
  • Les invités crashed ont échoué en cours d'exécution et n'ont plus cours. Cet état n'arrive que si l'invité a été configuré de manière a ne pas redémarrer lorsqu'il se trouve en échec.
Affichage des informations de CPU virtuels
Pour afficher l'information de CPU virtuels en provenance d'un invité avec la commande virsh:
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
Un exemple de sortie de virsh vcpuinfo :
# virsh vcpuinfo r5b2-mySQL01
VCPU:           0
CPU:            0
State:          blocked
CPU time:       0.0s
CPU Affinity:   yy
Configuration de l'affinité des CPU virtuels
Pour configurer l'affinité des CPU virtuels avec les CPU physiques:
# virsh vcpupin domain-id vcpu cpulist
The domain-id parameter is the guest's ID number or name.
Le paramètre vcpu dénombre combien de CPU virtualisés sont alloués à l'invité. Le paramètre vcpu doit être fourni.
Le paramètre vcpu est une liste des numéros d'identifiant de CPU physiques séparés par des virgules. Le paramètre cpulist détermine sur quels CPU peuvent être exécutés les VCPU.
Configuration du nombre de CPU virtuels
Pour modifier le nombre de CPU assignés à un invité avec virsh :
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
La nouvelle valeur count ne peut pas excéder le compte au-dessus du montant spécifié lorsque l'invité a été créé.
Configuration de l'allocation de la mémoire
To modify a guest's memory allocation with virsh :
# virsh setmem {domain-id or domain-name} count
Vous devez spécifier count en kilo-octets. La nouvelle valeur ne peut pas excéder le montant spécifié lors de la création de l'invité. Les valeurs inférieures à 64 Mo ne fonctionneront probablement pas sur la plupart des systèmes d'exploitation invités. Une valeur de mémoire maximum plus haute n'affectera pas un invité actif. Si celle-ci est inférieure, la mémoire disponible se reduira et l'invité pourrait échouer.
Affichage des informations sur les périphériques de traitement par blocs des invités
Utilisez virsh domblkstat afin d'afficher les statistiques de périphériques de traitement par blocs pour un invité en cours d'exécution.
# virsh domblkstat GuestName block-device
Affichage des informations des périphériques réseau des invités.
Utilisez virsh domifstat afin d'afficher les statistiques d'interface réseau pour un invité en cours d'exécution.
# virsh domifstat GuestName interface-device 
Migrer les invités avec virsh
Un invité peut être migré vers un autre hôte avec virsh. Migrer un domaine vers un autre hôte. Ajoutez --live pour une migration en direct. La commande migrate accepte des paramètres sous le format suivant :
# virsh migrate --live GuestName DestinationURL
Le paramètre --live est optionnel. Ajoutez-le pour des effectuer des migrations en direct.
Le paramètre GuestName représente le nom de l'invité que vous souhaitez migrer.
Le paramètre DestinationURL est l'URL ou le nom d'hôte du système destinataire. Le système destinataire requiert :
  • la même version de Red Hat Enterprise Linux,
  • le même hyperviseur (KVM ou Xen), et
  • le service libvirt doit être démarré.
Une fois la commande entrée, le mot de passe root du système destinataire vous sera demandé.
Gestion de réseaux virtuels
Cette section couvre la gestion de réseaux virtuels par la commande virsh. Pour faire la liste des réseaux:
# virsh net-list
Cette commande génère une sortie similaire à celle-ci :
# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes      
vnet1	             active     yes      
vnet2	             active     yes
Pour voir les informations d'un réseau virtuel spécifique :
# virsh net-dumpxml NetworkName
Cela affiche les informations d'un réseau virtuel spécifique au format 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>
Autres commandes virsh utilisées pour gérer des réseaux de machines virtuelles:
  • virsh net-autostart network-name — Démarre automatiquement un réseau appelé network-name.
  • virsh net-create XMLfile — génère et initie un nouveau réseau en utilisant un fichier XML préexistant.
  • virsh net-define XMLfile — génère un nouveau périphérique réseau à partir d'un fichier XML préexistant sans le démarrer.
  • virsh net-destroy network-name — détruit un réseau spécifié comme network-name.
  • virsh net-name networkUUID — convertit un réseau spécifié network UUID en un nom de réseau.
  • virsh net-uuid network-name — convertit un nom de réseau network name en un réseau UUID.
  • virsh net-start nameOfInactiveNetwork — démarre un réseau inactif.
  • virsh net-undefine nameOfInactiveNetwork — supprime la définition d'un réseau inactif.

Chapitre 26. Gestion des invités avec le gestionnaire de machines virtuelles (virt-manager)

Cette section décrit les fenêtres, boîtes de dialogue et divers contrôles GUI du gestionnaire de machines virtuelles (virt-manager)
virt-manager offre une vue graphique des hyperviseurs et de l'invité sur votre système ainsi que sur des machines distantes. Vous pouvez utiliser virt-manager pour définir les invités paravirtualisés ainsi que les invités totalement virtualisés. virt-manager peut effectuer des tâches de gestion de virtualisation, y compris :
  • l'attribution de mémoire,
  • l'attribution des CPU virtuels,
  • la surveillance la performance opérationnelle,
  • l'enregistrement et la restauration, la suspension et la reprise, et la fermeture et le démarrage des invités virtualisés,
  • des liens vers les consoles graphiques et textuelles, et
  • des migrations en direct et hors-ligne.

26.1. The Add Connection window

Cette fenêtre apparaît en premier et demande à l'utilisateur de choisir une session d'hyperviseur. Les utilisateurs non-privilégiés peuvent initier une session en mode lecture-seule. Les utilisateurs root peuvent démarrer une session en mode lecture-écriture complet. Pour une utilisation normale, sélectionnez l'option Local Xen host ou QEMU (pour KVM).
La fenêtre de connexion au gestionnaire de machines virtuelles
Figure 26.1. La fenêtre de connexion au gestionnaire de machines virtuelles

26.2. La fenêtre principale du gestionnaire de machines virtuelles apparaît.

This main window displays all the running guests and resources used by guests. Select a virtualized guest by double clicking the guest's name.
La fenêtre Gestionnaire de machines virtuelles
Figure 26.2. La fenêtre Gestionnaire de machines virtuelles

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
Figure 26.3. The Overview tab

26.4. La console graphique d'une machine virtuelle

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.
La fenêtre de console graphique
Figure 26.4. La fenêtre de console graphique

Une remarque de sécurité et 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 Chapitre 22, Gestion de machines virtuelles à distance. 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'.

Note

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. Démarrage de virt-manager

Pour démarrer une session virt-manager, ouvrez le menu Applications, puis le menu Outils de système et sélectionnez Gestionnaire de machines virtuelles (virt-manager).
La fenêtre principale du gestionnaire de machines virtuelles virt-manager apparaît.
Démarrage de virt-manager
Figure 26.5. Démarrage de 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 Section 22.1, « Gestion à distance avec SSH ».

26.6. Restauration d'une machine enregistrée

Après avoir démarré le gestionnaire de machines virtuelles, toutes les machines virtuelles de votre système sont affichées dans la fenêtre principale. Domain0 correspond à votre système hôte. Si il n'y a pas de machines affichées, cela signifie qu'il n'y a pas de machines en cours d'exécution sur le système.
Pour restaurer une session précédemment enregistrée :
  1. À partir du menu Fichier, sélectionnez Restaurer une machine enregistrée.
    Restauration d'une machine virtuelle
    Figure 26.6. Restauration d'une machine virtuelle

  2. La fenêtre principale restaurater une machine virtuelle apparaît.
  3. Naviguez dans le répertoire approprié et sélectionnez le fichier enregistré.
  4. Cliquez sur Ouvrir.
Les systèmes virtuels enregistrés apparaissent dans la fenêtre principale du gestionnaire de machines virtuelles.
La session du gestionnaire de machines virtuelles restaurée
Figure 26.7. La session du gestionnaire de machines virtuelles restaurée

26.7. Affichage des informations invité

Vous pouvez utiliser le contrôleur de machines virtuelles pour voir des informations de données pour toute machine virtuelle de votre système.
To view a virtual system's details:
  1. Dans la fenêtre principale du gestionnaire de machines virtuelles, sélectionnez la machine virtuelle que vous voulez afficher.
    Sélection d'une machine virtuelle à afficher
    Figure 26.8. Sélection d'une machine virtuelle à afficher

  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
    Figure 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.
    Affichage de l'aperçu des détails d'un invité
    Figure 26.10. Affichage de l'aperçu des détails d'un invité

  3. On the Virtual Machine window, click the Hardwaretab.
    Menu Affichage des détails du matériel d'un invité
    Figure 26.11. Menu Affichage des détails du matériel d'un invité

  4. Sur l'onglet Matériel, cliquez sur Processeur pour voir ou changer l'allocation mémoire du processeur.
    Panneau d'allocation du processeur
    Figure 26.12. Panneau d'allocation du processeur

  5. Sur l'onglet Matériel, cliquez sur Memoire pour voir ou changer l'allocation de la mémoire RAM.
    Affichage de l'allocation mémoire
    Figure 26.13. Affichage de l'allocation mémoire

  6. Sur l'onglet Hardware, cliquez sur Disque pour voir ou changer la configuration du disque dur.
    Affichage de la configuration du disque
    Figure 26.14. Affichage de la configuration du disque

  7. On the Hardware tab, click on NIC to view or change the current network configuration.
    Affichage de la configuration du réseau
    Figure 26.15. Affichage de la configuration du réseau

26.8. Statut de contrôle

Status status monitoring preferences can be modified with virt-manager's preferences window.
To configure status monitoring:
  1. À partir du menu Modifier, sélectionner Préférences.
    Modification des préférences d'un invité
    Figure 26.16. Modification des préférences d'un invité

    The Preferences window appears.
  2. From the Stats tab specify the time in seconds or stats polling options.
    Configuration de la surveillance des états
    Figure 26.17. Configuration de la surveillance des états

26.9. Affichage des identifiants d'invités

Pour voir les ID des invités de toutes les machines virtuelles de votre système :
  1. À partir du menu Affichage, sélectionnez la case à cocher ID du domaine.
    Affichage des ID des invités
    Figure 26.18. Affichage des ID des invités

  2. Le gestionnaire de machines virtuelles liste l'ID de domaine de tous les domaines de votre système.
    Affichage de l'ID du domaine
    Figure 26.19. Affichage de l'ID du domaine

26.10. Displaying a guest's status

Pour voir les états de toutes les machines virtuelles de votre système :
  1. À partir du menu Affichage, sélectionnez la case à cocher États.
    Selecting a virtual machine's status
    Figure 26.20. Selecting a virtual machine's status

  2. Le gestionnaire de machines virtuelles liste l'état de toutes les machines virtuelles de votre système :
    Displaying a virtual machine's status
    Figure 26.21. Displaying a virtual machine's status

26.11. Affichage des processeurs virtuels

Pour voir la quantité de CPU virtuels de toutes les machines virtuelles de votre système :
  1. À partir du menu Affichage, sélectionnez la case à cocher CPU virtuels.
    Sélection de l'option Processeur virtuel (virtual CPU)
    Figure 26.22. Sélection de l'option Processeur virtuel (virtual CPU)

  2. Le gestionnaire de machines virtuelles liste les CPU virtuels pour toutes les machines virtuelles sur votre système.
    Affichage des CPU virtuels
    Figure 26.23. Affichage des CPU virtuels

26.12. Affiche de l'utilisation CPU

Pour voir l'utilisation CPU de toutes les machines virtuelles de votre système :
  1. À partir du menu Affichage, sélectionnez la case à cocher Utilisation CPU.
    Sélection Utilisation CPU
    Figure 26.24. Sélection Utilisation CPU

  2. Le gestionnaire de machines virtuelles liste le pourcentage de CPU en cours d'utilisation de toutes les machines virtuelles de votre système.
    Affiche de l'utilisation CPU
    Figure 26.25. Affiche de l'utilisation CPU

26.13. Affichage de l'utilisation mémoire

Pour voir l'utilisation mémoire de toutes les machines virtuelles de votre système :
  1. À partir du menu Affichage, sélectionnez la case à cocher Utilisation mémoire.
    Affichage de l'utilisation mémoire
    Figure 26.26. Affichage de l'utilisation mémoire

  2. Le gestionnaire de machines virtuelles liste le pourcentage de mémoire en cours d'utilisation (en méga-octets) de toutes les machines virtuelles de votre système.
    Affichage de l'utilisation mémoire
    Figure 26.27. Affichage de l'utilisation mémoire

26.14. Nommage du système virtuel

Pour configurer un réseau virtuel sur votre système :
  1. À partir du menu Modifier, sélectionnez Détails sur l'hôte.
    Selecting a host's details
    Figure 26.28. Selecting a host's details

  2. Le menu Détails sur l'hôte s'ouvre. Cliquez sur l'onglet Réseaux virtuels.
    Affichage de la configuration du réseau
    Figure 26.29. Affichage de la configuration du réseau

  3. Tous les réseaux virtuels disponibles sont affichés dans la boîte située à gauche du menu. Pour modifier la configuration d'un réseau virtuel, sélectionnez-le à partir de cette boîte et modifiez-le.

26.15. Création d'un réseau virtuel

Pour créer un réseau virtuel sur votre système :
  1. Open the Host Details menu (refer to Section 26.14, « Nommage du système virtuel ») and click the Add button.
    Affichage de la configuration du réseau
    Figure 26.30. Affichage de la configuration du réseau

    Le menu Créer un nouveau réseau virtuel s'ouvre. Cliquez sur Suivant pour continuer.
    Création d'un nouveau réseau virtuel
    Figure 26.31. Création d'un nouveau réseau virtuel

  2. Saisissez un nom approprié pour votre réseau virtuel et cliquez sur Suivant.
    Nommage de votre réseau virtuel
    Figure 26.32. Nommage de votre réseau virtuel

  3. Saisissez un espace d'adressage IPv4 pour votre réseau virtuel et cliquez sur le bouton Suivant.
    Choisir un espace d'adressage IPv4
    Figure 26.33. Choisir un espace d'adressage IPv4

  4. Définissez la plage DHCP pour votre réseau virtuel en spécifiant une plage de début et de fin pour les adresses IP. Cliquez sur le bouton Suivant pour continuer.
    Sélectionner DHCP
    Figure 26.34. Sélectionner DHCP

  5. Sélectionnez la manière dont le réseau virtuel devrait de se connecter au réseau physique.
    Connexion à un réseau physique
    Figure 26.35. Connexion à un réseau physique

    Si vous sélectionnez Retransmission vers un réseau physique, choisissez si la destination doit être NAT sur tout périphérique physique ou NAT sur un périphérique physique eth0.
    Cliquez sur Suivant pour continuer.
  6. Vous êtes désormais prêt à créer le réseau. Vérifiez la configuration de votre réseau en cliquant sur le bouton Terminer.
    Vous êtes prêt à créer un réseau
    Figure 26.36. Vous êtes prêt à créer un réseau

  7. Le nouveau réseau virtuel est maintenant disponible dans l'onglet Réseau virtuel du menu Détails sur l'hôte.
    Le nouveau réseau virtuel est maintenant disponible
    Figure 26.37. Le nouveau réseau virtuel est maintenant disponible

Chapitre 27. Aide-mémoire des commandes xm

La commande xm peut gérer l'hyperviseur Xen. La plupart des opérations peuvent être effectuées avec les outils libvrit, l'application virt-manager ou la commande virsh. La commande xm ne possède pas la fonctionnalité de vérification d'erreur des outils libvirt et ne devrait pas être utilisée pour des tâches pouvant être accomplies par les outils libvirt.
Il existe un certain nombre d'opérations qui ne peuvent pas être accomplies actuellement avec virt-manager. Certaines options pour d'autres implémentations de la commande xm ne fonctionnent pas dans Red Hat Enterprise Linux 5. La liste ci-dessous présente une vue d'ensemble sur les options de commande disponible et non-disponibles.

Avertissement

Il est recommandé d'utiliser virsh ou virt-manager au lieu de xm. La commande xm ne prend pas très bien en charge la vérification d'erreur ou les erreurs de fichiers de configuration et celles-ci peuvent provoquer une instabilité du système ou des erreurs dans les machines virtuelles. La modification manuelle des fichiers de configuration Xen est dangereuse et devrait être évitée. Utilisez ce chapitre à vos risques et périls.
Options de gestion de base
Les commandes de base suivantes sont souvent utilisées xm:
  • xm help [--long]: aperçu des options disponibles et de help text.
  • utiliser la commande xm list pour répertorier les domaines actifs:
    $ 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 : arrête une machine virtuelle, tout comme si on l'éteignait.
  • xm reboot DomainName/ID: relance une machine virtuelle, fonctionne à travers le système normal d'arrêt/démarrage.
  • xm shutdown DomainName/ID: arrête une machine virtuelle, exécute une procédure normale d'arrêt.
  • xm pause
  • xm unpause
  • xm save
  • xm restore
  • xm migrate
Options de ressources de gestion
Utiliser les commandes suivantes xm pour gérer les ressources:
  • xm mem-set
  • utiliser xm vcpu-list pour lister les affinités des CPU virtuels :
    $ 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
  • utiliser la commande xm sched-credit pour afficher les paramètres d'ordonnancement pour un domaine donné:
    $ xm sched-credit -d 0
    {'cap': 0, 'weight': 256}
    $ xm sched-credit -d 13
    {'cap': 25, 'weight': 256}
    
Options de contrôle et de résolution des pannes
Utiliser les commandes suivantes xm pour contrôler et résoudre les pannes.
  • xm top
  • xm dmesg
  • xm info
  • xm log
  • utiliser xm uptime pour afficher le temps de disponibilité des invités et des hôtes:
    $ 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
Options actuellement non supportées
La commande xm vnet-list n'est pas actuellement supportée.

Chapitre 28. Configuration des paramètres d'amorçage du noyau Xen

GNU Grand Unified Boot Loader (ou GRUB) est un programme qui permet le démarrage de divers systèmes d'exploitation ou noyaux. Il permet également à l'utilisateur de passer des arguments au noyau. Le fichier de configuration GRUB (situé dans /boot/grub/grub.conf) crée une liste des systèmes d'exploitation dans l'interface de menu de démarrage GRUB. Lorsque vous installez le RPM kernel-xen, un script ajoute des entrées kernel-xen au fichier de configuration GRUB, qui démarrera kernel-xen par défaut. Modifiez le fichier grub.conf afin de modifier le noyau par défaut ou pour ajouter des paramètres de noyau supplémentaires.
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
Si vous paramétrez vos entrées grub Linux pour qu'elles reflètent cet exemple, le chargeur de démarrage charge l'hyperviseur, l'image initrd et le noyau Linux. Étant donné que l'entrée du noyau est la première des entrées, le noyau se charge en mémoire en premier. Le chargeur de démarrage envoie (et reçoit) des arguments en ligne de commande vers et en provenance de l'hyperviseur et du noyau Linux. Cet exemple d'entrée illustre comment restreindre la mémoire du noyau Linux de Domain0 à 800 Mo:
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
Vous pouvez utiliser les paramètres GRUB pour configurer l'hyperviseur de Virtualisation :
mem
Limite la quantité de mémoire qui est disponible dans le noyau de l'hyperviseur.
com1=115200, 8n1
Ceci active le premier port série dans le système de façon à agir comme une console série (com2 est assigné au prochain port, et ainsi de suite...).
dom0_mem
Limite la quantité de mémoire qui est disponible pour l'hyperviseur.
dom0_max_vcpus
Ceci limite la quantité de CPU visible par domain0 Xen.
acpi
Alterne l'hyperviseur ACPI avec l'hyperviseur et domain0. Les options du paramètre ACPI incluent :
/*   ****  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
Désactive ACPI pour la distribution d'interruptions.

Chapitre 29. Configurer ELILO

ELILO est le chargeur de démarrage utilisé sur les systèmes basés-EFI, notamment Itanium®. Tout comme GRUB, le chargeur de démarrage des systèmes x86 et x86-64, ELILO autorise les utilisateurs à sélectionner le noyau à charger pendant la séquence d'initialisation du système. Cela permet également à l'utilisateur de transmettre les arguments au noyau. Le fichier de configuration ELILO, qui est situé dans la partition d'amorçage EFI, et qui est lié symboliquement à /etc/elilo.conf, contient une liste des options globales et des strophes d'images (image stanzas). Lorsque vous installez le RPM kernel-xen, un script de post installation ajoute la strophe d'image qui convient sur elilo.conf.

ELILO

Cette section sur ELILO est pour les systèmes exécutant le noyau Xen sur une architecture Intel Itanium.
Le fichier de configuration ELILO comporte deux sections:
  • Options globales qui affectent le comportement d' ELILO et de toutes les saisies. Il n'y a normalement aucune raison de les changer par rapport aux valeurs par défaut.
  • Le paragraphe de configuration d'image qui définit la sélection d'amorçage et les options associées.
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 transcrit le paramètre read-only à l'option de la ligne de commande du noyau ro, ce qui entraîne à ce que le système de fichiers superutilisateur (root) soit monté en lecture-seule jusqu'à ce que les initscripts montent le root drive en lecture-écriture. ELILO copie la ligne "root" dans la ligne de commande du noyau. Elles sont fusionnées à la ligne de commande "append" pour construire une ligne de commande complète :
"-- root=/dev/VolGroup00/rhel5_2 ro rhgb quiet"
Les symboles -- déterminent les arguments de l'hyperviseur et du noyau. Les arguments de l'hyperviseur en premier, puis les délimiteurs --, suivis par les arguments du noyau. L'hyperviseur ne possède généralement pas d'arguments.

Note technique

ELILO passe la ligne de commande complète à l'hyperviseur. L'hyperviseur divise le contenu et passe les options de noyau au noyau.
Pour personnaliser l'hyperviseur, insérer les paramètres devant -- . Exemple de paramètre de mémoire d'hyperviseur (mem) et de paramètre quiet pour le noyau :
append="dom0_mem=2G -- quiet"
Paramètres d'hyperviseur ELILO
ParamètreDescription
mem=Le paramètre mem détermine l'utilisation RAM maximum de l'hyperviseur. Toute RAM supplémentaire ajoutée au système sera ignorée. Le paramètre peut être spécifié à l'aide du suffixe B, K, M ou G, qui représente les octets (Bytes), les Kilo-octets, les Méga-octets et les Giga-octets respectivement. S'il n'y a pas de suffixe de spécifié, l'unité choisie par défaut est le kilo-octet.
dom0_mem=dom0_mem= détermine le montant de RAM allouée à dom0. Les mêmes suffixes que pour le paramètre mem, sont respectés. Le montant par défaut dans Red Hat Enterprise Linux 5.2 est de 4G pour Itanium®.
dom0_max_vcpus=dom0_max_vcpus= détermine le nombre de CPU à allouer à l'hyperviseur. Le nombre par défaut est de 4 Itanium® dans Red Hat Enterprise Linux 5.2.
com1=<baud>,DPS,<io_base>,<irq>com1= détermine les paramètres pour la première ligne de la série. Par exemple, com1=9600,8n1,0x408,5. Les options io_base et irq peuvent être omises si on souhaite garder les valeurs standard par défaut. Le paramètre baud peut être fixé en auto pour indiquer que la configuration du chargeur d'amorçage doit être préservée. Le paramètre com1 peut être omis si les paramètres de la série sont configurés en tant qu'options globales dans ELILO ou dans la configuration EFI.
com2=<baud>,DPS,<io_base>,<irq>Déterminer les paramètres pour la deuxième ligne de série. Voir la description du paramètre com1 ci dessus.
console=<specifier_list>La console est une liste de préférences délimitée par une virgule, pour les options de console. Les options incluent vga, com1 et com2. Cette configuration devrait être omise car l'hyperviseur tentera d'hériter les paramètres de la console EFI.

Pour plus d'informations sur les paramètres ELILO

Une liste complète des paramètres ELILO sont disponibles dans XenSource.
Un exemple modifié de la configuration ci-dessus, montrant des exemples de syntaxe pour adjonction de mémoire et pour les paramètres d'allocation de mémoire à l'hyperviseur:
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 --"
De plus, cet exemple supprime les paramètres de noyau "rhgb quiet" de façon à ce que le noyau et la sortie initscript soient générés sur la console. Notez que les guillemets subsistent pour que la ligne de commande ajoutée soit convenablement interprétée en tant qu'arguments d'hyperviseur.

Chapitre 30. libvirt configuration reference

This chapter provides is a references for various parameters of libvirt XML configuration files
Tableau 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.

Chapitre 31. Fichiers de configuration 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, Tableau 31.1, « Référence au fichier de configuration Xen », is formatted output from xm create --help_config.
Tableau 31.1. Référence au fichier de configuration Xen
Parameter
Description
vncpasswd=NAME Mot de passe pour la console VNC sur le domaine HVM.
vncviewer=no | yes Démarrer un vncviewer à l'écoute d'un serveur vnc dans le domaine. L'adresse du vncviewer est transmise au domaine sur la ligne de commande du noyau en utilisant VNC_SERVER=<host>:<port>. Le port utilisé par vnc est 5500 + DISPLAY. Une valeur d'affichage avec port libre est choisie si possible. Valide uniquement quand vnc=1.
vncconsole=no | yes Spawn a vncviewer process for the domain's graphical console. Only valid when vnc=1.
name=NAME Nom de domaine. Doit être unique.
bootloader=FILE Chemin d'accès au chargeur d'amorçage.
bootargs=NAME Arguments à passer au chargeur d'amorçage.
bootentry=NAME DEPRECATED. Entrée pour démarrer à partir du chargeur d'amorçage. Utiliser bootargs.
kernel=FILE Chemin d'accès à l'image du noyau.
ramdisk=FILE Chemin d'accès au ramdisk.
features=FEATURES Fonctionalités pour activer un noyau d'invité.
builder=FUNCTION Fonctionalité utilisée pour construire un domaine.
memory=MEMORY Mémoire de domaine en Mo.
maxmem=MEMORY Mémoire de domaine maximum en Mo.
shadow_memory=MEMORY Mémoire fantôme de domaine en Mo.
cpu=CPU CPU hôte de VCPU0.
cpus=CPUS CPUS pour exécuter le domaine
pae=PAE Désactiver ou activer PAE du domaine HVM.
acpi=ACPI Désactiver ou activer ACPI du domaine HVM.
apic=APIC Désactiver ou activer PAE du domaine HVM.
vcpus=VCPUs Nombre de CPUS virtuels dans le domaine.
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 A éviter. Utiliser on_poweroff, on_reboot, et on_crash à la place. Si le domaine devait être redémarré après la sortie. - onreboot : redémarrer après la sortie avec le code de fermeture de session reboot - always : toujours redémarrer après la sortie, ignorer le code de sortie - never : ne jamais redémarrer après la sortie, ignorer le code de sortie
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 Transformer le domaine en périphérique dorsal.
netif=no | yes Transformer le domaine en interface dorsale de réseau.
tpmif=no | yes Transformer le domaine en interface dorsale TPM
disk=phy:DEV,VDEV,MODE[,DOM] Ajouter un lecteur de disques à un domaine. Le périphérique physique est DEV, qui est exporté dans le domaine en tant que VDEV. Le disque est en lecture-seule si MODE indique r, lecture-écriture si MODE indique w. Si DOM est spécifié, il détermine le domaine du pilote principal à utiliser pour le disque. L'option pourra être répétée pour ajouter plus d'un disque.
pci=BUS:DEV.FUNC Ajouter un périphérque PCI à un domaine, en utilisant les paramètres donnés (dans hex). Par exemple, pci=c0:02.1a. L'option pourra être répétée pour ajouter plus d'un appareil pci.
ioports=FROM[-TO] Ajouter une fourchette E/S héritée à un domaine, en utilisant les params donnés (en hex). Par exemple ioports=02f8-02ff. Cette option pourra être répétée pour ajouter plus d'une fourchette e/s.
irq=IRQ Ajouter une interruption (IRQ for Interrupt Request / demande d'interrupotion) à un domaine. Par exemple irq=7. Cette option pourra être répétée pour ajouter plus d'un IRQ.
usbport=PATH Ajouter une port physique USB à un domaine, comme indiqué par le chemin qui mène à ce port. Cette option pourra être répétée pour ajouter plus d'un seul port.
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
Ajouter une interface de réseau avec le pont et l'adresse MAC donnés. Le vif est configuré en appelant le script de configuration. Si le type n'est pas spécifié, le périphérique par défaut est netfront et non pas ioemu. Si l'adresse mac n'est pas spécifiée, une adresse MAC choisie au hasard sera utilisée. Si le pont n'est pas spécifié, le premier pont trouvé est utilisé. Si le script n'est pas spécifié, le script par défaut est utilisé. Si le backend n'est pas spécifié, le domaine du pilote backend par défaut est utilisé. Si le vifname n'est pas spécifié, l'interface virtuelle du backend aura nommé vifD.N avec D pour le domaine id et N pour l'interface id. Cette option peut être répétée pour ajouter plus d'un vif. Préciser les vifs augmentera le nombre d'interfaces au fur et à mesure des besoins.
vtpm=instance=INSTANCE,backend=DOM Ajouter une interface TPM. Sur la partie backend, utiliser l'instance donnée en tant qu'instance TPM virtuelle. Le nombre donnée est simplement le nombre préferré d'instances. Le script hotplug déterminera le nombre d'instances qui seront assignées au domaine. L'association entre le nombre d'instances de TPM et la machine virtuelle peut être trouvée dans /etc/xen/vtpm.db. Utiliser le backend dans le domaine donné.
access_control=policy=POLICY,label=LABEL Ajouter le label sécurité et la référence de politique de sécurité qui le définit. La référence ssid locale est calculée lorsqu'on démarre ou arrête le domaine. A ce moment là, la politique est contrôlée par rapport à la politique active. Ainsi, on couvre la migration entre les fonctions de sauvegarde et de restauration et les labels locaux sont automatiquement créés convenablement sur le système dans lequel le domaine est démarré ou terminé.
nics=NUM A EVITER. Utiliser des entrés vif à la place. Déterminer le nombre d'interfaces de réseaux. Utiliser l'option vif pour déterminer les paramètres d'interface, sinon les paramètres par défaut seront utilisés. Spécifier les vifs augmente le nombre d'interfaces suivant les besoins.
root=DEVICE Spécifie root= paramètre sur la ligne de commande du noyau. Utiliser un périphérique, par ex. /dev/sda1, ou /dev/nfs pour le root NFS.
extra=ARGS Spécifie des arguments supplémentaires à ajouter à la ligne de commande du noyau.
ip=IPADDR Spécifie l'adresse de l'interface IP du noyau.
gateway=IPADDR Spécifie la passerelle de l'adresse IP configurée.
netmask=MASK Spécifie le masque réseau de l'adresse IP configurée.
hostname=NAME Spécifie le nom d'hôte IP du noyau.
interface=INTF Spécifie le nom de l'interface IP du noyau.
dhcp=off|dhcp Spécifie l'option dhcp du noyau.
nfs_server=IPADDR Spécifie l'adresse du serveur NFS pour le root NFS.
nfs_root=PATH Spécifie le chemin d'accès au répertoire root NFS.
device_model=FILE Chemin d'accès au programme modèle du périphérique.
fda=FILE Chemin d'accès à fda
fdb=FILE Chemin d'accès fdb
serial=FILE Chemin d'accès au sériel (serial) ou pty ou vc
localtime=no | yes Est-ce que RTC est bien configuré à l'heure locale
keymap=FILE Configurer le clavier utilisé
usb=no | yes Emuler les USB
usbdevice=NAME Nom des USB à ajouter
stdvga=no | yes Use std vga or Cirrus Logic graphics
isa=no | yes Simuler un système spécifiquement ISA
boot=a|b|c|d Périphérique d'amorçage par défaut
nographic=no | yes Est ce que les modèles de périphériques doivent utiliser des graphiques?
soundhw=audiodev Est-ce que les modèles de périphériques doivent activer les périphériques audio ?
vnc Est-ce que les modèles de périphériques doivent utiliser VNC?
vncdisplay Affichage VNC à utiliser
vnclisten Adresse d'écoute pour le serveur VNC
vncunused Essayer de trouver un port non utilisé pour le serveur VNC. Valide uniquement pour vnc=1.
sdl Est-ce que le modèle de périphérique utilise SDL?
display=DISPLAY Affichage X11 à afficher
xauthority=XAUTHORITY Authorité X11 à utiliser
uuid xenstore UUID (universally unique identifier / identifiant universel unique) à utiliser. Sera généré au hasard si cette option n'est pas configurée, tout comme les adresses MAC dans le cas des interfaces de réseau virtuel. On doit utiliser une valeur unique pour l'ensemble des terminaux.

Tableau 31.3, « Valeurs par défaut des paramètres de configuration  » 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.
Tableau 31.2. Fonctions Python utilisées pour déterminer les valeurs de paramètres
Fonction parser Arguments valides
set_bool
Valeurs acceptées:
  • 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
accepte toute valeur Python.
append_value
accepte toute valeur Python, et l'adjoint à toute valeur précédente, stockée dans un tableau (array).

Tableau 31.3. Valeurs par défaut des paramètres de configuration
Parameter Fonction parser Valeurs par défaut
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

Partie VII. Conseils et astuces

Chapitre 32. Conseils et astuces

Ce chapitre contient des conseils et astuces pour améliorer la performance, l'extensibilité, et la stabilité de la virtualisation.

32.1. Démarrer les invités automatiquement

This section covers how to make virtualized guests start automatically during the host system's boot phase.
Cet exemple utilise virsh pour paramétrer un invité, TestServer, afin qu'il démarre automatiquement lors du lancement de l'hôte.
# virsh autostart TestServer
Domain TestServer marked as autostarted
L'invité démarrera maintenant automatiquement avec l'hôte.
Pour arrêterle démarrage automatique d'un invité, utiliser le paramètre --disable
# virsh autostart --disable TestServer
Domain TestServer unmarked as autostarted
L'invité ne démarrera plus automatiquement avec l'hôte.

32.2. Changer entre les hyperviseurs Xen et KVM

Cette section couvre le changement entre les hyperviseurs Xen et KVM.
Red Hat ne prend en charge qu'un seul hyperviseur à la fois.

Migration d'invités virtualisés entre hyperviseurs

Actuellement, il n'existe pas d'application pour échanger les invités basés-Xen sur KVM ou pour échanger les invités basés-KVM sur Xen. Les invités ne peuvent être utilisés que sur le type d'hyperviseur qui a été utilisé lors de leur création.

Avertissement

Cette procédure est disponible uniquement pour les versions Intel 64 ou AMD64 de Red Hat Enterprise Linux 5.4 ou plus récentes. Aucune autre configuration, et aucune autre version de Red Hat Enterprise Linux ne sont prises en charge. KVM n'est pas disponible dans les versions antérieures à Red Hat Enterprise Linux 5.4.

32.2.1. De Xen à KVM

La procédure suivante couvre l'échange de l'hyperviseur Xen à l'hyperviseur KVM. Cette procédure suppose que le paquetage kernel-xen est installé et activé.
  1. Installer le paquetage KVM

    Installer le paquetage kvm si ce n'est pas déjà fait.
    # yum install kvm
    
  2. Vérifier quel noyau est en cours d'utilisation

    Le paquetage kernel-xen est peut-être déjà installé. Utiliser la commande uname afin de déterminer quel noyau est en cours d'exécution :
    $ uname -r
    2.6.18-159.el5xen
    
    Le noyau actuel, "2.6.18-159.el5xen", est en cours d'exécution sur le système. Si le noyau par défaut, "2.6.18-159.el5", est en cours d'exécution, vous pouvez ignorer la sous-étape.
    1. Passer du noyau Xen au noyau par défaut

      Le fichier grub.conf détermine quel noyau est démarré. pour changer le noyau par défaut, modifier le fichier /boot/grub/grub.conf comme indiqué ci-dessous.
      								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
      
      Remarquez le paramètre default=1. Il instruit au chargeur d'amorçage GRUB de démarrer la seconde saisie, le noyau Xen. Changer la valeur par défaut sur 0 (ou sur la valeur du noyau par défaut) :
      								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. Redémarrer afin de lancer le nouveau noyau

    Redémarrer le système. L'ordinateur va redémarrer avec le noyau par défaut. Le module KVM devrait être automatiquement chargé avec le noyau. Vérifier que KVM est en cours d'exécution :
    $ lsmod | grep kvm
    kvm_intel              85992  1 
    kvm                   222368  2 ksm,kvm_intel
    
    Le module kvm, et soit le module kvm_intel, soit le module kvm_amd sont présent si tout a bien fonctionné.

32.2.2. De KVM à Xen

La procédure suivante couvre l'échange de l'hyperviseur KVM à l'hyperviseur Xen. Cette procédure suppose que le paquetage kvm est installé et activé.
  1. Installer les paquetages Xen

    Installer les paquetages kernel-xen et xen si ce n'est pas déjà fait.
    # yum install kernel-xen xen
    
    Le paquetage kernel-xen peut être installé mais est désactivé.
  2. Vérifier quel noyau est en cours d'utilisation

    Utiliser la commande uname afin de déterminer quel noyau est en cours d'exécution.
    $ uname -r
    2.6.18-159.el5
    
    Le noyau "2.6.18-159.el5", est en cours d'exécution sur le système. Il s'agit du noyau par défaut. Si le noyau possède xen à la fin (par exemple, 2.6.18-159.el5xen), alors le noyau Xen est en cours d'exécution et vous pouvez ignorer la sous-étape.
    1. Passer du noyau par défaut au noyau Xen

      Le fichier grub.conf détermine quel noyau est démarré. pour changer le noyau par défaut, modifier le fichier /boot/grub/grub.conf comme indiqué ci-dessous.
      								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
      
      Remarquez le paramètre default=0. celui-ci instruit le chargeur d'amorçage GRUB de démarrer la première saisie, qui est le noyau par défaut. Changer la valeur par défaut sur 1 (ou sur la valeur pour le noyau 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. Redémarrer afin de lancer le nouveau noyau

    Redémarrer le système. L'ordinateur va redémarrer avec le noyau Xen. Vérifier à l'aide de la commande uname :
    $ uname -r
    2.6.18-159.el5xen
    
    Si la sortie contient xen à la fin, alors le noyau Xen est en cours d'utilisation.

32.3. Utilisation de qemu-img

La ligne de commande qemu-img est utile au formatage de divers systèmes de fichiers utilisés par Xen et KVM. qemu-img devrait être utilisé pour le formatage d'images d'invités virtualisés, de périphérique de stockage supplémentaires, et de stockage réseau. Les options et utilisations qemu-img sont listées ci-dessous.
Formatage et création de nouvelles images et de nouveaux périphériques
Créer le nouveau nom de fichier image disque de taille size et de format format.
# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
Si base_image est spécifié, alors l'image va seulement enregistrer les différences de base_image. Dans ce cas, la taille n'a pas besoin d'être spécifiée. base_image ne sera jamais modifié à moins d'utiliser la commande de contrôle "commit".
Convertir une image existante dans un autre format.
L'option convert est utilisée pour convertir un format reconnu vers un autre format d'image.
Formatde la commande :
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
Convertir l'image disque filename en image disque output_filename en utilisant le formatage output_format. L'image disque peut être optionnellement cryptée avec l'option -e ou compressée avec l'option -c.
Seul le format "qcow" prend en charge le cryptage ou la compression. La compression est uniquement en lecture-seule. Ce qui veut dire que si un secteur compressé est réécrit, alors il sera réécrit sans être compressé.
Le cryptage utilise le format AES avec des clés très sécurisées de 128 bits. Utiliser un long mot de passe (de plus de 16 caractères) afin d'avoir une protection optimale.
La conversion d'image est aussi utilie afin d'obtenir de plus petites images lors de l'utilisation de formats qui peuvent s'agrandir, tels que qcow ou cow. Les secteurs vides sont détectés et supprimés de l'image de destination.
obtenir des informations d'image
Le paramètre info affiche des informations sur une image disque. Le format de l'option info est comme suit :
# qemu-img info [-f format] filename
Donne des informations à propos du nom de fichier de l'image disque À utiliser en particulier afin de savoir si la taille réservée sur le disque peut être différente de la taille affichée. Si les captures instantanées vm sont stockées dans l'image disque, elles seront aussi affichées.
Formats pris en charge
Le format d'une image est normalement automatiquement deviné. Les formats suivants sont pris en charge :
raw
Format d'image disque brut (défaut). Ce format a l'avantage d'être simple et facilement exportable sur d'autres émulateurs. Si votre système de fichiers prend en charge les trous (par exemple dans ext2 ou ext3 sur Linux ou NTFS sur Windows), alors seuls les secteurs écrits réserveront de l'espace. Utiliser qemu-img info afin de connaître la taille réelle utilisée par l'image, ou ls -ls sur Unix/Linux.
qcow2
Format d'image QEMU, le format le plus versatile. À utiliser afin d'obtenir des images plus petites (ce qui est utile si votre système de fichiers ne prend pas les trous en charge, par exemple : sur Windows), un cryptage AES optionnel, une compression basée-zlib, et la prise en charge de captures instantanées VM multiples.
qcow
Ancien format d'image QEMU. Est uniquement inclus pour faciliter la compatibilité avec les anciennes versions.
cow
Format d'image User Mode Linux Copy On Write. Le format cow est uniquement inclus pour faciliter la compatibilité avec des versions plus anciennes. Il ne fonctionne pas avec Windows.
vmdk
Format d'image compatible avec VMware 3 et 4.
cloop
Image Linux Compressed Loop, uniquement utile pour réutiliser des images CD-ROM directement compressées présentes dans les CD-ROM 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.

Support Xen

Memory overcommitting is not supported for the Xen hypervisor, however CPU overcommitting is supported.
Overcommiter la mémoire
La plupart des systèmes d'exploitation et des applications n'utilisent pas tout le temps 100% de la mémoire vive (RAM) disponible. Ce comportement peut être exploité avec KVM afin d'utiliser plus de mémoire pour les invités virtualisés que la mémoire physiquement disponible.
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.

Avertissement

S'il n'y pas suffisament d'espace Swap, les systèmes d'exploitation des invités seront forcés de s'éteindre. Ceci peut rendre les invités inopérables. Pour éviter ceci, ne jamais overcommiter plus de mémoire qu'il n'y a de mémoire Swap disponible.
La partition swap est utilisée pour permuter la mémoire sous-utilisée sur le disque dur afin d'améliorer vitesse de performance de la mémoire. La taille par défaut de la partition swap est calculée en fonction de la quantité de RAM et du taux des overcommits. Il est recommandé d'agrandir votre partition swap si vous comptez overcommiter de la mémoire avec KVM. Le taux d'overcommit recommandé est de 50% (0.5). La formule utilisée est  :
(0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
Il existe un article sur la manière de déterminer correctement et efficacement la taille de la partition swap sur la base de connaissances Red Hat.
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.
Il est possible d'exécuter avec un taux d'overcommit de dix fois le nombre d'invités virtualisés supérieur à la quantité de RAM physique dans le système. Ceci ne fonctionne qu'avec certaines charges d'applications (avec une virtualisation de bureau à moins de 100% d'utilisation par exemple). La formule de paramétrage des taux des overcommits n'est pas très compliquée, vous devez tester et personnaliser le taux en fonction de votre environnement.
Overcommiter les CPU virtuels
L'hyperviseur KVM prend en charge les overcommits de CPU virtualisés. Les CPU virtualisés peuvent être overcommités tant que les limites de charge des invités virtualisés le permettent. Faites attention lorsque vous overcommitez les VCPU car les charges avoisinant 100% peuvent causer à des requêtes d'être ignorées ou des temps de réponses inutilisables.
Les CPU virtualisés sont mieux overcommités lorsque chaque invité n'a qu'un seul VCPU. Le planificateur Linux est très efficace avec ce type de charge. KVM devrait pouvoir prendre en charge des invités virtualisés avec des charges de moins de 100% à un taux de cinq VCPU en toute sécurité. Overcommiter des invités virtualisés à VCPU unique ne pose pas de problèmes.
Vous ne pouvez pas overcommiter des invités à multitraitement symétrique sur plus que le nombre physique de coeurs de processeurs. Par exemple, un invité avec quatre VCPU ne devrait pas être exécuté sur un hôte avec un processeur à double coeur. Overcommiter des invités à multitraitement symétrique sur plus que le nombre physique de coeurs de processeurs provoquera une dégradation significative de la performance.
Assigner des VCPU d'invités en fonction du nombre de coeurs physiques convient et fonctionne comme prévu. Par exemple, l'exécution d'invités virtualisés avec quatre VCPU sur un hôte quadri-coeur. Dans cette installation, les invités avec des charges de moins de 100% devraient fonctionner de manière effective.

Toujours tester en premier

Ne pas overcommiter la mémoire ou les CPU dans un environnement de production sans avoir procédé à une longue série de tests. Les applications qui utilisent 100% de la mémoire ou des ressources du processeur peuvent devenir instables dans les environnements overcommités. Procéder aux tests avant tout déploiement.

32.5. Modification de /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.
La sortie ci-dessous est un exemple d'entrée grub.conf d'un système exécutant le paquetage kernel-xen. grub.conf peut varier sur votre système. La partie importante dans l'exemple ci-dessous est la section à partir de la ligne title jusqu'à la prochaine nouvelle ligne.
#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 point important à propos de grub.conf...

Your grub.conf could look very different if it has been manually edited before or copied from an example. Read Chapitre 28, Configuration des paramètres d'amorçage du noyau Xen for more information on using virtualization and grub.
Pour fixer un montant de mémoire pour votre système hôte de 256Mo au démarrage, vous aurez besoin d'adjoindre la ligne dom0_mem=256M à xen dans votre fichier grub.conf. Une version modifiée du fichier de configuration grub dans l'exemple précédent:
#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. Vérification des extensions de virtualisation

Utiliser cette section afin de déterminer si votre système possède le matériel des extensions de virtualisation. Les extensions de virtualisation (Intel VT ou AMD-V) sont requises pour une virtualisation totale.

Puis-je utiliser la virtualisation sans les extensions de virtualisation ?

Si les extensions de virtualisation de matériel ne sont pas présentes, il est possible d'utiliser la paravirtualisation Xen avec le paquetage kernel-xen de Red Hat.
  1. Exécuter la commande suivante afin de vérifier que les extensions de virtualisation de CPU sont disponibles :
    $ grep -E 'svm|vmx' /proc/cpuinfo
    
  2. Analyze the output.
    • La sortie suivante contient une saisie vmx, indiquant la présence d'un processeur Intel avec les extensions 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
      
    • La sortie suivante contient une saisie svm, indiquant la présence d'un processeur AMD avec les extensions 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.
    Le contenu de "flags:" peut apparaître plusieurs fois pour chaque hyperthread, chaque coeur, ou chaque CPU sur le système.
    The virtualization extensions may be disabled in the BIOS. If the extensions do not appear or full virtualization does not work refer to Procédure 35.1, « Activation des extensions de virtualisation dans 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.

Avertissement

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.
Procédure 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. Générer une nouvelle adresse MAC unique

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()
Une autre méthode pour générer un autre MAC pour votre invité
Vous pouvez également utiliser les modules engrangés de python-virtinst pour générer une nouvelle adresse MAC et UUID pour utiliser dans un fichier de configuration d'invité:
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
Le script ci-dessus peut également être implémenté en tant que fichier de script comme ci-dessous.
#!/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. Limiter la bande passante de réseau pour un invité 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.
La liste couvre les variables
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.
fenêtre temporelle
La fenêtre temporelle est optionnelle dans l'option rate=:
Le temps par défaut d'une fenêtre temporelle est de 50ms.
Une plus petite fenêtre temporelle procurera moins de transmissions par rafales. Cependant, le taux d'attente et le délai de reconstitution augmenteront.
La fenêtre de temps par défaut de 50ms représente un bon équilibre entre le taux de latence et le débit de traitement. Dans la plupart des cas, ce temps n'aura pas besoin d'être modifié.
Exemples de valeurs de paramètre de taux rate et utilisations.
rate=10Mb/s
Limite le taux de trafic de réseau en provenance de l'invité à 10Mo/s.
rate=250KB/s
Limite le trafic de réseau en provenance de l'invité à 250Ko/s.
rate=10MB/s@50ms
Limite la bande à 10Mo/s et procure une plage de 50Ko toutes les 50ms à l'invité.
Dans la configuration de la machine virtuelle, un exemple d'entrée VIF ressemblerait à ce qui suit:
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. Configuration des affinités de processeur Xen

Xen permet aux CPU virtuels d'un domaine de s'associer avec un ou plusieurs CPU hôtes. Ceci peut être utilisé pour allouer les ressources réelles aux invités virtualisés. Cette approche permet à Red Hat Enterprise Linux d'optimiser les ressources processeurs lors de l'emploi de processeurs dual-core, de l'hyperthreading ou d'autres technologies CPU avancées. Le planificateur de crédits Xen répartit les processeurs virtuels entre les processeurs physiques afin de maximiser l'utilisation système. Tant que le CPU virtuel reste fixé à un CPU physique, Red Hat Enterprise Linux permet au planificateur de crédits de déplacer les CPU lorsque cela s'avère nécessaire.
Si vous êtes en train d'exécuter des tâches intensives d'E/S, il est recommandé de dédier un hyperthread ou un coeur de processeur entier afin d'exécuter domain0.
Remarquez que ceci n'est pas nécessaire à KVM, car KVM utilise le planificateur du noyau Linux par défaut.
Les affinités de CPU peuvent être paramétrées avec virsh ou avec virt-manager :
To set CPU affinities using virsh refer to Configuration de l'affinité des CPU virtuels for more information.
To configure and view CPU information with virt-manager refer to Section 26.11, « Affichage des processeurs virtuels » for more information.

32.12. Modification de l'hyperviseur 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 offre un accès aux aborescences d'installation pour les invités paravirtualisés (par exemple pour les dépôts Red Hat Enterprise Linux 5) ou autress données. Si vous n'avez pas installé vsftpdpendant l'installation du serveur, vous pouvez saisir le paquetage RPM dans le répertoire Server de votre medium d'installation et l'installer en utilisant rpm -ivh vsftpd*.rpm (noter que le paquetage RPM doit figurer dans le répertoire actuel).
  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. vérifier que vsftpd n'est pas activé en utilisant chkconfig --list vsftpd :
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
    
  3. Exécuter chkconfig --levels 345 vsftpd on pour démarrer vsftpd automatiquement pour exécuter les niveaux 3, 4 et 5.
  4. Utiliser la commande chkconfig --list vsftpd pour vérifier que le démon vsftdp a bien été activé pour démarrer lors de l'initialisation du système :
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
    
  5. utiliser la commande service vsftpd start vsftpd pour démarrer le service vsftpd:
    $service vsftpd start vsftpd
    Starting vsftpd for vsftpd:                  [  OK  ]
    

32.14. Configurer la persistence LUN

This section covers how to implement LUN persistence in guests and on the host machine with and without multipath.
Implémenter la persistence LUN sans chemins multiples
Si votre système n'utilise pas de chemins multiples, vous pouvez utiliser la commande udev pour implémenter la persistence LUN. Avant d'implémenter la persistence LUN dans votre système, assurez- vous d'avoir bien acquis les UUID uniques qui conviennent. Une fois que vous les aurez acquis, vous pourrez configurer la persistence LUN en modifiant le fichier scsi_id qui réside dans le répertoire /etc . Une fois que vous avez ouvert ce dossier dans l'éditeur de textes, vous devrez commenter cette ligne:
# options=-b
Puis remplacez-la par ce paramètre :
# options=-g
Ceci a pour effet d'instruire udev de contrôler tous les systèmes SCSI qui retournent les UUID. Pour déterminer les UUID uniques, utiliser la commande scsi_id:
# scsi_id -g -s /block/sdc
*3600a0b80001327510000015427b625e*
Cette longue chaîne de caractères dans la sortie est l'UUID. L'UUID ne change pas quand vous ajoutez un nouveau périphérique à votre système. Obtenez un UUID pour chaque périphérique pour créer des règles de nomenclature de périphériques. Pour créer ces règles, vous devez modifier le fichier 20-names.rules qui réside dans le répertoire /etc/udev/rules.d . Les règles de nomenclature pour le nom doivent suivre le format suivant :
# KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="UUID", NAME="devicename"
Remplacer vos UUID et devicenameexistants et le nom du périphérique avec l'UUID ci-dessus. La règle de nomenclature devrait ressembler à ceci:
KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="3600a0b80001327510000015427b625e", NAME="mydevicename"
Ceci amène le système à activer tous les périphériques qui correspondent au motif /dev/sd* pour inspecter les UUID donnés. Lorsqu'il trouve un périphérique qui correspond, il crée un noeud de périphérique intitulé /etc/udev/rules.d . Pour cet exemple, le noeud de périphérique est /dev/mydevice . Finalement, vous aurez besoin d'adjoindre au fichier /etc/rc.local la ligne suivante:
/sbin/start_udev
Implémenter la persistence LUN avec les chemins multiples
Pour implémenter la persistance LUN dans un environnement à chemins multiples, vous devez définir les noms alias des périphériques à chemins multiples. Dans cet exemple, vous devez définir quatre alias de périphériques en modifiant le fichier multipath.conf qui réside dans le répertoire /etc/:
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp1
}
multipath  {  
             wwid       3600a0b80001327510000015427b6
             alias      oramp2
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp3
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp4
}
Ceci définit 4 LUNs: /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3, et dev/mpath/oramp4. Les périphériques résident dans le répertoire /dev/mpath . Les noms LUN sont persistants après les redémarrages car cela crée des noms aliasés sur le wwid de chacun des LUN.

32.15. Désactiver la surveillance du disque SMART pour les invités

La surveillance du disque SMART peut être désactivée car nous opérons sur des disques virtuels et le stockage physique est géré par l'hôte.
/sbin/service smartd stop
/sbin/chkconfig --del smartd

32.16. Nettoyer les anciens fichiers de configuration 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. Configurer le serveur VNC

Pour configurer le serveur VNC, utiliser l'application Remote Desktop dans System > Preferences. Sinon, vous pouvez exécuter la commande vino-preferences.
Suivre ces étapes pour exécuter une session dédiée au serveur VNC:
  1. Modifier le fichier ~/.vnc/xstartup pour démarrer la session GNOME quand vncserver démarre. La première fois que le script vncserver est exécuté, on vous demandera le mot de passe que vous souhaitez pour la session VNC.
  2. Echantillon de fichier 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. Cloner les fichiers de configuration d'un invité

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.
Vous devez modifier l'adresse HWADDR du fichier /etc/sysconfig/network-scripts/ifcfg-eth0 pour qu'il corresponde à la sortie du fichier ifconfig eth0 et si vous utilisez les adresses IP statiques, vous devrez modifier la saisie IPADDR.

32.19. Dupliquer un invité déjà existant et son fichier de configuration

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
Le nom de votre invité tel qu'il est connu à l'hyperviseur et tel qu'il est affiché dans les utilitaires de gestion. Cette saisie doit être unique dans votre système.
uuid
Par une simple opération de l'invité, un nouvel UUID peut être regénéré en utilisant la commande uuidgen. Echantillon de sortie 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 Section 32.9, « Générer une nouvelle adresse MAC unique ».
  • Si vous déplacez ou répliquez un fichier de configuration d'un invité existant vers un nouvel hôte, vous devrez bien ajuster la saisie xenbr pour correspondre à votre configuration de réseau local (vous obtiendrez l'information de pont en utilisant la commande brctl show).
  • Les saisies de périphériques: veillez à bien ajuster les saisies dans la section brctl show. pour pointer à l'image d'invité qui convient.
Maintenant, ajuster les paramètres de configuration du système pour votre invité:
/etc/sysconfig/network
Modify the HOSTNAME entry to the guest's new hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • Modifier l'adresse HWADDR à la sortie de ifconfig eth0
  • Modifier l'entrée IPADDR si une adresse IP statique est utilisée.

Chapitre 33. Création de scripts personnalisés libvirt

Cette section procure des informations qui peuvent être utiles aux programmeurs et aux administrateurs de systèmes qui ont l'intention d'écrire des scripts personnalisés afin de se rendre la vie plus facile en utilisant libvirt.
Chapitre 32, Conseils et astuces is recommended reading for programmers thinking of writing new applications which use libvirt.

33.1. Utilisation de fichiers de configuration XML à l'aide de 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

Partie VIII. Résolution de pannes

Introduction aux questions de solutions de problèmes et de résolution de pannes

Les chapitres suivants procurent des informations pour vous assister dans vos problèmes de résolution de pannes lors de votre utilisation de la virtualisation.

Notes importantes sur les problèmes de virtualisation

Votre problème précis ne figure peut-être pas dans cet ouvrage en raison du développement continu comme source de création et de résolution de bogues. Pour la liste la plus récente de bogues connus, problèmes et résolutons de bogues, lire les Notes de mise à jour Red Hat Enterprise Linux correspondant à votre version et à l'architecture de votre matériel. Les Notes de mise à jour peuvent être trouvées dans la section documentation du site Web Red Hat, www.redhat.com/docs/manuals/enterprise/.

Si tout échoue...

Veuillez contacter le service de support Red Hat Global Support Services (https://www.redhat.com/apps/support/). Le personnel pourra vous aider à résoudre vos problèmes.

Table des matières

34. Résolution de pannes Xen
34.1. Débogage et résolution de pannes dans Xen
34.2. Vue d'ensemble sur les fichiers journaux
34.3. Descriptions des fichiers journaux
34.4. Emplacements importants dans les répertoires
34.5. Résolution des pannes avec les fichiers journaux
34.6. Résolution des pannes avec la console série
34.7. Accès à la console de l'invité paravirtualisé
34.8. Accès à la console de l'invité pleinement virtualisé
34.9. Problèmes Xen communs
34.10. Erreurs de création d'invités
34.11. Résolution de pannes avec la console série
34.11.1. Sortie de console série pour Xen
34.11.2. Sortie de console série Xen depuis les invités parvirtualisés
34.11.3. Sorties de console série depuis des invités totalement virtualisés
34.12. Fichiers de configuration Xen
34.13. Interprétation des messages d'erreur Xen
34.14. La disposition des répertoires de journaux
35. Résolution de pannes
35.1. Indentifier les partitions et zônes de stockage disponibles
35.2. La console se bloque après le redémarrage des invités basés-Xen
35.3. Les périphériques Ethernet virtualisés ne sont pas détectés par les outils de réseau.
35.4. Erreurs de périphérique en boucle
35.5. Création de domaine mise en échec, pour manque de mémoire
35.6. Erreur de mauvaise image du noyau
35.7. Error de mauvaise image de noyau - noyau non-PAE sur une plateforme PAE
35.8. Invité 64 bits totalement virtualisé échoue au démarrage
35.9. Une saisie localhost manquante provoque l'échec de virt-manager
35.10. Erreur de microcode pendant le démarrage de l'invité
35.11. Messages de dépréciation Python lorsque vous démarrez une machine virtuelle.
35.12. Activation des extensions de matériel de virtualisation VT et AMD-V dans BIOS
35.13. Performance réseau KVM
36. Résolution des pannes de pilotes paravirtualisés Xen
36.1. Journalisation et répertoires de Red Hat Enterprise Linux 5 Virtualization.
36.2. L'invité paravirtualisé n'a pas réussi à télédécharger dans un système d'exploitation d'invité Red Hat Enterprise Linux 3.
36.3. Un message d'avertissement est affiché lorsque vous installez les pilotes paravirtualisés sur Red Hat Enterprise Linux 3
36.4. Charger manuellement les pilotes paravirtualisés
36.5. Vérifier que les pilotes paravirtualisés ont été chargés avec succès
36.6. Le système possède une vitesse de traitement limitée avec les pilotes paravirtualisés.

Chapitre 34. Résolution de pannes Xen

Ce chapitre couvre les concepts essentiels pour vous assister dans la résolutions de pannes de Xen. Les sujets de résolution de disfonctionnements couverts dans ce chapitre incluent :
  • outils de résolution de pannes pour Linux et pour la virtualisation.
  • techniques d'identification de problèmes.
  • Emplacement des fichiers de journalisation et explications des informations des journaux.
Ce chapitre sert à donner au lecteur des connaissances pour identifier où se trouvent les problèmes liés à la virtualisation. La résolution de pannes demande de la pratique et de l'expérience, choses qui s'apprennent pas d'un livre. Il est recommandé que vous testiez et expérimentiez la virtualisation sur Red Hat Enterprise Linux afin de développer vos capacités de résolution de pannes.
If you cannot find the answer in this document there may be an answer online from the virtualization community. Refer to Section A.1, « Ressources en ligne » for a list of Linux virtualization websites.

34.1. Débogage et résolution de pannes dans Xen

Cette section résume les applications de l'administrateur système, les utilitaires de mise en réseau, et les outils de débogage. Vous pouvez employer ces outils standards de l'administrateur de système et les fichiers journaux pour vous assister dans la résolution des pannes :
Commandes et applications utiles pour résolutions de pannes
xentop
xentop affiche des informations en temps réel sur le système hôte et sur les domaines invités.
xm
Utiliser les commandes dmesg et log
  • vmstat
  • iostat
  • lsof
Les commandes iostat, mpstat et sar sont fournies par le paquetage sysstat.
Utilisez les outils de débogage avancés et les fichiers journaux pour vous assister dans la résolution des pannes :
  • XenOprofile
  • systemtap
  • crash
  • sysrq
  • sysrq t
  • sysrq w
Vous pouvez employer ces outils de mise en réseau pour vous assister dans la résolution des pannes en réseau virtuel:
  • 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 est un outil de mise en réseau qui inspecte et configure la configuration de pont éthernet dans le noyau de Virtualisation Linux. Vous devez posséder un accès super-utilisateur avant d'exécuter ces exemples de commandes:
    # 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
    
Ci-dessous figure une liste des autres commandes utiles à la résoltuion de pannes de virtualisation sur Red Hat Enterprise Linux 5. Tous les utilitaires mentionnés peuvent être trouvés dans les dépôts Server de Red Hat Enterprise Linux 5.
  • strace est une commande qui traque les appels système et les évènements reçus et utilisés par un autre processus.
  • vncviewer: connect to a VNC server running on your server or a virtual machine. Install vncviewer using the yum install vnc command.
  • vncserver: démarre un bureau éloigné à partir de votre serveur. Vous donne la possibilité d'exécuter des interfaces graphiques d'utilisateur comme virt-manager par l'intermédiaire d'une session distante. Installer vncserver en utilisant la commande yum install vnc-server.

34.2. Vue d'ensemble sur les fichiers journaux

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:
  • Le répertoire de configuration Xen est /etc/xen/. Ce répertoire contient le démon xend et d'autres fichiers de configuration de machines virtuelles. Les fichiers des scripts de mise en réseau se trouvent dans le répertoire /scripts.
  • Tous les fichiers journeaux de Xen sont stockés dans le répertoire /var/log/xen.
  • Le répertoire par défaut pour toutes les images basées-fichiers est nommé /var/lib/libvirt/images.
  • Les informations deu noyau Xen sont stockées dans le répertoire /proc/xen/.

34.3. Descriptions des fichiers journaux

Xen a pour atouts le démon xend et le processus qemu-dm, deux utilitaires qui écrivent de multiples fichiers journaux dans le répertoire /var/log/xen/ :
  • xend.log est le fichier journal qui contient toutes les données collectées par le démon xend, que ce soit un évènement système ordinaire, ou une action initiée par l'opérateur. Toutes les opérations des machines virtuelles (comme créer, fermer, supprimer etc.) apparaissent à cet endroit. Le xend.log est généralement le premier endroit où vous pouvez tracer les problèmes d'événement ou de performance. Il contient des entrées détaillées et les conditions des messages d'erreur.
  • xend-debug.log est le fichier journal qui contient des données d'erreurs dans les évènements à partir de xend et les sous-systèmes de virtualisation (comme la mémoire tampon, les scripts Python, etc.).
  • xen-hotplug-log est le fichier journal contenant les données des évènements "hotplug". Si un périphérique ou un script réseau ne vient pas en ligne, l'évènement apparaît ici.
  • qemu-dm.[PID].log est le fichier journal créé par le processus qemu-dm pour chaque invité pleinement virtualisé. Quand vous utilisez ce fichier journal, vous devez récupérer le processus PID qemu-dm en utilisant la commande ps pour examiner les arguments du processus afin d'isoler le processus qemu-dm sur la machine virtuelle. Notez que vous devez remplacer le symbole [PID] par le processus PID qemu-dm.
Si des erreurs surviennent avec le gestionnaire de machines virtuelles (Virtual Machine Manager), vous pouvez revoir les données générées dans le fichier virt-manager.log qui réside dans le répertoire /.virt-manager. Notez que chaque fois que vous démarrer le gestionnaire de machines virtuelles, il surcharge le contenu des fichiers journaux existants. Assurez-vous de sauvegarder le fichier virt-manager.log avant de redémarrer le gestionnaire de machines virtuelles après une erreur système.

34.4. Emplacements importants dans les répertoires

Il existe d'autres utilitaires et des fichiers journaux à connaître lorsque vous traquez des erreurs et problèmes à résoudre dans Xen :
  • Les images d'invités virtualisés résident dans le répertoire /var/lib/libvirt/images.
  • Quand vous redémarrez le démon xend, il met à jour la xend-database qui réside dans le répertoire /var/lib/xen/xend-db.
  • Les vidages de machine virtuelle (que vous exécutez avec la commande xm dump-core) résident dans le répertoire /var/lib/xen/dumps.
  • Le répertoire /etc/xen contient les fichiers de configuration que vous utilisez pour gérer les ressources système. Le fichier de configuration du démon xend est appelé /etc/xen/xend-config.sxp. Ce fichier peut être modifié pour implémenter les modifications sur tout le système et pour configurer la mise en réseau. Cependant, la modification manuelle des fichiers dans le dossier /etc/xen/ est déconseillée.
  • Les commandes proc sont une autre ressource qui vous permet de rassembler des informations système. Ces entrées proc résident dans le répertoire /proc/xen:
/proc/xen/capabilities
/proc/xen/balloon
/proc/xen/xenbus/

34.5. Résolution des pannes avec les fichiers journaux

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'autre fichier journal xend-debug.log, est très utile aux administrateurs système puisqu'il contient des informations encore plus détaillées que le xend.log. Voici les mêmes données d'erreurs que pour le même problème de création de domaine de noyau:
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
Quand vous appelez l'assistance clientèle, incluez toujours une copie de ces deux fichiers journaux.

34.6. Résolution des pannes avec la console série

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
La sync_console peut vous aider à déterminer un problème qui cause des "hangs" (suspensions de système) avec des sorties de console d'hyperviseur asynchrone, et le "pnpacpi=off" se charge d'un problème qui casse les saisies sur la console série. Les paramètres "console=ttyS0" et "console=tty" signifient que les erreurs de noyau sont journalisées avec à la fois la console VGA normale et la console série. Ensuite vous pouvez installer et paramétrer ttywatch pour capturer les données sur un hôte distant connecté avec un cable "null-modem" standard. Par exemple, sur l'hôte distant vous pouvez saisir :

résolution de pannes sur la console série Ithanium

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 Chapitre 29, Configurer ELILO.
ttywatch --name myhost --port /dev/ttyS0
Cela canalise la sortie depuis /dev/ttyS0 vers le fichier /var/log/ttywatch/myhost.log.

34.7. Accès à la console de l'invité paravirtualisé

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. Accès à la console de l'invité pleinement virtualisé

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. Problèmes Xen communs

Quand vous tentez de démarrer le service xend, il ne se passe rien. Saisissez virsh list et vous recevrez ce qui suit :
Error: Error connecting to xend: Connection refused. Is xend running?
Vous essayez d'exécuter xend start manuellement et vous obtenez des messages d'erreurs supplémentaires :
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' )
Il est probable que vous ayez relancé votre hôte dans un noyau qui n'est pas un noyau kernel-xen. Pour corriger cela, vous devez sélectionner le noyau kernel-xen au moment du lancement (ou configurer kernel-xen par défaut dans le fichier grub.conf).

34.10. Erreurs de création d'invités

Quand vous tentez de créer un invité, vous recevez un message d'erreur "Invalid argument". Cela signifie en général que l'image noyau que vous tentez de lancer est incompatible avec l'hyperviseur. Un exemple de cela serait si vous tentiez d'exécuter un noyau non-PAE FC5 sur un hyperviseur FC6 uniquement PAE.
Vous faites une mise à jour yum et recevez un nouveau noyau, le noyau par défaut grub.conf redevient directement un noyau bare-metal au lieu d'un noyau de virtualisation.
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. Résolution de pannes avec la console série

Les noyaux Linux peuvent transférer des informations vers les ports en série. Ceci est utile lors de débogages de panique de noyau et lors de problèmes de matériel avec des périphériques vidéos ou autres serveurs adminstrés à distance. Les sous-sections de cette section couvrent le paramétrage de sortie des consoles série pour les machines exécutant des noyaux de virtualisation Red Hat Enterprise Linux et pour leur invités virtualisés.

34.11.1. Sortie de console série pour Xen

By default, the serial console for the Xen hypervisor is disabled and no data is output from serial ports.
Pour recevoir des informations sur le noyau sur un port série, modifier le fichier /boot/grub/grub.conf en choisissant les paramètres de périphérique série appropriés.
Si votre console série est sur com1, modifier /boot/grub/grub.conf en insérant les lignes com1=115200,8n1, console=tty0 et console=ttyS0,115200 comme indiqué.
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
Si votre console série est sur com2, modifier /boot/grub/grub.conf en insérant les lignes com2=115200,8n1 console=com2L, console=tty0 et console=ttyS0,115200 comme indiqué.
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
Sauvegarder les changements et redémarrer l'hôte. L'hyperviseur sort des données série sur le port série (com1, com2, etc.) que vous avez spécifié lors de l'étape précédente.
Remarquez l'exemple utilisant le port com2, le paramètre console=ttyS0 sur la ligne vmlinuz est utilisé. Le comportement de chaque port utilisé comme console=ttyS0 n'est pas un comportement Linux standard et est spécifique à l'environnement Xen.

34.11.2. Sortie de console série Xen depuis les invités parvirtualisés

Cette section décrit comment configurer une console série virtualisée pour les invités paravirtualisés Red Hat Enterprise Linux.
Les sorties de consoles série depuis les invités paravirtualisés peuvent être reçues à l'aide de "virsh console" ou dans la fenêtre "Serial Console" de virt-manager. Paramétrer la console série virtuelle à l'aide de la procédure suivante :
  1. Connectez-vous à votre invité paravirtualisé.
  2. Modifier /boot/grub/grub.conf comme suit :
    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. Redémarrer l'invité paravirtualisé.
Vous devriez maintenant recevoir des message du noyau sur les consoles "Serial Console" et "virsh console" de virt-manager.
Journalisation de la sortie de console série du domaine paravirtualisé
Le démon Xen (xend) peut être configuré pour journaliser les sorties de consoles série des invités paravirtualisés.
Pour configurer xend, modifier /etc/sysconfig/xend. Changer l'entrée :
# 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
Redémarrer l'hôte pour activer la journalisation de sortie de console série de l'invité.
Les fichiers journeaux des consoles série sont stockées dans le fichier /var/log/xen/console.

34.11.3. Sorties de console série depuis des invités totalement virtualisés

Cette section couvre l'activation des sorties de consoles série pour les invités totalement virtualisés.
Une sortie de console série d'un invité totalement virtualisé peut être vue avec la commande "virsh console".
Sachez que les consoles série d'invités totalement virtualisés ont certaines limitations. Les limitations actuelles incluent :
  • la journalisation de sortie avec xend n'est pas disponible.
  • les données de sortie peuvent être perdues ou brouillées.
Le port série est nommé ttyS0 sur Linux, ou COM1 sur Windows.
Vous devez configurer le système d'exploitation virtualisé pour sortir les informations vers le port série virtuel.
Pour sortir les informations du noyau depuis un invité Linux totalement virtualisé vers le domaine, modifier le fichier /boot/grub/grub.conf en insérant la ligne "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
Redémarrer l'invité.
Voir les messages de la console série en utilisant la commande "virsh console".

Remarque

Contrairement à ce qu'il en est pour les invités paravirtualisés, les messages de consoles série des domaines totalement virtualisés ne sont pas journalisés dans /var/log/xen/console.

34.12. Fichiers de configuration 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"
Notez que serial="pty" est la valeur par défaut pour le fichier de configuration. Cet exemple de fichier de configuration est pour l'invité pleinement virtualisé :
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'

Fichiers de configuration Xen

La modification des fichiers de configuration Xen N,est pas prise en charge. Utiliser virsh dumpxml et virsh create (ou virsh edit) pour modifier les fichiers de configuration libvirt (basés-XML) qui ont des fonctions de vérification d'erreurs et de vérification de sécurité.

34.13. Interprétation des messages d'erreur Xen

Vous recevez le message d'erreur suivant :
failed domain creation due to memory shortage, unable to balloon domain0
Un domaine peut échouer quand il n'y a pas assez de RAM disponible. Domain0 ne fournit pas suffisamment d'espace pour l'invité nouvellement créé. Vous pouvez vérifier le xend.log suite à cette erreur :
[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
Vous pouvez vérifier la quantité de mémoire utilisée par domain0 en utilisant la commande xm list Domain0. Si dom0 n'est pas réduit, vous pouvez utiliser la commande virsh setmem dom0 NewMemSize pour vérifier la mémoire.
Vous recevez le message d'erreur suivant :
wrong kernel image: non-PAE kernel on a PAE
Ce message indique que vous tentez d'exécuter une image de noyau d'invité qui n'est pas prise en charge sur votre hyperviseur. Cela arrive quand vous essayez de démarrer un noyau d'invité paravirtualisé non PAE sur un hôte Red Hat Enterprise Linux 5. e paquetage Red Hat kernel-xen ne prend en charge que des noyaux invités avec PAE et des architectures 64 bit.
Saisissez cette commande :
# 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)
Si vous désirez exécuter un noyau 32bit/non-PAE, il faudra exécuter votre invité en tant que machine virtuelle pleinement virtualisée. Pour les invités paravirtualisés, si vous devez exécuter un invité PAE 32bit, il vous faudra un hyperviseur PAE 32bit. Pour les invités paravirtualisés, si vous devez exécuter un invité PAE 64bit, il vous faudra un hyperviseur PAE 64bit. Pour les invités pleinement virtualisés, vous devez exécuter un invité 64bit avec un hyperviseur 64bit. L'hyperviseur PAE 32bit qui accompagne RHEL 5 i686 ne prend en charge que l'exécution du PAE 32 bit paravirtualisé et l'invité OSes 32bit pleinement virtualisé. L'hyperviseur 64bit ne prend en charge que les invités paravirtualisés 64bit.
Cela a lieu quand vous déplacez l'invité HVM pleinement virtualisé sur un système RHEL 5.0. Le démarrage de votre invité peut échouer et vous verrez une erreur sur l'écran de la console. Vérifiez l'entrée PAE dans votre fichier de configuration et assurez vous que pae=1. Vous utiliserez une distribution 32bit.
Vous recevez le message d'erreur suivant :
Unable to open a connection to the Xen hypervisor or daemon
Cela arrive quand le démarrage de l'application virt-manager échoue. Cette erreur a lieu quand il n'y a pas d'entrée d'hôte local (localhost) dans le fichier de configuration /etc/hosts. Vérifiez le fichier et vérifiez que l'entrée de l'hôte local est activée. Voici un exemple d'entrée d'hôte local incorrecte :
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
Voici un exemple d'entrée d'hôte local correcte :
# 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
Vous recevez l'erreur suivante (dans le xen-xend.log file):
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.
Par ailleurs, xend.log affiche les erreurs suivantes :
[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',]
Vous recevez ces erreurs d'obsolescence 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)
Python génère ces messages quand un fichier de configuration est invalide (ou incorrect). Pour résoudre ce problème, vous devez modifier le fichier de configuration incorrect, ou vous pouvez en créer un nouveau.

34.14. La disposition des répertoires de journaux

La structure de base de l'environnement Red Hat Enterprise Linux 5 Virtualization est le suivant:
le répertoire /etc/xen/ comprend
  • Fichiers de configuration utilisés par le démon xend.
  • Le répertoire scripts qui contient les scripts de pour réseaux virtuels.
/var/log/xen/
  • répertoire contenant tous les fichiers journaux Xen
/var/lib/libvirt/images/
  • Le répertoire par défaut des fichiers image pour machines virtuelles.
  • SI vous utilisez un répertoire différent pour vos images de machines virtuelles, veillez bien à ajouter le répertoire dans votre politique SELinux et d'en changer le nom avant de démarrer l'installation.
/proc/xen/
  • informations en rapport à Xen dans le système de fichiers /proc.

Chapitre 35. Résolution de pannes

Ce chapitre couvre les problèmes communs et leurs solutions pour la virtualisation Red Hat Enterprise Linux.

35.1. Indentifier les partitions et zônes de stockage disponibles

Vérifier que le pilote est chargé et que les périphériques et partitions sont disponibles pour l'invité. Il suffit d'exécuter "cat /proc/partitions" comme ci-dessous.
# cat /proc/partitions
major minor  #blocks   name 
 202    16  104857600  xvdb
   3     0    8175688  hda

35.2. La console se bloque après le redémarrage des invités basés-Xen

Occasionally, a Xen guest's console freezes when the guest boots. The console still displays messages but the user cannot log in.
Pour régler ce problème, ajouter la ligne suivante au fichier /etc/inittab :
1:12345:respawn:/sbin/mingetty xvc0
Redémarrer après avoir sauvegardé le fichier. Comme prévu, la session de la console devrait maintenant être interactive.

35.3. Les périphériques Ethernet virtualisés ne sont pas détectés par les outils de réseau.

Les outils réseau ne détectent pas la carte réseau Xen Virtual Ethernet dans le système d'exploitation de l'invité. Vérifier ceci (pour Red Hat Enterprise Linux 4 et Red Hat Enterprise Linux 5) en exécutant :
cat /etc/modprobe.conf
Ou (pour Red Hat Enterprise Linux 3) :
cat /etc/modules.conf
La sortie devrait contenir la ligne ainsi qu'une autre ligne similaire pour chaque interface supplémentaire.
alias eth0 xen-vnif
Pour régler ce problème, vous devrez ajouter les lignes d'alias (par example, alias eth0 xen-vnif) pour chaque interface paravirtualisée pour l'invité.

35.4. Erreurs de périphérique en boucle

Si les images basées-fichier sont utilisées, vous pouvez être amené à augmenter le nombre de périphériques configurés en boucle. La configuration par défaut vous autorise jusqu'à huit périphériques en boucle actifs. Si vous avez besoin de plus de 8 invités basés-fichier ou périphériques en boucle, le nombre de périphériques en boucle configurés peut être ajusté dans /etc/modprobe.conf. Modifier /etc/modprobe.conf et y ajouter la ligne suivante :
                options loop max_loop=64
Cet exemple utilise 64, mais vous pouvez spécifier un autre nombre pour définir la valeur maximum de boucles. Vous pouvez également implémenter des invités avec périphérique en boucle sur votre système. Pour utiliser des invités équipés de périphériques en boucle sur un invité partiellement virtualisé, utiliser les commandes phy: block device ou tap:aio Pour utiliser des invités équipés de périphériques en boucle sur un système complètement virtualisé, utiliser les commandes phy: device ou file: file .

35.5. Création de domaine mise en échec, pour manque de mémoire

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. Erreur de mauvaise image du noyau

Les invité paravirtualisés ne peuvent pas utiliser le noyau kernel-xen. Pour les invités paravirtualisés, utiliser le noyau standard uniquement.
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 solution est de vérifier que vous avez bien installé in noyau Xen dans votre invité et que c'est le noyau par défaut pour initialiser le fichier de /etc/grub.conf.
Si kernel-xen est installé sur votre invité, vous pouvez lancer l'invité :
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. Error de mauvaise image de noyau - noyau non-PAE sur une plateforme 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:
  • les invités partiellement virtualisés doivent faire correspondre le type d'architecture de votre hyperviseur. Si vous souhaitez exécuter un invité PAE 32 bit, vous devez posséder un hyperviseur PAE 32 bit.
  • pour exécuter un invité 64 bit paravirtualisé, votre hyperviseur doit être également une version 64 bit.
  • pour les invités totalement virtualisés, votre hyperviseur doit être de 32 bit ou de 64 bit pour des invités de 32 bit. Vous pouvez exécuter un invité de 32 bit (PAE et non-PAE) sur un hyperviseur de 32 bit ou de 64 bit.
  • pour exécuter un invité totalement virtualisé de 64 bit, votre hyperviseur doit posséder 64 bit également.

35.8. Invité 64 bits totalement virtualisé échoue au démarrage

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. Une saisie localhost manquante provoque l'échec de virt-manager

L'application virt-manager peut échouer au démarrage et afficher une erreur comme “Unable to open a connection to the Xen hypervisor/daemon”. Cela est normalement dû à une saisie manquante localhost dans le fichier /etc/hosts. Vérifiez que vous avez bien saisi localhost et s'il y a une saisie manquante dans /etc/hosts, et insérez une nouvelle saisie dans localhost si elle n'est pas présente. Un /etc/hosts éronné peut ressembler à ce qui suit :
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
La saisie correcte devrait être similaire à ce qui suit :
# 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. Erreur de microcode pendant le démarrage de l'invité

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. Messages de dépréciation Python lorsque vous démarrez une machine virtuelle.

Parfois, Python va générer un message comme celui qui suit, souvent causé par un fichier de configuration invalide ou incorrecte. Un fichier de configuration contenant des caractères non-ascii peut entraîner ce genre d'erreurs. La solution est soit de corriger le fichier de configuration, soit d'en générer un nouveau.
Une autre cause peut être un fichier de configuration incorrect dans votre répertoire de travail courant. “xm create” cherchera un fichier de configuration dans votre répertoire courant, puis dans /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. Activation des extensions de matériel de virtualisation VT et AMD-V dans BIOS

Cette section décrit comment identifier les extensions de virtualisation de matériel et les activer dans votre BIOS si elles sont désactivées.
Les extensions Intel VT peuvent être désactivées dans le BIOS. Certains fournisseurs d'ordinateurs portables ont désactivé les extensions BIOS dans les processeurs par défaut.
Les extensions de virtualisation ne peuvent pas être désactivées dans le BIOS pour AMD-V.
The virtualization extensions are sometimes disabled in BIOS, usually by laptop manufacturers. Refer to Section 35.12, « Activation des extensions de matériel de virtualisation VT et AMD-V dans BIOS » for instructions on enabling disabled virtualization extensions.
Vérifier que les extensions de virtualisation sont activées dans BIOS. Les paramètres BIOS pour VT ou AMD-V Intel® sont généralement dans les menus Chipset ou Processor. Les nom de menus peuvent varier de ceux proposés dans ce guide. Les paramètres d'extensions de virtualisation peuvent être trouvés dans Security Settings ou dans d'autres menus non standards.
Procédure 35.1. Activation des extensions de virtualisation dans 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. Débrancher la machine.
  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. Débrancher la machine.
  6. Exécuter cat /proc/cpuinfo | grep vmx svm. S'il en résulte en une sortie, alors les extensions de virtualisation sont activées. S'il n'y a pas de sortie, le paramètre des extensions de virtualisation de votre système ou le paramètre BIOS n'est peut-être pas activé.

35.13. Performance réseau KVM

Par défaut, les machines virtuelles KVM se voient assigner un contrôleur réseau NIC (de l'anglais, network interface controller) virtuel Realtek 8139 (rtl8139).
Le NIC virtualisé rtl8139 fonctionne correctement dans la plupart des environnements. Toutefois ce périphérique peut souffir d'une dégradation de performance sur certains réseaux, par exemple, un réseau Ethernet 10 Gigabit.
Pour contourner ce problème, il est possible de permuter sur un autre type de NIC virtualisé. Par exemple, Intel PRO/1000 (e1000) ou virtio (le pilote réseau paravirtualisé).
Pour permuter sur le pilote e1000 :
  1. Fermer le système d'exploitation invité.
  2. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name):
    # virsh edit GUEST
    La commande virsh edit utilise la variable shell $EDITOR afin de déterminer quel éditeur utiliser.
  3. Trouver la section interface réseau de la configuration. Cette section ressemble à l'extrait ci-dessous :
    <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. Sauvegarder les changements puis quitter l'éditeur
  6. Redémarrer le système d'exploitation invité.
Alternativement, vous pouvez installer les nouveaux invités virtualisés avec un pilote réseau différent. Ceci peut être requissi vous avez des difficultés lors de l'installation d'invités sur une connection réseau. Cette méthode requiert qu'au moins une machine virtuelle ait été créée au préalable (à partir d'un CD ou DVD), ceci afin qu'elle puisse servir de modèle.
  1. Créer un modèle XML depuis une machine virtuelle existante :
    # virsh dumpxml GUEST > /tmp/guest.xml
    
  2. Copier et modifier le fichier XML, et mettre à jour les champs uniques : nom de machine virtuelle, UUID, image disque, adresse MAC, ainsi que tout autre paramètre unique. Remarquez que vous pouvez supprimer les lignes de l'UUID et de l'adresse MAC et virsh les générera de nouveau.
    # cp /tmp/guest.xml /tmp/new-guest.xml
    # vi /tmp/new-guest.xml
    
    Ajouter la ligne modèle à la section interface réseau :
     <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  3. Créer la nouvelle machine virtuelle :
    # virsh define /tmp/new-guest.xml
    # virsh start new-guest
    
La performance réseau devrait être meilleure avec les pilotes e1000 ou virtio. (BZ#517181)

Chapitre 36. Résolution des pannes de pilotes paravirtualisés Xen

Ce chapitre traite des problèmes que vous pourriez rencontrer avec les hôtes Xen et les invités totalement virtualisés Red Hat Enterprise Linux utilisant les pilotes paravirtualisés.

36.1. Journalisation et répertoires de Red Hat Enterprise Linux 5 Virtualization.

/var/log/xen/
répertoire contenant tous les fichiers journaux générés par le démon xend et le processus qemu-dm.
xend.log
  • Ce fichier journal est utilisé par xend pour enregistrer tout évênement généré, soit des évênements de système ordinaires, soit des évênements initiés par l'opérateur.
  • les opérations en machine virtuelle comme créer, fermer, détruire etc sont toutes enregistrées dans ce fichier journal.
  • Normalement, ce fichier journal est le premier endroit où regarder en cas de problème. Dans de nombreux cas, vous serez en mesure d'identifier la cause principale en étudiant le fichier journal et en révisant les saisies qui précèdent le message d'erreur.
xend-debug.log
  • Enregistre les erreurs en provenance de xend et de ses sous-systèmes (tels que les scripts framebuffer et Python)
xen-hotplug.log
  • Journalise les événements hotplug.
  • Les notifications d'événements de périphériques hors ligne ou de ponts de réseau hors ligne sont journalisés dans ce fichier.
qemu-dm.PID.log
  • Ce fichier est créé par le processus qemu-dm qui est démarré pour chaque invité totalement virtualisé.
  • Le PID sera remplacé par le PID du processus lié au qemu-dm relatif
  • Vous pouvez retrouver le PID correspondant à un processus qemu-dm particulier en utilisant la commande ps et en regardant à quels arguments de processus qemu-dm la machine virtuelle peut être identifiée.
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.

Note

Le fichier journal est réécrit à chaque fois que vous démarrez virt-manager. Si vous rencontrez un problème avec virt-manager, assurez-vous bien de sauvegarder votre fichier journal avant de redémarrer virt-manager suite à une erreur.
/var/lib/libvirt/images/
le répertoire standard pour les images d'invités basées fichier.
/var/lib/xen/xend-db/
répertoire qui contient la base de données xend générée à chaque fois que le démon est redémarré.
/etc/xen/
Stocke un certain nombre de fichiers de configuration pour l'hyperviseur Xen.
  • /etc/xen/xend-config.sxp est la configuration principale du démon xend. Le fichier xend-config.sxp est utilisé pour activer ou désactiver les migrations ainsi que d'autres fonctionnalités qui ne sont pas configurées par libvirt. Utlisez les outils libvirt pour toutes les autres fonctionnalités.
/var/lib/xen/dump/
Contient les vidages générés par les machines virtuelles ou en utilisant la commande xm dump-core.
/proc/xen/
Stocke les informations xen-kernel dans les fichiers suivants :
  • /proc/xen/capabilities
  • /proc/xen/privcmd
  • /proc/xen/balloon
  • /proc/xen/xenbus
  • /proc/xen/xsd_port
  • /proc/xen/xsd_kva

36.2. L'invité paravirtualisé n'a pas réussi à télédécharger dans un système d'exploitation d'invité Red Hat Enterprise Linux 3.

Red Hat Enterprise Linux 3 utilise des RPM de noyaus de processeurs à architecture spécifique. Pour cette raison, les pilotes paravirtualisés peuvent échouer au niveau du chargement si le pilote RPM paravirtualisé ne correspond pas à l'architecture du noyau installé.
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. Un message d'avertissement est affiché lorsque vous installez les pilotes paravirtualisés sur Red Hat Enterprise Linux 3

L'installation de pilotes paravirtualisés sur le noyau Red Hat Enterprise Linux 3 antérieur à 2.4.21-52 peut aboutir à un message d'avertissement affichant que les modules ont bien été compilés dans une version plus récente à celle du noyau en cours.
Ce message, comme ci-dessous, peut être ignoré en toute sécurité.
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 partie importante de ce message est la dernière ligne qui doit expliquer que le module a été chargé avec des avertissements.

36.4. Charger manuellement les pilotes paravirtualisés

Si les pilotes paravirtualisés venaient à échouer en chargement automatique pendant le processus de démarrage, vous pouvez tenter de les charger manuellement.
Ceci vous permettra de reconfigurer le réseau ou les entités de stockage, ou encore d'identifier la raison pour laquelle ils ont échoué. Les étapes suivantes devraient vous permettre de charger les modules du pilote paravirtualisé.
Tout d'abord, localiser les modules du pilote paravirtualisé dans votre système.
# cd /lib/modules/`uname -r`/
# find . -name 'xen_*.ko' -print
Noter les emplacements et charger les modules manuellement. Substituer {LocationofPV-drivers} par l'emplacement qui convient et que vous avez noté à partir des données de sortie des commandes ci-dessus.
# 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. Vérifier que les pilotes paravirtualisés ont été chargés avec succès

Une des premières tâches à effectuer est de vérifier si les pilotes ont bien été chargés dans votre système.
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. Le système possède une vitesse de traitement limitée avec les pilotes paravirtualisés.

If network throughput is still limited even after installing the para-virtualized drivers and you have confirmed they are loaded correctly (refer to Section 36.5, « Vérifier que les pilotes paravirtualisés ont été chargés avec succès  »). To fix this problem, remove the 'type=ioemu' part of 'vif=' line in your guest's configuration file.

Glossary

Le glossaire a pour but de définir la terminologie utilisée dans le Guide d'installation.
Adresses MAC
L'adresse MAC (de l'anglais Media Access Control Address) est l'adresse du matériel sur une carte d'interface réseau. Dans un contexte de virtualisation, les adresses MAC doivent être générées pour les interfaces de réseaux virtuels, avec chaque MAC étant unique sur votre domaine local.
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.
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).
Hardware Virtual Machine
See Full virtualization.
Hôte
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.
Hyperviseur
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
Abréviation d'Entrée/Sortie. Ce terme, E/S, est utilisé pour décrire tout programme, opération ou appareil qui transmet des données vers ou en provenance d'un ordinateur ou d'un périphérique. Chaque transfert est une sortie 'en provenance de' et une entrée 'vers' un périphérique. Les matériels comme les claviers, les souris sont uniquement des périphériques d'entrée, tandis que les imprimantes sont uniquement des périphériques de sortie. Un CD-ROM inscriptible est à la fois un périphérique d'entrée et de sortie.
Itanium®
L'architecture de processeur Intel Itanium®.
Kernel SamePage Merging
Le module KSM (de l'anglais, Kernel SamePage Merging) est utilisé par l'hyperviseur KVM pour permettre aux invités KVM de partager des pages mémoire identiques. Les pages partagées sont habituellement des bibliothèques communes ou autres données de haute utilisation. KSM peut améliorer la performance de certains invités en gardant ces bibliothèques en cache pour divers invités, et peut aussi augmenter la densité des invités.
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 est un ensemble de modules du noyau Linux qui gère des périphériques, la mémoire, et la gestion des API pour le module de l'Hyperviseur. Les invités virtualisés sont exécutés comme des processus et threads Linux qui sont eux-même contrôlés par ces modules.
LUN
Un LUN (de l'anglais, Logical Unit Numbers) est le nombre qui est assigné à une unité logique (une entité du protocole SCSI).
Machines virtuelles
Une machine virtuelle est une implémentation logicielle d'une machine physique ou d'un langage de programmation (comme Java Runtime Environment ou LISP). Dans le contexte de virtualisation, les machines virtuelles sont des systèmes d'exploitation qui opèrent sur du matériel virtualisé.
Migration
Le terme migration est utilisé pour décrire le processus de déplacement d'un invité virtuel depuis un hôte vers un autre. Une migration peut être conduite hors-ligne (dans quel cas l'invité est suspendu, puis déplacé) ou celle-ci peut être conduite en direct (lorsque l'invité est déplacé sans être interrompu). Les invités Xen totalement virtualisés, les invités Xen paravirtualisés et les invités KVM totalement virtualisés peuvent tous être migrés.
La migration est une fonctionnalité clé de la virtualisation puisque le logiciel est totalement séparé du matériel physique. Celle-ci est utile pour :
  • L'équilibrage de la charge - les invités peuvent être déplacés vers les hôtes avec une utilisation moins importante lorsqu'un hôte est surchargé.
  • Le basculement de matériel - lorsque les périphériques matériel sur l'hôte commencent à échouer, les invités peuvent être déplacés en toute sécurité afin que l'hôte puisse être éteint puis réparé.
  • Les économies d'énergie - les invités peuvent être redistribués vers d'autres hôtes et les hôtes systèmes peuvent être éteints afin de'économiser de l'énergie et de réduire les coûts lors des périodes d'utilisation creuses.
  • Les migrations géographiques - les invités peuvent être déplacés vers une autre destination afin d'obtenir une latence plus faible ou dans des circonstances plus sérieuses.
Le stockage partagé en réseau est utilisé pour stocker les images des invités. Sans le stockage partagé, la migration n'est pas possible.
Une migration hors-ligne suspend l'invité, puis déplace une image de la mémoire de l'invité vers l'hôte destinataire. L'invité est relancé sur l'hôte destinataire et la mémoire utilisée par l'invité sur l'hôte source est libérée.
Le temps qu'une migration hors-ligne prend dépend de la bande passante du réseau et de la latence. Un invité avec 2 Go de mémoire ne devrait prendre que quelques secondes sur une liaison Ethernet de 1 Go.
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.
Le temps qu'une migration hors-ligne prend dépend de la bande passante du réseau et de la latence. Si le réseau est utilisé de manière importante ou si la bande passante est faible, alors la migration mettra bien plus longtemps.
Para-virtualisation
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.
Comme dans Fedora 9, on n'aura plus besoin d'un noyau spécial. Une fois que cette retouche est acceptée dans l'arborescence principale Linux, tous les noyaux linux suivant cette version verront leur virtualisation activée ou disponible.
Para-virtualisé
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.
Pilotes para-virtualisés
Les pilotes paravirtualisés sont des pilotes de périphériques qui opèrent sur des invités Linux totalement virtualisés. Ces pilotes augmentent considérablement la performance des réseaux et des périphériques E/S pour les invités totalement virtualisés.
Security Enhanced Linux
Abbréviation de Security Enhanced Linux, SELinux utilise les modules de sécurité Linux (de l'anglais, Linux Security Modules, ou LSM) du noyau Linux afin de fournir un ensemble de politiques de sécurité ne nécessitant qu'un minimum de privilèges.
Système Invité
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.
Totalement virtualisé
See Full virtualization.
Universally Unique Identifier
Unn identificateur unique universel (UUID) est une méthode de chiffrage standardisée pour périphériques, systèmes, et pour certains objets de logiciels dans les environnements de calcul distribué. Les types d'UUID dans la virtualisation incluent :Les identificateurs de systèmes de fichiers ext2 et ext3, les identificateurs de périphériques RAID, iSCSI et LUN, les adresses MAC et les identificateurs de machines virtuelles.
Virtualisation
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.
  • La virtualisation ou émulation de logiciel. La virtualisation utilise une traduction binaire ainsi que d'autres techniques d'émulation pour exécuter des systèmes d'exploitation non-modifiés. La virtualisation de logiciel est significativement plus lente que la virtualisation d'assistance matérielle ou que la paravirtualisation. La virtualisation de logiciel, sous la forme de QEMU, n'est pas prise en charge par 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.
Virtualisation totale
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.
Virtualized CPU
Un système comporte un certain nombre de CPU virtuels (VCPU) relatif au nombre de coeurs dans le(s) processeur(s) physique(s). Ce nombre de VCPU est fini et représente le nombre total de VCPU pouvant être assignés à des machines virtuelles invitées.
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.

Ressources supplémentaires

Pour en savoir plus sur la virtualisation et sur Red Hat Enterprise Linux, reportez-vous aux ressources suivantes.

A.1. Ressources en ligne

  • http://www.cl.cam.ac.uk/research/srg/netos/xen/ Le site Web du projet de gestionnaire de machines paravirtualisées Xen™ à partir duquel le paquetage Red Hat kernel-xen est dérivé. Le site maintient le code source et les binaires du projet Xen en amont, mais contient également des informations, des aperçus de l'architecture, de la documentation et des liens relatifs à Xen et aux technologies qui y sont associées.
  • Site web de la communauté Xen
  • http://www.libvirt.org/ est le site Web officiel pour l'API de virtualisation libvirt.
  • http://virt-manager.et.redhat.com/ — est le site Web du projet concernant le gestionnaire de machines virtuelles (virt-manager), l'application graphique pour la gestion des machines virtuelles.

A.2. Documentation installée

  • /usr/share/doc/xen-<version-number>/ —. est le répertoire contenant beaucoup d'informations à propos de l'hyperviseur de virtualisation partielle Xen et les outils de gestion associés, y compris un aperçu des différents exemples de configurations, des informations spécifiques au matériel et la documentation utilisateur en amont de Xen.
  • man virsh et /usr/share/doc/libvirt-<version-number> — contiennent des sous-commandes et des options pour l'utilitaire de gestion de la machine virtuelle virsh ainsi que des informations détaillées à propos de la bibliothèque de virtualisation API libvirt.
  • /usr/share/doc/gnome-applet-vm-<version-number> — Contient de la documentation sur l'applet graphique du tableau de bord GNOME qui contrôle et gère les machines virtuelles qui sont exécutées en local.
  • /usr/share/doc/libvirt-python-<version-number> — Fournit des détails sur les associations Python pour la bibliothèque libvirt. Le paquetage libvirt-python permet aux développeurs python de créer des programmes qui s'interfacent avec la bibliothèque de gestion de la virtualisation libvirt.
  • /usr/share/doc/python-virtinst-<version-number> — Fournit de la documentation sur la commande virt-install qui aide au démarrage d'installations de distributions Fedora et Red Hat Enterprise Linux au sein des machines virtuelles.
  • /usr/share/doc/virt-manager-<version-number> — Fournit de la documentation sur le gestionnaire de machines virtuelles qui fournit un outil graphique pour administrer les machines virtuelles.

Colophon

Ce manuel a été rédigé sous le format DocBook XML v4.3.
This book is based on the work of Jan Mark Holzer, Chris Curran and Scott Radvan.
Ont également contribués :
  • Don Dutile, éditeur technique pour la section Pilotes paravirtualisés.
  • Barry Donahue, éditeur technique pour la section Pilotes paravirtualisés.
  • Rick Ring, éditeur technique pour la section Gestion des machines virtuelles.
  • Michael Kearey, éditeur technique pour les sections sur l'utilisation des fichiers de configuration XML avec des lecteurs de disquettes virtualisés et virsh.
  • Marco Grigull, éditeur technique pour la section compatibilité et performance des logiciels.
  • Eugene Teo, éditeur technique pour la section Gestion des invités avec virsh.
Publican, l'outil de publication utilisé pour produire cet ouvrage, a été développé par Jeffrey Fearn.
Les personnes suivantes composent l'équipe de localisation Red Hat :
  • Chinois simplifié
    • Leah Wei Liu
  • Chinois traditionnel
    • Chester Cheng
    • Terry Chuang
  • Japonais
    • Kiyoto Hashida
  • Coréen
    • Eun-ju Kim
  • Français
    • Sam Friedmann
  • Allemand
    • Hedda Peters
  • Italien
    • Francesco Valente
  • Portugais brésilien
    • Glaucia de Freitas
    • Leticia de Lima
  • Espagnol
    • Angela Garcia
    • Gladys Guerrero
  • Russe
    • Yuliya Poyarkova