Product SiteDocumentation Site

Red Hat Enterprise Linux 5

Virtualisierungshandbuch

Virtualization Documentation

Ausgabe 5.8

Red Hat Engineering Content Services

Rechtlicher Hinweis

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

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

Vorwort
1. Über dieses Buch
2. Dokumentkonventionen
2.1. Typografische Konventionen
2.2. Konventionen für Seitenansprachen (engl.: pull-quotes)
2.3. Anmerkungen und Warnungen
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. Anforderungen und Einschränkungen bei der Virtualisierung mit Red Hat Enterprise Linux
1. Systemvoraussetzungen
2. Einschränkungen und Unterstützung von Xen
3. Einschränkungen und Unterstützung von KVM
4. Hyper-V restrictions and support
5. Einschränkungen der Virtualisierung
5.1. Allgemeine Einschränkungen der Virtualisierung
5.2. KVM-Einschränkungen
5.3. Xen-Einschränkungen
5.4. Anwendungseinschränkungen
II. Installation
6. Installation der Virtualisierungspakete
6.1. Installation von Xen während einer neuen Red Hat Enterprise Linux Installation
6.2. Installation von Xen-Paketen auf einem vorhandenen Red Hat Enterprise Linux System
6.3. Installation von KVM während einer neuen Red Hat Enterprise Linux Installation
6.4. Installation von KVM-Paketen auf einem vorhandenen Red Hat Enterprise Linux System
7. Überblick über die Installation virtualisierter Gäste
7.1. Erzeugen von Gästen mit virt-install
7.2. Erzeugen von Gästen mit virt-manager
7.3. Installation von Gästen mit PXE
8. Installationsverfahren für Gastbetriebssysteme
8.1. Installation von Red Hat Enterprise Linux 5 als paravirtualisierter Gast
8.2. Installation von Red Hat Enterprise Linux als voll virtualisierter Gast
8.3. Installation von Windows XP als voll virtualisierter Gast
8.4. Installation von Windows Server 2003 als voll virtualisierter Gast
8.5. Installation von Windows Server 2008 als voll virtualisierter Gast
III. Konfiguration
9. Virtualized storage devices
9.1. Anlegen eines virtualisierten Floppy-Disk-Controllers
9.2. Hinzufügen von Speichergeräten zum Gast
9.3. Konfiguration von persistentem Speicher in Red Hat Enterprise Linux 5
9.4. Hinzufügen eines virtualisierten CD-ROM- oder DVD-Laufwerks zu einem Gast
10. Netzwerkkonfiguration
10.1. Network Address Translation (NAT) mit libvirt
10.2. Bridged-Netzwerk mit libvirt
11. Xen-Netzwerke vor Red Hat Enterprise Linux 5.4
11.1. Konfiguration von multiplen Gastnetzwerk-Bridges zur Verwendung mehrerer Ethernet-Karten
11.2. Red Hat Enterprise Linux 5.0 Laptop-Netzwerkkonfiguration
12. Xen paravirtualisierte Treiber
12.1. Systemvoraussetzungen
12.2. Einschränkungen und Unterstützung der Paravirtualisierung
12.3. Installation der paravirtualisierten Treiber
12.3.1. Allgemeine Installationsschritte
12.3.2. Installation und Konfiguration von paravirtualisierten Treibern in Red Hat Enterprise Linux 3
12.3.3. Installation und Konfiguration von paravirtualisierten Treibern in 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. Konfiguration paravirtualisierter Netzwerktreiber
12.5. Konfiguration zusätzlicher paravirtualisierter Hardware
12.5.1. Virtualisierte Netzwerkschnittstellen
12.5.2. Virtuelle Speichergeräte
13. KVM paravirtualisierte Treiber
13.1. Installation der KVM Windows paravirtualisierten Treiber
13.2. Installing drivers with a virtualized floppy disk
13.3. Verwenden der KVM paravirtualisierten Treiber für vorhandene Geräte
13.4. Verwenden von KVM paravirtualisierten Treibern für neue Geräte
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Zeitverwaltung bei KVM-Gästen
IV. Verwaltung
17. Beste Verfahren für Server
18. Sicherheit für Virtualisierung
18.1. Storage security issues
18.2. SELinux und Virtualisierung
18.3. SELinux
18.4. Virtualization firewall information
19. Gästeverwaltung mit Hilfe von xend
20. Xen Live-Migration
20.1. Beispiel für eine Live-Migration
20.2. Konfiguration der Live-Migration eines Gasts
21. KVM Live-Migration
21.1. Voraussetzungen der Live-Migration
21.2. Beispiel für gemeinsam genutzten Speicher: NFS für eine einfache Migration
21.3. KVM Live-Migration mit virsh
21.4. Migration mit virt-manager
22. Remote-Verwaltung virtualisierter Gäste
22.1. Remote-Verwaltung mit SSH
22.2. Remote-Verwaltung über TLS und SSL
22.3. Transportmodi
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. Referenzhandbuch zur Virtualisierung
24. Virtualisierungs-Tools
25. Das Verwalten von Gästen mit virsh
26. Das Verwalten von Gästen mit dem Virtual Machine Manager (virt-manager)
26.1. The Add Connection window
26.2. Das Hauptfenster des Virtual Machine Managers
26.3. The guest Overview tab
26.4. Die grafische Konsole der virtuellen Maschine
26.5. Starten des virt-manager
26.6. Wiederherstellen einer gespeicherten Maschine
26.7. Anzeigen von Gastdetails
26.8. Überwachen des Status
26.9. Anzeigen der Gast-Identifier
26.10. Displaying a guest's status
26.11. Anzeigen virtueller CPUs
26.12. Anzeigen der CPU-Auslastung
26.13. Anzeigen des Speicherverbrauchs
26.14. Verwalten eines virtuellen Netzwerks
26.15. Erstellen eines virtuellen Netzwerks
27. Kurzanleitung zum xm-Befehl
28. Konfigurieren der Xen-Kernel-Boot-Parameter
29. Konfigurieren von ELILO
30. libvirt configuration reference
31. Xen-Konfigurationsdateien
VII. Tipps und Tricks
32. Tipps und Tricks
32.1. Gäste automatisch starten
32.2. Wechseln zwischen dem KVM- und Xen-Hypervisor
32.2.1. Xen zu KVM
32.2.2. KVM zu Xen
32.3. Verwenden von qemu-img
32.4. Overcommitting Resources
32.5. Modifizieren von /etc/grub.conf
32.6. Überprüfen der Virtualisierungserweiterungen
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. Generieren einer neuen, eindeutigen MAC-Adresse
32.10. Begrenzen der Netzwerkbandbreite für einen Xen-Gast
32.11. Konfigurieren von Xen-Prozessoraffinitäten
32.12. Modifizieren des Xen-Hypervisors
32.13. Very Secure ftpd
32.14. Konfigurieren von LUN-Persistenz
32.15. Abschalten der SMART-Disk-Überwachung von Gästen
32.16. Bereinigen alter Xen-Konfigurationsdateien
32.17. Konfigurieren eines VNC-Servers
32.18. Klonen von Gastkonfigurationsdateien
32.19. Kopieren eines existierenden Gasts und seiner Konfigurationsdatei
33. Erstellung angepasster libvirt-Skripte
33.1. Verwendung von XML-Konfigurationsdateien mit virsh
VIII. Suche und Beseitigung von Fehlern (Troubleshooting)
34. Suche und Beseitigung von Fehlern (Troubleshooting) in Xen
34.1. Suche und Beseitigung von allgemeinen Fehlern (Troubleshooting) und Programmfehlern (Debugging) in Xen
34.2. Überblick über Protokolldateien
34.3. Beschreibung der Protokolldateien
34.4. Speicherorte wichtiger Verzeichnisse
34.5. Suche und Beseitigung von Fehlern mit Hilfe der Protokolldateien
34.6. Suche und Beseitigung von Fehlern mit der seriellen Konsole
34.7. Konsolenzugriff bei paravirtualisierten Gästen
34.8. Konsolenzugriff bei voll virtualisierten Gästen
34.9. Häufige Probleme mit Xen
34.10. Fehler bei der Erstellung eines Gasts
34.11. Suche und Beseitigung von Fehlern mit seriellen Konsolen
34.11.1. Serielle Konsolenausgabe für Xen
34.11.2. Xen serielle Konsolenausgabe von paravirtualisierten Gästen
34.11.3. Serielle Konsolenausgabe von voll virtualisierten Gästen
34.12. Xen-Konfigurationsdateien
34.13. Interpretation von Xen-Fehlermeldungen
34.14. Aufbau der Protokollverzeichnisse
35. Suche und Beseitigung von Fehlern (Troubleshooting)
35.1. Identifizieren von verfügbarem Speicher und Partitionen
35.2. Nach Neustart von Xen-basierten Gästen bleibt die Konsole hängen
35.3. Virtualisierte Ethernet-Geräte werden nicht von den Netzwerk-Tools erkannt
35.4. Fehler bei Loop-Gerät
35.5. Domain-Erstellung schlägt fehl aufgrund von zu wenig Arbeitsspeicher
35.6. Fehler durch falsches Kernel-Image
35.7. Fehler durch falsches Kernel-Image – nicht-PAE-Kernel auf einer PAE-Plattform
35.8. Voll virtualisierter 64 Bit Gast kann nicht hochfahren
35.9. Ein fehlender Localhost-Eintrag führt zum Fehlschlagen von virt-manager
35.10. Microcode-Fehler beim Hochfahren des Gasts
35.11. Python-Warnmeldungen (Deprecation) beim Start einer virtuellen Maschine
35.12. Aktivieren der Intel VT und AMD-V Virtualisierungs-Hardware-Erweiterungen im BIOS
35.13. KVM-Netzwerkleistung
36. Suche und Beseitigung von Fehlern (Troubleshooting) bei Xen paravirtualisierten Treibern
36.1. Protokolldateien und -verzeichnisse der Red Hat Enterprise Linux 5 Virtualisierung
36.2. Paravirtualisierter Gast kann nicht auf einem Red Hat Enterprise Linux 3 Gastbetriebssystem geladen werden
36.3. Während der Installation des paravirtualisierten Treibers auf Red Hat Enterprise Linux 3 wird eine Warnmeldung angezeigt
36.4. Manuelles Laden der paravirtualisierten Treiber
36.5. Überprüfen des erfolgreichen Ladens der paravirtualisierten Treiber
36.6. Das System hat einen begrenzten Datendurchsatz mit paravirtualisierten Treibern
Glossary
A. Zusätzliche Informationsquellen
A.1. Online-Informationsquellen
A.2. Installierte Dokumentation
B. Kolophon

Vorwort

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

1. Über dieses Buch

This book is divided into 8 parts:
  • Systemvoraussetzungen
  • Installation
  • Konfiguration
  • Verwaltung
  • Storage
  • Glossar
  • Tipps und Tricks
  • Suche und Beseitigung von Fehlern (Troubleshooting)
Key terms and concepts used throughout this book are covered in the Glossary.
This book covers virtualization topics for Red Hat Enterprise Linux 5. The KVM and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization. Refer to Abschnitt 4, „What is Virtualization?“ and the Glossary for more details on these terms.

2. Dokumentkonventionen

Dieses Handbuch verwendet mehrere Konventionen, um bestimmte Wörter und Phrasen hervorzuheben und Aufmerksamkeit auf spezifische Informationen zu lenken.
In PDF- und Papierausgaben verwendet dieses Handbuch Schriftbilder des Liberation-Fonts-Sets. Das Liberation-Fonts-Set wird auch für HTML-Ausgaben verwendet, falls es auf Ihrem System installiert ist. Falls nicht, werden alternative, aber äquivalente Schriftbilder angezeigt. Beachten Sie: Red Hat Enterprise Linux 5 und die nachfolgende Versionen beinhalten das Liberation-Fonts-Set standardmäßig.

2.1. Typografische Konventionen

Es werden vier typografische Konventionen verwendet, um die Aufmerksamkeit auf spezifische Wörter und Phrasen zu lenken. Diese Konventionen und die Umstände, unter denen sie auftreten, sind folgende:
Nichtproportional Fett
Dies wird verwendet, um Systemeingaben hervorzuheben, einschließlich Shell-Befehle, Dateinamen und Pfade. Es wird ebenfalls zum Hervorheben von Tasten und Tastenkombinationen verwendet. Zum Beispiel:
Um den Inhalt der Datei my_next_bestselling_novel in Ihrem aktuellen Arbeitsverzeichnis zu sehen, geben Sie den Befehl cat my_next_bestselling_novel in den Shell-Prompt ein und drücken Sie Enter, um den Befehl auszuführen.
Das oben aufgeführte Beispiel beinhaltet einen Dateinamen, einen Shell-Befehl und eine Taste. Alle werden nichtproportional fett dargestellt und alle können, dank des Kontextes, leicht unterschieden werden.
Die Tastenkombination kann von einer Taste durch den Bindestrich, der alle Teile der Tastenkombination miteinander verbindet, unterschieden werden. Zum Beispiel:
Drücken Sie Enter, um den Befehl auszuführen.
Drücken Sie Strg+Alt+F2, um zum ersten virtuellen Terminal zu wechseln. Drücken Sie Strg+Alt+F1, um zu Ihrer X-Windows-Sitzung zurückzukehren.
Der erste Absatz hebt die jeweilige Taste hervor, die gedrückt werden soll. Der zweite Absatz hebt zwei Tastenkombinationen hervor (jeweils ein Satz von drei Tasten, wobei jeder Satz gleichzeitig gedrückt wird).
Falls Quellcode diskutiert wird, werden Klassennamen, Methoden, Funktionen, Variablennamen und Rückgabewerte, die innerhalb eines Abschnitts erwähnt werden, wie oben gezeigt nichtproportional fett dargestellt. Zum Beispiel:
Zu dateiverwandten Klassen zählen filesystem für Dateisysteme, file für Dateien und dir für Verzeichnisse. Jede Klasse hat ihren eigenen Satz an Berechtigungen.
Proportional Fett
Dies kennzeichnet Wörter oder Phrasen, die auf einem System vorkommen, einschließlich Applikationsnamen, Text in Dialogboxen, beschriftete Schaltflächen, Bezeichnungen für Auswahlkästchen und Radio-Buttons, Überschriften von Menüs und Untermenüs. Zum Beispiel:
Wählen Sie SystemEinstellungenMaus in der Hauptmenüleiste aus, um die Mauseinstellungen zu öffnen. Klicken Sie im Reiter Tasten auf das Auswahlkästchen Mit links bediente Maus und anschließend auf Schließen, um die primäre Maustaste von der linken auf die rechte Seite zu ändern (d.h., um die Maus auf Linkshänder anzupassen).
Um ein spezielles Zeichen in eine gedit-Datei einzufügen, wählen Sie AnwendungenZubehörZeichentabelle in der Hauptmenüleiste aus. Wählen Sie als Nächstes SuchenSuchen… aus der Menüleiste der Zeichentabelle aus, geben den Namen des Zeichens in das Suchbegriff-Feld ein und klicken auf Weiter. Das gesuchte Zeichen wird in der Zeichentabelle hervorgehoben. Doppelklicken Sie auf das hervorgehobene Zeichen, um es in das Feld Zu kopierender Text einzufügen und klicken Sie auf die Schaltfläche Kopieren. Wechseln Sie nun zurück in Ihr Dokument und wählen Sie BearbeitenEinfügen aus der gedit-Menüleiste aus.
Der oben aufgeführte Text enthält Applikationsnamen, systemweite Menünamen und -elemente, applikationsspezifische Menünamen sowie Schaltflächen und Text innerhalb einer GUI-Oberfläche. Alle werden proportional fett dargestellt und sind anhand des Kontextes unterscheidbar.
Nichtproportional Fett Kursiv oder Proportional Fett Kursiv
Egal ob nichtproportional fett oder proportional fett, ein zusätzlicher Kursivdruck weist auf einen ersetzbaren oder variablen Text hin. Kursivdruck kennzeichnet Text, der nicht wörtlich eingeben wird, oder angezeigter Text, der sich je nach gegebenen Umständen ändert. Zum Beispiel:
Um sich mit einer Remote-Maschine via SSH zu verbinden, geben Sie an einem Shell-Prompt ssh username@domain.name ein. Falls die Remote-Maschine example.com ist und Ihr Benutzername auf dieser Maschine John lautet, geben Sie also ssh john@example.com ein.
Der Befehl mount -o remount file-system hängt das angegebene Dateisystem wieder ein. Um beispielsweise das /home-Dateisystem wieder einzuhängen, verwenden Sie den Befehl mount -o remount /home.
Um die Version des derzeit installierten Pakets zu sehen, verwenden Sie den Befehl rpm -q package. Die Ausgabe sieht wie folgt aus: package-version-release.
Achten Sie auf die oben aufgeführten Wörter, die fett und kursiv gedruckt sind — username, domain.name, file-system, package, version und release. Jedes Wort ist ein Platzhalter, entweder für einen Text, den Sie eingeben, wenn Sie einen Befehl ausführen oder für Text, der durch das System angezeigt wird.
Neben der Standardbenutzung für die Darstellung des Titels eines Werks, zeigt der Kursivdruck auch die erstmalige Nutzung eines neuen und wichtigen Begriffs an. Zum Beispiel:
Publican ist ein DocBook Publishing-System.

2.2. Konventionen für Seitenansprachen (engl.: pull-quotes)

Ausgaben des Terminals und Auszüge aus dem Quellcode werden visuell vom umliegenden Text hervorgehoben.
Eine Ausgabe, die an das Terminal gesendet wird, wird in den Schrifttyp nichtproportional Roman gesetzt und demnach wie folgt präsentiert:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Auszüge aus dem Quellcode werden ebenfalls in den Schrifttyp nichtproportional Roman gesetzt, doch wird zusätztlich noch die Syntax hervorgehoben:
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. Anmerkungen und Warnungen

Zu guter Letzt verwenden wir drei visuelle Stile, um die Aufmerksamkeit auf Informationen zu lenken, die andernfalls vielleicht übersehen werden könnten.

Anmerkung

Eine Anmerkung ist ein Tipp, ein abgekürztes Verfahren oder ein alternativer Ansatz für die vorliegende Aufgabe. Das Ignorieren von Anmerkungen sollte keine negativen Auswirkungen haben, aber Sie verpassen so vielleicht einen Trick, der Ihnen das Leben vereinfachen könnte.

Wichtig

Die Wichtig-Schaukästen lenken die Aufmerksamkeit auf Dinge, die sonst leicht übersehen werden können: Konfigurationsänderungen, die nur für die aktuelle Sitzung gelten oder Dienste, für die ein Neustart nötig ist, bevor eine Aktualisierung wirksam wird. Das Ignorieren von Wichtig-Schaukästen würde keinen Datenverlust verursachen, kann aber unter Umständen zu Ärgernissen und Frustration führen.

Warnung

Eine Warnung sollte nicht ignoriert werden. Das Ignorieren von Warnungen führt mit hoher Wahrscheinlichkeit zu Datenverlust.

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.
Möglicherweise haben Sie bereits in die sich rasant entwickelnde Technologie der Virtualisierung investiert. Sollte dies der Fall sein, erwägen Sie einige der folgenden Ideen, um diese Technologie noch besser ausnutzen zu können. Falls Sie noch nicht investiert haben, ist jetzt der richtige Zeitpunkt gekommen, um einzusteigen.
Virtualisierung liefert eine Reihe von Tools, die Ihre Flexibilität steigern und Ihre Kosten senken können – wichtige Aspekte in jedem Unternehmen und jeder IT-Organisation. Virtualisierungslösungen sind immer mehr im Kommen und bieten zunehmend mehr Features.
Virtualisierung kann Ihnen signifikante Vorteile in vielen Bereichen Ihres Unternehmens bringen. Deshalb sollten Sie jetzt ein Pilotprojekt starten, Fachkenntnisse entwickeln und die Virtualisierungstechnologie in Ihrem Unternehmen auf den Weg bringen.
Virtualisierung für Innovation
Im Wesentlichen steigert Virtualisierung Ihre Flexibilität dadurch, dass Betriebssystem, Dienste und Anwendungen, die von diesem System unterstützt werden, von der spezifischen, physischen Hardware-Plattform entkoppelt werden. Es erlaubt die Einrichtung von mehreren virtuellen Umgebungen auf einer gemeinsam verwendeten Hardware-Plattform.
Nach Innovation strebende Unternehmen werden feststellen, dass die Möglichkeit, neue Systeme oder Dienste zu erzeugen, ohne zusätzliche Hardware installieren zu müssen (und ebenjene schnell wieder außer Betrieb nehmen zu können, wenn sie nicht länger benötigt werden), einen deutlichen Innovationsschub bringen kann.
Mögliche Herangehensweisen sind z. B. die schnelle Erzeugung von Entwicklungssystemen zur Herstellung von angepasster Software; die Möglichkeit, kurzfristig Testumgebungen einzurichten; die Fähigkeit, alternative Software-Lösungen bereitzustellen und diese ohne weitreichende Hardware-Investitionen zu vergleichen; die Unterstützung von schnellem Prototyping und flexiblen Entwicklungsumgebungen; sowie die Möglichkeit, bei Bedarf schnell neue Produktionsdienste einzurichten.
Diese Umgebungen können vor Ort erzeugt oder von extern bereitgestellt werden, wie z. B. durch Amazons EC2. Da die Kosten für die Erzeugung einer neuen virtuellen Umgebung gering ausfallen und auf bereits existierende Hardware zurückgegriffen werden kann, wird mit geringem Investitionsaufwand Innovation ermöglicht bzw. beschleunigt.
Virtualisierung unterstützt auch dadurch hervorragend Innovation, dass virtuelle Umgebungen zum Lernen und Üben benutzt werden können. Diese Dienste sind ideale Anwendungsfälle für die Virtualisierungstechnologie. Ein Kursteilnehmer kann so seine Arbeit in einer bekannten, standardmäßigen Systemumgebung aufnehmen. Die Arbeit in der Klasse kann vom Produktionsnetzwerk isoliert werden. Die Teilnehmer können einzigartige Software-Umgebungen errichten, ohne die Hardware-Ressourcen exklusiv zu beanspruchen.
In dem Maße, in dem sich die Möglichkeiten virtueller Umgebungen weiterentwickeln, wird es auch wahrscheinlicher, dass Virtualisierung verstärkt eingesetzt wird für portable, auf die Bedürfnisse eines Benutzers zugeschnittene Umgebungen. Diese Umgebungen können dynamisch in eine öffentliche oder lokale Umgebung verschoben werden, ungeachtet dessen, wo sich der Benutzer befindet. Die virtuellen Umgebungen des Benutzers können im Netzwerk gespeichert werden, oder auf einem portablen Speichergerät transportiert werden.
Ein artverwandtes Konzept ist das Appliance Operating System, ein Applikationspaket-orientiertes Betriebssystem, das für die Ausführung in einer virtuellen Umgebung entworfen wurde. Dieser Paketansatz kann zu niedrigeren Entwicklungs- und Support-Kosten führen, und stellt sicher, dass die Anwendung in einer bekannten, sicheren Umgebung läuft. Eine Appliance Operating System Lösung bietet Vorteile sowohl für Anwendungsentwickler als auch für Kunden dieser Anwendungen.
Wie sich diese Anwendungsfälle der Virtualisierungstechnologie auf Ihr Unternehmen übertragen lassen, kann ganz unterschiedlich sein. Falls Sie die Technologie bereits in mehr als einem der oben genannten Bereiche einsetzen, sollten Sie ggf. eine zusätzliche Investition in eine Lösung in Betracht ziehen, die eine schnelle Entwicklung erfordert. Falls Sie Virtualisierung noch nicht nutzen, beginnen Sie mit einer Implementierung zum Lernen und Üben, um Kenntnisse aufzubauen, und gehen anschließend zur Anwendungsentwicklung und zum Testen über. Unternehmen mit breitgefächerten Erfahrungen mit Virtualisierung sollten erwägen, portable virtuelle Umgebungen oder Anwendungen zu implementieren.
Virtualisierung als Kostenersparnis
Virtualisierung kann auch zur Kostensenkung eingesetzt werden. Ein offensichtlicher Nutzen liegt in der Zusammenlegung von Servern zu einer kleineren Anzahl leistungsstärkerer Hardware-Plattformen, auf denen eine Reihe virtueller Umgebungen ausgeführt werden. Durch die Verringerung des Hardware-Umfangs und die Verringerung ungenutzter Kapazitäten können nicht nur Kosten gespart werden, sondern ggf. auch die Leistung verbessert werden, da die virtuellen Gäste auf leistungsstärkerer Hardware laufen.
Weitere Vorteile sind u. a. die Möglichkeit, die Hardware-Kapazitäten ohne Betriebsstörungen zu erweitern, sowie die Möglichkeit, Arbeitsaufkommen dynamisch auf verfügbare Ressourcen zu migrieren.
Abhängig von den Bedürfnissen Ihres Unternehmens wäre es auch möglich, eine virtuelle Umgebung zur Wiederherstellung im Notfall zu erstellen. Die Einführung von Virtualisierung kann die Notwendigkeit zur Replikation identischer Hardware-Umgebungen signifikant verringern und erlaubt das kostengünstige Testen von Notfallszenarien.
Virtualisierung bietet eine hervorragende Lösung für den Umgang mit Stoßzeiten in der Auslastung. Falls Sie zusätzliches Arbeitsaufkommen in ihrem Unternehmen haben, können Sie denjenigen Anwendungen dynamisch Ressourcen zuteilen, die gerade die höchste Nachfrage haben. Falls Sie zu Stoßzeiten eine größere Auslastung haben, die Sie momentan unternehmensintern abfedern, können Sie evtl. bei Bedarf Kapazitäten von Extern zukaufen und diese mittels der Virtualisierungstechnologie effizient implementieren.
Die Kostenersparnis durch Server-Konsolidierung kann beeindruckend sein. Falls Sie Virtualisierung noch nicht zu diesem Zweck nutzen, sollten Sie jetzt damit anfangen. Während Sie Erfahrungen mit der Virtualisierung sammeln, sollten Sie die Vorteile der Lastverteilung und virtualisierter Umgebungen zur Wiederherstellung im Notfall erkunden.
Virtualisierung als Standardlösung
Unabhängig von den spezifischen Anforderungen Ihres Unternehmens sollten Sie sich mit Virtualisierung als Teil Ihres System- und Anwendungsportfolios auseinandersetzen, denn diese Technologie wird sich höchstwahrscheinlich durchsetzen. Wir erwarten, dass Anbieter von Betriebssystemen Virtualisierung als eine Standardkomponente einbinden werden, dass Hardware-Anbieter Virtualisierungsfähigkeiten in ihre Plattformen einbauen, und dass Virtualisierungsanbieter ihr Angebot erweitern werden.
Falls Sie noch nicht planen, eine Virtualisierungslösung in Ihre Architektur einzubinden, so ist jetzt der ideale Zeitpunkt gekommen, um ein Pilotprojekt zu starten. Wählen Sie hierfür einfach ein paar nicht ausgelastete Hardware-Plattformen aus und gewinnen Sie Kenntnisse über diese flexible und kosteneffiziente Technologie. Erweitern Sie anschließend Ihre Zielarchitekturen durch die Einbindung virtueller Lösungen. Zwar sind schon wesentliche Vorteile möglich, wenn vorhandene Dienste virtualisiert werden. Doch gerade die Erstellung neuer Anwendungen mit integrierter Virtualisierungsstrategie kann weitere Vorteile hinsichtlich Verwaltbarkeit und Verfügbarkeit bringen.
Mehr Informationen über die Virtualisierungslösungen von Red Hat finden Sie unter http://www.redhat.com/products/.

Teil I. Anforderungen und Einschränkungen bei der Virtualisierung mit Red Hat Enterprise Linux

Systemvoraussetzungen, Einschränkungen der Unterstützung und sonstige Grenzen

Dieses Kapitel beschreibt die Systemvoraussetzungen, Einschränkungen der Unterstützung und sonstige Grenzen bei der Virtualisierung mit Red Hat Enterprise Linux.

Kapitel 1. Systemvoraussetzungen

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 Kapitel 6, Installation der Virtualisierungspakete.
Mindestsystemvoraussetzungen
  • 6 GB freier Speicherplatz
  • 2 GB 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 Abschnitt 32.4, „Overcommitting Resources“.
Voraussetzungen für Xen-Paravirtualisierung
Paravirtualisierte Gäste benötigen einen Red Hat Enterprise Linux 5 Installationsbaum, der über das Netzwerk via NFS, FTP oder HTTP-Protokollen verfügbar ist.
Voraussetzungen für Xen Volle Virtualisierung
Volle Virtualisierung mit dem Xen-Hypervisor erfordert:
  • an Intel processor with the Intel VT extensions, or
  • einen AMD-Prozessor mit den AMD-V-Erweiterungen, oder
  • einen Intel Itanium Prozessor.
Refer to Abschnitt 32.6, „Überprüfen der Virtualisierungserweiterungen“ to determine if your processor has the virtualization extensions.
Voraussetzungen für KVM
Der KVM-Hypervisor erfordert:
  • einen Intel-Prozessor mit den Intel VT und den Intel 64 Erweiterungen, oder
  • einen AMD-Prozessor mit den AMD-V und den AMD64-Erweiterungen.
Refer to Abschnitt 32.6, „Überprüfen der Virtualisierungserweiterungen“ to determine if your processor has the virtualization extensions.
Speicherunterstützung
Die unterstützen Methoden für Gastspeicher sind:
  • Files on local storage
  • Physical disk partitions
  • Locally connected physical LUNs
  • LVM partitions
  • iSCSI and Fibre Channel based LUNs

Dateibasierter Gastspeicher

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 Abschnitt 18.2, „SELinux und Virtualisierung“ for details.

Kapitel 2. Einschränkungen und Unterstützung von 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:

Anmerkung

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

Itanium®-Unterstützung

Virtualization with the Xen hypervisor on the Intel Itanium architecture requires the guest firmware image package, refer to Installation des Xen-Hypervisors mit yum for more information.

Kapitel 3. Einschränkungen und Unterstützung von 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 Abschnitt 32.6, „Überprüfen der Virtualisierungserweiterungen“.
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:

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

Anmerkung

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.

Kapitel 5. Einschränkungen der Virtualisierung

Dieses Kapitel beschreibt zusätzliche Einschränkungen der Virtualisierungstechnologie in Red Hat Enterprise Linux.

5.1. Allgemeine Einschränkungen der Virtualisierung

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.
Weitere Einschränkungen
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.
Vor Einsatz testen
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. KVM-Einschränkungen

Die folgenden Einschränkungen gelten für den KVM-Hypervisor:
Konstantes TSC-Bit
Systems without a Constant Time Stamp Counter require additional configuration. Refer to Kapitel 16, Zeitverwaltung bei KVM-Gästen for details on determining whether you have a Constant Time Stamp Counter and configuration steps for fixing any related issues.
Speicher-Overcommit
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.
CPU-Overcommit
Es werden nicht mehr als zehn virtuelle CPUs pro physischem Prozessorkern unterstützt. Eine Zuweisung von virtuellen CPUs über die Anzahl der physischen Prozessorkerne hinaus (CPU-Overcommit) kann mit bestimmten virtualisierten Gästen Probleme verursachen.
Overcommitting CPUs has some risk and can lead to instability. Refer to Abschnitt 32.4, „Overcommitting Resources“ for tips and recommendations on overcommitting CPUs.
Virtualisierte SCSI-Geräte
SCSI emulation is presently not supported. Virtualized SCSI devices are disabled in KVM.
Virtualisierte IDE-Geräte
KVM ist beschränkt auf eine Anzahl von maximal vier virtualisierten (emulierten) IDE-Geräten pro Gast.
Paravirtualisierte Geräte
Paravirtualisierte Geräte, die die virtio-Treiber nutzen, sind PCI-Geräte. Derzeit sind Gäste auf maximal 32 PCI-Geräte beschränkt. Bei einigen PCI-Geräten ist es für den Gast entscheidend, dass sie laufen; diese Geräte können nicht entfernt werden. Die standardmäßig notwendigen Geräte sind:
  • die Host-Bridge,
  • die ISA-Bridge und USB-Bridge (die ISA- und USB-Bridge sind dasselbe Gerät),
  • die Grafikkarte (die entweder den Cirrus- oder qxl-Treiber nutzt), sowie
  • das "Memory Ballooning"-Gerät.
Von den 32 verfügbaren PCI-Geräten für einen Gast sind vier nicht entfernbar. Das bedeutet, dass pro Gast nur 28 PCI-Slots für zusätzliche Geräte zur Verfügung stehen. Jedes paravirtualisierte Netzwerk- oder Blockgerät braucht einen Slot. Jeder Gast kann bis zu 28 zusätzliche Geräte in einer beliebigen Kombination aus paravirtualisiertem Netzwerk, paravirtualisierte Festplatten oder anderen PCI-Geräten mit VT-d einsetzen.
Migrationseinschränkungen
Live-Migration ist nur möglich mit CPUs von demselben Hersteller (also z. B. Intel zu Intel oder AMD zu AMD).
Das No eXecution (NX) Bit muss für Live-Migration für beide CPUs auf "on" oder "off" gesetzt sein.
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. Xen-Einschränkungen

Anmerkung

All limitations in this chapter are limitations for Red Hat Enterprise Linux 5.8 except where noted. Older versions may have fewer limitations.
Xen-Host (dom0)-Einschränkungen
  • 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.

Umgehen der Höchstgrenze für paravirtualisierte Geräte

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.
Ein Host kann eine unbegrenzte Anzahl von phy-Geräten haben, sofern er über ausreichend Ressourcen verfügt.
LVM, oder ein vergleichbares Tool zur logischen Partitionierung, kann auf Blockgeräten verwendet werden, um auf einem einzigen paravirtualisierten Blockgerät zusätzliche logische Partitionen anzulegen.
Einschränkungen der Xen-Paravirtualisierung
  • 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.
  • Eine Höchstanzahl von 15 Netzwerkgeräten pro virtualisiertem Gast.
Einschränkungen der Xen-Vollvirtualisierung
  • For x86 guests, a maximum of 16GB memory per guest.
  • Eine Höchstanzahl von vier virtualisierten (emulierten) IDE-Geräten pro Gast.
    Diese Einschränkung gilt nicht für Geräte, welche die paravirtualisierten Treiber für voll virtualisierte Gäste verwenden.
  • 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.

    Verwenden von mehr als 8 Loopback-Geräten

    Standardmäßig schränkt Red Hat Enterprise Linux die Anzahl verfügbarer Loopback-Geräte ein. Diese Anzahl kann jedoch vergrößert werden, indem die Begrenzung im Kernel verändert wird.
    Fügen Sie in /etc/modprobe.conf die folgende Zeile hinzu:
    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.
  • Eine Höchstanzahl von 15 Netzwerkgeräten pro virtualisiertem Gast.
  • Eine Höchstanzahl von 15 virtualisierten SCSI-Geräten pro virtualisiertem Gast.
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. Anwendungseinschränkungen

Es gibt bei der Virtualisierung einige Aspekte, aufgrund derer Virtualisierung für bestimmte Anwendungstypen ungeeignet ist.
Anwendungen mit hohem I/O-Durchsatz sollten die paravirtualisierten Treiber für voll virtualisierte Gäste verwenden. Ohne die paravirtualisierten Treiber können bestimmte Anwendungen unter hoher I/O-Last instabil werden.
Die folgenden Anwendungen sollten wegen Ihren hohen I/O-Anforderungen vermieden werden:
  • kdump-Server
  • netdump-Server
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.

Teil II. Installation

Kapitel 6. Installation der Virtualisierungspakete

Bevor Sie Virtualisierung einsetzen können, müssen die Virtualisierungspakete auf Red Hat Enterprise Linux installiert sein. Virtualisierungspakete können entweder während der Installationssequenz oder nach abgeschlossener Installation mit Hilfe des yum-Befehls und Red Hat Network (RHN) installiert werden.
Sie können den KVM- und den Xen-Hypervisor auf demselben System installieren. Der Xen-Hypervisor verwendet das kernel-xen-Paket und der KVM-Hypervisor verwendet den standardmäßigen Red Hat Enterprise Linux Kernel mit dem kvm-Kernel-Modul. Xen und KVM nutzen jeweils einen anderen Kernel, und zu jeder Zeit kann nur ein Hypervisor aktiv sein. Red Hat empfiehlt, nur denjenigen Hypervisor zu installieren, den Sie für die Virtualisierung verwenden möchten.
To change hypervisor from Xen to KVM or KVM to Xen refer to Abschnitt 32.2, „Wechseln zwischen dem KVM- und Xen-Hypervisor“.

6.1. Installation von Xen während einer neuen Red Hat Enterprise Linux Installation

Dieser Abschnitt behandelt die Installation von Virtualisierungs-Tools und Xen-Paketen als Teil einer neuen Red Hat Enterprise Linux Installation

Benötigen Sie Hilfe bei der Installation?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.
  1. Starten Sie eine interaktive Red Hat Enterprise Linux Installation von der Red Hat Enterprise Linux Installations-CD-ROM, DVD oder PXE.
  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.
    Wählen Sie die Paketgruppe Virtualisierung und die Option Jetzt anpassen.
  4. Wählen Sie die Paketgruppe Virtualisierung. Die Paketgruppe Virtualisierung wählt den KVM-Hypervisor sowie virt-manager, libvirt und virt-viewer samt zugehöriger Abhängigkeiten zur Installation.
  5. Anpassen der Pakete (falls nötig)

    Passen Sie die Gruppe Virtualisierung an, falls Sie andere Virtualisierungspakete benötigen.
    Press the Close button then the Forward button to continue the installation.

Anmerkung

Sie benötigen eine gültige RHN-Berechtigung zur Virtualisierung, um Updates für die Virtualisierungspakete zu erhalten.
Installation der Xen-Pakete mit Kickstart-Dateien
In diesem Abschnitt wird beschrieben, wie Sie Kickstart-Dateien dazu verwenden können, Red Hat Enterprise Linux mit den Xen-Hypervisor-Paketen zu installieren. Kickstart-Dateien erlauben umfangreiche, automatisierte Installationen, ohne dass jedes einzelne System manuell installiert werden muss. Die Schritte in diesem Abschnitt sollen Ihnen dabei helfen, unter Verwendung einer Kickstart-Datei Red Hat Enterprise Linux mit den Red Hat Virtualisierungspaketen zu installieren.
Fügen Sie im %packages-Abschnitt Ihrer Kickstart-Datei die folgende Paketgruppe hinzu:
%packages
@xen

Für Intel Itanium Systeme

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 von Xen-Paketen auf einem vorhandenen Red Hat Enterprise Linux System

Dieser Abschnitt beschreibt die notwendigen Schritte, um die Virtualisierungspakete auf einem laufenden Red Hat Enterprise Linux System zu installieren.
Hinzufügen von Paketen in Ihre Liste mit Red Hat Network Berechtigungen
Dieser Abschnitt beschreibt, wie Red Hat Network (RHN) Berechtigungen für Virtualisierung aktiviert werden. Sie müssen diese Berechtigungen aktiviert haben, um die Virtualisierungspakete auf Red Hat Enterprise Linux installieren und aktualisieren zu können. Sie müssen über einen gültigen Red Hat Network Account verfügen, um die Virtualisierungspakete auf Red Hat Enterprise Linux zu installieren.
Darüberhinaus müssen Ihre Maschinen beim RHN angemeldet sein. Um eine noch nicht angemeldete Installation von Red Hat Enterprise Linux zu registrieren, führen Sie den rhn_register-Befehl aus und folgen Sie den Anweisungen.
Falls Sie kein gültiges Red Hat Abonnement haben, besuchen Sie den Red Hat Online Store.
Prozedur 6.1. Virtualisierungsberechtigung mit RHN hinzufügen
  1. Melden Sie sich mit Ihrem Benutzernamen und Passwort bei RHN an.
  2. Wählen Sie die Systeme aus, auf denen Sie die Virtualisierung installieren wollen.
  3. Im Bereich Systemeigenschaften sind neben der Berechtigungen-Überschrift die aktuellen Systemberechtigungen aufgelistet. Klicken Sie auf den Link (Diese Eigenschaften bearbeiten), um die Berechtigungen zu ändern.
  4. Wählen Sie das Virtualisierung-Auswahlkästchen aus.
Ihr System ist jetzt dazu berechtigt, die Virtualisierungspakete zu erhalten. Der nächste Abschnitt behandelt die Installation dieser Pakete.
Installation des Xen-Hypervisors mit yum
Um auf Red Hat Enterprise Linux die Virtualisierung einzusetzen, benötigen Sie die xen und kernel-xen-Pakete. Das xen-Paket beinhaltet den Hypervisor und grundlegende Virtualisierungs-Tools. Das kernel-xen-Paket beinhaltet einen modifizierten Linux-Kernel, der als virtuelle Maschine auf dem Hypervisor läuft.
Um die xen und kernel-xen-Pakete zu installieren, führen Sie Folgendes aus:
# yum install xen kernel-xen
Voll virtualisierte Gäste auf der Itanium®-Architektur benötigen das Gast-Firmeware-Image-Paket (xen-ia64-guest-firmware) von der Extras-Installations-DVD. Dieses Paket kann mit dem yum-Befehl auch von RHN installiert werden:
# yum install xen-ia64-guest-firmware
It is advised to install additional virtualization packages for management and configuration. Empfohlene Virtualisierungspakete: lists the recommended packages.
Installieren Sie die anderen empfohlenen Virtualisierungspakete:
# yum install virt-manager libvirt libvirt-python python-virtinst

6.3. Installation von KVM während einer neuen Red Hat Enterprise Linux Installation

Dieser Abschnitt behandelt die Installation der Virtualisierungs-Tools und des KVM-Pakets als Teil einer neuen Red Hat Enterprise Linux Installation.

Benötigen Sie Hilfe bei der Installation?

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

Sie benötigen eine gültige Installationsnummer

Ohne eine gültige Installationsnummer können Sie während der Installation nicht die Virtualisierungspakete auswählen.
  1. Starten Sie eine interaktive Red Hat Enterprise Linux Installation von der Red Hat Enterprise Linux Installations-CD-ROM, DVD oder PXE.
  2. Wenn Sie dazu aufgefordert werden, müssen Sie eine gültige Installationsnummer eingeben, um Zugriff auf die Virtualisierungspakete und andere erweiterte Plattformpakete zu erlangen.
  3. Complete all steps up to the package selection step.
    Wählen Sie die Paketgruppe Virtualisierung und die Option Jetzt anpassen.
  4. Wählen Sie die KVM-Paketgruppe. Heben Sie die Auswahl der Paketgruppe Virtualisierung auf. Dadurch wird der KVM-Hypervisor sowie virt-manager, libvirt und virt-viewer zur Installation ausgewählt.
  5. Anpassen der Pakete (falls nötig)

    Passen Sie die Gruppe Virtualisierung an, falls Sie andere Virtualisierungspakete benötigen.
    Press the Close button then the Forward button to continue the installation.

Anmerkung

Sie benötigen eine gültige RHN-Berechtigung zur Virtualisierung, um Updates für die Virtualisierungspakete zu erhalten.
Installation von KVM-Paketen mit Kickstart-Dateien
In diesem Abschnitt wird beschrieben, wie Sie Kickstart-Dateien dazu verwenden können, Red Hat Enterprise Linux mit den KVM-Hypervisor-Paketen zu installieren. Kickstart-Dateien erlauben umfangreiche, automatisierte Installationen, ohne dass jedes einzelne System manuell installiert werden muss. Die Schritte in diesem Abschnitt sollen Ihnen dabei helfen, unter Verwendung einer Kickstart-Datei Red Hat Enterprise Linux mit den Red Hat Virtualisierungspaketen zu installieren.
Fügen Sie im %packages-Abschnitt Ihrer Kickstart-Datei die folgende Paketgruppe hinzu:
%packages
@kvm
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.4. Installation von KVM-Paketen auf einem vorhandenen Red Hat Enterprise Linux System

Dieser Abschnitt beschreibt die Schritte zur Installation des KVM-Hypervisors auf einem laufenden Red Hat Enterprise Linux 5.4 System oder höher.
Hinzufügen von Paketen in Ihre Liste mit Red Hat Network Berechtigungen
Dieser Abschnitt beschreibt, wie Red Hat Network (RHN) Berechtigungen für Virtualisierung aktiviert werden. Sie müssen diese Berechtigungen aktiviert haben, um die Virtualisierungspakete auf Red Hat Enterprise Linux installieren und aktualisieren zu können. Sie müssen über einen gültigen Red Hat Network Account verfügen, um die Virtualisierungspakete auf Red Hat Enterprise Linux zu installieren.
Darüberhinaus müssen Ihre Maschinen beim RHN angemeldet sein. Um eine noch nicht angemeldete Installation von Red Hat Enterprise Linux zu registrieren, führen Sie den rhn_register-Befehl aus und folgen Sie den Anweisungen.
Falls Sie kein gültiges Red Hat Abonnement haben, besuchen Sie den Red Hat Online Store.
Prozedur 6.2. Virtualisierungsberechtigung mit RHN hinzufügen
  1. Melden Sie sich mit Ihrem Benutzernamen und Passwort bei RHN an.
  2. Wählen Sie die Systeme aus, auf denen Sie die Virtualisierung installieren wollen.
  3. Im Bereich Systemeigenschaften sind neben der Berechtigungen-Überschrift die aktuellen Systemberechtigungen aufgelistet. Klicken Sie auf den Link (Diese Eigenschaften bearbeiten), um die Berechtigungen zu ändern.
  4. Wählen Sie das Virtualisierung-Auswahlkästchen aus.
Ihr System ist jetzt dazu berechtigt, die Virtualisierungspakete zu erhalten. Der nächste Abschnitt behandelt die Installation dieser Pakete.
Installation des KVM-Hypervisors mit yum
Um auf Red Hat Enterprise Linux die Virtualisierung einzusetzen, benötigen Sie das kvm-Paket. Das kvm-Paket beinhaltet das KVM-Kernel-Modul, das den KVM-Hypervisor auf dem standardmäßigen Red Hat Enterprise Linux Kernel liefert.
Um das kvm-Paket zu installieren, führen Sie Folgendes aus:
# yum install kvm
Installieren Sie nun die zusätzlichen Virtualisierungspakete zur Verwaltung.
Installieren Sie die anderen empfohlenen Virtualisierungspakete:
# yum install virt-manager libvirt libvirt-python python-virtinst

Kapitel 7. Überblick über die Installation virtualisierter Gäste

Nachdem Sie die Virtualisierungspakete auf dem Host-System installiert haben, können Sie Gastbetriebssysteme installieren. Dieses Kapitel beschreibt die allgemeinen Verfahren zur Installation von Gastbetriebssystemen auf virtuellen Maschinen. Sie können Gäste erzeugen durch Klick auf die Neu-Schaltfläche im virt-manager oder mit Hilfe der Befehlszeilenschnittstelle virt-install. Beide Methoden werden in diesem Kapitel behandelt.
Detailed installation instructions are available for specific versions of Red Hat Enterprise Linux, other Linux distributions and Windows. Refer to Kapitel 8, Installationsverfahren für Gastbetriebssysteme for those procedures.

7.1. Erzeugen von Gästen mit virt-install

Sie können den virt-install-Befehl verwenden, um virtualisierte Gäste von der Befehlszeile aus zu erzeugen. virt-install kann entweder interaktiv verwendet werden oder in einem Skript, um die Erstellung virtueller Maschinen zu automatisieren. Wenn virt-install zusammen mit Kickstart-Dateien verwendet wird, können virtuelle Maschinen unbeaufsichtigt installiert werden.
Das virt-install-Tool bietet eine Reihe von Optionen, die in der Befehlszeile übergeben werden können. Um eine vollständige Auflistung dieser Optionen zu sehen, geben Sie ein:
$ virt-install --help
Auch die virt-install-Handbuchseite dokumentiert jede Befehlszeilenoption sowie wichtige Variablen.
qemu-img ist ein zugehöriger Befehl, der vor virt-install dazu verwendet werden kann, Speicheroptionen zu konfigurieren.
An important option is the --vnc option which opens a graphical window for the guest's installation.
Beispiel 7.1. Verwenden von virt-install mit KVM, um einen Red Hat Enterprise Linux 3 Gast zu erzeugen
Dieses Beispiel erzeugt einen Red Hat Enterprise Linux 3 Gast namens rhel3support von einer CD-ROM, mit virtuellem Netzwerk und einem 5 GB dateibasiertem Blockgerät-Image. Dieses Beispiel verwendet den KVM-Hypervisor.
# 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

Beispiel 7.2. Verwenden von virt-install, um einen Fedora 11 Gast zu erzeugen
# 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. Erzeugen von Gästen mit virt-manager

virt-manager, auch als Virtual Machine Manager bekannt, ist ein grafisches Tool zur Erstellung und Verwaltung virtualisierter Gäste.
Prozedur 7.1. Erzeugen eines virtualisierten Gasts mit 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

    Im virt-manager-Fenster können Sie eine neue virtuelle Maschine erstellen. Klicken Sie dazu auf die Neu-Schaltfläche. Dies öffnet den im nachfolgenden Screenshot gezeigten Assistenten.
  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:
    Überprüfen Sie die angegebenen Informationen für Ihre Installation und klicken anschließend auf Weiter.
  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

    Es erscheint nun das Fenster Wählen einer Virtualisierungsmethode. Wählen Sie zwischen Paravirtualisiert oder Voll virtualisiert.
    Volle Virtualisierung setzt ein System mit Intel® VT oder AMD-V Prozessor voraus. Falls die Virtualisierungserweiterungen nicht vorhanden sind, sind die Optionen Voll virtualisiert oder Kernel/Hardware-Beschleunigung aktivieren nicht auswählbar. Die Option Paravirtualisiert ist grau hinterlegt, falls der kernel-xen nicht der aktuell laufende Kernel ist.
    Falls Sie mit einem KVM-Hypervisor verbunden sind, steht nur die volle Virtualisierung zur Auswahl.
    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 Kapitel 10, Netzwerkkonfiguration 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 Abschnitt 18.2, „SELinux und Virtualisierung“ 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.
    Weisen Sie zusätzlichen Speicherplatz zu, falls der Gast weiteren Platz für Anwendungen oder andere Daten benötigt. So benötigen Webserver beispielsweise zusätzlichen Platz für Protokolldateien.
    Wählen Sie auf Ihrem ausgewählten Speichertyp eine angemessene Größe für den Gast und klicken anschließend auf Weiter.

    Anmerkung

    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.
    Gäste benötigen ausreichend physischen Arbeitsspeicher (RAM), um effektiv und effizient zu arbeiten. Wählen Sie einen Wert für den Speicher, der am Besten Ihrem Gastbetriebssystem und den Anforderungen der Anwendungen gerecht wird. Die meisten Betriebssysteme benötigen mindestens 512 MB RAM, um effizient zu arbeiten. Bedenken Sie, dass Gäste physischen RAM verbrauchen. Falls zu viele Gäste ausgeführt werden oder nicht genügend Arbeitsspeicher für das Host-System verbleibt, wird verstärkt virtueller Speicher genutzt. Virtueller Speicher hat jedoch deutlich langsamere Zugriffszeiten, infolgedessen sinkt die Leistung und Reaktionszeit des Systems. Stellen Sie daher sicher, dass Sie ausreichend Speicher zuweisen, damit sowohl alle Gäste als auch der Host effektiv arbeiten können.
    Weisen Sie dem virtualisierten Gast zudem genügend virtuelle CPUs zu. Falls der Gast eine Multithread-Anwendung ausführt, dann weisen Sie so viele virtualisierte CPUs wie nötig zu, damit der Gast effizient arbeiten kann. Weisen Sie nicht mehr virtuelle CPUs zu, als das Host-System physische Prozessoren (oder Hyper-Threads) besitzt. Es ist zwar möglich, mehr virtuelle Prozessoren zuzuweisen, dies verursacht allerdings einen signifikanten Overhead beim Kontextwechsel der Prozessoren und wirkt sich infolgedessen deutlich negativ auf die Leistung des Gasts und des Hosts aus.
    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.
    Ein VNC-Fenster öffnet sich und zeigt den Beginn des Installationsprozesses für das Gastbetriebssystem an.
This concludes the general process for creating guests with virt-manager. Kapitel 8, Installationsverfahren für Gastbetriebssysteme contains step-by-step instructions to installing a variety of common operating systems.

7.3. Installation von Gästen mit PXE

Dieser Abschnitt behandelt die nötigen Schritte zur Installation von Gästen mit PXE. Die PXE-Gästeinstallation setzt ein gemeinsam verwendetes Netzwerkgerät, auch Netzwerk-Bridge genannt, voraus. Das nachfolgend beschriebene Verfahren umfasst die Erstellung einer Bridge sowie die nötigen Schritte, um diese Bridge für die PXE-Installation zu nutzen.
  1. Neue Bridge erstellen

    1. Erzeugen Sie eine neue Netzwerkskriptdatei im /etc/sysconfig/network-scripts/-Verzeichnis. Dieses Beispiel erstellt eine Datei namens ifcfg-installation, die eine Bridge namens installation erzeugt.
      # cd /etc/sysconfig/network-scripts/
      # vim ifcfg-installation
      DEVICE=installation
      TYPE=Bridge
      BOOTPROTO=dhcp
      ONBOOT=yes
      

      Warnung

      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. Es sind bislang noch keine Schnittstellen zur neuen Bridge hinzugefügt. Verwenden Sie den brctl show-Befehl, um Einzelheiten der Netzwerk-Bridges auf dem System einzusehen.
      # brctl show
      bridge name     bridge id               STP enabled     interfaces
      installation    8000.000000000000       no
      virbr0          8000.000000000000       yes
      
      Die virbr0-Bridge ist die Standard-Bridge, die von libvirt für Network Address Translation (NAT) auf dem Standard-Ethernet-Gerät verwendet wird.
  2. Eine Schnittstelle zur neuen Bridge hinzufügen

    Bearbeiten Sie die Konfigurationsdatei der Schnittstelle. Fügen Sie den BRIDGE-Parameter mit dem Namen der Bridge, die im vorangegangenen Schritt erzeugt wurde, zur Konfigurationsdatei hinzu.
    # Intel Corporation Gigabit Network Connection
    DEVICE=eth1
    BRIDGE=installation
    BOOTPROTO=dhcp
    HWADDR=00:13:20:F7:6E:8E
    ONBOOT=yes
    
    Nachdem Sie die Konfigurationsdatei bearbeitet haben, starten Sie das Netzwerk oder das ganze System neu.
    # service network restart
    
    Überprüfen Sie mit Hilfe des brctl show-Befehls, dass die Schnittstelle nun verknüpft ist:
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    installation    8000.001320f76e8e       no              eth1
    virbr0          8000.000000000000       yes
    
  3. Sicherheitskonfiguration

    Konfigurieren Sie iptables, so dass sämtlicher Datenverkehr über die Bridge weitergeleitet werden darf.
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
    # service iptables save
    # service iptables restart
    

    Deaktivieren von iptabels auf Bridges

    Alternativ können Sie auch dafür sorgen, dass Datenverkehr über die Bridge nicht von den iptables-Regeln bearbeitet wird. Fügen Sie dazu in /etc/sysctl.conf folgende Zeilen hinzu:
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    
    Laden Sie die Kernel-Parameter, die mit sysctl konfiguriert wurden, neu.
    # sysctl -p /etc/sysctl.conf
    
  4. libvirt vor der Installation neustarten

    Starten Sie den libvirt-Daemon neu.
    # service libvirtd reload
    
Die Bridge ist nun konfiguriert, Sie können jetzt mit einer Installation beginnen.
PXE-Installation mit virt-install
Fügen Sie für virt-install den --network=bridge:installation-Installationsparameter an, wobei installation der Name Ihrer Bridge ist. Verwenden Sie für PXE-Installationen den --pxe-Parameter.
Beispiel 7.3. PXE-Installation mit 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 \

PXE-Installation mit virt-manager
The steps below are the steps that vary from the standard virt-manager installation procedures. For the standard installations refer to Kapitel 8, Installationsverfahren für Gastbetriebssysteme.
  1. PXE auswählen

    Wählen Sie PXE als Installationsmethode.
  2. Bridge auswählen

    Wählen Sie Gemeinsam verwendetes physisches Gerät und wählen die Bridge, die in den vorangegangenen Schritten erstellt wurde.
  3. Installation starten

    Die Installation ist bereit zum Start.
Eine DHCP-Anfrage wird gesendet, und falls ein gültiger PXE-Server gefunden wird, beginnt der Gastinstallationsprozess.

Kapitel 8. Installationsverfahren für Gastbetriebssysteme

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 Kapitel 7, Überblick über die Installation virtualisierter Gäste.

Wichtig

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. Installation von Red Hat Enterprise Linux 5 als paravirtualisierter Gast

Dieser Abschnitt beschreibt die Installation eines paravirtualisierten Red Hat Enterprise Linux 5 Gasts. Paravirtualisierung ist schneller als volle Virtualisierung, unterstützt dabei jedoch sämtliche Vorzüge der vollen Virtualisierung. Paravirtualisierung erfordert einen speziellen, unterstützten Kernel, den kernel-xen-Kernel.

Wichtige Anmerkung zur Paravirtualisierung

Paravirtualisierung funktioniert nur mit dem Xen-Hypervisor. Paravirtualisierung funktioniert nicht mit dem KVM-Hypervisor.
Vergewissern Sie sich, dass Sie über Root-Rechte verfügen, bevor Sie mit der Installation beginnen.
Dieses Verfahren installiert Red Hat Enterprise Linux von einem Remote-Server. Die in diesem Abschnitt beschriebenen Installationsanweisungen ähneln denen für die Installation von der Live-CD-ROM für Minimalinstallation.
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 Abschnitt 7.2, „Erzeugen von Gästen mit virt-manager“.
Erzeugen Sie einen paravirtualisierten Gast mit dem Befehlszeilen-Tool virt-install. Durch die Option --vnc wird die grafische Installation gestartet. Der Name des Gasts lautet in diesem Beispiel rhel5PV, die Image-Datei ist rhel5PV.dsk und ein lokaler Spiegelserver des Red Hat Enterprise Linux 5 Installationsbaums ist ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/. Ersetzen Sie diese Werte passend für Ihr System und Ihr Netzwerk.
# 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/

Automatische Installation

Red Hat Enterprise Linux kann ohne grafische Oberfläche oder manuelle Eingaben installiert werden. Verwenden Sie Kickstart-Dateien, falls Sie die Installation automatisieren möchten.
Unabhängig von der gewählten Methode öffnet sich nun das folgende Fenster und zeigt die ersten Boot-Phasen Ihres Gasts:
Nachdem Ihr Gast den initialen Boot abgeschlossen hat, beginnt nun der Standardinstallationsprozess für Red Hat Enterprise Linux. Für die meisten Installationen können dabei die Standardantworten übernommen werden.
Prozedur 8.1. Installationsprozess für paravirtualisierten Red Hat Enterprise Linux Gast
  1. Wählen Sie die gewünschte Sprache und klicken Sie auf OK.
  2. Wählen Sie das gewünschte Tastatur-Layout und klicken Sie auf OK.
  3. Assign the guest's network address. Choose to use DHCP (as shown below) or a static IP address:
  4. Falls Sie DHCP für Ihren Gast gewählt haben, wird der Installationsprozess nun versuchen, eine IP-Adresse für Ihren Gast zu beziehen:
  5. If you chose a static IP address for your guest this prompt appears. Enter the details on the guest's networking configuration:
    1. Geben Sie eine gültige IP-Adresse ein. Stellen Sie sicher, dass die eingegebene IP-Adresse den Installations-Server mit dem Installationsbaum erreichen kann.
    2. Geben Sie eine gültige Subnetzmaske, das Standard-Gateway und die Name-Server-Adresse ein.
    Wählen Sie die gewünschte Sprache und klicken Sie auf OK.
  6. Sehen Sie nachfolgend ein Beispiel für eine Konfiguration mit statischer IP-Adresse:
  7. Der Installationsprozess ruft nun die benötigten Dateien vom Server ab:
Sobald die ersten Schritte fertiggestellt sind, startet der grafische Installationsprozess.
Falls Sie eine Beta- oder Vorabversion installieren, müssen Sie bestätigen, dass Sie das Betriebssystem wirklich installieren wollen. Klicken Sie Trotzdem installieren und klicken anschließend auf OK:
Prozedur 8.2. Der grafische Installationsprozess
  1. Geben Sie einen gültigen Registrierungsschlüssel ein. Falls Sie einen gültigen RHN-Abonnementsschlüssel besitzen, geben Sie diesen im Feld Installationsnummer ein:

    Anmerkung

    Falls Sie den Schritt zur Registrierung überspringen, bestätigen Sie Ihre Red Hat Network Account-Details nach abgeschlossener Installation mit Hilfe des rhn_register-Befehls. Der rhn_register-Befehl erfordert Root-Rechte.
  2. Die Installation fordert Sie nun auf zu bestätigen, dass alle Daten in dem Speicher, den Sie für die Installation ausgewählt haben, gelöscht werden sollen:
    Klicken Sie auf Ja, um fortzufahren.
  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. Bestätigen Sie den ausgewählten Speicher für die Installation.
    Klicken Sie auf Ja, um fortzufahren.
  5. Konfigurieren Sie als Nächstes das Netzwerk und den Host-Namen. Diese Einstellungen werden mit den Daten, die Sie zuvor im Installationsprozess eingegeben haben, vorausgefüllt. Sie können diese Einstellungen jedoch ändern, falls notwendig.
    Klicken Sie auf OK, um fortzufahren.
  6. Wählen Sie die richtige Zeitzone für Ihren Standort aus:
  7. Wählen Sie ein Root-Passwort für Ihren Gast.
    Klicken Sie auf Weiter, um fortzufahren.
  8. Wählen Sie die zu installierenden Software-Pakete. Wählen Sie die Schaltfläche Jetzt anpassen. Sie müssen das kernel-xen-Paket im System-Verzeichnis installieren. Das kernel-xen-Paket ist Voraussetzung für die Paravirtualisierung.
    Click Forward.
  9. Abhängigkeiten und Speicherplatzvoraussetzungen werden ermittelt.
  10. After the installation dependencies and space requirements have been verified click Forward to start the actual installation.
  11. Alle ausgewählten Software-Pakete werden automatisch installiert.
  12. Nachdem die Installation abgeschlossen ist, müssen Sie den Gast neu starten:
  13. Der Gast wird nicht neu starten, sondern herunterfahren.
  14. Boot the guest. The guest's name was chosen when you used the virt-install in Abschnitt 8.1, „Installation von Red Hat Enterprise Linux 5 als paravirtualisierter Gast“. If you used the default example the name is rhel5PV.
    Starten Sie den Gast mit Hilfe des virsh-Befehls neu:
    # virsh reboot rhel5PV
    Alternativ können Sie virt-manager öffnen, den Namen Ihres Gasts auswählen, auf Öffnen und danach auf Ausführen klicken.
    A VNC window displaying the guest's boot processes now opens.
  15. Beim Hochgefahren des Gasts startet der First Boot-Konfigurationsbildschirm. Dieser Assistent wird Sie durch einige grundlegende Konfigurationsschritte für Ihren Gast führen:
  16. Zuerst müssen Sie die Lizenzvereinbarung lesen und dieser zustimmen.
    Klicken Sie im Fenster der Lizenzvereinbarung auf Weiter.
  17. Konfigurieren Sie als Nächstes die Firewall.
    Klicken Sie auf Weiter, um fortzufahren.
    1. Falls Sie die Firewall deaktivieren möchten, müssen Sie diese Entscheidung noch einmal bestätigen. Klicken Sie auf Ja, um zu bestätigen und fortzufahren. Es wird nicht empfohlen, die Firewall zu deaktivieren.
  18. Konfigurieren Sie als Nächstes SELinux. Es wird dringend empfohlen, SELinux im Enforcing-Modus auszuführen. Sie können SELinux jedoch auch im Permissive-Modus ausführen oder vollständig deaktivieren.
    Klicken Sie auf Weiter, um fortzufahren.
    1. Falls Sie SELinux deaktivieren, wird diese Warnung angezeigt. Klicken Sie Ja, um SELinux zu deaktivieren.
  19. Disable kdump. The use of kdump is unsupported on para-virtualized guests.
    Klicken Sie auf Weiter, um fortzufahren.
  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.
    Klicken Sie auf Weiter, um fortzufahren.
  21. Richten Sie Software-Aktualisierungen ein. Falls Sie ein Red Hat Network Abonnement haben oder eine Testversion ausprobieren möchten, können Sie auf dem unten gezeigten Bildschirm Ihren neu installierten Gast in RHN anmelden:
    Klicken Sie auf Weiter, um fortzufahren.
    1. Bestätigen Sie Ihre Auswahl für RHN.
    2. Sie sehen ggf. noch einen weiteren Bildschirm, falls Sie den RHN-Zugang nicht konfiguriert haben. Falls der RHN-Zugang nicht aktiviert ist, werden Sie keine Software-Aktualisierungen erhalten.
      Klicken Sie auf Weiter.
  22. Erstellen Sie ein nicht privilegiertes (nicht-Root) Benutzerkonto. Es wird empfohlen, dass Sie für normale Tätigkeiten aus Sicherheitsgründen ein nicht privilegiertes Benutzerkonto anlegen. Geben Sie den Benutzernamen, Namen und Passwort ein.
    Klicken Sie auf Weiter.
  23. Wenn ein Audiogerät entdeckt wird und Sie Audioausgabe benötigen, kalibrieren Sie das Gerät. Schließen Sie den Vorgang ab und klicken auf Weiter.
  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. Der Gast konfiguriert nun alle von Ihnen vorgenommenen Einstellungen und fährt mit dem Boot-Vorgang fort.
  26. Der Red Hat Enterprise Linux 5 Anmeldebildschirm erscheint. Melden Sie sich mit dem Benutzerkonto an, das Sie in den vorangegangenen Schritten erstellt haben.
  27. Sie haben nun erfolgreich einen paravirtualisierten Red Hat Enterprise Linux 5 Gast installiert.

8.2. Installation von Red Hat Enterprise Linux als voll virtualisierter Gast

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.
Prozedur 8.3. Erzeugen eines voll virtualisierten Red Hat Enterprise Linux 5 Gasts mittels virt-manager
  1. Öffnen Sie virt-manager

    Starten Sie virt-manager. Wählen Sie dazu im Menü Anwendungen das Untermenü Systemwerkzeuge und wählen dort den Virtual Machine Manager aus. Alternativ können Sie auch den Befehl virt-manager als Root ausführen.
  2. Wählen Sie den Hypervisor

    Wählen Sie den Hypervisor. Falls installiert, wählen Sie Xen oder KVM. Wählen Sie für dieses Beispiel KVM aus. Beachten Sie, dass KVM derzeit qemu heißt.
    Connect to a hypervisor if you have not already done so. Open the File menu and select the Add Connection... option. Refer to Abschnitt 26.1, „The Add Connection window“.
    Nachdem eine Hypervisor-Verbindung ausgewählt wurde, erscheint die Schaltfläche Neu. Klicken Sie auf Neu.
  3. Starten Sie den Assistenten zur Erzeugung virtueller Maschinen

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Benennen Sie die virtuelle Maschine

    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. Wählen Sie eine Virtualisierungsmethode

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (Schritt 4) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Wählen Sie die Installationsart

    Red Hat Enterprise Linux kann mit Hilfe einer der folgenden Methoden installiert werden:
    • Lokales Installationsmedium, entweder ein ISO-Image oder ein physisches, optisches Medium.
    • Wählen Sie Netzwerk-Installationsbaum, falls der Installationsbaum für Red Hat Enterprise Linux via HTTP, FTP oder NFS auf Ihrem Netzwerk gehosted wird.
    • Falls Sie einen PXE-Server zum Booten von Red Hat Enterprise Linux Installationsmedien konfiguriert haben, kann auch PXE verwendet werden. Die Konfiguration eines Servers zum PXE-Booten einer Red Hat Enterprise Linux Installation wird in diesem Handbuch nicht behandelt. Allerdings sind die meisten Installationsschritte dieselben, nachdem das Medium gebootet wurde.
    Set OS Type to Linux and OS Variant to Red Hat Enterprise Linux 5 as shown in the screenshot.
    Press Forward to continue.
  7. Wählen Sie den Ort des Installationsmediums

    Wählen Sie "Speicherort des ISO-Images" oder "CD-ROM oder DVD-Laufwerk". In diesem Beispiel wird ein ISO-Datei-Image der Red Hat Enterprise Linux Installations-DVD verwendet.
    1. Klicken Sie auf die Schaltfläche Durchsuchen.
    2. Suchen Sie den Speicherort der ISO-Datei und wählen das ISO-Image aus. Klicken Sie auf Öffnen, um Ihre Auswahl zu bestätigen.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Image-Dateien und 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 Abschnitt 18.2, „SELinux und Virtualisierung“ for details.
  8. Einrichten von Speicherplatz

    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 Teil V, „Virtualization Storage Topics“.
  9. Einrichten des Netzwerks

    Wählen Sie entweder Virtuelles Netzwerk oder Gemeinsam verwendetes physisches Gerät.
    Die Option "Virtuelles Netzwerk" nutzt Network Address Translation (NAT), um das Standardnetzwerkgerät gemeinsam mit den virtualisierten Gästen zu verwenden. Verwenden Sie diese Option für Wireless-Netzwerke.
    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. Speicher- und CPU-Zuweisung

    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.
    Virtualisierte Gäste benötigen ausreichend physischen Arbeitsspeicher (RAM), um effektiv und effizient zu arbeiten. Wählen Sie einen Wert für den Speicher, der am Besten Ihrem Gastbetriebssystem und den Anforderungen der Anwendungen gerecht wird. Bedenken Sie, dass Gäste physischen RAM verbrauchen. Falls zu viele Gäste ausgeführt werden oder nicht genügend Arbeitsspeicher für das Host-System verbleibt, wird verstärkt virtueller Speicher genutzt und Swapping durchgeführt. Virtueller Speicher hat jedoch deutlich langsamere Zugriffszeiten, infolgedessen sinkt die Leistung und Reaktionszeit des Systems. Stellen Sie daher sicher, dass Sie ausreichend Speicher zuweisen, damit sowohl alle Gäste als auch der Host effektiv arbeiten können.
    Weisen Sie dem virtualisierten Gast zudem genügend virtuelle CPUs zu. Falls der Gast eine Multithread-Anwendung ausführt, dann weisen Sie so viele virtualisierte CPUs wie nötig zu, damit der Gast effizient arbeiten kann. Weisen Sie nicht mehr virtuelle CPUs zu, als das Host-System physische Prozessoren (oder Hyper-Threads) besitzt. Es ist zwar möglich, mehr virtuelle Prozessoren zuzuweisen, dies verursacht allerdings einen signifikanten Overhead beim Kontextwechsel der Prozessoren und wirkt sich infolgedessen deutlich negativ auf die Leistung des Gasts und des Hosts aus.
    Press Forward to continue.
  11. Überprüfen und Starten der Gastinstallation

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

    Stellen Sie die Red Hat Enterprise Linux 5 Installationssequenz fertig. Die Installationssequenz wird im Installationshandbuch behandelt. Das Red Hat Enterprise Linux Installationshandbuch finden Sie unter Red Hat Documentation.
Ein voll virtualisierter Red Hat Enterprise Linux 5 Gast ist nun fertig installiert.

8.3. Installation von Windows XP als voll virtualisierter Gast

Windows XP kann als voll virtualisierter Gast installiert werden. Dieser Abschnitt beschreibt, wie Windows XP als voll virtualisierter Gast auf Red Hat Enterprise Linux installiert werden kann.
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.
Bevor Sie mit der Prozedur beginnen, vergewissern Sie sich, dass Sie Root-Rechte besitzen.

Itanium®-Unterstützung

Red Hat Enterprise Linux Hosts auf der Itanium®-Architektur unterstützen derzeit keine voll virtualisierten Windows XP Gäste. Nur Windows Server 2003 für Itanium-basierte Systeme werden für Itanium-Systeme unterstützt.
  1. Starten Sie 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. Benennen Sie das virtuelle System

    Geben Sie den Systemnamen ein und klicken anschließend auf Weiter.
  3. Wählen Sie eine Virtualisierungsmethode

    If you selected KVM or Xen earlier (step Schritt 1 ) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Windows kann nur unter Verwendung der vollen Virtualisierung installiert werden.
  4. Wählen Sie die Installationsart

    In diesem Bildschirm können Sie die Installationsart und den Betriebssystemtyp wählen.
    Wählen Sie Windows aus der Liste der Betriebssystemtypen und Microsoft Windows XP aus der Liste der Betriebssystemversionen.
    Die Installation von Gästen mit PXE wird in Red Hat Enterprise Linux 5.2 unterstützt. Auf PXE-Installation wird in diesem Kapitel jedoch nicht näher eingegangen.

    Image-Dateien und 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 Abschnitt 18.2, „SELinux und Virtualisierung“ for details.
    Klicken Sie auf Weiter, um fortzufahren.
  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.
    Klicken Sie auf Weiter, um fortzufahren.
  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 Abschnitt 18.2, „SELinux und Virtualisierung“ for details.
    Weisen Sie zusätzlichen Speicherplatz zu, wenn der Gast weiteren Platz für Anwendungen oder andere Daten benötigt. So benötigen Webserver beispielsweise zusätzlichen Platz für Protokolldateien.
    Wählen Sie auf Ihrem ausgewählten Speichertyp eine angemessene Größe für den Gast und klicken anschließend auf Weiter.

    Anmerkung

    Es wird empfohlen, das Standardverzeichnis für die virtuellen Maschinen-Images zu verwenden, also /var/lib/libvirt/images/. Falls Sie einen anderen Speicherort verwenden (wie z. B. /images/ in diesem Beispiel), stellen Sie sicher, dass Sie ihn in der SELinux-Richtlinie hinzugefügt und neu gekennzeichnet haben, bevor Sie mit der Installation fortfahren (an späterer Stelle im Dokument finden Sie Informationen darüber, wie Sie Ihre SELinux-Richtlinie anpassen).
  7. Einrichten des Netzwerks

    Wählen Sie entweder Virtuelles Netzwerk oder Gemeinsam verwendetes physisches Gerät.
    Die Option "Virtuelles Netzwerk" nutzt Network Address Translation (NAT), um das Standardnetzwerkgerät gemeinsam mit den virtualisierten Gästen zu verwenden. Verwenden Sie diese Option für Wireless-Netzwerke.
    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.
    Gäste benötigen ausreichend physischen Arbeitsspeicher (RAM), um effektiv und effizient zu arbeiten. Wählen Sie einen Wert für den Speicher, der am Besten Ihrem Gastbetriebssystem und den Anforderungen der Anwendungen gerecht wird. Die meisten Betriebssysteme benötigen mindestens 512 MB RAM, um effizient zu arbeiten. Bedenken Sie, dass Gäste physischen RAM verbrauchen. Falls zu viele Gäste ausgeführt werden oder nicht genügend Arbeitsspeicher für das Host-System verbleibt, wird verstärkt virtueller Speicher genutzt. Virtueller Speicher hat jedoch deutlich langsamere Zugriffszeiten, infolgedessen sinkt die Leistung und Reaktionszeit des Systems. Stellen Sie daher sicher, dass Sie ausreichend Speicher zuweisen, damit sowohl alle Gäste als auch der Host effektiv arbeiten können.
    Weisen Sie dem virtualisierten Gast zudem genügend virtuelle CPUs zu. Falls der Gast eine Multithread-Anwendung ausführt, dann weisen Sie so viele virtualisierte CPUs wie nötig zu, damit der Gast effizient arbeiten kann. Weisen Sie nicht mehr virtuelle CPUs zu, als das Host-System physische Prozessoren (oder Hyper-Threads) besitzt. Es ist zwar möglich, mehr virtuelle Prozessoren zuzuweisen, dies verursacht allerdings einen signifikanten Overhead beim Kontextwechsel der Prozessoren und wirkt sich infolgedessen deutlich negativ auf die Leistung des Gasts und des Hosts aus.
  9. Bevor mit der Installation fortgefahren wird, sehen Sie eine Zusammenfassung auf dem Bildschirm. Klicken Sie auf Fertigstellen, um mit der Gastinstallation fortzufahren:
  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. Die Installation fährt fort mit der standardmäßigen Windows Installation.
  12. Partitionieren Sie die Festplatte, wenn Sie dazu aufgefordert werden.
  13. Nachdem die Festplatte formatiert wurde, beginnt Windows damit, die Dateien auf die Festplatte zu kopieren.
  14. Die Dateien sind auf das Speichergerät kopiert, Windows startet nun neu.
  15. Starten Sie Ihren Windows-Gast neu:
    # virsh start WindowsGuest
    Wobei WindowsGuest der Name Ihrer virtuellen Maschine ist.
  16. Wenn sich das Konsolenfenster öffnet, sehen Sie die Setup-Phase der Windows-Installation.
  17. Falls Ihre Installation während der Setup-Phase zu hängen scheint, starten Sie den Gast mittels virsh reboot WindowsGuestName neu. Wenn Sie Ihre virtuelle Maschine neu starten, sehen Sie die Nachricht Setup wird neu gestartet:
  18. Nachdem das Setup abgeschlossen ist, sehen Sie den Windows-Boot-Bildschirm:
  19. Sie können jetzt mit dem Standard-Setup für Ihre Windows-Installation fortfahren:
  20. Der Setup-Prozess ist nun abgeschlossen.

8.4. Installation von Windows Server 2003 als voll virtualisierter Gast

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 Abschnitt 8.3, „Installation von Windows XP als voll virtualisierter Gast“.

Itanium®-Unterstützung

Red Hat Enterprise Linux Hosts auf der Itanium®-Architektur unterstützen derzeit keine voll virtualisierten Windows-Gäste. Dieser Abschnitt gilt nur für x86 und x86-64 Hosts.
  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. Sobald die Gastinstallation startet, müssen Sie schnell F5 drücken. Wenn Sie nicht rechtzeitig F5 drücken, müssen Sie die Installation neu beginnen. Durch Drücken von F5 können Sie verschiedene HAL oder Computer-Typen auswählen. Wählen Sie Standard PC als Computertyp aus. Die Änderung des Computertyps ist notwendig für Windows Server 2003 virtualisierte Gäste.
  3. Führen Sie den Rest der Installation zu Ende.
  4. Windows Server 2003 ist nun als voll virtualisierter Gast installiert.

8.5. Installation von Windows Server 2008 als voll virtualisierter Gast

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.
Prozedur 8.4. Installation von Windows Server 2008 mit virt-manager
  1. Öffnen Sie virt-manager

    Starten Sie virt-manager. Wählen Sie dazu im Menü Anwendungen das Untermenü Systemwerkzeuge und wählen dort den Virtual Machine Manager aus. Alternativ können Sie auch den Befehl virt-manager als Root ausführen.
  2. Wählen Sie den Hypervisor

    Wählen Sie den Hypervisor. Falls installiert, wählen Sie Xen oder KVM. Wählen Sie für dieses Beispiel KVM aus. Beachten Sie, dass KVM derzeit qemu heißt.
    Nachdem die Option gewählt wurde, erscheint die Schaltfläche Neu. Klicken Sie auf Neu.
  3. Starten Sie den Assistenten zur Erzeugung virtueller Maschinen

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Benennen Sie die virtuelle Maschine

    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. Wählen Sie eine Virtualisierungsmethode

    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. Wählen Sie die Installationsart

    Für alle Windows-Versionen müssen Sie ein Lokales Installationsmedium verwenden, also entweder ein ISO-Image oder ein physisches, optisches Medium.
    Falls Sie einen PXE-Server für Windows-Netzwerkinstallationen konfiguriert haben, kann auch PXE verwendet werden. PXE-Windows-Installation wird in diesem Handbuch jedoch nicht behandelt.
    Set OS Type to Windows and OS Variant to Microsoft Windows 2008 as shown in the screenshot.
    Press Forward to continue.
  7. Wählen Sie den Ort des Installationsmediums

    Wählen Sie "Speicherort des ISO-Images" oder "CD-ROM oder DVD-Laufwerk". In diesem Beispiel wird ein ISO-Datei-Image der Windows Server 2008 Installations-CD verwendet.
    1. Klicken Sie auf die Schaltfläche Durchsuchen.
    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.

    Image-Dateien und 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 Abschnitt 18.2, „SELinux und Virtualisierung“ for details.
  8. Einrichten von Speicherplatz

    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. Einrichten des Netzwerks

    Wählen Sie entweder Virtuelles Netzwerk oder Gemeinsam verwendetes physisches Gerät.
    Die Option "Virtuelles Netzwerk" nutzt Network Address Translation (NAT), um das Standardnetzwerkgerät gemeinsam mit den virtualisierten Gästen zu verwenden. Verwenden Sie diese Option für Wireless-Netzwerke.
    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. Speicher- und CPU-Zuweisung

    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.
    Virtualisierte Gäste benötigen ausreichend physischen Arbeitsspeicher (RAM), um effektiv und effizient zu arbeiten. Wählen Sie einen Wert für den Speicher, der am Besten Ihrem Gastbetriebssystem und den Anforderungen der Anwendungen gerecht wird. Bedenken Sie, dass Gäste physischen RAM verbrauchen. Falls zu viele Gäste ausgeführt werden oder nicht genügend Arbeitsspeicher für das Host-System verbleibt, wird verstärkt virtueller Speicher genutzt und Swapping durchgeführt. Virtueller Speicher hat jedoch deutlich langsamere Zugriffszeiten, infolgedessen sinkt die Leistung und Reaktionszeit des Systems. Stellen Sie daher sicher, dass Sie ausreichend Speicher zuweisen, damit sowohl alle Gäste als auch der Host effektiv arbeiten können.
    Weisen Sie dem virtualisierten Gast zudem genügend virtuelle CPUs zu. Falls der Gast eine Multithread-Anwendung ausführt, dann weisen Sie so viele virtualisierte CPUs wie nötig zu, damit der Gast effizient arbeiten kann. Weisen Sie nicht mehr virtuelle CPUs zu, als das Host-System physische Prozessoren (oder Hyper-Threads) besitzt. Es ist zwar möglich, mehr virtuelle Prozessoren zuzuweisen, dies verursacht allerdings einen signifikanten Overhead beim Kontextwechsel der Prozessoren und wirkt sich infolgedessen deutlich negativ auf die Leistung des Gasts und des Hosts aus.
    Press Forward to continue.
  11. Überprüfen und Starten der Gastinstallation

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

Teil III. Konfiguration

Konfigurieren der Virtualisierung in Red Hat Enterprise Linux

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

Inhaltsverzeichnis

9. Virtualized storage devices
9.1. Anlegen eines virtualisierten Floppy-Disk-Controllers
9.2. Hinzufügen von Speichergeräten zum Gast
9.3. Konfiguration von persistentem Speicher in Red Hat Enterprise Linux 5
9.4. Hinzufügen eines virtualisierten CD-ROM- oder DVD-Laufwerks zu einem Gast
10. Netzwerkkonfiguration
10.1. Network Address Translation (NAT) mit libvirt
10.2. Bridged-Netzwerk mit libvirt
11. Xen-Netzwerke vor Red Hat Enterprise Linux 5.4
11.1. Konfiguration von multiplen Gastnetzwerk-Bridges zur Verwendung mehrerer Ethernet-Karten
11.2. Red Hat Enterprise Linux 5.0 Laptop-Netzwerkkonfiguration
12. Xen paravirtualisierte Treiber
12.1. Systemvoraussetzungen
12.2. Einschränkungen und Unterstützung der Paravirtualisierung
12.3. Installation der paravirtualisierten Treiber
12.3.1. Allgemeine Installationsschritte
12.3.2. Installation und Konfiguration von paravirtualisierten Treibern in Red Hat Enterprise Linux 3
12.3.3. Installation und Konfiguration von paravirtualisierten Treibern in 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. Konfiguration paravirtualisierter Netzwerktreiber
12.5. Konfiguration zusätzlicher paravirtualisierter Hardware
12.5.1. Virtualisierte Netzwerkschnittstellen
12.5.2. Virtuelle Speichergeräte
13. KVM paravirtualisierte Treiber
13.1. Installation der KVM Windows paravirtualisierten Treiber
13.2. Installing drivers with a virtualized floppy disk
13.3. Verwenden der KVM paravirtualisierten Treiber für vorhandene Geräte
13.4. Verwenden von KVM paravirtualisierten Treibern für neue Geräte
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Zeitverwaltung bei KVM-Gästen

Kapitel 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. Anlegen eines virtualisierten Floppy-Disk-Controllers

Floppy-Disk-Controller sind nötig für eine Reihe von älteren Betriebssystemen, insbesondere zur Installation von Treibern. Derzeit können virtualisierte Gäste nicht auf physische Floppy-Laufwerke zugreifen. Allerdings wird die Erstellung und der Zugriff auf Floppy-Disketten-Images durch virtualisierte Floppy-Laufwerke unterstützt. Dieser Abschnitt befasst sich mit dem Anlegen eines virtualisierten Floppy-Laufwerks.
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

Anmerkung für paravirtualisierte Treiber

The para-virtualized drivers can map physical floppy devices to fully virtualized guests. For more information on using para-virtualized drivers read Kapitel 13, KVM paravirtualisierte Treiber.
Dieses Beispiel verwendet ein Gastsystem, das mittels virt-manager angelegt wurde und auf dem eine vollvirtualisierte Installation von Red Hat Enterprise Linux läuft, mit einem Image in /var/lib/libvirt/images/rhel5FV.img. In diesem Beispiel wird der Xen-Hypervisor verwendet.
  1. Erstellen Sie die XML-Konfigurationsdatei für Ihr Gast-Image, indem Sie den Befehl virsh auf einem laufenden Gast ausführen.
    # 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 Kapitel 33, Erstellung angepasster libvirt-Skripte.
  2. Erstellen Sie ein Floppy-Disketten-Image für den Gast.
    # 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. Starten Sie den Gast neu unter Verwendung der XML-Konfigurationsdatei.
    # virsh create rhel5FV.xml
    
Das Floppy-Laufwerk ist nun für den Gast erreichbar und als Image-Datei auf dem Host gespeichert.

9.2. Hinzufügen von Speichergeräten zum Gast

Dieser Abschnitt erläutert das Hinzufügen von Speichergeräten zu virtualisierten Gästen. Zusätzlicher Speicher kann erst hinzugefügt werden, nachdem die Gäste angelegt wurden. Unterstützte Speichergeräte und -protokolle sind u. a.:
  • Lokale Festplattenpartitionen
  • Logische Datenträger
  • Direkt mit dem Host verbundene Fibre Channel oder iSCSI
  • Datei-Container in einem Dateisystem auf dem Host
  • Direkt in der virtuellen Maschine eingehängte NFS-Dateisysteme
  • Für den Gast direkt zugänglicher iSCSI-Speicher
  • Cluster-Dateisysteme (GFS)
Hinzufügen von dateibasiertem Speicher zum Gast
Dateibasierter Speicher oder dateibasierte Container sind Dateien auf dem Host-Dateisystem, die als virtualisierte Festplatten für virtualisierte Gäste fungieren. Um einen dateibasierten Container hinzuzufügen, sind die folgenden Schritte nötig:
  1. Erzeugen Sie eine leere Container-Datei oder verwenden Sie eine bereits existierende Container-Datei (wie z. B. eine ISO-Datei).
    1. Erzeugen Sie mit Hilfe des dd-Befehls eine Sparse-Datei. Beachten Sie bitte, dass die Verwendung von Sparse-Dateien aufgrund von Integritäts- und Performance-Problemen nicht empfohlen wird. Sparse-Dateien sind schnell erzeugt und können zum Testen verwendet werden, sollten jedoch nicht im Produktionsumfeld eingesetzt werden.
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
      
    2. Vorab zugewiesene Nicht-Sparse-Dateien werden empfohlen für dateibasierte Speicher-Images. Führen Sie folgenden Befehl aus, um eine Nicht-Sparse-Datei zu erzeugen:
      # 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. Erstellen Sie einen Speicherauszug der Gastkonfiguration. In diesem Beispiel heißt der Gast Guest1 und die Datei wird im Benutzerverzeichnis gespeichert.
    # virsh dumpxml Guest1 > ~/Guest1.xml
    
  3. Öffnen Sie die Konfigurationsdatei (in diesem Beispiel Guest1.xml) in einem Texteditor und suchen nach den disk=-Elementen, diese Elemente beschreiben Speichergeräte. Ein disk-Element könnte wie folgt aussehen:
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    
  4. Fügen Sie den zusätzlichen Speicher hinzu, indem Sie das <disk>-Element duplizieren oder neu erstellen. Versichern Sie sich, dass Sie einen Gerätenamen für die virtuellen Blockgerätattribute angeben. Diese Attribute müssen in der Konfigurationsdatei jedes Gasts eindeutig sein. Das folgende Beispiel ist ein Abschnitt aus einer Konfigurationsdatei, die einen zusätzlichen dateibasierten Speicher-Container namens FileName.img enthält:
    <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. Starten Sie den Gast neu unter Verwendung der aktualisierten XML-Konfigurationsdatei.
    # 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. Wählen Sie n für eine neue Partition.
      # fdisk /dev/sdb
      Command (m for help):
      
    2. Wählen Sie p für eine Primärpartition.
      Command action
         e   extended
         p   primary partition (1-4)
      
    3. Wählen Sie eine verfügbare Partitonsnummer. In diesem Beispiel wird die erste Partition ausgewählt durch Eingabe von 1.
      Partition number (1-4): 1
      
    4. Übernehmen Sie den Standardwert für den ersten Zylinder durch Drücken der Eingabe-Taste.
      First cylinder (1-400, default 1):
      
    5. Wählen Sie die Größe der Partition. In diesem Beispiel wird die gesamte Festplatte zugewiesen durch Drücken der Eingabe-Taste.
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
      
    6. Stellen Sie den Partitionstyp ein durch die Eingabe t.
      Command (m for help): t
      
    7. Wählen Sie die Partition aus, die Sie in den vorigen Schritten angelegt haben. In diesem Beispiel ist das die Partition 1.
      Partition number (1-4): 1
      
    8. Geben Sie 83 für eine Linux-Partition ein.
      Hex code (type L to list codes): 83
      
    9. Speichern Sie Ihre Änderungen und beenden.
      Command (m for help): w 
      Command (m for help): q
      
    10. Formatieren Sie die neue Partition mit dem ext3-Dateisystem.
      # mke2fs -j /dev/sdb1
      
  7. Hängen Sie die Festplatte auf dem Gast ein.
    # mount /dev/sdb1 /myfiles
    
Der Gast besitzt nun ein zusätzliches, virtualisiertes, dateibasiertes Speichergerät.
Hinzufügen von Festplatten und anderen Blockgeräten zu einem Gast
System administrators use additional hard drives for to provide more storage space or to separate system data from user data. This procedure, Prozedur 9.1, „Hinzufügen physischer Blockgeräte zu virtualisierten Gästen“, describes how to add a hard drive on the host to a virtualized guest.
Dieses Verfahren funktioniert für alle physischen Blockgeräte einschließlich CD-ROM-, DVD- und Floppy-Laufwerke.

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.
Prozedur 9.1. Hinzufügen physischer Blockgeräte zu virtualisierten Gästen
  1. Schließen Sie die Festplatte physisch an den Host an. Konfigurieren Sie den Host entsprechend, falls auf das Laufwerk nicht standardmäßig zugegriffen werden kann.
  2. Konfigurieren Sie das Gerät mit multipath und Persistenz auf dem Host, falls nötig.
  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.
    Hängen Sie für Floppy-Geräte dem Befehl den Parameter --type floppy an.
    # 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. Konfiguration von persistentem Speicher in Red Hat Enterprise Linux 5

Dieser Abschnitt bezieht sich auf Systeme mit Netzwerkspeicher oder externem Speicher, d. h. auf Fibre Channel oder iSCSI basierende Speichergeräte. Für derartige Systeme wird empfohlen, persistente Gerätenamen für Ihren Host zu konfigurieren. Dies ist nicht nur hilfreich bei der Live-Migration, sondern gewährleistet bei mehreren virtualisierten Geräten konsistente Gerätenamen und Speicher.
Universally Unique Identifiers (UUIDs) sind Teil eines standardisierten Verfahrens zur Identifizierung von Systemen und Geräten in verteilten Rechnernetzen. Dieser Abschnitt verwendet UUIDs dazu, iSCSI oder Fibre Channel LUNs zu identifizieren. UUIDs bleiben auch nach Neustarts, Abbruch der Verbindung oder Geräteaustausch erhalten. Die UUID ist vergleichbar mit einer Kennung auf dem Gerät.
Systems which are not running multipath must use Konfiguration eines einzigen Pfads (Single Path). Systems running multipath can use Konfiguration multipler Pfade (Multiple Path).
Konfiguration eines einzigen Pfads (Single Path)
This procedure implements LUN device persistence using udev. Only use this procedure for hosts which are not using multipath.
  1. Bearbeiten Sie die /etc/scsi_id.config-Datei.
    1. Vergewissern Sie sich, dass die Zeile options=-b auskommentiert ist.
      # options=-b
      
    2. Fügen Sie folgende Zeile hinzu:
      options=-g
      
      Diese Option konfiguriert udev um anzunehmen, dass alle angeschlossenen SCSI-Geräte einen UUID (Unique Device Identifier) wiedergeben.
  2. Um die UUID für ein bestimmtes Gerät anzuzeigen, führen Sie den Befehl scsi_id -g -s /block/sd* aus. Zum Beispiel:
    # scsi_id -g -s /block/sd*
    3600a0b800013275100000015427b625e
    
    Die Ausgabe kann sich von dem obigen Beispiel unterscheiden. In der Ausgabe wird die UUID des Geräts /dev/sdc angezeigt.
  3. Vergewissern Sie sich, dass die UUID-Ausgabe durch den scsi_id -g -s /block/sd*-Befehl identisch ist von Computern, die auf das Gerät zugreifen.
  4. Erstellen Sie nun eine Regel für den Namen des Geräts. Legen Sie in /etc/udev/rules.d die Datei 20-names.rules an. In dieser Datei fügen Sie neue Regeln hinzu. Alle Regeln werden in dieselbe Datei und in demselben Format eingefügt. Das Format für Regeln sieht folgendermaßen aus:
    KERNEL=="sd[a-z]", BUS=="scsi", PROGRAM="/sbin/scsi_id -g -s /block/%k", RESULT="UUID", NAME="devicename"
    
    Ersetzen Sie UUID und devicename durch die vorher abgefragte UUID und den gewünschten Namen für das Gerät. Für das obige Beispiel könnte eine Regel wie folgt aussehen:
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="rack4row16"
    
    Der udev-Daemon sucht daraufhin alle Geräte namens /dev/sd* für die UUID in der Regel. Sobald ein passendes Gerät mit dem System verbunden wird, wird dem Gerät der Name aus der Regel zugewiesen. Das Gerät mit der UUID 3600a0b800013275100000015427b625e würde demnach als /dev/rack4row16 erscheinen.
  5. Fügen Sie folgende Zeile am Ende von /etc/rc.local an:
    /sbin/start_udev
    
  6. Kopieren Sie die Änderungen in den Dateien /etc/scsi_id.config, /etc/udev/rules.d/20-names.rules und /etc/rc.local für alle relevanten Hosts.
    /sbin/start_udev
    
Netzwerkspeichergeräte mit konfigurierten Regeln haben jetzt persistente Namen auf all jenen Hosts, auf denen die Dateien aktualisiert wurden. Das bedeutet, dass Sie Gäste zwischen Hosts migrieren können mit Hilfe des gemeinsam genutzen Speichers, und die Gäste können auf die Speichergeräte in ihren Konfigurationsdateien zugreifen.
Konfiguration multipler Pfade (Multiple Path)
Das multipath-Paket wird für Systeme mit mehr als einem physischen Pfad vom Computer zu Speichergeräten verwendet. multipath bietet Fehlertoleranz, die Möglichkeit zum Failover, sowie verbesserte Leistung für Netzwerkspeichergeräte unter Red Hat Enterprise Linux Systemen.
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
Die Multipath-Geräte werden im /dev/mpath-Verzeichnis angelegt. In dem nachfolgenden Beispiel sind vier Geräte in /etc/multipath.conf definiert:
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. Hinzufügen eines virtualisierten CD-ROM- oder DVD-Laufwerks zu einem Gast

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.

Kapitel 10. Netzwerkkonfiguration

Diese Seite gibt einen Überblick über gebräuchliche Netzwerkkonfigurationen, die von Anwendungen genutzt werden, die auf libvirt basieren. Diese Informationen gelten für alle Hypervisoren, egal ob Xen, KVM oder andere. Weitere Informationen finden Sie in der Dokumentation zur libvirt-Netzwerkarchitektur.
Die zwei gebräuchlichsten Konfigurationen sind "Virtuelles Netzwerk" und "Gemeinsam verwendetes physisches Gerät". Ersteres ist identisch über alle Distributionen hinweg und im Lieferumfang enthalten. Letzteres dagegen erfordert eine distributionsspezifische, manuelle Konfiguration.
Network services on virtualized guests are not accessible by default from external hosts. You must enable either Network address translation (NAT) ir a network Bridge to allow external hosts access to network services on virtualized guests.

10.1. Network Address Translation (NAT) mit libvirt

Eine der häufigsten Methoden zur gemeinsamen Verwendung von Netzwerkverbindungen ist der Einsatz von Network Address Translation (NAT) Weiterleitung (auch "virtuelle Netzwerke" genannt).
Host-Konfiguration
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
Falls es nicht vorhanden ist, kann die Beispiel-XML-Konfigurationsdatei neu geladen und aktiviert werden:
# virsh net-define /usr/share/libvirt/networks/default.xml
Das Standardnetzwerk ist durch /usr/share/libvirt/networks/default.xml definiert.
Kennzeichnen Sie das Standardnetzwerk zum automatischen Start:
# virsh net-autostart default
Network default marked as autostarted
Starten Sie das Standardnetzwerk:
# virsh net-start default
Network default started
Sobald das libvirt-Standardnetzwerk läuft, werden Sie ein isoliertes Bridge-Gerät sehen. Dieses Gerät besitzt keine physischen Schnittstellen, da es NAT- und IP-Weiterleitung verwendet, um sich mit der Außenwelt zu verbinden. Fügen Sie keine neuen Schnittstellen hinzu.
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
libvirt fügt iptables-Regeln hinzu, die Datenverkehr von und zu Gästen erlauben, die mit dem virbr0-Gerät in den INPUT, FORWARD, OUTPUT und POSTROUTING-Ketten verknüpft sind. libvirt versucht daraufhin, den ip_forward-Parameter zu aktivieren. Einige andere Anwendungen deaktivieren möglicherweise ip_forward, deshalb sollten Sie am Besten Folgendes zur /etc/sysctl.conf-Datei hinzufügen.
 net.ipv4.ip_forward = 1
Gastkonfiguration
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>

Anmerkung

Es steht Ihnen frei, ob Sie eine MAC-Adresse angeben möchten. Falls Sie keine angegeben, wird automatisch eine MAC-Adresse generiert. In einigen Fällen kann das manuelle Einstellen der MAC-Adresse jedoch sinnvoll sein.
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
  </interface>

10.2. Bridged-Netzwerk mit libvirt

Bridged-Netzwerke (auch Gemeinsame Verwendung physischer Geräte genannt) werden eingesetzt, um einer virtuellen Maschine pyhsische Geräte bereitzustellen. Bridging wird meist in fortgeschrittenen Konfigurationen und auf Servern mit mehreren Netzwerkschnittstellen angewendet.
Deaktivieren der Xen-Netzwerkskripte
Falls Ihr System eine Xen-Bridge verwendete, wird empfohlen, die standardmäßige Xen-Netzwerk-Bridge zu deaktivieren, indem Sie /etc/xen/xend-config.sxp bearbeiten und die folgende Zeile ändern, von:
 (network-script network-bridge)
To:
 (network-script /bin/true)
Deaktivieren des NetworkManagers
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

Anmerkung

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.
Erstellen von Netzwerkinitialisierungsskripten
Erstellen oder bearbeiten Sie die folgenden zwei Netzwerkkonfigurationsdateien. Dieser Schritt kann mit verschiedenen Namen wiederholt werden für zusätzliche Netzwerk-Bridges.
Wechseln Sie in das /etc/sysconfig/network-scripts-Verzeichnis:
# cd /etc/sysconfig/network-scripts
Öffnen Sie die Netzwerkskripte für das Gerät, das Sie zur Bridge hinzufügen wollen. In diesem Beispiel definiert ifcfg-eth0 die physische Netzwerkschnittstelle, die als Teil einer Bridge eingestellt wird:
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
Erstellen Sie ein neues Netzwerkskript in dem /etc/sysconfig/network-scripts-Verzeichnis namens ifcfg-br0 oder ähnlich. br0 ist der Name der Bridge. Dieser Name kann beliebig lauten, solange der Name der Datei dem Namen des DEVICE-Parameters entspricht.
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.

Warnung

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
Starten Sie nach der Konfiguration das Netzwerk oder den Rechner neu.
# service network restart
Konfigurieren Sie iptables, so dass sämtlicher Datenverkehr über die Bridge weitergeleitet werden darf.
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Deaktivieren von iptabels auf Bridges

Alternativ können Sie auch dafür sorgen, dass Datenverkehr über die Bridge nicht von den iptables-Regeln bearbeitet wird. Fügen Sie dazu in /etc/sysctl.conf folgende Zeilen hinzu:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Laden Sie die mit sysctl konfigurierten Kernel-Parameter neu.
# sysctl -p /etc/sysctl.conf
Starten Sie den libvirt-Daemon neu.
# service libvirtd reload
Sie sollten jetzt über ein "Gemeinsam verwendetes physisches Gerät" verfügen, mit dem Gäste verknüpft werden können und so vollen LAN-Zugriff erlangen können. Überprüfen Sie Ihre neue Bridge wie folgt:
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0
Beachten Sie, dass die Bridge vollständig unabhängig ist von der virbr0-Bridge. Versuchen Sie nicht, ein physisches Gerät mit virbr0 zu verknüpfen. Die virbr0-Bridge dient ausschließlich der Network Address Translation (NAT) Konnektivität.

Kapitel 11. Xen-Netzwerke vor Red Hat Enterprise Linux 5.4

Dieses Kapitel behandelt spezielle Themen rund um die Vernetzung und Netzwerkkonfiguration mit dem Xen-Hypervisor.
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, Kapitel 7, Überblick über die Installation virtualisierter Gäste.
Network configuration is also covered in the tool specific reference chapters for virsh (Kapitel 25, Das Verwalten von Gästen mit virsh) and virt-manager (Kapitel 26, Das Verwalten von Gästen mit dem Virtual Machine Manager (virt-manager)). Those chapters provide a detailed description of the networking configuration tasks using both tools.

Tip

Using para-virtualized network drivers improves performance on fully virtualized Linux guests. Kapitel 12, Xen paravirtualisierte Treiber explains how to utilize para-virtualized network drivers.

11.1. Konfiguration von multiplen Gastnetzwerk-Bridges zur Verwendung mehrerer Ethernet-Karten

Verfahren zum Einrichten von Netzwerk-Bridges (mit dem Xen-Hypervisor):
  1. Konfigurieren Sie eine weitere Netzwerkschnittstelle, entweder mit Hilfe des system-config-network-Tools oder durch Erstellung einer neuen Konfigurationsdatei namens ifcfg-ethX in /etc/sysconfig/network-scripts, wobei X eine beliebige noch nicht verwendete Zahl sein kann. Nachfolgend finden Sie ein Beispiel einer Konfigurationsdatei für eine zweite Netzwerkschnittstelle namens 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. Kopieren Sie die Datei /etc/xen/scripts/network-bridge nach /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. Red Hat Enterprise Linux 5.0 Laptop-Netzwerkkonfiguration

Für Red Hat Enterprise Linux 5.1 oder höher

Dieser Abschnitt beschreibt das manuelle Hinzufügen von Netzwerk-Bridges. Dieses Verfahren ist für Red Hat Enterprise Linux Versionen höher als Version 5.0 weder notwendig noch empfohlen. Verwenden Sie in neueren Versionen "Virtuelle Netzwerk"-Adapter beim Erstellen von Gästen in virt-manager. NetworkManager funktioniert standardmäßig mit virtuellen Netzwerkgeräten in Red Hat Enterprise Linux 5.1 und höher.
Ein Beispiel einer virsh XML-Konfigurationsdatei für ein virtuelles Netzwerkgerät:
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
</interface>
In xm-Konfigurationsdateien sind virtuelle Geräte mit "vif" gekennzeichnet.
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.
Dieses Setup wird Ihnen ermöglichen, Xen im Offline-Modus laufen zu lassen, wenn Sie gerade keine aktive Netzwerkverbindung auf Ihrem Laptop haben. Für die einfachste Lösung, Xen auf einem Laptop laufen zu lassen, gehen Sie wie folgt vor:
  • 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.
  • Sie werden statische IP-Adressen verwenden müssen, da DHCP auf der Dummy-Schnittstelle nicht auf DHCP-Anfragen horchen wird. Sie können Ihre eigene Version von DHCP kompilieren, um auf Dummy-Schnittstellen zu horchen, sollten jedoch die Verwendung von dnsmasq für DNS, DHCP und tftpboot-Diensten in einer Xen-Umgebung erwägen. Das Setup und die Konfiguration werden später in diesem Kapitel erklärt.
  • Sie können auch NAT- und IP-Maskierung konfigurieren, um den Zugriff von Ihren Gästen auf das Netzwerk zu ermöglichen.
Konfiguration einer Dummy-Netzwerkschnittstelle
Führen Sie folgende Konfigurationsschritte auf Ihrem Host aus:
  1. Erzeugen Sie eine dummy0-Netzwerkschnittstelle und weisen Sie ihr eine statische IP-Adresse zu. In unserem Beispiel wird 10.1.1.1 ausgewählt, um Routing-Probleme in unserer Umgebung zu vermeiden. Um die Unterstützung des Dummy-Geräts zu aktivieren, fügen Sie folgende Zeilen zu /etc/modprobe.conf hinzu.
    alias dummy0 dummy
    options dummy numdummies=1
    
  2. Um eine Vernetzung für dummy0 zu konfigurieren, erstellen/bearbeiten Sie bitte /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. Binden Sie xenbr0 an dummy0, damit Sie ein Netzwerk verwenden können, selbst wenn Sie nicht an ein physisches Netzwerk angeschlossen sind. Bearbeiten Sie /etc/xen/xend-config.sxp und fügen den Eintrag netdev=dummy0 hinzu:
    (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. Das Einrichten von NAT im Host ermöglicht dem Gast den Zugriff auf das Internet, auch über Wireless, und löst damit die Probleme von Xen mit Wireless-Karten. Das folgende Skript aktiviert NAT, basierend auf der Schnittstelle, die zu dem Zeitpunkt für Ihre Netzwerkverbindung genutzt wird.
Konfigurieren von NAT für virtualisierte Gäste
Network Address Translation (NAT) erlaubt mehreren Netzwerkadressen, sich mittels einer einzigen IP-Adresse zu verbinden, indem Pakete abgefangen und an die privaten IP-Adressen weitergeleitet werden. Sie können das folgende Skript nach /etc/init.d/xenLaptopNAT kopieren und eine symbolische Verknüpfung zu /etc/rc3.d/S99xenLaptopNAT erzeugen. Dies startet NAT zum Zeitpunkt des Hochfahrens automatisch.

NetworkManager und Wireless-NAT

Das untere Skript funktioniert unter Umständen nicht einwandfrei mit Wireless-Netzwerken oder NetworkManager aufgrund von Verzögerungen beim Hochfahren. In diesem Fall starten Sie das Skript manuell, sobald die Maschine hochgefahren ist.
#!/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
Konfiguration von dnsmasq für DNS-, DHCP- und tftpboot-Dienste
Eine der Herausforderungen beim Ausführen von Virtualisierung auf einen Laptop (oder jedem anderen Computer, der nicht durch eine einzige oder stabile Netzwerkverbindung verbunden ist) sind die Veränderungen der Netzwerkschnittstellen und der Verfügbarkeit. Die Verwendung einer Dummy-Netzwerkschnittstelle hilft zwar, eine stabilere Umgebung zu schaffen, bringt allerdings auch neue Herausforderungen bezüglich der Bereitstellung von DHCP, DNS und tftboot-Diensten für Ihre Gäste/virtuellen Maschinen mit sich. Der standardmäßige DHCP-Daemon von Red Hat Enterprise Linux und Fedora Core horcht nicht auf die Dummy-Schnittstellen, Ihre weitergeleiteten DNS-Informationen können sich evtl. ändern, wenn Sie sich mit verschiedenen Netzwerken und VPNs verbinden.
Eine Lösung der oben genannten Herausforderungen besteht in der Verwendung von dnsmasq, welches alle oben genannten Dienste in einem einzigen Paket liefert und Ihnen ebenfalls erlaubt, den Dienst so zu steuern, dass nur Anfragen von der Dummy-Schnittstelle entgegengenommen werden. Nachfolgend wird beschrieben, wie dnsmasq auf einem Laptop mit Virtualisierung konfiguriert wird:
  • Die neueste Version von dnsmasq finden Sie hier.
  • 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 kann als ein Dispatcher-Skript für den NetworkManager verwendet werden. Es wird immer gestartet, wenn der NetworkManager eine Änderung in der Verbindung erkennt und erzwingt einen Neustart bzw. Neuladen von dnsmasq. Es sollte nach /etc/NetworkManager/dispatcher.d/nm-dnsmasq kopiert werden.
    • xenDNSmasq kann als Haupt-Startup- oder -Shutdown-Skript für /etc/init.d/xenDNSmasq verwendet werden.
    • dnsmasq.conf ist ein Beispiel für eine Konfigurationsdatei für /etc/dnsmasq.conf.
    • dnsmasq ist das Binär-Image für /usr/local/sbin/dnsmasq.
  • Sobald Sie dnsmasq entpackt und installiert haben (die standardmäßige Installation wird in /usr/local/sbin/dnsmasq sein), müssen Sie Ihre dnsmasq-Konfigurationsdatei bearbeiten. Diese Datei befindet sich in /etc/dnsmaqa.conf.
  • Bearbeiten Sie Ihre Konfiguration so, dass Sie Ihren lokalen Bedürfnissen und Anforderungen entspricht. Die folgenden Parameter sind dafür wahrscheinlich zu ändern:
    • Der interface-Parameter erlaubt es dnsmasq, auf DHCP- und DNS-Anfragen nur auf spezifizierten Schnittstellen zu horchen. Dies können Dummy-Schnittstellen anstelle Ihrer öffentlichen Schnittstellen sein, oder auch die lokale Loopback-Schnittstelle. Fügen Sie weitere interface-Zeilen für weitere Schnittstellen hinzu. interface=dummy0 beispielsweise horcht auf die dummy0-Schnittstelle.
    • dhcp-range: Um den integrierten DHCP-Server zu aktivieren, müssen Sie einen verfügbaren Adressbereich und optional eine Lease-Zeit angeben. Falls Sie mehr als ein Netzwerk haben, müssen Sie dies für jedes weitere Netzwerk wiederholen, das Sie mit dem DHCP-Dienst versorgen wollen. Ein Beispiel wäre (für Netzwerk 10.1.1.* und eine Lease-Zeit von 12 Std): dhcp-range=10.1.1.10,10.1.1.50,255.255.255.0,12h.
    • dhcp-option: Um die von dnsmasq gelieferte Standard-Route außer Kraft zu setzen, wodurch angenommen wird, dass der Router dieselbe Maschine ist, die auch dnsmasq ausführt. Ein Beispiel wäre dhcp-option=3,10.1.1.1.
  • Nachdem dnsmasq konfiguriert wurde, können Sie das untere Skript als xenDNSmasq nach /etc/init.d kopieren.
  • Falls Sie möchten, dass dnsmasq automatisch während des Hochfahrens startet, sollten Sie es mittels chkconfig(8) registrieren:
    chkconfig --add xenDNSmasq
    
    Aktivieren des automatischen Starts:
    chkconfig --levels 345 xenDNSmasq on
    
  • Um dnsmasq so zu konfigurieren, dass es jedesmal neu startet, wenn NetworkManager eine Änderung in der Verbindung entdeckt, können Sie das nm-dnsmasq-Skript verwenden.
    • Kopieren Sie das nm-dnsmasq-Skript nach /etc/NetworkManager/dispatcher.d/
    • Der NetworkManager-Dispatcher wird das Skript (in alphabetischer Reihenfolge, falls Sie andere Skripte in demselben Verzeichnis haben) bei jeder Änderung in der Verbindung durchführen.
  • dnsmasq wird ebenfalls Veränderungen in Ihrer /etc/resolv.conf-Datei erkennen und sie automatisch neuladen (z. B. wenn Sie eine VPN-Sitzung beginnen).
  • Sowohl das nm-dnsmasq als auch das xenDNSmasq-Skript richten ebenfalls NAT ein, um Ihren virtualisierten Gästen – falls sich diese in einem versteckten Netzwerk befinden – Zugriff auf das öffentliche Netzwerk zu erlauben.

Kapitel 12. Xen paravirtualisierte Treiber

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.

Andere paravirtualisierte Treiber

Es gibt andere paravirtualisierte Treiber für Windows sowohl für Xen- als auch KVM-Hypervisoren.
Werfen Sie für Windows-Gäste auf Xen-Hosts einen Blick auf den Windows Para-virtualized Drivers Guide (Handbuch für Windows paravirtualisierte Treiber), in dem die Installation und Administration beschrieben werden.
For Windows guests on KVM hosts, refer to Kapitel 13, KVM paravirtualisierte Treiber.
Die RPM-Pakete für die paravirtualisierten Treiber beinhalten die Module für Speicher und Networking von paravirtualisierten Treibern für die unterstützten Red Hat Enterprise Gastbetriebssysteme. Diese Treiber ermöglichen einen Hochleistungsdatendurchsatz bei I/O-Operationen in unmodifizierten Red Hat Enterprise Linux Gastbetriebssystemen auf einem Red Hat Enterprise Linux 5.1. Host oder höher.
Die unterstützen Gastbetriebssysteme sind:
  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5

Unterstützte Architektur für paravirtualisierte Treiber

Die Mindestvoraussetzungen für Gastbetriebssysteme sind architekturabhängig. Nur x86- und x86-64 Gäste werden unterstützt.
Die Treiber werden nicht von Red Hat Enterprise Linux Gastbetriebssystemen vor Red Hat Enterprise Linux 3 unterstützt.
Die Verwendung von Red Hat Enterprise Linux 5 als eine Virtualisierungsplattform erlaubt Systemadministratoren das Zusammenlegen von Linux- und Windows-Arbeitslasten auf eine neuere, leistungsstärkere Hardware mit höherer Leistung und effizienterer Kühlung. Red Hat Enterprise Linux 4 (seit Update 6) und Red Hat Enterprise Linux 5 Gastbetriebssysteme sind sich der zu Grunde liegenden Virtualisierungstechnologie bewusst und können mittels spezifischer Schnittstellen und Funktionen effektiv damit arbeiten. Auf diese Weise können Datendurchsätze und Leistungsmerkmale erreicht werden, die vergleichbar sind mit jenen bei einer Ausführung auf dem Bare-Metal-System.
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.
Die paravirtualisierten Gerätetreiber sind in den Red Hat Enterprise Linux-Paketen enthalten. Diese Treiber bringen viele der Leistungsvorteile der paravirtualisierten Gastbetriebssysteme in unmodifizierte Betriebssysteme ein, denn nur der paravirtualisierte Gerätetreiber (jedoch nicht das übrige Betriebssystem) ist sich der zu Grunde liegenden Virtualisierungsplattform bewusst.
Nach der Installation der paravirtualisierten Gerätetreiber erscheint dem Betriebssystem ein Plattengerät oder eine Netzwerkkarte weiterhin als eine normale, physische Platte oder Netzwerkkarte. Der Gerätetreiber interagiert nun jedoch direkt mit der Virtualisierungsplattform (ohne Emulation), um effizient Platten- und Netzwerkzugriff zu ermöglichen. Dies erlaubt es den Platten und Netzwerksubsystemen sogar in einer virtualisierten Umgebung mit fast Originalgeschwindigkeit zu arbeiten, ohne dass dazu Änderungen am vorhandenen Gastbetriebssystem nötig wären.
Die paravirtualisierten Treiber stellen bestimmte Anforderungen an den Host. 64 Bit Hosts unterstützen:
  • 32 Bit Gäste.
  • 64 Bit Gäste.
  • eine Mischung aus 32 Bit und 64 Bit Gästen.

12.1. Systemvoraussetzungen

Dieser Abschnitt beinhaltet die Voraussetzungen für paravirtualisierte Treiber mit Red Hat Enterprise Linux.
Installation
Bevor Sie mit der Installation der paravirtualisierten Treiber beginnen, müssen folgende (unten aufgelistete) Voraussetzungen gegeben sein.

Red Hat Enterprise Linux 4.7 und 5.3 oder höher

In alle Red Hat Enterprise Linux Versionen ab 4.7 und 5.3 ist das Kernel-Modul für die paravirtualisierten Treiber, das pv-on-hvm-Modul, im Standard-Kernel-Paket enthalten. Das bedeutet, dass die paravirtualisierten Treiber für Gäste mit Red Hat Enterprise Linux 4.7 und höher sowie 5.3 und höher zur Verfügung stehen.
Für jede Installation eines Gastbetriebssystems benötigen Sie folgende RPM-Pakete für paravirtualisierte Treiber.
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. Einschränkungen und Unterstützung der Paravirtualisierung

Dieser Abschnitt beschreibt Einschränkungen der Unterstützung und Voraussetzungen für die Verwendung von paravirtualisierten Treibern in Red Hat Enterprise Linux. In den folgenden Abschnitten finden Sie Angaben darüber, was unterstützt wird, und wo es Einschränkungen der Unterstützung gibt.
Unterstützte Gastbetriebssysteme
Für folgende Betriebssysteme und Versionen steht Unterstützung für paravirtualisierte Treiber zur Verfügung.
  • Red Hat Enterprise Linux 5.1 und höher.
  • Red Hat Enterprise Linux 4 Update 6 und höher.
  • Red Hat Enterprise Linux 3 Update 9 und höher.
32 Bit Gast-Betriebssysteme mit paravirtualisierten Treibern auf einer 64 Bit Red Hat Enterprise Linux 5 Virtualisierung wird unterstützt.
Die untere Tabelle zeigt unterschiedliche Kernel-Varianten auf, die von paravirtualisierten Treibern unterstützt werden. Mit Hilfe des folgenden Befehls können Sie die genaue Kernel-Revision herausfinden, die derzeit auf Ihrem Host installiert ist. Vergleichen Sie die Ausgabe mit der Tabelle, um festzustellen, ob er unterstützt wird.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Die Red Hat Enterprise Linux 5 i686 und x86_64 Kernel-Varianten beinhalten Symmetric Multiprocessing (SMP), ein separater SMP-Kernel RPM ist nicht notwendig.
Beachten Sie die prozessorspezifischen Kernel-Voraussetzungen für Red Hat Enterprise Linux 3 Gäste in der nachfolgenden Tabelle.
Tabelle 12.1. Unterstützte Gast-Kernel-Architekturen für paravirtualisierte Treiber
Kernel-Architektur Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5
Athlon Unterstützt (AMD)   
athlon-SMP Unterstützt (AMD)   
i32e Unterstützt (Intel)   
i686 Unterstützt (Intel) Unterstützt Unterstützt
i686-PAE Unterstützt
i686-SMP Unterstützt (Intel) Unterstützt  
i686-HUGEMEM Unterstützt (Intel) Unterstützt  
x86_64 Unterstützt (AMD) Unterstützt Unterstützt
x86_64-SMP Unterstützt (AMD) Unterstützt  
x86_64-LARGESMP Unterstützt  
Itanium (IA64) Unterstützt

Wichtig

Das Host-System erfordert Red Hat Enterprise Linux 5.1 oder höher.

Laufenden Kernel herausfinden

Schreiben Sie sich die Ausgabe des folgenden Befehls auf, oder merken Sie sich diese. Dieser Wert entscheidet, welche Pakete und Module Sie herunterladen müssen.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Ihre Ausgabe sollte ungefähr wie folgt aussehen:
kernel-PAE-2.6.18-53.1.4.el5.i686
Der Name des Kernels lautet PAE (Physical Address Extension), die Kernel-Version ist 2.6.18, die Release ist 53.1.4.el5 und die Architektur i686. Die Kernel-RPM sollte immer dem Format kernel-name-version-release.arch.rpm folgen.
Wichtige Einschränkungen
Paravirtuallisierte Gerätetreiber können nach der erfolgreichen Installation eines Gastbetriebssystems installiert werden. Sie müssen einen funktionierenden Gast und Host haben, bevor Sie die Treiber installieren können.

Paravirtualisierte Blockgeräte und GRUB

GRUB kann derzeit nicht auf paravirtualisierte Blockgeräte zugreifen. Daher kann ein Gast nicht von einen Gerät gestartet werden, das die paravirtualisierten Blockgerättreiber verwendet. Dazu gehört die Platte, welche die Master Boot Record (MBR) enthält, eine Platte, die einen Bootloader (GRUB) enthält, oder eine Platte, die die Kernel initrd-Images enthält. Kurz, jede Platte, die ein /boot-Verzeichnis oder -Partition enthält, kann die paravirtualisierten Blockgerättreiber nicht verwenden.
Abhängigkeiten der Red Hat Enterprise Linux 3 Kernel-Architektur-Varianten
Für Gastbetriebssysteme, die auf Red Hat Enterprise Linux 3 basieren, müssen Sie den prozessorspezifischen Kernel und die paravirtualisierten Treiber-RPMs verwenden, wie in der unteren Tabelle aufgezeigt. Falls Sie nicht das passende Paket mit paravirtualisierten Treibern installieren, schlägt das Laden des xen-pci-platform-Moduls fehl.
Die Tabelle unten zeigt, welcher Host-Kernel einen Red Hat Enterprise Linux 3 Gast ausführen muss, wenn der Gast für einen Intel-Prozessor kompiliert wurde.
Tabelle 12.2. Erforderliche Host-Kernel-Architektur für Gäste, die paravirtualisierte Treiber auf Red Hat Enterprise Linux 3 für Intel-Prozessoren verwenden
Gast-Kernel-Typ Erforderlicher Host-Kernel-Typ
ia32e (UP und SMP) x86_64
i686 i686
i686-SMP i686
i686-HUGEMEM i686

Die Tabelle unten zeigt, welcher Host-Kernel einen Red Hat Enterprise Linux 3 Gast ausführen muss, wenn der Gast für einen AMD-Prozessor kompiliert wurde.
Tabelle 12.3. Erforderliche Host-Kernel-Architektur für Gäste, die paravirtualisierte Treiber auf Red Hat Enterprise Linux 3 für AMD-Prozessoren verwenden
Gast-Kernel-Typ Erforderlicher Host-Kernel-Typ
Athlon i686
athlon-SMP i686
x86_64 x86_64
x86_64-SMP x86_64

12.3. Installation der paravirtualisierten Treiber

In den folgenden drei Kapiteln wird beschrieben, wie Sie einen voll virtualisierten Gast installieren und konfigurieren können, der auf Red Hat Enterprise Linux 5.1. oder höher mit paravirtualisierten Treibern läuft.

Überprüfen Sie, dass Ihre Architektur unterstützt wird, ehe Sie beginnen.

Paravirtualisierte Treiber werden nur auf bestimmten Kombination aus Hardware und Version unterstützt. Vergewissern Sie sich, dass die Hardware- und Betriebssystemvoraussetzungen erfüllt werden, bevor Sie mit der Installation von paravirtualisierten Treibern beginnen.

Maximieren der Vorteile von paravirtualisierten Treibern für neue Installationen

Falls Sie ein neues Gastsystem installieren, sollten Sie, um den bestmöglichen Nutzen aus den paravirtualisierten Blockgerättreibern zu ziehen, den Gast mit mindestens zwei Platten erstellen.
Benutzen Sie die paravirtualisierten Treiber für die Platte, die MBR und den Boot-Loader (GRUB) enthält, sowie für die /boot-Partition. Diese Partition kann sehr klein sein, sie benötigt nur ausreichend Speicherplatz für die /boot Partition.
Benutzen Sie die zweite Platte und alle weiteren Platten für alle anderen Partitionen (z. B. /, /usr) oder logische Datenträger.
Mit dieser Installationsmethode, bei der die paravirtualisierten Blockgerättreiber erst nach abgeschlossener Installation des Gasts installiert werden, werden die virtualisierten Blockgerättreiber nur zum Hochfahren des Gasts und zum Zugriff auf die /boot-Partition benutzt.

12.3.1. Allgemeine Installationsschritte

Die folgende Liste beinhaltet diejenigen Installationsschritte, die allen Gastbetriebssystemversionen gemein sind.
  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 Abschnitt 12.2, „Einschränkungen und Unterstützung der Paravirtualisierung“.
  2. Benutzen Sie den rpm-Befehl oder den yum-Befehl, um die Pakete zu installieren. Das rpm-Dienstprogramm wird die folgenden vier neuen Kernel-Module in /lib/modules/[%kversion][%kvariant]/extra/xenpv/%release installieren:
    • 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. Falls Ihr Gastbetriebssystem nicht das automatische Laden von paravirtualisierten Treibern unterstützt (wie z. B. Red Hat Enterprise Linux 3), führen Sie bitte die erforderlichen Schritte nach der Installation aus, um die Treiber in die für das Betriebssystem spezifischen Orte zu kopieren.
  4. Fahren Sie das Gastbetriebssystem herunter.
  5. Reconfigure the guest operating system's configuration file on the host to use the installed para-virtualized drivers.
  6. Löschen Sie den “type=ioemu”-Eintrag für das Netzwerkgerät.
  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. Fügen Sie jegliche zusätzliche Speichereinheiten hinzu, die Sie für den paravirtualisierten Blockgerättreiber benutzen wollen.
  11. Starten Sie Ihren Gast neu:
    # 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 und Konfiguration von paravirtualisierten Treibern in Red Hat Enterprise Linux 3

Dieser Abschnitt beinhaltet detaillierte Anleitungen für paravirtualisierte Treiber in einem Red Hat Enterprise 3 Gastbetriebssystem.

Anmerkung

Diese Pakete unterstützen nicht das Booten von einer paravirtualisierten Festplatte. Das Booten des Gastbetriebssystem-Kernels erfordert immer noch die Verwendung des emulierten IDE-Treibers, während alle anderen (nicht-system-) User-Space-Anwendungen und -Daten die paravirtualisierten Blockgerättreiber verwenden können.
Treiberinstallation
Die nachfolgende Liste zeigt die Schritte auf, die nötig sind, um einen Red Hat Enterprise Linux 3 Gast mit paravirtualisierten Treiber zu installieren.
  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. Kopieren Sie das kmod-xenpv-RPM, das Ihrer Hardware-Architektur und Kernel-Variante entspricht, auf Ihr Gastbetriebssystem.
  3. Benutzen Sie das rpm-Dienstprogramm, um die RPM-Pakete zu installieren. Vergewissern Sie sich, dass Sie korrekt dasjenige Paket identifiziert haben, das Sie für Ihre Gastbetriebssystemvariante und -architektur benötigen.
    [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
    

    Anmerkung

    Bei der Installation von Binär-Treibermodulen werden von insmod Warnungen generiert, weil Red Hat Enterprise Linux 3 MODVERSIONS aktiviert hat. Diese Warnungen können jedoch ignoriert werden.
  5. Überprüfen Sie /etc/modules.conf und stellen Sie sicher, dass Sie ein Alias für eth0 haben ähnlich dem unten gezeigten. Falls Sie mehrere Schnittstellen konfigurieren möchten, fügen Sie eine zusätzliche Zeile pro Schnittstelle hinzu.
    alias eth0 xen-vnif
    
    Bearbeiten Sie /etc/rc.local und fügen diese Zeile hinzu:
    insmod /lib/modules/'uname -r'/extra/xenpv/%release/xen-vbd.o
    

    Anmerkung

    Ersetzen Sie "%release" durch die richtige Release-Version (z. B. 0.1-5.el) für die paravirtualisierten Treiber. Falls Sie das PRM-Paket der paravirtualisierten Treiber aktualisieren, stellen Sie sicher, dass Sie die Release-Version auf die passende Version aktualisieren.
  6. Fahren Sie die virtuelle Maschine herunter (führen Sie “#shutdown -h now” innerhalb des Gasts aus).
  7. Edit the guest configuration file in /etc/xen/YourGuestName with a text editor, performing the following changes:
    • Löschen Sie den “type=ioemu”-Eintrag vom “vif=”-Eintrag.
    • Fügen Sie jegliche Plattenpartitionen, Datenträger oder LUNs zum Gast hinzu, so dass via paravirtualisiertem (xen-vbd) Plattentreiber auf diese zugegriffen werden kann.
    • 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.

Achtung

Die paravirtualisierten Treiber werden nicht automatisch im System hinzugefügt und geladen, denn in Red Hat Enterprise Linux 3 ist keine Unterstützung für weak-modules und modversions enthalten. Um das Modul einzufügen, führen Sie nachstehenden Befehl aus.
insmod xen_vbd.ko
Red Hat Enterprise Linux 3 erfordert die manuelle Erstellung der Spezialdateien für Blockgeräte, die xen-vbd verwenden. Die nachfolgenden Schritte veranschaulichen die Erstellung und Registrierung von paravirtualisierten Blockgeräten.
Verwenden Sie das folgende Skript, um Spezialdateien zu erstellen, nachdem der paravirtualisierte Blockgerättreiber geladen wurde.
#!/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*
Erhöhen Sie die Minor-Zahl für jede zusätzliche virtuelle Platte um 16. Im Beispiel unten wird ein zusätzliches Gerät mit der Minor-Zahl 16 erzeugt.
# mknod /dev/xvdc b $major 16
# mknod /dev/xvdc1 b $major 17
Das nächste Gerät wäre 32, was wie folgt erzeugt werden kann:
# mknod /dev/xvdd b $major 32
# mknod /dev/xvdd1 b $major 33
Nun sollten Sie überprüfen, ob die von Ihnen erstellten Partitionen verfügbar sind.
[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
In der Ausgabe oben können Sie erkennen, dass das partitionierte Gerät "xvdb" dem System zur Verfügung steht.
Das nachfolgende Verfahren fügt das neue Gerät zum Gast hinzu und macht es persistent auch nach Neustart. Alle diese Befehle werden auf dem Gast ausgeführt.
  1. Erstellen Sie Verzeichnisse, um die Blockgerät-Images darin einzuhängen.
    [root@rhel3]# mkdir /mnt/pvdisk_p1
    [root@rhel3]# mkdir /mnt/pvdisk_p2
    
  2. Hängen Sie die Geräte in den neuen Verzeichnissen ein.
    [root@rhel3]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel3]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Vergewissern Sie sich, dass die Geräte korrekt eingehängt sind.
    [root@rhel3]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Aktualisieren Sie die /etc/fstab-Datei im Gast, um die Geräte während der Boot-Sequenz einzuhängen. Fügen Sie folgende Zeilen hinzu:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Tipp für bessere Leistung

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
Ein Red Hat Enterprise Linux 5.2 dom0 braucht diesen Kernel-Parameter für den Gast nicht.

Wichtig

Die Itanium (ia64) Binär-RPM-Pakete und -Builds sind derzeit nicht verfügbar.

12.3.3. Installation und Konfiguration von paravirtualisierten Treibern in Red Hat Enterprise Linux 4

Dieser Abschnitt beinhaltet detaillierte Anleitungen für paravirtualisierte Treiber in einem Red Hat Enterprise 4 Gast-Betriebssystem.

Anmerkung

Diese Pakete unterstützten nicht das Booten von einer paravirtualisierten Platte. Das Booten des Gast-Betriebssystem-Kernels erfordert immer noch die Verwendung des emulierten IDE-Treibers, während alle anderen (nicht-system-) User-Space-Anwendungen und -Daten den paravirtualisierten Blockgerättreiber verwenden können.
Treiberinstallation
Die nachfolgende Liste zeigt die Schritte auf, die nötig sind, um einen Red Hat Enterprise Linux 4 Gast mit paravirtualisierten Treiber zu installieren.
  1. Kopieren Sie die kmod-xenpv, modules-init-tools und modversions-RPMs, die Ihrer Hardware-Architektur und Kernel-Variante entsprechen, auf Ihr Gastbetriebssystem.
  2. Benutzen Sie das rpm-Dienstprogramm, um die RPM-Pakete zu installieren. Vergewissern Sie sich, dass Sie korrekt dasjenige Paket identifiziert haben, das Sie für Ihre Gastbetriebssystemsvariante und -architektur benötigen. Ein aktualisiertes module-init-tools wird für dieses Paket benötigt, welches für den Red Hat Enterprise Linux 4-6-z Kernel und höher erhältlich ist.
    [root@rhel4]# rpm -ivh modversions
    [root@rhel4]# rpm -Uvh module-init-tools
    [root@rhel4]# rpm -ivh kmod-xenpv*
    

    Anmerkung

    Es gibt verschiedene Pakete für UP, SMP, Hugemem und Architekturen, deshalb sollten Sie sicher stellen, dass Sie die richtigen RPMs für Ihren Kernel haben.
  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. Fahren Sie die virtuelle Maschine herunter (führen Sie “#shutdown -h now” innerhalb des Gasts aus).
  5. Bearbeiten Sie die Gastkonfigurationsdatei in /etc/xen/YourGuestName folgendermaßen:
    • Löschen Sie den “type=ioemu-” Eintrag vom “vif=”-Eintrag.
    • Fügen Sie jegliche Plattenpartitionen, Datenträger oder LUNs zum Gast hinzu, so dass via paravirtualisiertem (xen-vbd) Plattentreiber auf diese zugegriffen werden kann.
    • Fügen Sie für alle zusätzlichen physischen Laufwerke, LUNs, Partitionen oder Datenträger je einen Eintrag ähnlich dem unten gezeigten in den "disk="-Bereich der Gastkonfigurationsdatei ein. Der ursprüngliche disk=-Eintrag kann ebenfalls dem unten gezeigten ähneln.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    • Nachdem Sie zusätzliche physische Geräte, LUNs, Partitionen oder Datenträger hinzugefügt haben, sollte der Eintrag für die paravirtualisierten Treiber in Ihrer XML-Konfiguration etwa wie folgt aussehen.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Anmerkung

      Verwenden Sie "tap:aio" für das paravirtualisierte Gerät, falls ein dateibasiertes Image verwendet wird.
  6. Booten Sie die virtuelle Maschine mit dem virsh-Befehl:
    # virsh start YourGuestName
Beim ersten Neustart des virtuellen Gasts wird kudzu Sie fragen, ob Sie das "Realtek Netzwerkgerät behalten oder löschen" und das "Xen-Bridge Gerät konfigurieren" möchten. Sie sollten xen-bridge konfigurieren und das Realtek-Netzwerkgerät löschen.

Tipp für bessere Leistung

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
Ein Red Hat Enterprise Linux 5.2 dom0 braucht diesen Kernel-Parameter für den Gast nicht.
Nun sollten Sie überprüfen, ob die von Ihnen erstellten Partitionen verfügbar sind.
[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
Im oberen Beispiel können Sie sehen, dass die Partition xvdb im System erreichbar ist.
Das nachfolgende Verfahren fügt das neue Gerät zum Gast hinzu und macht es persistent auch nach Neustart. Alle diese Befehle werden auf dem Gast ausgeführt.
  1. Erstellen Sie Verzeichnisse, um die Blockgerät-Images darin einzuhängen.
    [root@rhel4]# mkdir /mnt/pvdisk_p1
    [root@rhel4]# mkdir /mnt/pvdisk_p2
    
  2. Hängen Sie die Geräte in den neuen Verzeichnissen ein.
    [root@rhel4]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel4]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Vergewissern Sie sich, dass die Geräte korrekt eingehängt sind.
    [root@rhel4]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Aktualisieren Sie die /etc/fstab-Datei im Gast, um die Geräte während der Boot-Sequenz einzuhängen. Fügen Sie folgende Zeilen hinzu:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Anmerkung

Dieses Paket wird nicht unterstützt für Systeme und Kernels von Red Hat Enterprise Linux 4-GA bis Red Hat Enterprise Linux 4 Update 2.

Wichtige Anmerkung

IA64 Binär-RPM-Pakete und -Builds sind derzeit nicht verfügbar.

Automatischen Laden der Module

Der xen-vbd-Treiber lädt unter Umständen nicht automatisch. Führen Sie den folgenden Befehl auf dem Gast aus, ersetzen Sie dabei %release durch die korrekte Release-Version für die paravirtualisierten Treiber.
# 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.

Anmerkung

Diese Pakete unterstützen nicht das Booten von einer paravirtualisierten Platte. Das Booten des Gast-Betriebssystem-Kernels erfordert immer noch die Verwendung des emulierten IDE-Treibers, während alle anderen (nicht-system-) User-Space-Anwendungen und -Daten den paravirtualisierten Blockgerättreiber verwenden kann.
The procedure below covers the steps to enable the para-virtualized drivers for a Red Hat Enterprise Linux 5 guest.
Prozedur 12.1. Enable para-virtualized drivers for a Red Hat Enterprise Linux Guest
  1. Fahren Sie die virtuelle Maschine herunter (führen Sie “#shutdown -h now” innerhalb des Gasts aus).
  2. Bearbeiten Sie die Gastkonfigurationsdatei in /etc/xen/YourGuestName folgendermaßen:
    1. Löschen Sie den “type=ioemu”-Eintrag vom “vif=”-Eintrag.
    2. Fügen Sie jegliche Plattenpartitionen, Datenträger oder LUNs zum Gast hinzu, so dass via paravirtualisiertem (xen-vbd) Plattentreiber auf diese zugegriffen werden kann.
    3. Fügen Sie für alle zusätzlichen physischen Laufwerke, LUNs, Partitionen oder Datenträger je einen Eintrag ähnlich dem unten gezeigten in den "disk="-Bereich der Gastkonfigurationsdatei ein. Der ursprüngliche disk=-Eintrag kann ebenfalls dem unten gezeigten ähneln.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    4. Nachdem Sie zusätzliche physische Geräte, LUNs, Partitionen oder Datenträger hinzugefügt haben, sollte der Eintrag für die paravirtualisierten Treiber in Ihrer XML-Konfiguration etwa wie folgt aussehen.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Anmerkung

      Verwenden Sie "tap:aio" für das paravirtualisierte Gerät, falls ein dateibasiertes Image verwendet wird.
  3. Booten Sie die virtuelle Maschine mit dem virsh-Befehl:
    # virsh start YourGuestName
    
Um zu überprüfen, ob die Netzwerkschnittstellen nach der Installation der paravirtualisierten Treiber aktiv sind, führen Sie folgenden Befehl auf dem Gast aus. Dies sollte die Schnittstelleninformation inklusive einer zugewiesenen IP-Adresse anzeigen.
[root@rhel5]# ifconfig eth0
Nun sollten Sie überprüfen, ob die von Ihnen erstellten Partitionen verfügbar sind.
[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
Im oberen Beispiel können Sie sehen, dass die Partition xvdb im System erreichbar ist.
Das nachfolgende Verfahren fügt das neue Gerät zum Gast hinzu und macht es persistent auch nach Neustart. Alle diese Befehle werden auf dem Gast ausgeführt.
  1. Erstellen Sie Verzeichnisse, um die Blockgerät-Images darin einzuhängen.
    [root@rhel5]# mkdir /mnt/pvdisk_p1
    [root@rhel5]# mkdir /mnt/pvdisk_p2
    
  2. Hängen Sie die Geräte in den neuen Verzeichnissen ein.
    [root@rhel5]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel5]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Vergewissern Sie sich, dass die Geräte korrekt eingehängt sind.
    [root@rhel5]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Aktualisieren Sie die /etc/fstab-Datei im Gast, um die Geräte während der Boot-Sequenz einzuhängen. Fügen Sie folgende Zeilen hinzu:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Tipp für bessere Leistung

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
Ein Red Hat Enterprise Linux 5.2 dom0 braucht diesen Kernel-Parameter für den Gast nicht.
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. Konfiguration paravirtualisierter Netzwerktreiber

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.
Führen Sie bitte die folgenden Schritte aus, um Ihre Netzwerkschnittstelle innerhalb des Gasts neu zu konfigurieren.
  1. Öffnen Sie im virt-manager das Konsolenfenster für den Gast und melden sich als root an.
  2. Überprüfen Sie in Red Hat Enterprise Linux 4, dass die Datei /etc/modprobe.conf die Zeile “alias eth0 xen-vnif” beinhaltet.
    # 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 Abschnitt 36.4, „Manuelles Laden der paravirtualisierten Treiber“.
    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. Sie sollten nun die neue Netzwerkschnittstelle mit einer zugewiesenen IP-Adresse sehen.
    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. Konfiguration zusätzlicher paravirtualisierter Hardware

Dieser Abschnitt erklärt, wie ein zusätzliches virtuelles Netzwerk oder Speicher zu einen Gastbetriebssystem hinzugefügt wird. Mehr Informationen über Netzwerkkonfiguration und Speicherressourcen mit Red Hat Enterprise Linux 5 Virtualisierung finden Sie unter Emerging Technologies, Red Hat.com.

12.5.1. Virtualisierte Netzwerkschnittstellen

Führen Sie folgende Schritte aus, um zusätzliche Netzwerkgeräte für Ihren Gast zu konfigurieren.
Bearbeiten Sie Ihre Gastkonfigurationsdatei in /etc/xen/YourGuestName und ersetzen YourGuestName durch den Namen Ihres Gasts.
Der ursprüngliche Eintrag sieht etwa wie folgt aus.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0" ]
Fügen Sie einen zusätzlichen Eintrag in den “vif=”-Bereich der Konfigurationsdatei ein, etwa wie der Eintrag unten.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0",
    "mac=00:16:3e:2f:d5:a9,bridge=xenbr0" ]
Stellen Sie sicher, dass Sie eine eindeutige MAC-Adresse für Ihre neue Schnittstelle generieren. Sie können dazu den folgenden Befehl verwenden.
# echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
Nachdem der Gast neu gestartet wurde, führen Sie bitte folgenden Schritt im Gastbetriebssystem aus. Überprüfen Sie, ob die Aktualisierung in Ihre /etc/modules.conf in Red Hat Enterprise Linux 3 oder /etc/modprobe.conf in Red Hat Enterprise Linux 4 oder Red Hat Enterprise Linux 5 hinzugefügt wurde. Fügen Sie ein Alias für jede neue Schnittstelle hinzu.
alias eth1 xen-vnif
Testen Sie nun, ob jede der neu hinzugefügten Schnittstellen innerhalb des Gasts erreichbar ist.
# ifconfig eth1
Der obige Befehl sollte die Eigenschaften von eth1 anzeigen. Wiederholen Sie diesen Befehl für eth2, falls Sie eine dritte Schnittstelle hinzugefügt haben, und so weiter.
Konfigurieren Sie nun die neuen Schnittstellen mittels redhat-config-network für Red Hat Enterprise Linux 3 oder mittels system-config-network für Red Hat Enterprise Linux 4 und Red Hat Enterprise Linux 5.

12.5.2. Virtuelle Speichergeräte

Führen Sie folgende Schritte aus, um zusätzliche virtuelle Speichergeräte für Ihren Gast hinzuzufügen.
Bearbeiten Sie Ihre Gastkonfigurationsdatei in /etc/xen/YourGuestName und ersetzen YourGuestName durch den Namen Ihres Gasts. Der ursprüngliche Eintrag sieht etwa wie folgt aus.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w"]
Fügen Sie nun einen zusätzlichen Eintrag für Ihr neues physisches Gerät, LUN, Partition oder Datenträger zum “disk=”-Parameter der Konfigurationsdatei hinzu. Speichereinheiten, die den paravirtualisierten Treiber verwenden, sehen etwa wie der Eintrag unten aus. Der “tap:aio”-Parameter weist den Hypervisor an, den paravirtualisierten Treiber zu verwenden.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w" ]
Falls Sie mehr Einträge hinzufügen möchten, fügen Sie diese einfach als kommagetrennte Liste im “disk=”-Bereich ein.

Anmerkung

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" ]
Überprüfen Sie, ob die Partitionen erzeugt wurden und erreichbar sind.
# 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
In der obigen Ausgabe können Sie sehen, dass die Partition oder das Gerät “xvdb” für das System verfügbar ist.
Hängen Sie die neuen Geräte und Platten an lokalen Einhängepunkten ein und aktualisieren Sie /etc/fstab innerhalb des Gasts, um die Geräte und Partitionen zum Zeitpunkt des Hochfahrens einzuhängen.
# 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

Kapitel 13. KVM paravirtualisierte Treiber

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.
Paravirtualisierte Treiber verbessern die Leistung von voll virtualisierten Gästen. Mit paravirtualisierten Treibern verringert sich die Latenz bei I/O-Vorgängen des Gasts, und der Datendurchsatz wird erhöht auf nahezu dasselbe Niveau wie bei Bare-Metal-Implementierungen. Die Verwendung von paravirtualisierten Treibern wird empfohlen für voll virtualisierte Gäste, auf denen I/O-intensive Aufgaben und Anwendungen ausgeführt werden.
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.

Anmerkung

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.
Die folgenden Microsoft Windows Versionen besitzen unterstützte KVM paravirtualisierte Treiber:
  • 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 der KVM Windows paravirtualisierten Treiber

Dieser Abschnitt erläutert den Installationsvorgang für die KVM Windows paravirtualisierten Treiber. Die KVM paravirtualisierten Treiber können während der Windows-Installation geladen werden oder nach abgeschlossener Installation des Gasts installiert werden.
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. Herunterladen der Treiber

    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.
    Das virtio-win-Paket installiert ein CD-ROM-Image namens virtio-win.iso im /usr/share/virtio-win/-Verzeichnis.
  2. Installation der paravirtualisierten Treiber

    Es wird empfohlen, die Treiber auf dem Gast zu installieren, bevor Sie ein Gerät, welches die paravirtualisierten Treiber verwenden soll, verknüpfen bzw. modifizieren.
    Für Blockgeräte, auf denen Root-Dateisysteme gespeichert sind sowie für andere zum Booten des Gasts nötige Blockgeräte müssen die Treiber installiert sein, ehe das Gerät modifiziert wird. Sollten die Treiber nicht auf dem Gast installiert sein, und der Treiber wird auf den virtio-Treiber eingestellt, kann der Gast nicht starten.
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 Prozedur 13.1, „Verwenden von virt-manager zum Einhängen eines CD-ROM-Images für einen Windows-Gast“ to add a CD-ROM image with virt-manager and then install the drivers.
Prozedur 13.1. Verwenden von virt-manager zum Einhängen eines CD-ROM-Images für einen Windows-Gast
  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.
    Falls die Treiber auf einer physischen CD-ROM vorliegen, wählen Sie die Option Normale Plattenpartition.
    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 Prozedur 13.2, „Windows installation“.
Prozedur 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 (Abschnitt 13.3, „Verwenden der KVM paravirtualisierten Treiber für vorhandene Geräte“) or install a new device which uses the para-virtualized drivers (Abschnitt 13.4, „Verwenden von KVM paravirtualisierten Treibern für neue Geräte“).

13.2. Installing drivers with a virtualized floppy disk

Diese Anleitung zeigt die Installation der paravirtualisierten Treiber während einer Windows-Installation.
  • Verbinden Sie bei der ersten Installation der Windows-VM mit Hilfe des "run-once"-Menüs viostor.vfd als Floppy.
    1. Windows Server 2003

      Wenn Windows Sie dazu auffordert, für Treiber von Drittanbietern F6 zu drücken, tun Sie dies und folgen den Anweisungen auf dem Bildschirm.
    2. Windows Server 2008

      Wenn das Installationsprogramm nach den Treibern verlangt, klicken Sie auf Treiber laden, weisen auf Laufwerk A: und wählen den Treiber aus, der dem Betriebssystem und der Architektur Ihres Gasts entspricht.

13.3. Verwenden der KVM paravirtualisierten Treiber für vorhandene Geräte

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 Abschnitt 13.4, „Verwenden von KVM paravirtualisierten Treibern für neue Geräte“.
  1. Unten sehen Sie ein dateibasiertes Blockgerät, das den virtualisierten IDE-Treiber verwendet. Dies ist ein typischer Eintrag für einen virtualisierten Gast, der keine paravirtualisierten Treiber verwendet.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='ide'/>
    </disk>
    
  2. Um das paravirtualisierte Gerät zu verwenden, ändern Sie den Eintrag bus= auf virtio.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='virtio'/>
    </disk>
    

13.4. Verwenden von KVM paravirtualisierten Treibern für neue Geräte

Diese Anleitung zeigt die Erstellung neuer Geräte zur Verwendung der KVM paravirtualisierten Treiber mittels virt-manager.
Alternativ können Sie auch die Befehle virsh attach-disk oder virsh attach-interface nutzen, um Geräte zu verknüpfen, die die paravirtualisierten Treiber verwenden.

Installieren Sie die Treiber zuerst

Vergewissern Sie sich, dass die Treiber auf dem Windows-Gast installiert wurden, ehe Sie damit beginnen, neue Geräte zu installieren. Falls die Treiber nicht bereitstehen, kann das Gerät nicht erkannt werden und wird nicht funktionieren.
  1. Öffnen Sie den virtualisierten Gast, indem Sie in virt-manager auf den Namen des Gasts doppelklicken.
  2. Öffnen Sie den Hardware-Reiter.
  3. Klicken Sie auf die Schaltfläche Hardware hinzufügen.
  4. Wählen Sie unter dem Reiter "Hinzufügen virtueller Hardware" Speicher oder Netzwerk für den Gerätetyp.
    1. New disk devices
      Wählen Sie das Speichergerät oder dateibasierte Image. Wählen Sie Virtio-Disk als Gerätetyp und klicken auf Weiter.
    2. New network devices
      Wählen Sie Virtuelles Netzwerk oder Gemeinsam verwendetes physisches Gerät. Wählen Sie Virtio als Gerätetyp und klicken auf Weiter.
  5. Klicken Sie auf Abschließen, um das Gerät zu speichern.
  6. Starten Sie den Gast neu. Das Gerät wird unter Umständen nicht erkannt, ehe der Windows-Gast nicht neu gestartet wird.

Kapitel 14. PCI passthrough

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

Wichtig

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.

Warnung

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.
Prozedur 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:

Kapitel 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
Prozedur 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 Prozedur 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)
    

    Anmerkung

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

Kapitel 16. Zeitverwaltung bei KVM-Gästen

Virtualisierung bringt hinsichtlich der Zeitmessung bei Gästen verschiedene Herausforderungen mit sich. Gäste, die den Time Stamp Counter (TSC) als Zeitquelle verwenden, können ggf. Schwierigkeiten bekommen, denn einige CPUs besitzen keinen Time Stamp Counter. Gäste ohne genaue Zeitmessung haben unter Umständen Probleme mit bestimmten Netzwerkanwendungen und Prozessen, denn diese Gäste laufen schneller oder langsamer als die tatsächliche Zeit und können somit die Synchronität nicht aufrecht erhalten.
KVM vermeidet dieses Problem, indem es Gästen eine paravirtualisierte Uhr zur Verfügung stellt. Alternativ können einige Gäste in zukünftigen Versionen dieser Betriebssysteme andere x86-Zeitquellen für die Zeitmessung nutzen.
Derzeit wird die paravirtualisierte Uhr nur von Red Hat Enterprise Linux 5.4 und neueren Gästen vollständig unterstützt.
Mehrere Probleme können auftreten bei Gästen mit ungenauer Zeitmessung:
  • Systemuhren sind ggf. nicht mehr synchron mit der tatsächlichen Zeit, was Sitzungen ungültig macht und Auswirkungen auf Netzwerke hat.
  • Gäste mit langsameren Systemuhren haben ggf. Probleme mit der Migration.
Diese Probleme existieren ebenso auf anderen Virtualisierungsplattformen; die Zeitmessung sollte daher immer überprüft werden.

NTP

Der Network Time Protocol (NTP) Daemon sollte sowohl auf dem Host als auch auf dem Gast laufen. Aktivieren Sie den ntpd-Dienst wie folgt:
# service ntpd start
Fügen Sie den ntpd-Dienst zur standardmäßigen Startup-Sequenz hinzu:
# chkconfig ntpd on
Die Verwendung des ntpd-Dienstes sollte die Folgen der Zeitabweichung in jedem Fall minimieren.
Feststellen, ob Ihre CPU über den konstanten Time Stamp Counter verfügt
Ihre CPU verfügt über den konstanten Time Stamp Counter, wenn das constant_tsc-Flag vorhanden ist. Um festzustellen, ob Ihre CPU das constant_tsc-Flag gesetzt hat, führen Sie den folgenden Befehl aus:
$ cat /proc/cpuinfo | grep constant_tsc
Wenn Sie eine Ausgabe erhalten, verfügt Ihre CPU über das constant_tsc-Bit. Falls keinerlei Ausgabe erfolgt, folgen Sie den unten stehenden Anweisungen.
Konfiguration von Hosts ohne konstanten Time Stamp Counter
Systeme ohne konstanten Time Stamp Counter erfordern zusätzliche Konfiguration. Funktionen der Energieverwaltung behindern die genaue Zeitmessung und müssen deaktiviert werden, damit Gäste mit KVM die genaue Zeit messen können.

Anmerkung

Diese Anweisungen gelten ausschließlich für AMD Revision F CPUs.
Falls die CPU nicht über das constant_tsc-Bit verfügt, deaktivieren Sie sämtliche Funktionen zur Energieverwaltung (BZ#513138). Jedes System hat mehrere Timer, die es zur Zeitmessung verwendet. Der TSC ist nicht stabil auf dem Host, was manchmal durch Änderungen an cpufreq verursacht wird, durch tiefen C-Status oder durch Migration auf einen Host mit einem schnelleren TSC. Ein tiefer C-Ruhestatus kann den TSC anhalten. Um zu verhindern, dass der Kernel tiefe C-Stati verwendet, fügen Sie auf dem Host "processor.max_cstate=1" zu den Boot-Optionen des Kernels in Grub hinzu:
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
Deaktivieren Sie cpufreq (nur nötig auf Hosts ohne constant_tsc), indem Sie die Konfigurationsdatei /etc/sysconfig/cpuspeed bearbeiten und die Variablen MIN_SPEED und MAX_SPEED auf die höchstmögliche Frequenz ändern. Zulässige Höchstgrenzen finden Sie in den /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies-Dateien.
Verwendung der paravirtualisierten Systemuhr mit Red Hat Enterprise Linux Gästen
Für bestimmte Red Hat Enterprise Linux Gäste sind zusätzliche Kernel-Parameter erforderlich. Diese Parameter können gesetzt werden, indem Sie an das Ende der /kernel-Zeile in der /boot/grub/grub.conf-Datei des Gasts angehängt werden.
Die Tabelle unten zeigt Red Hat Enterprise Linux Versionen und deren erforderliche Parameter für Gäste ohne konstanten Time Stamp Counter.
Red Hat Enterprise LinuxZusätzliche Kernel-Parameter für den Gast
5.4 AMD64/Intel 64 mit der paravirtualisierten UhrZusätzliche Parameter nicht notwendig
5.4 AMD64/Intel 64 ohne die paravirtualisierte Uhrdivider=10 notsc lpj=n
5.4 x86 mit der paravirtualisierten UhrZusätzliche Parameter nicht notwendig
5.4 x86 ohne die paravirtualisierte Uhrdivider=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 64Zusätzliche Parameter nicht notwendig
3.9 x86Zusätzliche Parameter nicht notwendig
Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
Windows verwendet sowohl die Echtzeituhr (engl. Real Time Clock, RTC) als auch den Time Stamp Counter (TSC). Für Windows-Gäste kann die Echtzeituhr anstelle des TSC für alle Zeitquellen verwendet werden, was die Probleme der Zeitmessung beim Gast löst.
Um die Echtzeituhr für die PMTIMER-Zeitquelle zu aktivieren (der PMTIMER verwendet normalerweise den TSC), fügen Sie folgende Zeile zu den Windows-Boot-Einstellungen hinzu. Die Windows-Boot-Einstellungen befinden sich in der boot.ini-Datei. Fügen Sie die folgende Zeile zur boot.ini-Datei hinzu:
/use pmtimer
Weitere Information über die Windows-Boot-Einstellungen und die pmtimer-Option finden Sie unter Verfügbare Befehlszeilenoptionen für die Boot.ini-Dateien von Windows XP und Windows Server 2003.
Using the Real-Time Clock with Windows Vista, Windows Server 2008 and Windows 7 guests
Windows verwendet sowohl die Echtzeituhr (engl. Real Time Clock, RTC) als auch den Time Stamp Counter (TSC). Für Windows-Gäste kann die Echtzeituhr anstelle des TSC für alle Zeitquellen verwendet werden, was die Probleme der Zeitmessung beim Gast löst.
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.

Teil IV. Verwaltung

Kapitel 17. Beste Verfahren für Server

Die folgenden Tipps und Tricks können Ihnen dabei helfen, die Zuverlässigkeit Ihres Red Hat Enterprise Linux 5 Server Hosts (dom0) zu gewährleisten.
  • Betreiben Sie SELinux im Enforcing-Modus. Sie können dies einstellen mit Hilfe des folgenden Befehls.
    # setenforce 1
    
  • Löschen oder deaktivieren Sie jeden unnötigen Dienst, wie z. B. AutoFS, NFS, FTP, HTTP, NIS, telnetd, sendmail und so weiter.
  • Fügen Sie nur die minimale Anzahl von Benutzerkonten, die zur Verwaltung der Plattform auf dem Server benötigt werden, hinzu und löschen Sie unnötige Benutzerkonten.
  • Vermeiden Sie, dass unnötige Applikationen auf Ihrem Host laufen. Das Ausführen von Applikationen auf dem Host kann Auswirkungen auf die Leistung Ihrer virtuellen Maschine haben und die Stabilität ihres Servers gefährden. Jede Applikation, die evtl. den Server zum Absturz bringen kann, würde infolgedessen auch alle virtuellen Maschinen auf dem Server zum Absturz bringen.
  • Verwenden Sie einen zentralen Speicherort für Installationen und Images virtueller Maschinen. Images virtueller Maschinen sollten unter /var/lib/libvirt/images/ gespeichert werden. Falls Sie ein anderes Verzeichnis für Ihre Images virtueller Maschinen verwenden, stellen Sie sicher, dass Sie dieses Verzeichnis zu Ihrer SELinux-Richtlinie hinzufügen und vor Start der Installation neu kennzeichnen.
  • Installationsquellen, -bäume und -Images sollten an einem zentralen Ort gespeichert werden, normalerweise der Ort Ihres vsftpd-Servers.

Kapitel 18. Sicherheit für Virtualisierung

Beim Einsatz der Virtualisierungstechnologie innerhalb der Infrastruktur Ihres Unternehmens müssen Sie sicherstellen, dass der Host nicht kompromittiert werden kann. Der Host im Xen-Hypervisor ist die privilegierte Domain, die die Systemverwaltung übernimmt und sämtliche virtuellen Maschinen verwaltet. Falls der Host unsicher ist, sind alle anderen Domains im System angreifbar. Es gibt verschiedene Möglichkeiten zur Verbesserung der Sicherheit auf Systemen mit Virtualisierung. Sie bzw. Ihre Organisation sollte einen Einsatzplan entwickeln, welcher nicht nur Funktionsspezifikationen enthält, sondern auch Dienste spezifiziert, die auf Ihren virtualisierten Gästen und Host-Servern laufen sollen, sowie die nötige Unterstützung für diese Dienste spezifiziert. Nachfolgend sind einige Themen im Zusammenhang mit der Sicherheit aufgeführt, die bei der Entwicklung eines Einsatzplans beachtet werden sollten:
  • Führen Sie auf den Hosts nur absolut notwendige Dienste aus. Je weniger Dienste und Prozesse auf dem Host laufen, desto höher ist das Maß an Sicherheits und die Leistung.
  • Enable Security-Enhanced Linux (SELinux) on the hypervisor. Read Abschnitt 18.2, „SELinux und Virtualisierung“ for more information on using SELinux and virtualization.
  • Verwenden Sie eine Firewall, um den Datenverkehr zu dom0 einzuschränken. Sie können eine Firewall mit "default-reject"-Regeln einrichten, die dom0 gegen Attacken absichern. Weiterhin ist es wichtig, Dienste mit Netzwerkverbindung zu begrenzen.
  • Erlauben Sie normalen Benutzern den Zugriff auf dom0 nicht. Wenn Sie normalen Benutzern den Zugriff auf dom0 gestatten, laufen Sie Gefahr, dom0 angreifbar zu machen. Denken Sie daran, dass dom0 privilegiert ist, das Einrichten von unprivilegierten Benutzerkonten kann daher das hohe Maß an Sicherheit gefährden.

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 und Virtualisierung

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.
Hinzufügen von LVM-basiertem Speicher mit SELinux im Enforcing-Modus
Der folgende Abschnitt liefert ein Beispiel für das Hinzufügen eines logischen Datenträgers zu einem virtualisierten Gast bei aktiviertem SELinux. Diese Anleitung lässt sich auch auf Festplattenpartitionen übertragen.
Prozedur 18.1. Erstellen und Einhängen eines logischen Datenträgers auf einem virtualisierten Gast mit aktiviertem SELinux
  1. Legen Sie einen logischen Datenträger an. Dieses Beispiel erstellt einen 5 GB großen logischen Datenträger namens NewVolumeName auf der Datenträgergruppe namens volumegroup.
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. Formatieren Sie den logischen Datenträger NewVolumeName mit einem Dateisystem, das erweiterte Attribute unterstützt, wie z. B. ext3.
    # mke2fs -j /dev/volumegroup/NewVolumeName
    
  3. Erzeugen Sie ein neues Verzeichnis, um den neuen logischen Datenträger einzuhängen. Dieses Verzeichnis kann sich überall auf dem Dateisystem befinden, es wird jedoch empfohlen, es weder in einem der wichtigen Systemverzeichnisse zu erstellen (/etc, /var, /sys) noch in Benutzerverzeichnissen (/home oder /root). Dieses Beispiel verwendet ein Verzeichnis namens /virtstorage.
    # mkdir /virtstorage
    
  4. Hängen Sie den logischen Datenträger ein.
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the correct SELinux type for a Xen folder.
    semanage fcontext -a -t xen_image_t "/virtstorage(/.*)?"
    
    Oder stellen Sie den richtigen SELinux-Typ für ein KVM-Verzeichnis ein.
    semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    
    Falls die Targeted-Richtlinie verwendet wird (das ist der Standard), fügt der Befehl eine Zeile zur /etc/selinux/targeted/contexts/files/file_contexts.local-Datei hinzu, wodurch diese Änderung persistent gemacht wird. Die angefügte Zeile sieht etwa wie folgt aus:
    /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

Dieser Abschnitt enthält Aspekte, die Sie beachten müssen, wenn Sie SELinux in Ihrer Virtualisierungsumgebung einsetzen. Wenn Sie Veränderungen im System durchführen oder Geräte hinzufügen, müssen Sie Ihre SELinux-Richtlinie entsprechend anpassen. Um einen LVM-Datenträger für einen Gast zu konfigurieren, müssen Sie den SELinux-Kontext für das entsprechende zu Grunde liegende Blockgerät und die Datenträgergruppe anpassen.
# semanage fcontext -a -t xen_image_t -f -b /dev/sda2
# restorecon /dev/sda2
Der Boolesche Parameter xend_disable_t versetzt xend nach einem Neustart des Daemons in einen unbeschränkten Modus. Es ist besser, den Schutz für einen einzelnen Daemon zu deaktivieren, als für das gesamte System. Es wird empfohlen, dass Sie Verzeichnisse, die Sie an anderer Stelle verwenden werden, nicht als xen_image_t umkennzeichnen.
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.

Anmerkung

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.

Kapitel 19. Gästeverwaltung mit Hilfe von xend

Der xend-Daemon führt gewisse Systemverwaltungsfunktionen durch, die im Zusammenhang mit virtuellen Maschinen stehen. Dieser Daemon kontrolliert die virtualisierten Ressourcen, demnach muss xend laufen, um mit den virtuellen Maschinen interagieren zu können. Bevor Sie xend starten, müssen Sie die Betriebsparameter angeben, indem Sie die xend-Konfigurationsdatei xend-config.sxp, die sich im Verzeichnis etc/xen befindet, bearbeiten. Nachfolgend finden Sie die Parameter, die Sie in der Konfigurationsdatei xend-config.sxp aktivieren oder deaktivieren können:
Tabelle 19.1. xend-Konfigurationsparameter
Element Beschreibung
(console-limit)
Determines the console server's memory buffer limit and assigns that limit on a per domain basis.
(min-mem)
Bestimmt die minimale Anzahl an Megabytes, die für domain0 reserviert werden (wenn Sie 0 eingeben, ändert sich der Wert nicht).
(dom0-cpus)
Bestimmt die Zahl der von domain0 verwendeten CPUs (mindestens 1 CPU wird standardmäßig zugewiesen).
(enable-dump)
Falls aktiviert, erstellt Xen im Falle eines Absturzes eine Speicherauszugsdatei (standardmäßig 0).
(external-migration-tool)
Bestimmt das Skript oder die Anwendung, das/die eine externe Gerätemigration handhabt. Die Skripte müssen sich im /etc/xen/scripts/external-device-migrate-Verzeichnis befinden.
(logfile)
Bestimmt den Ort der Protokolldatei (standardmäßig /var/log/xend.log).
(loglevel)
Filtert die Werte des Protokollmodus aus: DEBUG, INFO, WARNING, ERROR oder CRITICAL (standardmäßig DEBUG).
(network-script)
Bestimmt das Skript, welches die Netzwerkumgebung aktiviert. Die Skripte müssen sich im etc/xen/scripts -Verzeichnis befinden.
(xend-http-server)
Aktiviert den HTTP-Stream Paket-Management-Server (standardmäßig "no").
(xend-unix-server)
Aktiviert den UNIX Domain-Socket-Server. Der Socket-Server ist ein Kommunikationsendpunkt, der Lowlevel-Netzwerkverbindungen handhabt und einkommende Verbindungen akzeptiert oder abweist. Der Standardwert ist auf "yes" eingestellt.
(xend-relocation-server)
Aktiviert den Migrations-Server für maschinenübergreifende Migrationen (standardmäßig "no").
(xend-unix-path)
Bestimmt den Ort, an dem der Befehl xend-unix-server Daten ausgibt (standardmäßig var/lib/xend/xend-socket)
(xend-port)
Bestimmt den Port, den der HTTP-Management-Server verwendet (standardmäßig 8000).
(xend-relocation-port)
Bestimmt den Port, den der Migrations-Server verwendet (standardmäßig 8002).
(xend-relocation-address)
Bestimmt die Host-Adressen, die zur Migration zugelassen sind. Der Standardwert ist der Wert der xend-address.
(xend-address)
Bestimmt die Adresse, mit der sich der Domain-Socket-Server verbindet. Der standardmäßige Wert erlaubt alle Verbindungen.

Nach dem Einrichten dieser Betriebsparameter sollten Sie überprüfen, dass xend läuft. Sollte dies nicht der Fall sein, initialisieren Sie den Daemon. Sie können den xend-Daemon am Kommandozeilenprompt starten, indem Sie Folgendes eingeben:
service xend start
Sie können xend auch dazu verwenden, den Daemon zu stoppen:
service xend stop
Dies beendet das Ausführen des Daemon.
Sie können mit xend den Daemon erneut starten:
service xend restart
Der Daemon startet erneut.
Und Sie können den Status des xend-Daemon überprüfen.
service xend status
The output displays the daemon's status.

xend zur Boot-Zeit aktivieren

Verwenden Sie den Befehl chkconfig, um xend in das initscript einzufügen.
chkconfig --level 345 xend
xend wird nun in den Runlevels 3,4 und 5 starten.

Kapitel 20. Xen Live-Migration

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.
  • Offline-Migration hält den virtualisierten Gast auf dem Quell-Host an, überträgt den Gast zum Ziel-Host und startet ihn wieder, sobald dieser vollständig übertragen wurde. Offline-Migration nutzt den virsh migrate-Befehl.
    # 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.
    Live-Migration nutzt die --live-Option für den virsh migrate-Befehl.
    # virsh migrate--live GuestName libvirtURI

Anmerkung zur Itanium®-Unterstützung

Migration wird derzeit für die Itanium®-Architektur nicht unterstützt.
Um Migration mit Xen zu aktivieren, müssen einige Änderungen an der Konfigurationsdatei /etc/xen/xend-config.sxp vorgenommen werden. Migration ist standardmäßig deaktiviert, da es – wenn nicht korrekt konfiguriert – ein mögliches Sicherheitsrisiko darstellen kann. Das Öffnen eines Migrations-Ports ermöglicht es einem unautorisierter Host, eine Migration einzuleiten oder sich mit den Migrations-Ports zu verbinden. Authentifizierung und Autorisierung sind für Migrationsanfragen nicht konfiguriert, daher basiert die einzige Kontrollmöglichkeit auf Host-Namen und IP-Adressen. Es sollte besonders darauf geachtet werden, dass der Migrations-Port nicht für unautorisierte Host zugänglich ist.

Sicherheit der Virtualisierungsmigration

Filter für IP-Adressen und Host-Namen bieten nur minimale Sicherheit. Beide dieser Attribute können gefälscht werden, falls der Angreifer die Adresse oder den Host-Namen des Migrations-Clients kennt. Die beste Methode zur Absicherung der Migration besteht darin, das Netzwerk von externen und unautorisierten internen Verbindungen zu isolieren.
Aktivieren der Migration
Modifizieren Sie die folgenden Einträge in /etc/xen/xend-config.sxp, um die Migration zu aktivieren. Ändern Sie wo nötig die Werte und entfernen Sie die Kommentierung (das #-Symbol) vor den folgenden Paramentern:
(xend-relocation-server yes)
Der Standardwert, der die Migration deaktiviert, lautet no. Ändern Sie den Wert von xend-relocation-server auf yes, um die Migration zu ermöglichen.
(xend-relocation-port 8002)
Der Parameter (xend-relocation-port) spezifiziert den Port, den xend für die Migrationsschnittstelle verwenden soll, falls xend-relocation-server auf yes gesetzt ist.
Der Standardwert dieser Variablen dürfte für die meisten Installationen funktionieren. Falls Sie den Wert verändern, stellen Sie sicher, dass Sie einen unbenutzten Port auf dem Migrations-Server verwenden.
Der Port, der durch den xend-relocation-port-Parameter gesetzt wird, muss auf beiden Systemen offen sein.
(xend-relocation-address '')
(xend-relocation-address) ist die Adresse, auf die xend auf Migrationsbefehle auf der relocation-socket-Verbindung horcht, falls xend-relocation-server gesetzt ist.
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.
Falls der Wert leer ist, wie im Beispiel oben ein leerer String in einfachen Anführungszeichen, dann sind alle Verbindungen erlaubt. Es wird angenommen, dass Verbindungen auf einem Port und einer Schnittstelle eingehen, auf die der Migrations-Server horcht; siehe auch xend-relocation-port und xend-relocation-address.
Andernfalls sollte der Parameter (xend-relocation-hosts-allow) eine Sequenz regulärer Ausdrücke sein, die durch Leerzeichen voneinander getrennt sind. Jeder Host mit einem vollqualifizierten Domain-Namen oder IP-Adresse, der/die mit diesen regulären Ausdrücken übereinstimmt, wird akzeptiert.
Ein Beispiel für ein (xend-relocation-hosts-allow)-Attribut:
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Nachdem Sie die Parameter in Ihrer Konfigurationsdatei konfiguriert haben, starten Sie den Xen-Dienst neu.
# service xend restart

20.1. Beispiel für eine Live-Migration

Nachfolgend sehen Sie ein Beispiel für die Erstellung einer einfachen Umgebung für Live-Migration. Diese Konfiguration verwendet NFS für den gemeinsam verwendeten Speicher. NFS ist ausreichend für Demo-Umgebungen, für eine Produktionsumgebung wird hingegen eine robustere Konfiguration für gemeinsam verwendeten Speicher empfohlen wie z. B. mittels Fibre Channel oder iSCSI und GFS.
Die Konfiguration unten besteht aus zwei Servern (et-virt07 und et-virt08), beide verwenden eth1 als standardmäßige Netzwerkschnittstelle und verwenden demzufolge xenbr1 als ihre Xen-Netzwerk-Bridge. Wir verwenden eine lokal angeschlossene SCSI-Platte (/dev/sdb) auf et-virt07 für den gemeinsam verwendeten Speicher unter Verwendung von NFS.
Setup für Live-Migration
Erstellen Sie das Verzeichnis, das für die Migration verwendet wird, und hängen es ein:
# mkdir /var/lib/libvirt/images
# mount /dev/sdb /var/lib/libvirt/images

Wichtig

Stellen Sie sicher, dass das Verzeichnis mit den korrekten Optionen exportiert ist. Falls Sie das standardmäßige Verzeichnis /var/lib/libvirt/images/ exportieren, vergewissern Sie sich, dass Sie nur das /var/lib/xen/images/ und nicht das /var/lib/xen/-Verzeichnis exportieren, da dies Verzeichnis vom xend-Daemon und anderen Xen-Komponenten verwendet wird. Die Freigabe von /var/lib/xen/ würde zu unvorhersehbarem Verhalten führen.
# cat /etc/exports
/var/lib/libvirt/images  *(rw,async,no_root_squash)
Versichern Sie sich, dass es via NFS exportiert ist:
# showmount -e et-virt07
Export list for et-virt07:
/var/lib/libvirt/images *
Installation des Gasts
Sehen Sie nachfolgend den Installationsbefehl, der in diesem Beispiel zur Installation des Gasts verwendet wird:
# 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 Kapitel 8, Installationsverfahren für Gastbetriebssysteme.
Überprüfen der Umgebung für die Migration
Vergewissern Sie sich, dass die virtualisierten Netzwerk-Briges korrekt konfiguriert sind und auf beiden Hosts denselben Namen tragen:
[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
Überprüfen Sie, dass die Migrationsparameter auf beiden Hosts konfiguriert wurden:
[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 '')
Vergewissern Sie sich, dass der Migrations-Server gestartet ist und auf den dezidierten Port für Xen-Migrationen (8002) horcht:
[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
Überprüfen der Speicherung und Wiederherstellung des Gasts
Starten Sie die virtuelle Maschine (falls diese nicht bereits läuft):
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
[et-virt07 ~]# virsh start testvm1
Domain testvm1 started
Überprüfen Sie, dass die virtuelle Maschine läuft:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Speichern Sie die virtuelle Maschine auf dem lokalen Host:
[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
Stellen Sie die virtuelle Maschiene auf dem lokalen Host wieder her:
[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
Testen des Fortschritts und Initialisieren der Live-Migration
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
Denken Sie daran, dass dieses Skript nur für Testzwecke gedacht ist und für eine Live-Migration in einer Produktionsumgebung unnötig ist.
Überprüfen Sie, dass die virtuelle Maschine auf et-virt08 läuft, bevor Sie diese auf et-virt07 zu migrieren versuchen:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Initiieren Sie eine Live-Migration nach et-virt07. Sie können den time-Befehl hinzufügen, um zu sehen, wie lange die Migration dauert:
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Führen Sie das Skript innerhalb des Gasts aus:
# ./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
Überprüfen Sie, dass die virtuelle Maschine auf et-virt08 heruntergefahren wurde:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Überprüfen Sie, dass die virtuelle Maschine auf et-virt07 hochgefahren wurde:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Starten Sie einen weiteren Durchlauf für die Migration von et-virt07 nach et-virt08. Initiieren Sie die Migration von et-virt07 nach et-virt08:
[et-virt07 images]# xm migrate --live testvm1 et-virt08
Überprüfen Sie, dass die virtuelle Maschine heruntergefahren wurden:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Bevor Sie die Migration einleiten, starten Sie das einfache Skript im Gast. Beachten Sie dabei die Veränderung der Zeit, während der Gast migriert wird:
# ./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
Nachdem der Migrationsbefehl auf et-virt07 abgeschlossen ist, überprüfen Sie auf et-virt08, dass die virtuelle Maschine gestartet wurde:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
und starten Sie einen weiteren Durchlauf:
[et-virt08 ~]# time virsh migrate --live testvm1 et-virt07
real    0m10.378s
user    0m0.068s
sys     0m0.052s
Sie haben jetzt erfolgreich einen Test für eine Offline- und eine Live-Migaration durchgeführt.

20.2. Konfiguration der Live-Migration eines Gasts

Dieser Abschnitt beschreibt die Offline-Migration von Xen-Gästen zu anderen Servern, auf denen Red Hat Enterprise Linux läuft. Weiterhin wird eine Migration mit Hilfe der Offline-Methode durchgeführt (unter Verwendung des Befehls xm migrate). Eine Live-Migration kann mit demselben Befehl durchgeführt werden. Allerdings gibt es ein paar Änderungen, die Sie zusätzlich an der xend-config-Konfigurationsdatei durchführen müssen. Das nachfolgende Beispiel zeigt die Einträge auf, die Sie ändern müssen, um eine erfolgreiche Migration zu gewährleisten:
(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)
Dieser Parameter legt den Port fest, den xend für die Migration verwendet. Verwenden Sie den voreingestellten Wert, sofern nicht Ihre Netzwerkumgebung einen benutzerdefinierten Wert erfordert. Entfernen Sie die Kommentierung, um den Eintrag zu aktivieren.
(xend-relocation-address )
Dieser Parameter bezeichnet die Adresse, die auf Migrations-Socket-Verbindungen horcht, nachdem Sie xend-relocation-server aktiviert haben. Der Xen-Hypervisor horcht nur auf der angegebenen Schnittstelle auf Netzwerkverkehr zur Migration.
(xend-relocation-hosts-allow )
Dieser Parameter steuert den Host, der mit dem Migrations-Port kommuniziert. Falls der Wert leer ist, sind alle eingehenden Verbindungen erlaubt. Sie müssen dies umändern in eine Sequenz regulärer Ausdrücke, durch Leerzeichen voneinander getrennt, zum Beispiel:
(xend-relocation-hosts-allow- '^localhost\\.localdomain$' )>
Akzeptierte Werte sind u. a. vollqualifizierte Domain-Namen, IP-Adressen oder reguläre Ausdrücke, mit Leerzeichen voneinander getrennt.
Starten Sie nach abgeschlossener Konfiguration den Host neu, damit die neuen Einstellungen geladen werden.

Kapitel 21. KVM Live-Migration

Dieses Kapitel behandelt die Migration von Gästen auf einem KVM-Hypervisor zu einem anderen KVM-Host.
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:
  • Lastverteilung – Wenn ein Host überlastet ist, können Gäste auf Hosts mit geringerer Auslastung verlagert werden.
  • Hardware Failover – Wenn Hardware-Geräte auf dem Host ausfallen, können Gäste sicher verschoben werden, so dass der Host in der Zwischenzeit sicher abgeschaltet und repariert werden kann.
  • Energie sparen – In Zeiten mit geringer Auslastung können Gäste auf die Hosts umverteilt werden, so dass einige Host-Systeme abgeschaltet werden können, um Energie zu sparen.
  • Geografische Migration – Gäste können zugunsten geringerer Latenz oder in außergewöhnlichen Umständen an einen anderen Standort umziehen.
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.
Eine Offline-Migration hält zunächst den Gast an und verschiebt dann ein Image des Gastspeichers zum Ziel-Host. Der Gast wird auf dem Ziel-Host wieder gestartet, und der Speicher, den der Gast auf dem ursprünglichen Host belegt hatte, wird frei.
Die Zeit, die eine Offline-Migration dauert, hängt von der Netzwerkbandbreite und Latenz ab. Ein Gast mit 2 GB Speicher sollte über eine 1 Gbit Ethernet-Verbindung etwa zehn Sekunden brauchen.
Bei einer Live-Migration läuft der Gast auf dem Quell-Host weiter ohne anzuhalten, während der Speicher verschoben wird. Jegliche Änderungen an den Speicherseiten werden nachverfolgt und zum Ziel gesendet, nachdem das Image übertragen wurde. Der Speicher wird dann mit den modifizierten Speicherseiten aktualisiert. Dieser Prozess läuft so lange, bis die Zeit, die dem Gast zum Pausieren zugestanden wird, der Zeit entspricht, die voraussichtlich für die Übertragung der letzten Seiten benötigt wird. KVM schätzt die verbleibende Zeit und versucht, die höchstmögliche Anzahl an Seiten von der Quelle zum Ziel zu übertragen, bis für KVM absehbar ist, dass die verbleibenden Seiten während einer kurzen Zeitspanne, die die virtuelle Maschine pausiert, übertragen werden können. Die Register werden nun auf dem neuen Host geladen und der Gast wird schließlich auf dem Ziel-Host wieder gestartet. Falls der Gast auf diese Weise nicht übertragen werden kann (was bei extrem hoher Auslastung des Gasts vorkommen kann), so wird er angehalten und stattdessen eine Offline-Migration eingeleitet.
Die Zeit, die eine Offline-Migration dauert, hängt von der Netzwerkbandbreite und Latenz ab. Bei hoher Auslastung des Netzwerks oder bei geringer Bandbreite dauert die Migration deutlich länger.

21.1. Voraussetzungen der Live-Migration

Für die Migration von Gästen müssen die folgenden Voraussetzungen erfüllt sein:
Migrationsvoraussetzungen
  • Ein virtualisierter Gast, installiert auf gemeinsam verwendetem Netzwerkspeicher, unter Verwendung eines der folgenden Protokolle:
    • Fibre Channel
    • iSCSI
    • NFS
    • GFS2
  • Zwei oder mehr Red Hat Enterprise Linux Systeme derselben Version mit denselben Aktualisierungen.
  • Auf beiden Systeme müssen die entsprechenden Ports offen sein.
  • Beide Systeme müssen eine identische Netzwerkkonfiguration besitzen. Sämtliches Bridging und sämtliche Netzwerkkonfiguration muss auf beiden Hosts genau übereinstimmen.
  • Gemeinsam verwendeter Speicher muss auf dem Quell-Host und dem Ziel-Host an derselben Stelle eingehängt sein. Der Name des eingehängten Verzeichnisses muss identisch sein.
Konfiguration von Netzwerkspeicher
Configure shared storage and install a guest on the shared storage. For shared storage instructions, refer to Teil V, „Virtualization Storage Topics“.

21.2. Beispiel für gemeinsam genutzten Speicher: NFS für eine einfache Migration

Dieses Beispiel nutzt NFS, um Gast-Images mit anderen KVM-Hosts gemeinsam zu verwenden. Dieses Beispiel ist für größere Installationen weniger praktisch, es soll lediglich dazu dienen, Migrationstechniken und kleine Einsätze zu veranschaulichen. Verwenden Sie dieses Beispiel nicht zur Migration oder Ausführung von mehr als einer Handvoll virtualisierter Gäste.
For advanced and more robust shared storage instructions, refer to Teil V, „Virtualization Storage Topics“
  1. Exportieren Sie Ihr libvirt-Image-Verzeichnis

    Fügen Sie das standardmäßige Image-Verzeichnis zur /etc/exports-Datei hinzu:
    /var/lib/libvirt/images *.example.com(rw,no_root_squash,async)
    
    Passen Sie den Host-Parameter auf Ihre Umgebung an.
  2. Starten Sie NFS

    1. Installieren Sie die NFS-Pakete, falls diese noch nicht installiert sind:
      # yum install nfs
      
    2. Öffnen Sie in iptables die Ports für NFS und fügen NFS zur /etc/hosts.allow-Datei hinzu.
    3. Starten Sie den NFS-Dienst:
      # service nfs start
      
  3. Hängen Sie den gemeinsam verwendeten Speicher am Ziel ein

    Hängen Sie das /var/lib/libvirt/images-Verzeichnis auf dem Zielsystem ein:
    # mount sourceURL:/var/lib/libvirt/images /var/lib/libvirt/images
    

    Einhängepunkte müssen auf dem Quell- und Zielsystem identisch sein.

    Das für den Gast gewählte Verzeichnis muss auf dem Host und dem Gast exakt dasselbe sein. Dies gilt für alle Arten von gemeinsamem Speicher. Ist das Verzeichnis nicht identisch, schlägt die Migration fehl.

21.3. KVM Live-Migration mit virsh

Ein Gast kann mit Hilfe des virsh-Befehls auf einen anderen Host migriert werden. Der migrate-Befehl akzeptiert Parameter im folgenden Format:
# virsh migrate --live GuestName DestinationURL
Der Parameter GuestName steht für den Namen desjenigen Gasts, den Sie migrieren möchten.
Der Parameter DestinationURL ist die URL oder der Host-Name des Zielsystems. Auf dem Zielsystem muss dieselbe Version von Red Hat Enterprise Linux laufen, zudem muss derselbe Hypervisor verwendet werden und libvirt laufen.
Nachdem der Befehl eingegeben wurde, werden Sie nach dem Root-Passwort des Zielsystems gefragt.
Beispiel: Live-Migration mit virsh
Dieses Beispiel migriert von test1.example.com nach test2.example.com. Passen Sie die Host-Namen auf Ihre Umgebung an. Dieses Beispiel migriert eine virtuelle Maschine namens RHEL4test.
This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: Migrationsvoraussetzungen).
  1. Überprüfen Sie, dass der Gast läuft

    Überprüfen Sie vom Quellsystem test1.example.com aus, ob RHEL4test läuft:
    [root@test1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
  2. Migrieren Sie den Gast

    Führen Sie folgenden Befehl aus, um eine Live-Migration des Gasts zum Ziel test2.example.com durchzuführen. Fügen Sie /system an das Ende der Ziel-URL an, um libvirt mitzuteilen, dass Sie umfassenden Zugriff benötigen.
    # virsh migrate --live RHEL4test qemu+ssh://test2.example.com/system
    Nachdem der Befehl eingegeben wurde, werden Sie nach dem Root-Passwort des Zielsystems gefragt.
  3. Warten Sie

    Die Migration kann abhängig von der Größe und Auslastung des Gasts einige Zeit in Anspruch nehmen. virsh meldet nur Fehler. Der Gast wird solange weiterhin auf dem Quell-Host ausgeführt, bis er vollständig migriert ist.
  4. Überprüfen Sie, ob der Gast auf dem Ziel-Host angekommen ist

    Überprüfen Sie vom Zielsystem test2.example.com aus, ob RHEL4test läuft:
    [root@test2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
Die Live-Migration ist damit abgeschlossen.

Andere Netzwerkverfahren

libvirt supports a variety of networking methods including TLS/SSL, unix sockets, SSH, and unencrypted TCP. Refer to Kapitel 22, Remote-Verwaltung virtualisierter Gäste for more information on using other methods.

21.4. Migration mit virt-manager

Dieser Abschnitt behandelt die Migration von KVM-basierten Gästen mit virt-manager.
  1. Verbinden Sie die Quell- und Ziel-Hosts. Klicken Sie dazu im Datei-Menü auf Verbindung hinzufügen, woraufhin das Fenster Verbindung hinzufügen erscheint.
    Geben Sie die folgenden Informationen ein:
    • Hypervisor: Wählen Sie QEMU.
    • Verbindung: Wählen Sie die Verbindungsart.
    • Host-Name: Geben Sie den Host-Namen ein.
    Klicken Sie auf Verbinden.
    Der Virtual Machine Manager zeigt eine Liste verbundener Hosts an.
  2. Fügen Sie einen Speicher-Pool mit demselben NFS zum Quell- und Ziel-Host hinzu.
    Klicken Sie im Bearbeiten-Menü auf Host-Details, woraufhin das Fenster "Host-Details" erscheint.
    Klicken Sie auf den Reiter Speicher.
  3. Fügen Sie einen neuen Speicher-Pool hinzu. Klicken Sie oben links im Fenster auf die +-Schaltfläche. Es erscheint das Fenster "Neuen Speicher-Pool hinzufügen".
    Geben Sie die folgenden Informationen ein:
    • Name: Geben Sie den Namen des Speicher-Pools ein.
    • Typ: Wählen Sie netfs: Network Exported Directory.
    Klicken Sie auf Weiter.
  4. Geben Sie die folgenden Informationen ein:
    • Format: Wählen Sie den Speichertyp. Für Live-Migrationen muss dies entweder NFS oder iSCSI sein.
    • Host-Name: Geben Sie die IP-Adresse oder den vollqualifizierten Domain-Namen des Speicher-Servers ein.
    Klicken Sie auf Abschließen.
  5. Erzeugen Sie einen neuen Datenträger in dem gemeinsam genutzten Speicher-Pool. Klicken Sie dazu auf Neuer Datenträger.
  6. Geben Sie die Details ein und klicken anschließend auf Datenträger erzeugen.
  7. Erzeugen Sie eine virtuelle Maschine mit dem neuen Datenträger und starten anschließend die virtuelle Machine.
    Das Fenster für die virtuelle Maschine erscheint.
  8. Klicken Sie im Fenster des Virtual Machine Managers mit der rechten Maustaste auf die virtuelle Maschine, wählen Sie dann migrieren aus und klicken den Migrationsort an.
  9. Klicken Sie auf Ja, um die Migration zu bestätigen.
    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.

Kapitel 22. Remote-Verwaltung virtualisierter Gäste

Dieser Abschnitt erläutert, wie Sie Ihren virtualisierten Gast mittels ssh oder TLS und SSL von Remote aus verwalten.

22.1. Remote-Verwaltung mit SSH

Das ssh-Paket stellt ein verschlüsseltes Netzwerkprotokoll zur Verfügung, mit Hilfe dessen Verwaltungsfunktionen sicher an entfernte Virtualisierungs-Server übertragen werden können. Das beschriebene Verfahren verwendet die libvirt-Verwaltungsverbindung, sicher getunnelt über eine SSH-Verbindung, um die Remote-Maschinen zu verwalten. Die Authentifizierung erfolgt mit SSH-Public-Key-Kryptografie und Passwörtern, die von Ihrem lokalen SSH-Agenten erfasst werden. Darüberhinaus wird die VNC-Konsole für jede virtuelle Gastmaschine über SSH getunnelt.
SSH wird normalerweise automatisch konfiguriert, deswegen verfügen Sie höchstwahrscheinlich bereits über ein SSH-Schlüssel-Setup und es müssen für den Zugriff auf den Verwaltungsdienst oder die VNC-Konsole keine zusätzlichen Firewall-Regeln hinzugefügt werden.
Sie sollten sich der Probleme bewusst sein, die der Gebrauch von SSH zum Fernsteuern Ihrer virtuellen Maschine mit sich bringt, so zum Beispiel:
  • Sie benötigen Root-Login-Zugang zu der Remote-Maschine, um virtuelle Maschinen zu verwalten,
  • der anfänglich Prozess zur Verbindungsherstellung kann ggf. langsam sein,
  • there is no standard or trivial way to revoke a user's key on all hosts or guests, and
  • SSH ist bei einer großen Anzahl von Remote-Maschinen wenig praktikabel.
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.
Der libvirt-Daemon (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
Nachdem libvirtd und SSH konfiguriert sind, sollten Sie in der Lage sein, auf Ihre virtuellen Maschinen von Remote aus zuzugreifen und diese zu verwalten. Sie sollten nunmehr auch über VNC auf Ihre Gäste zugreifen können.
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. Remote-Verwaltung über TLS und SSL

You can manage virtual machines using TLS and SSL. TLS and SSL provides greater scalability but is more complicated than ssh (refer to Abschnitt 22.1, „Remote-Verwaltung mit 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.
Schritte zum Einrichten von TLS/SSL-Zugang für virt-manager
In der folgenden Kurzanleitung wird angenommen, dass Sie ganz am Anfang beginnen und keinerlei Kenntnisse über TLS/SSL-Zertifikate besitzen. Falls Sie einen Zertifikats-Management-Server haben, können Sie die ersten Schritte wahrscheinlich überspringen.
libvirt-Server-Einrichtung
Mehr Informationen zur Erstellung von Zertifikaten finden Sie auf der libvirt-Website, http://libvirt.org/remote.html.
Xen-VNC-Server
Für den Xen-VNC-Server kann TLS aktiviert werden, indem die Konfigurationsdatei /etc/xen/xend-config.sxp bearbeitet wird. Entfernen Sie in der Konfigurationsdatei die Kommentierung des Konfigurationsparameters (vnc-tls 1).
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.
virt-manager und virsh Client-Einrichtung
Das Einrichten von Clients ist derzeit leicht inkonsistent. Um die libvirt-Verwaltungs-API über TLS zu aktivieren, müssen die CA- und Client-Zertifikate in /etc/pki platziert sein. Weitere Einzelheiten dazu finden Sie unter http://libvirt.org/remote.html.
In the virt-manager user interface, use the 'SSL/TLS' transport mechanism option when connecting to a host.
Für virsh hat die URI das folgende Format:
  • qemu://hostname.guestname/system für KVM.
  • xen://hostname.guestname/ für Xen.
Um SSL und TLS für VNC zu aktivieren, ist es notwendig, die CA- und Client-Zertifikate in $HOME/.pki zu platzieren. Es handelt sich um die folgenden drei Dateien:
  • CA oder ca-cert.pem – Das CA-Zertifikat.
  • libvirt-vnc oder clientcert.pem – Das von der CA signierte Client-Zertifikat.
  • libvirt-vnc oder clientkey.pem – Der private Schlüssel des Clients.

22.3. Transportmodi

Für Remote-Verwaltung unterstützt virsh list die folgenden Transportmodi:
Transport Layer Security (TLS)
Transport Layer Security TLS 1.0 (SSL 3.1) authentifizierter und verschlüsselter TCP/IP-Socket, horcht in der Regel auf einen öffentlichen Port. Um dies nutzen zu können, müssen Sie Client- und Server-Zertifikate generieren. Der Standard-Port ist 16514.
UNIX-Sockets
Auf Unix-Domain-Sockets kann nur auf der lokalen Maschine zugegriffen werden. Socket sind nicht verschlüsselt und verwenden UNIX-Berechtigungen oder SELinux zur Authentifizierung. Die Standard-Socket-Namen sind /var/run/libvirt/libvirt-sock und /var/run/libvirt/libvirt-sock-ro (für schreibgeschützte Verbindungen).
SSH
Transportiert über eine Secure Shell Protocol (SSH) Verbindung. Setzt voraus, dass Netcat (das nc-Paket) installiert ist. Der libvirt-Daemon (libvirtd) muss auf der Remote-Maschine laufen und Port 22 muss für SSH-Zugang offen sein. Sie sollten ein Verfahren zur SSH-Schlüsselverwaltung nutzen (z. B. das ssh-agent-Dienstprogramm), andernfalls werden Sie nach einem Passwort gefragt.
ext
Der ext-Parameter wird für alle externen Programme verwendet, die eine Verbindung zur Remote-Maschine herstellen können auf Wegen, die von libvirt nicht erfasst werden. Dieser Parameter wird nicht unterstützt.
tcp
Unverschlüsselter TCP/IP-Socket. Nicht empfohlen in Produktionsumgebungen. Dies ist normalerweise deaktiviert, kann jedoch von einem Administrator zu Testzwecken oder zum Gebrauch in einem vertrauenswürdigen Netzwerk aktiviert werden. Der Standard-Port it 16509.
Sofern nichts anderes spezifiziert wurde, ist TLS der standardmäßige Transportmodus.
Remote-URIs
Ein Uniform Resource Identifier (URI) wird von virsh und libvirt verwendet, um mit einem Remote-Host zu verbinden. URIs können auch mit dem --connect-Parameter für den virsh-Befehl gebraucht werden, um einzelne Befehle oder Migrationen auf Remote-Hosts durchzuführen.
libvirt-URIs haben das folgende Format (Inhalte in eckigen Klammern, "[ ]", sind optionale Funktionen):
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
Um auf einen externen Speicherort zu verweisen, muss die Transportmethode oder der Host-Name angegeben werden.
Beispiele für Parameter zur Remote-Verwaltung
  • Verbinden mit einem entfernten Xen-Hypervisor auf einem Host namens towada, unter Verwendung des SSH-Transports und dem SSH-Benutzernamen ccurran.
    xen+ssh://ccurran@towada/
    
  • Verbinden mit einem entfernten Xen-Hypervisor auf einem Host namens towada unter Verwendung von 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
    
  • Verbinden mit einem entfernten KVM-Hypervisor auf einem Host namens towada unter Verwendung von SSH.
    qemu+ssh://towada/system
    
Beispiele zum Testen
  • Verbinden mit dem lokalen KVM-Hypervisor unter Verwendung eines nicht standardmäßigen UNIX-Sockets. Der vollständige Pfad zum Unix-Socket ist in diesem Fall explizit angegeben.
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
    
  • Verbindet mit dem libvirt-Daemon unter Verwendung einer unverschlüsselten TCP/IP-Verbindung über den Server mit der IP-Adresse 10.1.1.10 auf Port 5000. Dies verwendet den Testtreiber mit Standardeinstellungen.
    test+tcp://10.1.1.10:5000/default
    
Zusätzliche URI-Parameter
Extra parameters can be appended to remote URIs. The table below Tabelle 22.1, „Zusätzliche URI-Parameter“ 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).
Tabelle 22.1. Zusätzliche URI-Parameter
Name Transportmodus Beschreibung Beispielverwendung
name alle Modi Der Name, der an die Remote-virConnectOpen-Funktion übergeben wird. Der Name wird in der Regel gebildet, indem Transport, Host-Name, Port-Nummer, Benutzername und zusätzliche Parameter von der Remote-URI entfernt werden. In bestimmten, sehr komplexen Fällen ist es jedoch ratsam, den Namen explizit anzugeben. name=qemu:///system
command ssh und ext Der externe Befehl. Für ext-Transport ist dies erforderlich. Für ssh ist der Standard ssh. Der PATH wird nach dem Befehl durchsucht. command=/opt/openssh/bin/ssh
socket unix und ssh Der Pfad zum UNIX-Domain-Socket, was den Standard außer Kraft setzt. Für ssh-Transport wird dies an den Remote-Netcat-Befehl übergeben (siehe netcat). socket=/opt/libvirt/run/libvirt/libvirt-sock
netcat ssh
Der netcat-Befehl kann dazu verwendet werden, sich mit entfernten Maschinen zu verbinden. Der standardmäßige netcat-Parameter nutzt den nc-Befehl. Für SSH-Transport konstruiert libvirt einen SSH-Befehl nach folgendem Schema:
								command -p port [-l username] hostname
								netcat -U socket
Die Parameter port, username und hostname können als Teil der Remote-URI spezifiziert werden. command, netcat und socket stammen von anderen zusätzlichen Parametern.
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 Falls auf einen anderen Wert als Null eingestellt, fragt ssh nicht nach einem Passwort, falls es sich nicht automatisch bei der Remote-Maschine anmelden kann (zum Gebrauch von ssh-agent o. ä.). Verwenden Sie dies, wenn Sie keinen Zugriff auf ein Terminal haben, z. B. in grafischen Programmen, die libvirt verwenden. no_tty=1

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

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

Wichtig

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
    

    Wichtig

    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
    

    Wichtig

    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.

Teil VI. Referenzhandbuch zur Virtualisierung

Kapitel 24. Virtualisierungs-Tools

Nachfolgend sehen Sie eine Liste von Tools zur Verwaltung der Virtualisierung und zur Suche und Bereinigung von Programmfehlern (Debugging) sowie Netzwerk-Tools, die nützlich sind für Systeme, auf denen Xen läuft.
Systemadministrations-Tools
  • vmstat
  • iostat
  • lsof
    # lsof -i :5900
    xen-vncfb 10635  root  5u  IPv4 218738  TCP grumble.boston.redhat.com:5900 (LISTEN)
    
  • qemu-img
Fortgeschrittene Tools zur Suche und Bereinigung von Programmfehlern
  • systemTap
  • crash
  • xen-gdbserver
  • sysrq
  • sysrq t
  • sysrq w
  • sysrq c
Netzwerk-Tools
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
KVM-Tools
  • ps
  • pstree
  • top
  • kvmtrace
  • kvm_stat
Xen-Tools
  • xentop
  • xm dmesg
  • xm log

Kapitel 25. Das Verwalten von Gästen mit virsh

virsh ist ein Befehlszeilen-Tool zur Verwaltung der Gäste und des Hypervisors.
Das virsh-Tool setzt an der libvirt-Management-API an und fungiert als Alternative zum xm-Befehl und dem grafischen Gäste-Manager (virt-manager). Unprivilegierte Benutzer können virsh in schreibgeschütztem Modus nutzen. Sie können virsh dazu verwenden, Skripte für die Gastmaschinen auszuführen.
Kurzanleitung zum virsh-Befehl
Die folgende Tabelle gibt eine Kurzanleitung für alle Befehlszeilenoptionen.
Tabelle 25.1. Befehle der Gästeverwaltung
Befehl Beschreibung
help Zeigt grundlegende Hilfe-Informationen.
list Listet alle Gäste auf.
dumpxml Gibt die XML-Konfigurationsdatei für den Gast aus.
create Erzeugt einen Gast anhand einer XML-Konfigurationsdatei und startet den neuen Gast.
start Startet einen inaktiven Gast.
destroy Zwingt einen Gast zum Beenden.
define Gibt eine XML-Konfigurationsdatei für einen Gast aus.
domid Displays the guest's ID.
domuuid Displays the guest's UUID.
dominfo Zeigt Gastinformationen.
domname Displays the guest's name.
domstate Zeigt den Status eines Gasts an.
quit Beendet das interaktive Terminal.
reboot Startet einen Gast neu.
restore Stellt einen zuvor in einer Datei gespeicherten Gast wieder her.
resume Setzt einen angehaltenen Gast fort.
save Speichert den aktuellen Zustand eines Gasts in einer Datei.
shutdown Fährt einen Gast herunter.
suspend Hält einen Gast an.
undefine Löscht alle zu einem Gast gehörigen Dateien.
migrate Migriert einen Gast auf einen anderen Host.

Die folgenden virsh-Befehlsoptionen steuern die Gast- und Hypervisor-Ressourcen:
Tabelle 25.2. Optionen zur Ressourcenverwaltung
Befehl Beschreibung
setmem Legt den zugewiesenen Speicher für einen Gast fest.
setmaxmem Legt die Höchstgrenze an Speicher für den Hypervisor fest.
setvcpus Ändert die Anzahl virtueller CPUs, die einem Gast zugewiesen sind.
vcpuinfo Zeigt Informationen zur virtuellen CPU für einen Gast.
vcpupin Steuert die Affinität einer virtuellen CPU für einen Gast.
domblkstat Zeigt Blockgerätstatistiken für einen laufenden Gast.
domifstat Zeigt Netzwerkschnittstellenstatistiken für einen laufenden Gast.
attach-device Verknüpft ein Gerät mit einem Gast mittels einer Gerätdefinition in einer XML-Datei.
attach-disk Verknüpft eine neue Festplatte mit einem Gast.
attach-interface Verknüpft eine neue Netzwerkschnittstelle mit einem Gast.
detach-device Löst verknüpftes Gerät von einem Gast, nimmt dieselben XML-Beschreibungen wie der Befehl attach-device.
detach-disk Löst verknüpfte Festplatte von einem Gast.
detach-interface Löst verknüpfte Netzwerkschnittstelle von einem Gast.

Dies sind sonstige virsh-Optionen:
Tabelle 25.3. Sonstige Optionen
Befehl Beschreibung
version Zeigt die Version von virsh.
nodeinfo Gibt Informationen über den Hypervisor aus.

Verbinden mit dem Hypervisor
Verbinden Sie mit einer Hypervisor-Sitzung mittels virsh:
# virsh connect {hostname OR URL}
Wobei <name> der Name der Maschine des Hypervisors ist. Um eine schreibgeschützte Verbindung herzustellen, hängen Sie an den oben aufgeführten Befehl -readonly an.
Erstellen eines XML-Speicherauszugs einer virtuellen Maschine (Konfigurationsdatei)
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 Abschnitt 33.1, „Verwendung von XML-Konfigurationsdateien mit virsh“ for more information on modifying files created with virsh dumpxml.
Ein Beispiel einer virsh dumpxml-Ausgabe:
# 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>
Erzeugen eines Gasts mit Hilfe einer Konfigurationsdatei
Guests can be created from XML configuration files. You can copy existing XML from previously created guests or use the dumpxml option (refer to Erstellen eines XML-Speicherauszugs einer virtuellen Maschine (Konfigurationsdatei)). 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 Erstellen eines XML-Speicherauszugs einer virtuellen Maschine (Konfigurationsdatei)) 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
Dadurch wird ein Texteditor geöffnet. Der Standardtexteditor ist der $EDITOR-Shell-Parameter (auf vi voreingestellt).
Anhalten eines Gasts
Um einen Gast mit virsh anzuhalten:
# 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 (Fortsetzen eines Gastes) option.
Fortsetzen eines Gastes
Um einen angehaltenen Gast mit virsh wieder fortzusetzen, verwenden Sie die resume-Option:
# virsh resume {domain-id, domain-name or domain-uuid}
Diese Operation wird sofort umgesetzt und die Gastparameter werden für suspend- und resume-Operationen beibehalten.
Speichern eines Gasts
Speichern Sie den aktuellen Status eines Gasts mit Hilfe des virsh-Befehls in einer Datei:
# 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 (Wiederherstellen eines Gasts) option. Save is similar to pause, instead of just pausing a guest the present state of the guest is saved.
Wiederherstellen eines Gasts
Restore a guest previously saved with the virsh save command (Speichern eines Gasts) 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.
Herunterfahren eines Gasts
Herunterfahren eines Gasts mit dem Befehl 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.
Neustarten eines Gasts
Neustarten eines Gasts mit dem Befehl 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.
Abbrechen eines Gasts
Abbrechen eines Gasts mit dem Befehl 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(Herunterfahren eines Gasts) instead.
Abrufen der Domain-ID eines Gasts
Um die Domain-ID eines Gasts zu erhalten:
# virsh domid {domain-name or domain-uuid}
Abrufen des Domain-Namens eines Gasts
Um den Domain-Namen eines Gasts zu erhalten:
# virsh domname {domain-id or domain-uuid}
Abrufen der UUID eines Gasts
Um die Universally Unique Identifier (UUID) eines Gasts zu erhalten:
# virsh domuuid {domain-id or domain-name}
Ein Beispiel für eine virsh domuuid-Ausgabe:
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011
Anzeigen von Gastinformationen
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}
Sehen Sie ein Beispiel für eine virsh dominfo-Ausgabe:
# 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
Anzeigen von Host-Informationen
Um Informationen über den Host anzuzeigen:
# virsh nodeinfo
Ein Beispiel für eine virsh nodeinfo-Ausgabe:
# 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
Dargestellt werden die Knoteninformationen und die Maschinen, die den Virtualisierungsprozess unterstützen.
Anzeigen der Gäste
Um eine Gästeliste samt jeweiligem aktuellen Status mit virsh anzuzeigen:
# virsh list
Andere verfügbare Optionen sind u. a.:
die Option --inactive, um inaktive Gäste aufzulisten (also Gäste, die zwar definiert wurden, zur Zeit jedoch nicht aktiv sind, und
die Option --all, um alle Gäste aufzulisten. Zum Beispiel:
# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  1 Domain202            paused
  2 Domain010            inactive
  3 Domain9600           crashed
Die Ausgabe von virsh list kann kategorisiert werden als eine von sechs möglichen Stati (nachfolgend erläutert):
  • Der Status running bezieht sich auf Gäste, die derzeit auf einer CPU aktiv sind.
  • Gäste mit dem Status blocked sind blockiert und werden nicht ausgeführt bzw. können nicht ausgeführt werden. Dies können Gäste sein, die auf eine I/O warten (traditionell der "wait"-Status) oder die sich im Ruhezustand befinden.
  • Der paused-Status bezieht sich auf Gäste, die angehalten wurden. Das ist der Fall, wenn ein Administrator die Schaltfläche pause im virt-manager klickt oder xm pause bzw. virsh suspend ausführt. Wenn ein Gast angehalten ist, verbraucht er weiterhin Arbeitsspeicher und andere Ressourcen, nimmt jedoch nicht am Scheduling teil und erhält keine CPU-Ressourcen vom Hypervisor.
  • Der Status shutdown ist für Gäste, die gerade dabei sind herunterzufahren. Dem Gast wurde das Signal zum Herunterfahren gesendet und sollte im Begriff sein, seine Operationen zu beenden. Dies funktionert ggf. nicht mit allen Betriebssystemen, denn einige Betriebssysteme reagieren nicht auf diese Signale.
  • Gäste mit dem Status dying sind "am Sterben", d. h. der Gast wurde nicht vollständig heruntergefahren oder ist abgestürzt.
  • Gäste mit dem Status crashed schlugen bei der Ausführung fehl und laufen nicht mehr. Dieser Status kann nur auftreten, wenn der Gast konfiguriert wurde, nach einem Absturz nicht neu zu starten.
Anzeigen von Informationen zur virtuellen CPU
Um Information einer virtuellen CPU für einen Gast mittels virsh anzuzeigen:
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
Hier ein Beispiel für eine virsh vcpuinfo-Ausgabe:
# virsh vcpuinfo r5b2-mySQL01
VCPU:           0
CPU:            0
State:          blocked
CPU time:       0.0s
CPU Affinity:   yy
Konfigurieren der Affinität einer virtuellen CPU
Um die Affinität von virtuellen CPUs mit physischen CPUs zu konfigurieren:
# virsh vcpupin domain-id vcpu cpulist
The domain-id parameter is the guest's ID number or name.
Der vcpu-Parameter gibt die Anzahl der virtualisierten CPUs an, die dem Gast zugewiesen sind. Der vcpu-Parameter muss angegeben werden.
Der cpulist-Parameter ist eine kommagetrennte Liste mit Identifikationsnummern der physischen CPUs. Durch den cpulist-Parameter wird festgelegt, auf welchen physischen CPUs die VCPUs laufen können.
Konfigurieren der Anzahl virtueller CPUs
Um mit virsh die Anzahl der CPUs zu ändern, die einem Gast zugewiesen sind:
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
Der neue count-Wert darf die Anzahl, die bei der Erstellung des Gasts festgelegt wurde, nicht überschreiten.
Konfigurieren der Speicherzuweisung
To modify a guest's memory allocation with virsh :
# virsh setmem {domain-id or domain-name} count
Sie müssen count in Kilobytes angeben. Der neue Wert darf die Menge, die Sie bei der Erstellung des Gasts festgelegt haben, nicht überschreiten. Werte kleiner als 64 MB funktionieren mit den meisten Betriebssystemen wahrscheinlich nicht. Ein höherer maximaler Speicherwert beeinflusst einen aktiven Gast nicht. Falls der neue Wert niedriger ist, wird der verfügbare Speicher verkleinert und der Gast kann unter Umständen abstürzen.
Anzeigen von Blockgerätinformationen für einen Gast
Verwenden Sie virsh domblkstat, um Blockgerätstatistiken für einen laufenden Gast anzuzeigen.
# virsh domblkstat GuestName block-device
Anzeigen von Netzwerkgerätinformationen für einen Gast
Verwenden Sie virsh domifstat, um Netzwerkgerätstatistiken für einen laufenden Gast anzuzeigen.
# virsh domifstat GuestName interface-device 
Gästeverwaltung mit virsh
Ein Gast kann mit Hilfe des virsh-Befehls auf einen anderen Host migriert werden. Migrieren Sie eine Domain auf einen anderen Host. Fügen Sie --live für eine Live-Migration hinzu. Der migrate-Befehl akzeptiert Parameter im folgenden Format:
# virsh migrate --live GuestName DestinationURL
Der --live-Parameter ist optional. Fügen Sie den --live-Parameter für Live-Migrationen hinzu.
Der GuestName-Parameter steht für den Namen desjenigen Gasts, den Sie migrieren möchten.
Der Parameter DestinationURL ist die URL oder der Host-Name des Zielsystems. Das Zielsystem benötigt:
  • dieselbe Version von Red Hat Enterprise Linux,
  • denselben Hypervisor (KVM oder Xen) und
  • den laufenden libvirt-Dienst.
Nachdem der Befehl eingegeben wurde, werden Sie nach dem Root-Passwort des Zielsystems gefragt.
Verwalten virtueller Netzwerke
Dieser Abschnitt behandelt die Verwaltung virtueller Netzwerke mit virsh. Um virtuelle Netzwerke aufzulisten:
# virsh net-list
Dieser Befehl generiert eine Ausgabe ähnlich der folgenden:
# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes      
vnet1	             active     yes      
vnet2	             active     yes
Um Netzwerkinformationen für ein spezielles virtuelles Netzwerk anzusehen:
# virsh net-dumpxml NetworkName
So werden Informationen über ein angegebenes virtuelles Netzwerk im XML-Format angezeigt:
# 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>
Andere virsh-Befehle zur Verwaltung virtueller Netzwerke sind u. a.:
  • virsh net-autostart network-name — Startet automatisch ein Netzwerk spezifiziert als network-name.
  • virsh net-create XMLfile — Generiert und startet ein neues Netzwerk unter Verwendung einer vorhandenen XML-Datei.
  • virsh net-define XMLfile — Generiert ein neues Netzwerkgerät von einer vorhandenen XML-Datei, ohne dieses zu starten.
  • virsh net-destroy network-name — Zerstört ein Netzwerk spezifiziert als network-name.
  • virsh net-name networkUUID — Konvertiert eine angegebene networkUUID in einen Netzwerknamen.
  • virsh net-uuid network-name — Konvertiert einen spezifizierten network-name in eine Netzwerk-UUID.
  • virsh net-start nameOfInactiveNetwork — Startet ein inaktives Netzwerk.
  • virsh net-undefine nameOfInactiveNetwork — Löscht die Definition von einem inaktiven Netzwerk.

Kapitel 26. Das Verwalten von Gästen mit dem Virtual Machine Manager (virt-manager)

Dieser Abschnitt beschreibt die Fenster, Dialogkästen und verschiedenen GUI-Kontrollmöglichkeiten des Virtual Machine Managers (virt-manager).
Der virt-manager bietet eine grafische Ansicht der Hypervisoren und Gäste auf Ihrem System und auf entfernten Maschinen. Sie können mit Hilfe von virt-manager sowohl paravirtualisierte als auch voll virtualisierte Gäste definieren. virt-manager kann zudem Aufgaben zur Verwaltung der Virtualisierung durchführen, u. a.:
  • Speicher zuweisen,
  • virtuelle CPUs zuweisen,
  • Leistung im Betrieb überwachen,
  • speichern und wiederherstellen, anhalten und fortsetzen, herunterfahren und starten von virtualisierten Gästen,
  • verbindet mit den Text- und grafischen Konsolen, und
  • Live- und Offline-Migrationen.

26.1. The Add Connection window

Zu Beginn erscheint dieses Fenster und fordert den Benutzer dazu auf, eine Hypervisor-Sitzung auszuwählen. Nicht privilegierte Benutzer können eine schreibgeschützte Sitzung initiieren. Root-Benutzer können eine Sitzung mit vollem Lese- und Schreibzugriff starten. Wählen Sie für normalen Gebrauch die Lokaler Xen-Host Option oder QEMU (für KVM).
Das Fenster mit Verbindungen des Virtual Machine Manager
Abbildung 26.1. Das Fenster mit Verbindungen des Virtual Machine Manager

26.2. Das Hauptfenster des Virtual Machine Managers

This main window displays all the running guests and resources used by guests. Select a virtualized guest by double clicking the guest's name.
Hauptfenster des Virtual Machine Managers
Abbildung 26.2. Hauptfenster des Virtual Machine Managers

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

26.4. Die grafische Konsole der virtuellen Maschine

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.
Das Fenster der grafischen Konsole
Abbildung 26.4. Das Fenster der grafischen Konsole

Anmerkung zur Sicherheit und 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 Kapitel 22, Remote-Verwaltung virtualisierter Gäste. 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'.

Anmerkung

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. Starten des virt-manager

Um eine virt-manager-Sitzung zu starten, öffnen Sie das Anwendungen-Menü, anschließend das Systemwerkzeuge-Menü und wählen dort den Virtual Machine Manager (virt-manager).
Das Hauptfenster vom virt-manager erscheint.
Das Starten von virt-manager
Abbildung 26.5. Das Starten von 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 Abschnitt 22.1, „Remote-Verwaltung mit SSH“.

26.6. Wiederherstellen einer gespeicherten Maschine

Nachdem Sie den Virtual Machine Manager gestartet haben, werden alle virtuellen Maschinen auf Ihrem System im Hauptfenster angezeigt. Domain0 ist Ihr Host-System. Falls keine Maschinen existieren, bedeutet dies, dass derzeit keine Maschinen auf dem System laufen.
Um eine zuvor gespeicherte Sitzung wiederherzustellen:
  1. Wählen Sie aus dem Menü Datei die Option Gespeicherte Maschine wiederherstellen.
    Wiederherstellen einer virtuellen Maschine
    Abbildung 26.6. Wiederherstellen einer virtuellen Maschine

  2. Das Hauptfenster Virtuelle Maschine wiederherstellen erscheint.
  3. Begeben Sie sich in das korrekte Verzeichnis und wählen Sie die gespeicherte Sitzungsdatei.
  4. Klicken Sie auf Öffnen.
Das gespeicherte virtuelle System erscheint im Fenster des Virtual Machine Manager.
Die wiederhergestellte Sitzung des Virtual Machine Manager
Abbildung 26.7. Die wiederhergestellte Sitzung des Virtual Machine Manager

26.7. Anzeigen von Gastdetails

Mit Hilfe des Virtual Machine Monitor können Sie sich die Daten zur Aktivität einer beliebigen virtuellen Maschine auf Ihrem System anschauen.
To view a virtual system's details:
  1. Markieren Sie im Hauptfenster des Virtual Machine Manager die virtuelle Maschine, die Sie ansehen möchten.
    Auswahl einer anzuzeigenden virtuellen Maschine
    Abbildung 26.8. Auswahl einer anzuzeigenden virtuellen Maschine

  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
    Abbildung 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.
    Anzeigen des Detail-Überblicks der virtuellen Maschine
    Abbildung 26.10. Anzeigen des Detail-Überblicks der virtuellen Maschine

  3. On the Virtual Machine window, click the Hardwaretab.
    Anzeigen der Hardware-Details der virtuellen Maschine
    Abbildung 26.11. Anzeigen der Hardware-Details der virtuellen Maschine

  4. Um die derzeitige Zuweisung von Prozessorspeicher zu betrachten oder zu verändern, klicken Sie auf Prozessor auf dem Reiter Hardware.
    Anzeigen der Prozessorzuweisung
    Abbildung 26.12. Anzeigen der Prozessorzuweisung

  5. Um die derzeitige Zuweisung von Arbeitsspeicher zu betrachten oder zu verändern, klicken Sie auf Speicher auf dem Reiter Hardware.
    Anzeigen der Arbeitsspeicherzuweisung
    Abbildung 26.13. Anzeigen der Arbeitsspeicherzuweisung

  6. Um die derzeitige Festplattenkonfiguration zu betrachten oder zu verändern, klicken Sie auf Festplatte auf dem Reiter Hardware.
    Anzeigen der Festplattenkonfiguration
    Abbildung 26.14. Anzeigen der Festplattenkonfiguration

  7. On the Hardware tab, click on NIC to view or change the current network configuration.
    Anzeigen der Netzwerkkonfiguration
    Abbildung 26.15. Anzeigen der Netzwerkkonfiguration

26.8. Überwachen des Status

Status status monitoring preferences can be modified with virt-manager's preferences window.
To configure status monitoring:
  1. Wählen Sie Präferenzen aus dem Menü Bearbeiten.
    Modifizieren der Präferenzen des Gasts
    Abbildung 26.16. Modifizieren der Präferenzen des Gasts

    The Preferences window appears.
  2. From the Stats tab specify the time in seconds or stats polling options.
    Konfiguration der Statusüberwachung
    Abbildung 26.17. Konfiguration der Statusüberwachung

26.9. Anzeigen der Gast-Identifier

Gehen Sie wie folgt vor, um die Gast-IDs für alle virtuellen Maschinen auf Ihrem System anzusehen:
  1. Wählen Sie das Kontrollkästchen Domain-ID aus dem Menü Anzeigen.
    Anzeigen der Gast-IDs
    Abbildung 26.18. Anzeigen der Gast-IDs

  2. Der Virtual Machine Manager listet die Domain-IDs für alle Domains auf Ihrem System auf.
    Anzeigen der Domain-ID
    Abbildung 26.19. Anzeigen der Domain-ID

26.10. Displaying a guest's status

Gehen Sie wie folgt vor, um den Status aller virtuellen Maschinen auf Ihrem System zu betrachten:
  1. Wählen Sie das Kontrollkästchen Status aus dem Menü Ansicht.
    Selecting a virtual machine's status
    Abbildung 26.20. Selecting a virtual machine's status

  2. Der Virtual Machine Manager listet den Status aller virtuellen Maschinen auf Ihrem System auf.
    Displaying a virtual machine's status
    Abbildung 26.21. Displaying a virtual machine's status

26.11. Anzeigen virtueller CPUs

Gehen Sie wie folgt vor, um die Anzahl der virtuellen CPUs für alle virtuellen Maschinen auf Ihrem System anzusehen:
  1. Wählen Sie aus dem Menü Anzeigen das Kontrollkästchen Virtuelle CPUs.
    Auswahl der virtuellen CPU-Optionen
    Abbildung 26.22. Auswahl der virtuellen CPU-Optionen

  2. Der Virtual Machine Manager listet die virtuellen CPUs für alle virtuellen Maschinen auf Ihrem System auf.
    Anzeigen virtueller CPUs
    Abbildung 26.23. Anzeigen virtueller CPUs

26.12. Anzeigen der CPU-Auslastung

Gehen Sie wie folgt vor, um die CPU-Auslastung für alle virtuellen Maschinen auf Ihrem System anzusehen:
  1. Wählen Sie das Kontrollkästchen CPU-Auslastung aus dem Menü Anzeige.
    Auswahl der CPU-Auslastung
    Abbildung 26.24. Auswahl der CPU-Auslastung

  2. Der Virtual Maschine Manager listet die CPU-Auslastung in Prozent für alle virtuellen Maschinen auf Ihrem System auf.
    Anzeigen der CPU-Auslastung
    Abbildung 26.25. Anzeigen der CPU-Auslastung

26.13. Anzeigen des Speicherverbrauchs

Gehen Sie wie folgt vor, um den Speicherverbrauch für alle virtuellen Maschinen auf Ihrem System zu betrachten:
  1. Wählen Sie aus dem Menü Anzeigen das Kontrollkästchen Speicherbelegung.
    Auswahl des Speicherverbrauchs
    Abbildung 26.26. Auswahl des Speicherverbrauchs

  2. Der Virtual Machine Manager listet den Anteil des Speicherverbrauchs (in Megabytes) für alle virtuellen Maschinen auf Ihrem System auf.
    Anzeigen des Speicherverbrauchs
    Abbildung 26.27. Anzeigen des Speicherverbrauchs

26.14. Verwalten eines virtuellen Netzwerks

Zur Konfiguration eines virtuellen Netzwerks auf Ihrem System:
  1. Wählen Sie Host-Details aus dem Menü Bearbeiten.
    Selecting a host's details
    Abbildung 26.28. Selecting a host's details

  2. Dies öffnet das Menü Host-Details. Klicken Sie auf den Reiter Virtuelle Netzwerke.
    Virtuelle Netzwerkkonfiguration
    Abbildung 26.29. Virtuelle Netzwerkkonfiguration

  3. Alle verfügbaren virtuellen Netzwerke sind im linken Kasten des Menüs aufgelistet. Sie können die Konfiguration eines virtuellen Netzwerks bearbeiten, indem Sie es aus diesem Kasten auswählen und nach Bedarf ändern.

26.15. Erstellen eines virtuellen Netzwerks

Um ein virtuelles Netzwerk auf Ihrem System zu erstellen:
  1. Open the Host Details menu (refer to Abschnitt 26.14, „Verwalten eines virtuellen Netzwerks“) and click the Add button.
    Virtuelle Netzwerkkonfiguration
    Abbildung 26.30. Virtuelle Netzwerkkonfiguration

    Dies öffnet das Menü Neues virtuelles Netzwerk erstellen. Klicken Sie auf Weiter, um fortzufahren.
    Erstellung eines neuen virtuellen Netzwerks
    Abbildung 26.31. Erstellung eines neuen virtuellen Netzwerks

  2. Geben Sie den Namen Ihres virtuellen Netzwerks ein und klicken Sie auf Weiter.
    Benennung Ihres virtuellen Netzwerks
    Abbildung 26.32. Benennung Ihres virtuellen Netzwerks

  3. Geben Sie einen IPv4-Adressraum für Ihr virtuelles Netzwerk ein und klicken Sie auf Weiter.
    Auswahl eines IPv4-Adressraums
    Abbildung 26.33. Auswahl eines IPv4-Adressraums

  4. Definieren Sie den DHCP-Bereich für Ihr virtuelles Netzwerk durch die Angabe eines Start- und End- Bereichs von IP-Adressen. Klicken Sie auf Weiter, um fortzufahren.
    Auswahl des DHCP-Bereichs
    Abbildung 26.34. Auswahl des DHCP-Bereichs

  5. Wählen Sie aus, wie sich das virtuelle Netzwerk mit dem physischen Netzwerk verbinden soll.
    Verbindung mit dem physischen Netzwerk
    Abbildung 26.35. Verbindung mit dem physischen Netzwerk

    Falls Sie sich für An physisches Netzwerk weiterleiten entscheiden, wählen Sie, ob das Ziel entweder NAT zu allen physischen Geräten oder NAT zum physischen Gerät eth0 sein soll.
    Klicken Sie auf Weiter, um fortzufahren.
  6. Sie sind nun bereit, das Netzwerk einzurichten. Überprüfen Sie die Konfiguration Ihres Netzwerks und klicken Sie auf Fertigstellen.
    Bereit zur Erstellung des Netzwerks
    Abbildung 26.36. Bereit zur Erstellung des Netzwerks

  7. Das neue virtuelle Netzwerk steht nun im Reiter Virtuelles Netzwerk des Menüs Host-Details zur Verfügung.
    Neues virtuelles Netzwerk ist nun verfügbar
    Abbildung 26.37. Neues virtuelles Netzwerk ist nun verfügbar

Kapitel 27. Kurzanleitung zum xm-Befehl

Mit Hilfe des xm-Befehls kann der Xen-Hypervisor verwaltet werden. Die meisten Operationen können mit den libvirt-Tools, der virt-manager-Anwendung oder dem virsh-Befehl durchgeführt werden. Der xm-Befehl verfügt im Gegensatz zu den libvirt-Tools nicht über die Fähigkeit zur Fehlerüberprüfung und sollte daher für keine Aufgaben eingesetzt werden, die von den libvirt-Tools erledigt werden können.
Es gibt einige Operationen, die derzeit nicht mit dem virt-manager ausgeführt werden können. Einige Optionen für andere Xen-Implementierungen des xm-Befehls funktionieren nicht in Red Hat Enterprise Linux 5. Die untenstehende Liste gibt einen Überblick darüber, welche Befehlsoptionen verfügbar bzw. nicht verfügbar sind.

Warnung

Es wird empfohlen, virsh oder virt-manager anstelle von xm zu verwenden. Der xm-Befehl handhabt Fehlerüberprüfung und Fehler in Konfigurationsdateien nicht besonders gut, infolgedessen können Fehler zu Systeminstabilität oder Problemen mit den virtuellen Maschinen führen. Das manuelle Bearbeiten der Xen-Konfigurationsdateien ist riskant und sollte vermieden werden. Nutzen Sie dieses Kapitel auf eigene Gefahr.
Grundlegende Optionen zur Verwaltung
Die folgenden Befehle sind grundlegende und gebräuchliche xm-Befehle:
  • xm help [--long]: Zeigt verfügbare Optionen und Hilfetext an.
  • Verwenden Sie den Befehl xm list, um aktive Domains aufzulisten:
    $ 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: beendet eine virtuelle Maschine, ähnlich wie power off.
  • xm reboot DomainName/ID: startet eine virtuelle Maschine neu; führt den normalen Prozess des Herunterfahrens und Hochfahrens des Systems durch.
  • xm shutdown DomainName/ID: fährt eine virtuelle Maschine herunter, führt den normalen Prozess des Herunterfahrens des Systems durch.
  • xm pause
  • xm unpause
  • xm save
  • xm restore
  • xm migrate
Optionen zur Ressourcenverwaltung
Verwenden Sie die folgenden xm-Befehle, um Ressourcen zu verwalten:
  • xm mem-set
  • Benutzen Sie xm vcpu-list, um virtualisierte CPU-Affinitäten aufzulisten.
    $ 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
  • Verwenden Sie den xm sched-credit-Befehl, um Scheduler-Parameter für eine angegebene Domain anzuzeigen:
    $ xm sched-credit -d 0
    {'cap': 0, 'weight': 256}
    $ xm sched-credit -d 13
    {'cap': 25, 'weight': 256}
    
Optionen zur Überwachung (Monitoring) und zur Suche und Beseitigung von Fehlern (Troubleshooting)
Benutzen Sie die folgenden xm-Befehle zur Überwachung (Monitoring) und zur Suche und Beseitigung von Fehlern (Troubleshooting):
  • xm top
  • xm dmesg
  • xm info
  • xm log
  • Benutzen Sie xm uptime, um die Betriebszeit für Gäste und Hosts anzuzeigen:
    $ 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
Derzeit nicht unterstützte Optionen
Der Befehl xm vnet-list wird derzeit nicht unterstützt.

Kapitel 28. Konfigurieren der Xen-Kernel-Boot-Parameter

Der GNU Grand Unified Boot Loader (GRUB) ist ein Programm zum Booten verschiedener installierter Betriebssysteme oder Kernel. GRUB ermöglicht es dem Benutzer außerdem, Parameter an den Kernel zu übergeben. Die Konfigurationsdatei von GRUB (zu finden unter /boot/grub/grub.conf) erstellt eine Liste von Betriebssystemen für die Menüoberfläche von GRUB. Wenn Sie das kernel-xen-RPM installieren, fügt ein Skript den kernel-xen-Eintrag zur GRUB-Konfigurationsdatei hinzu, der den kernel-xen standardmäßig bootet. Sie können die grub.conf-Datei bearbeiten, um den Standard-Kernel zu ändern oder zusätzliche Kernel-Parameter hinzuzufügen.
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
Wenn Sie die Linux Grub-Einträge entsprechend dieses Beispiels einrichten, lädt der Bootloader den Hypervisor, das initrd-Image und den Linux-Kernel. Da sich der Kernel-Eintrag oberhalb der anderen Einträge befindet, wird der Kernel zuerst in den Speicher geladen. Der Bootloader sendet (und empfängt) Befehlszeilenparameter an den (bzw. vom) Hypervisor und dem Linux-Kernel. Dieser Beispieleintrag zeigt, wie Sie den Speicher des Linux-Kernels der Dom0 auf 800 MB beschränken:
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
Mit Hilfe dieser GRUB-Parameter können Sie den Virtualisierungs-Hypervisor konfigurieren:
mem
Dies schränkt die Menge an Speicher ein, die für den Hypervisor-Kernel zur Verfügung steht.
com1=115200, 8n1
Dies aktiviert den ersten seriellen Port im System, so dass dieser als serielle Konsole fungiert (com2 wird dem nächsten Port zugewiesen, usw.).
dom0_mem
Dies schränkt den Arbeitsspeicher ein, der dem Hypervisor zur Verfügung steht.
dom0_max_vcpus
Dies schränkt die Anzahl der CPUs ein, die für die Xen-domain0 sichtbar sind.
acpi
Dies wechselt den ACPI-Hypervisor in den Hypervisor und domain0. Die ACPI-Parameteroptionen umfassen:
/*   ****  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
Dies deaktiviert ACPI für Interrupt-Zuweisung.

Kapitel 29. Konfigurieren von ELILO

ELILO ist der Bootloader, der auf EFI-basierten Systemen verwendet wird, insbesondere Itanium®. Ähnlich wie GRUB, der Bootloader auf x86 und x86-64 Systemen, erlaubt ELILO es dem Benutzer auszuwählen, welcher Kernel während der Systemboot-Sequenz geladen werden soll. ELILO ermöglicht es dem Benutzer auch, Parameter an den Kernel zu übergeben. Die ELILO-Konfigurationsdatei, die in der EFI-Boot-Partition liegt und symbolisch mit /etc/elilo.conf verlinkt ist, beinhaltet eine Liste von globalen Optionen und Image-Stanzas. Wenn Sie das kernel-xen-RPM installieren, fügt ein Post-Installationsskript die entsprechenden Image-Stanzas zur elilo.conf hinzu.

ELILO

Dieser Abschnitt über ELILO gilt für Systeme, auf denen der Xen-Kernel auf der Intel Itanium Architektur läuft.
Die ELILO-Konfigurationsdatei besteht aus zwei Abschnitten:
  • Globale Optionen, die das Verhalten von ELILO und allen anderen Einträgen beeinflussen. Normalerweise bedarf es keiner Änderung der Standardwerte.
  • Image-Stanzas, die eine Boot-Auswahl samt zugehöriger Optionen definieren.
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 übersetzt read-only zu der Kernel-Befehlszeilenoption ro, was dazu führt, dass das Root-Dateisystem schreibgeschützt eingehängt wird, bis die initscripts das Root-Laufwerk mit Lese- und Schreibzugriff einhängt. ELILO kopiert die "root"-Zeile in die Kernel-Befehlszeile. Diese wird mit der "append"-Zeile zusammengeführt, um eine komplette Befehlszeile zu erstellen:
"-- root=/dev/VolGroup00/rhel5_2 ro rhgb quiet"
Die ---Symbole trennen Hypervisor- von Kernel-Parametern. Die Hypervisor-Parameter kommen zuerst, dann die -- Trennzeichen, gefolgt von den Kernel-Parametern. Der Hypervisor hat normalerweise keine Parameter.

Technische Anmerkung

ELILO übergibt die gesamte Befehlszeile an den Hypervisor. Der Hypervisor unterteilt den Inhalt und leitet die Kernel-Optionen an den Kernel weiter.
Um den Hypervisor anzupassen, fügen Sie vor -- die gewünschten Parameter ein. Nachfolgend ein Beispiel für den Hypervisor-Arbeitsspeicher (mem)-Parameter und den quiet-Parameter für den Kernel:
append="dom0_mem=2G -- quiet"
ELILO Hypervisor-Parameter
ParameterBeschreibung
mem=Der mem-Parameter definiert die maximale RAM-Benutzung des Hypervisors. Jeder zusätzliche RAM im System wird ingnoriert. Die Paramenter können mit dem Zusatz B, K, oder G spezifiziert werden, dies steht für Bytes, Kilobytes, Megabytes und Gigabytes. Falls kein Zusatz angegeben wird, ist Kilobytes die Standardeinheit.
dom0_mem=dom0_mem= setzt die Menge an RAM fest, die dom0 zugewiesen wird. Es gelten dieselben Regeln für Einheiten wie beim o. g. mem-Parameter. Der Standard in Red Hat Enterprise Linux 5.2 auf Itanium® ist 4 G.
dom0_max_vcpus=dom0_max_vcpus= setzt die Anzahl von CPUs fest, die dem Hypervisor zugewiesen werden. Der Standard in Red Hat Enterprise Linux 5.2 auf Itanium® ist 4.
com1=<baud>,DPS,<io_base>,<irq>com1= setzt die Parameter für die erste serielle Zeile, z. B. com1=9600,8n1,0x408,5. Die Optionen io_base und irq können weggelassen werden, um diese in der Standardeinstellung beizubehalten. Der Parameter baud kann auf auto gesetzt werden, um die Boot-Loader-Einstellungen zu erhalten. Der Paramenter com1 kann weggelassen werden, falls serielle Parameter als globale Optionen in ELILO oder der EFI-Konfiguration gesetzt sind.
com2=<baud>,DPS,<io_base>,<irq>Setzt Parameter für die zweite serielle Zeile. Siehe o. g. Beschreibung des com1-Parameters.
console=<specifier_list>console ist eine kommagetrennte Präferenzenliste für die Konsolenoptionen. Die Optionen umfassen vga, com1 und com2. Diese Einstellungen sollten weggelassen werden, da der Hypervisor versuchen wird, die Einstellungen der EFI-Konsole zu übernehmen.

Mehr Informationen zu ELILO-Parametern

Eine vollständige Liste der ELILO-Parameter finden Sie unter XenSource.
Sehen Sie hier ein modifiziertes Beispiel der Konfiguration oben, das die Syntax für hinzugefügten Arbeitsspeicher und Parameter zur CPU-Zuweisung für den Hypervisor veranschaulicht:
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 --"
Zusätzlich entfernt dieses Beispiel die Kernel-Parameter "rhgb quiet", so dass die Ausgabe von Kernel und initscript auf der Konsole angezeigt wird. Beachten Sie, dass der doppelte Bindestrich an seinem Platz bleibt, so dass die "append"-Zeile korrekt als Hypervisor-Parameter interpretiert wird.

Kapitel 30. libvirt configuration reference

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

Kapitel 31. Xen-Konfigurationsdateien

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, Tabelle 31.1, „Referenz für Xen-Konfigurationsdatei“, is formatted output from xm create --help_config.
Tabelle 31.1. Referenz für Xen-Konfigurationsdatei
Parameter
Description
vncpasswd=NAME Passwort für VNC-Konsole auf HVM-Domain.
vncviewer=no | yes Erzeugen eines VNCViewer-Listings für einen VNC-Server in der Domain. Die Adresse des VNCViewers wird über die Kernel-Befehlszeile an die Domain übergeben mittels VNC_SERVER=<host>:<port>. Der von VNC verwendete Port ist 5500 + DISPLAY. Falls möglich, wird ein Anzeigewert mit einen freien Port gewählt. Gilt nur, wenn vnc=1.
vncconsole=no | yes Spawn a vncviewer process for the domain's graphical console. Only valid when vnc=1.
name=NAME Domain-Name. Muss eindeutig sein.
bootloader=FILE Pfad zum Bootloader.
bootargs=NAME Parameter, die an den Bootloader übergeben werden.
bootentry=NAME VERALTET. Eintrag zum Booten via Bootloader. Benutzen Sie dazu bootargs.
kernel=FILE Pfad zum Kernel-Image.
ramdisk=FILE Pfad zur Ramdisk.
features=FEATURES Features, die im Gast-Kernel zu aktivieren sind.
builder=FUNCTION Funktion zum Erzeugen der Domain.
memory=MEMORY Domain-Speicher in MB.
maxmem=MEMORY Maximaler Domain-Speicher in MB.
shadow_memory=MEMORY Domain-Shadow-Speicher in MB.
cpu=CPU CPU, die VCPU0 hostet.
cpus=CPUS CPUs, auf denen die Domain läuft.
pae=PAE Aktivieren oder deaktivieren von PAE von HVM-Domain.
acpi=ACPI Aktivieren oder deaktivieren von ACPI von HVM-Domain.
apic=APIC Aktivieren oder deaktivieren von APIC von HVM-Domain.
vcpus=VCPUs Anzahl virtueller CPUs in Domain.
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 Veraltet. Verwenden Sie stattdessen on_poweroff, on_reboot und on_crash. Legt fest, ob die Domain nach Beenden neu gestartet werden soll. - onreboot: Neustart nach Beenden mit Shutdown-Code Reboot - always: immer Neustart nach Beenden, ignoriere den Exit-Code - never: niemals Neustart nach Beenden, ignoriere den Exit-Code
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 Macht die Domain zum Blockgerät-Backend
netif=no | yes Macht die Domain zum Netzwerkschnittstellen-Backend
tpmif=no | yes Macht die Domain zum TPM-Schnittstellen-Backend.
disk=phy:DEV,VDEV,MODE[,DOM] Hinzufügen einer Festplatte zu einer Domain. Das physische Gerät ist DEV, welches als VDEV zur Domain exportiert wird. Die Festplatte ist schreibgeschützt, wenn MODE auf r steht, und les- und schreibbar, wenn MODE auf w steht. Falls DOM spezifiziert ist, definiert es die Backend-Treiber-Domain für die Festplatte. Diese Option kann wiederholt werden, um mehrere Festplatten hinzuzufügen.
pci=BUS:DEV.FUNC Hinzufügen eines PCI-Geräts zu einer Domain, unter Verwendung gegebener Parameter (in Hexadezimal), z. B. pci=c0:02.1a. Diese Option kann wiederholt werden, um mehrere PCI-Geräte hinzuzufügen.
ioports=FROM[-TO] Hinzufügen eines I/O-Wertebereich zu einer Domain, unter Verwendung gegebener Parameter (in Hexadezimal), z. B. ioports=02f8-02ff. Diese Option kann wiederholt werden, um mehrere I/O-Wertebereiche hinzuzufügen.
irq=IRQ Hinzufügen eines IRQ (Interrupt Line) zu einer Domain, z. B. irq=7. Diese Option kann wiederholt werden, um mehrere IRQs hinzuzufügen.
usbport=PATH Hinzufügen eines physischen USB-Ports zu einer Domain, wie durch den Pfad zum Port spezifiziert. Diese Option kann wiederholt werden, um mehrere Ports hinzuzufügen.
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
Hinzufügen einer Netzwerkschnittstelle mit der gegebenen MAC-Adresse und Bridge. Der vif wird konfiguriert durch Aufruf des Konfigurationsskripts. Falls "type" nicht spezifiziert ist, ist die standardmäßige Einstellung netfront und nicht ioemu-Gerät. Falls "MAC" nicht spezifiziert ist, wählt das Netzwerk-Backend seine eigene MAC Adresse willkürlich aus. Falls "bridge" nicht definiert ist, wird die erste Bridge verwendet, die gefunden wird. Falls "script" nicht spezifiziert ist, wird das Standardskript verwendet. Falls "backend" nicht spezifiziert ist, wird die standardmäßige Backend-Treiber-Domain verwendet. Falls "vifname" nicht spezifiziert ist, erhält die virtuelle Backend-Schnittstelle den Namen "vifD.N", wobei D die Domain-ID ist und N die Schnittstellen-ID ist. Diese Option kann wiederholt werden, um mehrere vifs hinzuzufügen. Das Spezifizieren von vifs erhöht je nach Bedarf die Anzahl an Schnittstellen.
vtpm=instance=INSTANCE,backend=DOM Hinzufügen einer TPM-Schnittstelle. Benutzen Sie auf der Backend-Seite die gegebene Instanz als virtuelle TPM-Instanz. Die gegebene Nummer ist nur die bevorzugte Instanznummer. Das Hotplug-Skript wird entscheiden, welche Instanznummer der Domain tatsächlich zugewiesen wird. Die Verknüpfung zwischen der virtuellen Maschine und der TPM-Instanznummer befindet sich in /etc/xen/vtpm.db. Benutzen Sie das Backend in der gegebenen Domain.
access_control=policy=POLICY,label=LABEL Fügen Sie eine Sicherheitskennung und den Verweis auf die Sicherheitsrichtlinie, die sie definiert, ein. Die lokale SSID-Referenz wird berechnet, wenn die Domain gestartet oder wieder gestartet wird. Zu diesem Zeitpunkt wird die Richtlinie auch mit der aktiven Richtlinie verglichen. Dadurch ist die Migration durch Speicher- oder Wiederherstellungsfunktionen gesichert und lokale Kennungen werden automatisch korrekt erzeugt im System, in dem eine Domain gestartet wird.
nics=NUM VERALTET. Benutzen Sie stattdessen leere VIF-Einträge. Einstellen der Anzahl von Netzwerkschnittstellen. Verwenden Sie die VIF-Option, um die Schnittstellenparamenter zu definieren, anderenfalls werden die Standards verwendet. Das Spezifizieren von vifs erhöht je nach Bedarf die Anzahl an Schnittstellen.
root=DEVICE Einstellen des root= Parameters in die Kernel-Befehlszeile. Benutzen Sie ein Gerät, z. B. /dev/sda1, oder /dev/nfs für NFS-Root.
extra=ARGS Setzen von zusätzlichen Parametern zum Anhängen an die Kernel-Befehlszeile.
ip=IPADDR Setzen der Kernel-IP-Schnittstellenadresse.
gateway=IPADDR Setzen des Kernel-IP-Gateways.
netmask=MASK Setzen der Kernel-IP-Netzmaske.
hostname=NAME Setzen des Kernel-IP-Hostnamens.
interface=INTF Setzen des Kernel-IP-Schnittstellennames.
dhcp=off|dhcp Setzen der Kernel-dhcp-Option.
nfs_server=IPADDR Setzen der Adresse des NFS-Servers für NFS-Root.
nfs_root=PATH Setzen des Pfads des Root-NFS-Verzeichnisses.
device_model=FILE Pfad zum Gerätemodell-Programm.
fda=FILE Pfad zu fda
fdb=FILE Pfad zu fdb
serial=FILE Pfad zu Serial oder PTY oder VC
localtime=no | yes Ist RTC auf Ortszeit gesetzt
keymap=FILE Setzen des Tastatur-Layouts
usb=no | yes Emulieren von USB-Geräten
usbdevice=NAME Name des hinzuzufügenden USB-Geräts
stdvga=no | yes Use std vga or Cirrus Logic graphics
isa=no | yes Simulieren eines ISA-Systems
boot=a|b|c|d Standardmäßiges Boot-Gerät
nographic=no | yes Sollen Gerätemodelle Grafiken verwenden?
soundhw=audiodev Sollten Gerätemodelle Audiogeräte aktivieren?
vnc Soll das Gerätemodell VNC verwenden?
vncdisplay Zu verwendenes VCN-Display
vnclisten Adresse, auf die der VNC Server horchen soll.
vncunused Versuchen, einen unbenutzten Port zu finden für den VNC-Server. Nur gültig wenn vnc=1
sdl Soll das Gerätemodell SDL verwenden?
display=DISPLAY Zu verwendendes X11 Display
xauthority=XAUTHORITY Zu verwendende X11 Authority
uuid Xenstore UUID (Universally Unique Identifier). Ist diese Option nicht gesetzt, wird zufällig eine UUID generiert, ganz wie bei der MAC-Adresse für virtuelle Netzwerkschnittstellen. Dies muss ein einzigartiger Wert im gesamten Cluster sein.

Tabelle 31.3, „Standardwerte der Konfigurationsparameter“ 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.
Tabelle 31.2. Python-Funktionen, die Parameterwerte setzen
Parser-Funktion Gültige Parameter
set_bool
Akzeptierte Werte:
  • 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
Akzeptiert jeden Python-Wert.
append_value
Akzeptiert jeden Python-Wert und fügt diesen dem vorangegangenen Wert, der in einem Array gespeichert ist, an.

Tabelle 31.3. Standardwerte der Konfigurationsparameter
Parameter Parser-Funktion Standardwert
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

Teil VII. Tipps und Tricks

Kapitel 32. Tipps und Tricks

Dieses Kapitel beinhaltet nützliche Hinweise und Tipps, um die Leistung, Skalierbarkeit und Stabilität der Virtualisierung zu verbessern.

32.1. Gäste automatisch starten

This section covers how to make virtualized guests start automatically during the host system's boot phase.
Dieses Beispiel verwendet virsh, um einen Gast namens TestServer so einzustellen, dass dieser automatisch startet, wenn der Host hochfährt.
# virsh autostart TestServer
Domain TestServer marked as autostarted
Der Gast startet nun automatisch mit dem Host.
Um zu deaktivieren, dass der Gast automatisch startet, verwenden Sie den --disable-Parameter.
# virsh autostart --disable TestServer
Domain TestServer unmarked as autostarted
Der Gast startet nun nicht mehr automatisch mit dem Host.

32.2. Wechseln zwischen dem KVM- und Xen-Hypervisor

Dieser Abschnitt behandelt das Wechseln zwischen dem KVM- und Xen-Hypervisor.
Red Hat unterstützt nur einen aktiven Hypervisor zur selben Zeit.

Migration von virtualisierten Gästen zwischen Hypervisoren

Derzeit existiert keine Applikationen zum Wechseln von Xen-basierten Gästen zu KVM-basierten Gästen bzw. umgekehrt. Gäste können ausschließlich auf dem Hypervisor-Typ verwendet werden, auf dem sie ursprünglich erzeugt wurden.

Warnung

Dieses Verfahren steht nur für die Intel 64 oder AMD64 Version von Red Hat Enterprise Linux 5.4 oder höher zur Verfügung. Es werden keine anderen Konfigurationen oder Red Hat Enterprise Linux Versionen unterstützt. KVM ist nicht verfügbar in Versionen vor Red Hat Enterprise Linux 5.4.

32.2.1. Xen zu KVM

Das folgende Verfahren beschreibt den Wechsel vom Xen-Hypervisor zum KVM-Hypervisor. Dieses Verfahren setzt voraus, dass das kernel-xen-Paket installiert und aktiviert ist.
  1. Installieren Sie das KVM-Paket

    Installieren Sie das kvm-Paket, sofern Sie das nicht bereits getan haben.
    # yum install kvm
    
  2. Überprüfen Sie, welcher Kernel verwendet wird

    Das kernel-xen-Paket kann installiert sein. Verwenden Sie den uname-Befehl, um festzustellen, welcher Kernel ausgeführt wird:
    $ uname -r
    2.6.18-159.el5xen
    
    Der aktuelle Kernel, "2.6.18-159.el5xen", läuft auf dem System. Falls der Standard-Kernel, "2.6.18-159.el5", ausgeführt wird, können Sie diesen Unterschritt überspringen.
    1. Wechsel vom Xen-Kernel zum Standard-Kernel

      In der grub.conf-Datei wird festgelegt, welcher Kernel gebootet wird. Um den Standard-Kernel zu ändern, bearbeiten Sie die /boot/grub/grub.conf-Datei wie unten veranschaulicht.
      								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
      
      Beachten Sie den default=1-Parameter. Dadurch wird der GRUB Bootloader angewiesen, den zweiten Eintrag – also den Xen-Kernel – zu booten. Ändern Sie den Standard auf 0 (oder die Nummer für den Standard-Kernel):
      								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. Starten Sie neu, um den neuen Kernel zu laden

    Starten Sie das System neu. Der Computer wird mit dem neuen Standard-Kernel starten. Das KVM-Modul sollte automatisch mit dem Kernel geladen werden. Überprüfen Sie, ob KVM läuft:
    $ lsmod | grep kvm
    kvm_intel              85992  1 
    kvm                   222368  2 ksm,kvm_intel
    
    Sofern alles einwandfrei geklappt hat, ist nun das kvm-Modul sowie entweder das kvm_intel-Modul oder das kvm_amd-Modul vorhanden.

32.2.2. KVM zu Xen

Das folgende Verfahren beschreibt den Wechsel vom KVM-Hypervisor zum Xen-Hypervisor. Dieses Verfahren setzt voraus, dass das kvm-Paket installiert und aktiviert ist.
  1. Installieren Sie die Xen-Pakete

    Installieren Sie das kernel-xen-Paket, sofern Sie das nicht bereits getan haben.
    # yum install kernel-xen xen
    
    Das kernel-xen-Paket kann installiert, aber deaktiviert sein.
  2. Überprüfen Sie, welcher Kernel verwendet wird

    Verwenden Sie den uname-Befehl, um festzustellen, welcher Kernel derzeit läuft.
    $ uname -r
    2.6.18-159.el5
    
    Der aktuelle Kernel, "2.6.18-159.el5", läuft auf dem System. Dies ist der Standard-Kernel. Wenn der Kernel auf xen endet (z. B. 2.6.18-159.el5xen), dann läuft der Xen-Kernel bereits und Sie können diesen Unterschritt überspringen.
    1. Wechsel vom Standard-Kernel zum Xen-Kernel

      In der grub.conf-Datei wird festgelegt, welcher Kernel gebootet wird. Um den Standard-Kernel zu ändern, bearbeiten Sie die /boot/grub/grub.conf-Datei wie unten veranschaulicht.
      								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
      
      Beachten Sie den default=0-Parameter. Dadurch wird der GRUB Bootloader angewiesen, den ersten Eintrag – also den Standard-Kernel – zu booten. Ändern Sie den Standard auf 1 (oder die Nummer für den Xen-Kernel):
      								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. Starten Sie neu, um den neuen Kernel zu laden

    Starten Sie das System neu. Der Computer wird mit dem neuen Xen-Kernel starten. Überprüfen Sie dies mit dem uname-Befehl:
    $ uname -r
    2.6.18-159.el5xen
    
    Falls die Ausgabe auf xen endet, wird der Xen-Kernel ausgeführt.

32.3. Verwenden von qemu-img

Das qemu-img-Befehlszeilen-Tool wird zur Formatierung verschiedener von Xen und KVM genutzter Dateisysteme verwendet. qemu-img sollte verwendet werden, um virtualisierte Gast-Images, zusätzliche Speichergeräte und Netzwerkspeicher zu formatieren. Die Verwendung und die verfügbaren Optionen von qemu-img werden im Folgenden erläutert.
Formatierung und Erstellung neuer Images oder Geräte
Erstellen Sie das neue Disk-Image "filename" mit der Größe size und dem Format format.
# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
Falls base_image spezifiziert ist, so wird das Image nur die Unterschiede zu base_image aufzeichnen. In diesem Fall ist keine Angabe der Größe nötig. base_image wird nie modifiziert werden, es sei denn, Sie verwenden den "commit" Monitor-Befehl.
Umwandeln eines existierenden Images in ein anderes Format
Die convert-Option wird verwendet, um ein anerkanntes Format in ein anderes Image-Format umzuwandeln.
Befehlsformat:
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
Konvertieren Sie das Disk-Image filename zu Disk-Image output_filename unter Verwendung des Formats output_format. Das Disk-Image kann optional mit der -e-Option verschlüsselt oder mit der -c-Option komprimiert werden.
Nur das Format "qcow" unterstützt Verschlüsselung oder Komprimierung. Die Komprimierung ist schreibgeschützt. Das heißt, wenn ein komprimierter Sektor neu geschrieben wird, wird dieser unkomprimiert beschrieben.
Die Verschlüsselung verwendet das AES-Format mit sehr sicherer 128 Bit Verschlüsselung. Wählen Sie ein langes Passwort (mehr als 16 Zeichen) für höchstmögliche Sicherheit.
Image-Konvertierung ist außerdem sehr hilfreich, um kleinere Images zu erhalten, wenn Sie ein Image-Format verwenden, das wachsen kann wie z. B. qcow oder cow. Die leeren Sektoren werden erkannt und für das Ziel-Image ausgeblendet.
Abrufen von Image-Informationen
Der info-Parameter zeigt Informationen über ein Disk-Image. Das Format der info-Option ist wie folgt:
# qemu-img info [-f format] filename
Gibt Informationen über das Disk-Image "filename". Verwenden Sie dies insbesondere dazu, die reservierte Größe auf der Festplatte festzustellen, denn diese kann abweichen von der angezeigten Größe. Falls vm-Schnappschüsse im Disk-Image gespeichert sind, werden auch diese angezeigt.
Unterstützte Formate
Das Format eines Images wird normalerweise automatisch erkannt. Die folgenden Formate werden unterstützt:
raw
Raw Disk-Image-Format (Standard). Dieses Format hat den Vorteil, dass es einfach exportierbar auf alle anderen Emulatoren ist. Falls Ihr Dateisystem Löcher unterstützt (z. B. ext2 oder ext3 unter Linux bzw. NTFS unter Windows), dann werden nur die beschriebenen Sektoren Platz belegen. Verwenden Sie qemu-img info, um die Größe festzustellen, die wirklich vom Image gebraucht wird, oder ls -ls unter Unix/Linux.
qcow2
QEMU Image-Format, das vielseitigste Format. Verwenden Sie es zur Erzeugung kleinerer Images (nützlich, wenn Ihr Dateisystem keine Löcher unterstützt, z. B. unter Windows), für optionale AES-Verschlüsselung, zlib-basierte Komprimierung und für Unterstützung verschiedener VM-Schnappschüsse.
qcow
Altes QEMU Image-Format. Nur zwecks Kompatibilität mit älteren Versionen enthalten.
cow
Benutzermodus Linux "Copy On Write" Image-Format. Das cow-Format ist nur zwecks Kompatibilität mit älteren Versionen enthalten. Es funktioniert nicht mit Windows.
vmdk
Mit VMware 3 und 4 kompatibles Image-Format.
cloop
Linux Compressed Loop Image, nur nützlich zum Wiederverwenden direkt komprimierter CD-ROM Images, wie sie z. B. auf Knoppix CD-ROMs vorliegen.

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.

Xen-Unterstützung

Memory overcommitting is not supported for the Xen hypervisor, however CPU overcommitting is supported.
Overcommitting von Speicher
Die meisten Betriebssysteme und Anwendungen nutzen nicht ständig 100% des zur Verfügung stehenden RAMs. Dieses Verhalten kann mit KVM ausgenutzt werden, um mehr Speicher für virtualisierte Gäste zu verwenden, als physisch verfügbar ist.
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.

Warnung

Falls nicht genügend Swap-Speicher zur Verfügung steht, werden Gastbetriebssysteme zwangsweise heruntergefahren. Dies kann dazu führen, dass Gäste funktionsunfähig werden. Sie sollten dies vermeiden, indem Sie niemals mehr Speicher zuweisen, als Swap zur Verfügung steht.
Die Swap-Partition wird verwendet, um wenig verwendeten Speicher zur Festplatte auszulagern, so dass die Speicherleistung erhöht wird. Die Standardgröße der Swap-Partition wird auf Grundlage der RAM-Menge und Overcommit-Rate berechnet. Es wird empfohlen, Ihre Swap-Partition größer anzulegen, wenn Sie beabsichtigen, Speicher-Overcommit mit KVM durchzuführen. Die empfohlene Rate für das Overcommiting liegt bei 50% (0,5). Die verwendete Formel lautet:
(0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
In der Red Hat Knowledgebase finden Sie einen Artikel darüber, wie die Größe der Swap-Partition sicher und effizient bestimmt werden kann.
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.
Es ist möglich, eine Overcommit-Rate von mehr als dem Zehnfachen der Anzahl virtualisierter Gäste über dem physischen RAM des Systems zu haben. Dies funktioniert nur mit bestimmten Anwendungsauslastungen (z. B. Desktop-Virtualisierung mit weniger als 100% Auslastung). Die Formel zum Einstellen der Overcommit-Rate ist nicht sehr kompliziert, Sie müssen nur Ihre Rate testen und an Ihre Umgebung anpassen.
Overcommitting von virtualisierten CPUs
Der KVM-Hypervisor unterstützt das Overcommitting von virtualisierten CPUs. Das Overcommitting von virtualisierten CPUs wird nur durch die Auslastungsgrenze virtualisierter Gäste beschränkt. Seien Sie beim Overcommitting von virtualisierten CPUs jedoch vorsichtig, denn Auslastungen von beinahe 100% können dazu führen, dass Anfragen verworfen werden oder die Antwortzeiten untragbar lang werden.
Das Overcommitting von virtualisierten CPUs geht am besten, wenn jeder virtualisierte Gast nur über eine einzige VCPU verfügt. Der Linux Scheduler arbeitet sehr effizient mit dieser Art Auslastung. KVM sollte Gäste mit Auslastungen unter 100% bei einer Rate von fünf VCPUs sicher unterstützen. Overcommitting von virtualisierten Gästen mit einfachem VCPU stellt kein Problem dar.
Sie können kein Overcommitting bei Gästen mit symmetrischem Multiprocessing für mehr als die Anzahl physischer Prozessorkerne durchführen. Zum Beispiel sollte ein Gast mit vier VCPUs nicht auf einem Host mit Dual Core Prozessor ausgeführt werden. Overcommitting bei Gästen mit symmetrischem Multiprocessing für mehr als die Anzahl physischer Prozessorkerne hat deutliche Leistungseinbußen zur Folge.
Sie können Gästen VCPUs bis zur Anzahl der physischen Prozessorkerne zuweisen, dies funktioniert einwandfrei. So können Sie beispielsweise virtualisierte Gäste mit vier VCPUs auf einem Quad Core Host ausführen. Gäste mit Auslastungen von unter 100% sollten mit dieser Konfiguration effektiv arbeiten können.

Grundsätzlich vorher testen

Wenden Sie in einer Produktionsumgebung kein Overcomitting von Speicher oder CPUs an, ohne vorher umfangreiche Tests durchgeführt zu haben. Anwendungen, die 100% des Speichers oder der Prozessorressourcen brauchen, können in Umgebungen mit Overcommitment instabil werden. Testen Sie also gründlich vor dem Einsatz.

32.5. Modifizieren von /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.
Die Ausgabe unten ist ein Beispiel für einen grub.conf-Eintrag eines Systems, auf dem das kernel-xen-Paket läuft. Die grub.conf auf Ihrem System kann davon abweichen. Der wichtige Teil in dem unteren Beispiel ist der Abschnitt ab der title-Zeile bis zum Beginn der nächsten neuen Zeile.
#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

Wichtiger Hinweis zum Bearbeiten von grub.conf

Your grub.conf could look very different if it has been manually edited before or copied from an example. Read Kapitel 28, Konfigurieren der Xen-Kernel-Boot-Parameter for more information on using virtualization and grub.
Um die Menge an Arbeitsspeicher für Ihr Host-System zur Bootzeit auf 250 MB zu stellen, müssen Sie dom0_mem=256M in der xen-Zeile in Ihrer grub.conf eingeben. Sehen Sie eine modifizierte Version der Grub-Konfigurationsdatei im folgenden Beispiel:
#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. Überprüfen der Virtualisierungserweiterungen

Dieser Abschnitt hilft Ihnen dabei festzustellen, ob Ihr System die nötigen Hardware-Virtualisierungserweiterungen besitzt. Virtualisierungserweiterungen (Intel VT oder AMD-V) sind für volle Virtualisierung erforderlich.

Kann ich Virtualisierung ohne die Virtualisierungserweiterungen nutzen?

Falls Virtualisierungserweiterungen nicht vorhanden sind, können Sie die Xen-Paravirtualisierung mit dem Red Hat kernel-xen-Paket nutzen.
  1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die CPU-Virtualisierungserweiterungen zur Verfügung stehen:
    $ grep -E 'svm|vmx' /proc/cpuinfo
    
  2. Analyze the output.
    • Die folgende Ausgabe enthält einen vmx-Eintrag, wodurch angezeigt wird, dass ein Intel-Prozessor mit den Intel VT Erweiterungen vorhanden ist:
      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
      
    • Die folgende Ausgabe enthält einen svm-Eintrag, wodurch angezeigt wird, dass ein AMD-Prozessor mit den AMD-V Erweiterungen vorhanden ist:
      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.
    Der "flags:" Inhalt kann mehrmals erscheinen für jeden Hyperthread, Kern oder CPU auf dem System.
    The virtualization extensions may be disabled in the BIOS. If the extensions do not appear or full virtualization does not work refer to Prozedur 35.1, „Aktivieren der Virtualisierungserweiterungen im 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.

Warnung

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.
Prozedur 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. Generieren einer neuen, eindeutigen MAC-Adresse

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()
Eine andere Methode zum Generieren einer neuen MAC-Adresse für Ihren Gast
Sie können auch die integrierten Module von python-virtinst verwenden, um eine neue MAC-Adresse und UUID zur Verwendung in einer Gastkonfigurationsdatei zu generieren:
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
Das obige Skript kann ebenfalls als eine Skriptdatei implementiert werden, wie unten gezeigt.
#!/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. Begrenzen der Netzwerkbandbreite für einen Xen-Gast

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.
Liste der Variablen:
rate
The rate= option can be added to the VIF= entry in a virtual machine configuration file to limit a virtual machine's network bandwidth or specify a specific time interval for a time window.
time window
Das "time window" (Zeitfenster) ist optional zur rate=-Option:
Das standardmäßige Zeitfenster ist 50 ms.
Ein kleineres Zeitfenster wird zu weniger fehlgeschlagenen Übertragungen führen, allerdings wird die Auffüllungsrate und Latenz erhöht.
Das standardmäßige 50 ms Zeitfenster ist ein guter Kompromiss zwischen Latenz und Datendurchsatz und muss in den meisten Fällen nicht geändert werden.
Beispiele für rate-Parameterwerte und Verwendung.
rate=10Mb/s
Begrenzt den ausgehenden Netzwerkverkehr des Gasts auf 10 MB/s.
rate=250KB/s
Begrenzt den ausgehenden Netzwerkverkehr des Gasts auf 250 MB/s.
rate=10MB/s@50ms
Begrenzt die Bandbreite auf 10 MB/s und stellt dem Gast alle 50 ms einen 50 KB Datenblock bereit.
In der Konfiguration der virtuellen Maschine würde ein VIF-Beispieleintrag wie folgt aussehen:
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. Konfigurieren von Xen-Prozessoraffinitäten

Xen kann virtuelle CPUs zu einem oder mehreren Host-CPUs zuweisen. Dadurch werden echte Prozessorressourcen den virtualisierten Gästen zugewiesen. Diese Herangehensweise ermöglicht es Red Hat Enterprise Linux, Prozessorressourcen beim Einsatz von Dual-Core, Hyperthreading oder anderen CPU-Concurrency-Technologien zu optimieren. Der Xen-Credit-Scheduler verteilt virtuelle CPUs automatisch auf physische CPUs, um die Systemleistung zu maximieren. Red Hat Enterprise Linux erlaubt es dem Credit-Scheduler, CPUs je nach Bedarf umzuverteilen, solange die virtuelle CPU mit einer physischen CPU verbunden ist.
Wenn Sie I/O-intensive Aufgaben durchführen, wird empfohlen, entweder einen Hyperthread oder einen ganzen Prozessorkern der Ausführung von domain0 zu widmen.
Beachten Sie, dass dies für KVM nicht notwendig ist, da KVM den standardmäßigen Linux-Kernel-Scheduler verwendet.
CPU-Affinitäten können mit Hilfe von virsh oder virt-manager eingestellt werden:
To set CPU affinities using virsh refer to Konfigurieren der Affinität einer virtuellen CPU for more information.
To configure and view CPU information with virt-manager refer to Abschnitt 26.11, „Anzeigen virtueller CPUs“ for more information.

32.12. Modifizieren des Xen-Hypervisors

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 bietet Zugang zu Installationsbäumen für paravirtualisierte Gäste (z. B. die Red Hat Enterprise Linux 5 Depots) oder anderen Daten. Falls Sie während der Server-Installation vsftpd noch nicht installiert haben, können Sie das RPM-Paket im Server-Verzeichnis Ihres Installationsmediums finden und es mittels rpm -ivh vsftpd*.rpm installieren (beachten Sie, dass sich das RPM-Paket in Ihrem aktuellen Verzeichnis befinden muss).
  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. Überprüfen Sie mittels chkconfig --list vsftpd, dass vsftpd nicht aktiviert ist:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
    
  3. Führen Sie chkconfig --levels 345 vsftpd on aus, damit vsftpd für Runlevel 3, 4 und 5 automatisch gestartet wird.
  4. Verwenden Sie den Befehl chkconfig --list vsftpd, um sich zu vergewissern, dass vsftdp für den automatischen Start beim Hochfahren des Systems aktiviert wurde:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
    
  5. Verwenden Sie service vsftpd start vsftpd, um den vsftpd-Dienst zu starten:
    $service vsftpd start vsftpd
    Starting vsftpd for vsftpd:                  [  OK  ]
    

32.14. Konfigurieren von LUN-Persistenz

This section covers how to implement LUN persistence in guests and on the host machine with and without multipath.
Implementierung von LUN-Persistenz ohne Mulitpath
Falls Ihr System kein Multipath verwendet, können Sie udev verwenden, um LUN-Persistenz zu implementieren. Bevor Sie die LUN-Persistenz auf Ihrem System implementieren, stellen Sie sicher, dass Sie die passenden UUIDs erhalten. Sobald Sie diese haben, können Sie die LUN-Persistenz konfigurieren, indem Sie die Datei scsi_id bearbeiten, die sich im /etc-Verzeichnis befindet. Sobald Sie diese Datei in einem Texteditor geöffnet haben, müssen Sie die folgende Zeile auskommentieren:
# options=-b
Ersetzen Sie dies anschließend durch diesem Parameter:
# options=-g
Dies veranlasst udev, alle SCSI-Geräte des Systems auf zurückkehrende UUIDs zu überwachen. Um die UUIDs des Systems zu ermitteln, verwenden Sie den Befehl scsi_id:
# scsi_id -g -s /block/sdc
*3600a0b80001327510000015427b625e*
Diese lange Zeichenkette ist die UUID. Die UUID verändert sich nicht, wenn Sie ein neues Gerät zu Ihrem System hinzufügen. Ermitteln Sie die UUID für jedes Gerät, um Regeln für diese Geräte erstellen zu können. Um neue Regeln für Geräte zu erstellen, müssen Sie die Datei 20-names.rules bearbeiten, die sich im Verzeichnis /etc/udev/rules.d befindet. Die Regeln zur Benennung der Geräte haben das folgende Format:
# KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="UUID", NAME="devicename"
Ersetzen Sie Ihre bestehende UUID und den devicename mit dem oben erhaltenen UUID-Eintrag. Die Regel sollte daher wie folgt lauten:
KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="3600a0b80001327510000015427b625e", NAME="mydevicename"
Dies veranlasst das System, sämtliche Geräte, die mit /dev/sd* übereinstimmen, zu aktivieren, um die festgelegten UUID zu untersuchen. Wird ein passendes Gerät gefunden, wird ein Geräteknoten mit der Bezeichnung /dev/devicename erstellt. In diesem Beispiel ist der Geräteknoten /dev/mydevice. Abschließend müssen Sie noch die Datei /etc/rc.local anhängen mit der Zeile:
/sbin/start_udev
Implementierung von LUN-Persistenz mit Multipath
Um LUN-Persistenz in einer Multipath-Umgebung zu implementieren, müssen Sie den Alias-Namen für die Multipath-Geräte definieren. Bei diesem Beispiel müssen Sie vier Geräte-Aliasse definieren, indem Sie die Datei multipath.conf, die sich im Verzeichnis /etc/ befindet, bearbeiten:
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp1
}
multipath  {  
             wwid       3600a0b80001327510000015427b6
             alias      oramp2
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp3
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp4
}
Dies definiert vier LUNs: /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 und dev/mpath/oramp4. Diese Geräte befinden sich im Verzeichnis /dev/mpath. Die LUN-Namen bleiben auch über Neustarts hinaus bestehen, da Alias-Namen auf den wwid (weltweiten ID) der LUNs erstellt werden.

32.15. Abschalten der SMART-Disk-Überwachung von Gästen

Die SMART-Disk-Überwachung kann deaktiviert werden, da wir nur mit virtuellen Platten arbeiten und der eigentliche physische Speicher vom Host verwaltet wird.
/sbin/service smartd stop
/sbin/chkconfig --del smartd

32.16. Bereinigen alter Xen-Konfigurationsdateien

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. Konfigurieren eines VNC-Servers

Sie können einen VNC-Server konfigurieren mit Hilfe der Entfernter Desktop-Anwendung in System > Einstellungen. Alternativ können Sie auch den Befehl vino-preferences ausführen.
Mit den folgenden Schritten können Sie eine dezidierte VNC-Server-Sitzung einrichten:
  1. Bearbeiten Sie die ~/.vnc/xstartup-Datei, um eine GNOME-Sitzung zu starten, sobald vncserver gestartet wird. Bei der ersten Ausführung des vncserver-Skripts werden Sie nach einen Passwort gefragt, das Sie für die VNC-Sitzung verwenden möchten.
  2. Eine Beispiel-xstartup-Datei:
    #!/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. Klonen von Gastkonfigurationsdateien

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.
Sie müssen die HWADDR-Adresse der /etc/sysconfig/network-scripts/ifcfg-eth0-Datei modifizieren, um mit der Ausgabe von ifconfig eth0 übereinzustimmen. Falls Sie eine statische IP-Adresse verwenden, müssen Sie den Eintrag IPADDR modifizieren.

32.19. Kopieren eines existierenden Gasts und seiner Konfigurationsdatei

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
Der Name Ihres Gasts, wie er im Hypervisor bekannt ist und in Verwaltungsdiensten angezeigt wird. Dieser Eintrag sollte in Ihrem System eindeutig sein.
uuid
Eine eindeutige Kennung für den Gast; eine neue UUID kann durch den Befehl uuidgen erstellt werden. Eine Beispiel-Ausgabe der 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 Abschnitt 32.9, „Generieren einer neuen, eindeutigen MAC-Adresse“.
  • Falls Sie eine existierende Gastkonfigurationsdatei auf einen neuen Host verschieben oder kopieren, müssen Sie sicherstellen, dass Sie den xenbr-Eintrag anpassen, um mit Ihrer lokalen Netzwerkkonfiguration übereinzustimmen. (Sie können die Bridge-Informationen mit Hilfe des Befehls brctl show erhalten.)
  • Stellen Sie sicher, dass Sie die Geräteeinträge in dem disk=-Abschnitt eingestellt haben, um auf das richtige Gast-Image zu verweisen.
Passen Sie nun die Systemkonfigurationseinstellungen auf Ihrem Gast an:
/etc/sysconfig/network
Modify the HOSTNAME entry to the guest's new hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • Ändern Sie die HWADDR-Adresse auf die Ausgabe von ifconfig eth0.
  • Modifizieren Sie den IPADDR-Eintrag, falls statische IP-Adressen verwendet werden.

Kapitel 33. Erstellung angepasster libvirt-Skripte

Die Informationen in diesem Abschnitt sind hilfreich für Programmierer und Systemadministratoren, die sich das Schreiben angepasster Skripte durch Verwendung von libvirt vereinfachen möchten.
Kapitel 32, Tipps und Tricks is recommended reading for programmers thinking of writing new applications which use libvirt.

33.1. Verwendung von XML-Konfigurationsdateien mit 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

Teil VIII. Suche und Beseitigung von Fehlern (Troubleshooting)

Einführung in die Suche und Beseitigung von Fehlern

Das folgende Kapitel bietet Informationen, die Ihnen bei der Suche und Beseitigung von Fehlern, die beim Einsatz der Virtualisierung auftreten können, helfen sollen.

Wichtiger Hinweis zu Virtualisierungsproblemen

Aufgrund der ständigen Weiterentwicklung, bei der sowohl Fehler behoben als auch manchmal neue verursacht werden, ist Ihr spezielles Problem eventuell noch nicht in diesem Handbuch enthalten. Werfen Sie für die aktuellste Liste aller bekannten Fehler, Probleme und Problemlösungen einen Blick auf die Red Hat Enterprise Linux Release Notes für Ihre Version und Hardware-Architektur. Die Release Notes finden Sie im Dokumentationsbereich der Red Hat Website, www.redhat.com/docs/manuals/enterprise/.

Wenn alles andere nicht hilft...

Setzen Sie sich mit dem Red Hat Global Support Service in Verbindung (https://www.redhat.com/apps/support/). Unsere Mitarbeiter können Sie bei der Lösung Ihres Problems unterstützen.

Inhaltsverzeichnis

34. Suche und Beseitigung von Fehlern (Troubleshooting) in Xen
34.1. Suche und Beseitigung von allgemeinen Fehlern (Troubleshooting) und Programmfehlern (Debugging) in Xen
34.2. Überblick über Protokolldateien
34.3. Beschreibung der Protokolldateien
34.4. Speicherorte wichtiger Verzeichnisse
34.5. Suche und Beseitigung von Fehlern mit Hilfe der Protokolldateien
34.6. Suche und Beseitigung von Fehlern mit der seriellen Konsole
34.7. Konsolenzugriff bei paravirtualisierten Gästen
34.8. Konsolenzugriff bei voll virtualisierten Gästen
34.9. Häufige Probleme mit Xen
34.10. Fehler bei der Erstellung eines Gasts
34.11. Suche und Beseitigung von Fehlern mit seriellen Konsolen
34.11.1. Serielle Konsolenausgabe für Xen
34.11.2. Xen serielle Konsolenausgabe von paravirtualisierten Gästen
34.11.3. Serielle Konsolenausgabe von voll virtualisierten Gästen
34.12. Xen-Konfigurationsdateien
34.13. Interpretation von Xen-Fehlermeldungen
34.14. Aufbau der Protokollverzeichnisse
35. Suche und Beseitigung von Fehlern (Troubleshooting)
35.1. Identifizieren von verfügbarem Speicher und Partitionen
35.2. Nach Neustart von Xen-basierten Gästen bleibt die Konsole hängen
35.3. Virtualisierte Ethernet-Geräte werden nicht von den Netzwerk-Tools erkannt
35.4. Fehler bei Loop-Gerät
35.5. Domain-Erstellung schlägt fehl aufgrund von zu wenig Arbeitsspeicher
35.6. Fehler durch falsches Kernel-Image
35.7. Fehler durch falsches Kernel-Image – nicht-PAE-Kernel auf einer PAE-Plattform
35.8. Voll virtualisierter 64 Bit Gast kann nicht hochfahren
35.9. Ein fehlender Localhost-Eintrag führt zum Fehlschlagen von virt-manager
35.10. Microcode-Fehler beim Hochfahren des Gasts
35.11. Python-Warnmeldungen (Deprecation) beim Start einer virtuellen Maschine
35.12. Aktivieren der Intel VT und AMD-V Virtualisierungs-Hardware-Erweiterungen im BIOS
35.13. KVM-Netzwerkleistung
36. Suche und Beseitigung von Fehlern (Troubleshooting) bei Xen paravirtualisierten Treibern
36.1. Protokolldateien und -verzeichnisse der Red Hat Enterprise Linux 5 Virtualisierung
36.2. Paravirtualisierter Gast kann nicht auf einem Red Hat Enterprise Linux 3 Gastbetriebssystem geladen werden
36.3. Während der Installation des paravirtualisierten Treibers auf Red Hat Enterprise Linux 3 wird eine Warnmeldung angezeigt
36.4. Manuelles Laden der paravirtualisierten Treiber
36.5. Überprüfen des erfolgreichen Ladens der paravirtualisierten Treiber
36.6. Das System hat einen begrenzten Datendurchsatz mit paravirtualisierten Treibern

Kapitel 34. Suche und Beseitigung von Fehlern (Troubleshooting) in Xen

Dieses Kapitel behandelt die grundlegenden Verfahren, die Ihnen die Suche und Beseitigung von Fehlern (Troubleshooting) in Xen erleichtern sollen. Die in diesen Kapitel enthaltenen Themen zur Suche und Beseitigung von Fehlern sind:
  • Tools zur Suche und Beseitigung von Fehlern für Linux und Virtualisierung.
  • Techniken zur Identifizierung von Problemen.
  • Speicherorte von Protokolldateien samt Erklärung der Inhalte.
Dieses Kapitel soll Ihnen das Hintergrundwissen liefern, das Sie brauchen, um identifizieren zu können, wo Probleme mit der Virtualisierungstechnologie liegen. Die Suche und Beseitigung von Fehlern braucht vor allem Übung und Erfahrung, was naturgemäß schwierig aus einem Buch zu erlernen ist. Daher wird empfohlen, dass Sie Virtualisierung auf Red Hat Enterprise Linux selbst testen und damit experimentieren, um Ihre Fähigkeiten zur Suche und Beseitigung von Fehlern stetig zu verbessern.
If you cannot find the answer in this document there may be an answer online from the virtualization community. Refer to Abschnitt A.1, „Online-Informationsquellen“ for a list of Linux virtualization websites.

34.1. Suche und Beseitigung von allgemeinen Fehlern (Troubleshooting) und Programmfehlern (Debugging) in Xen

Dieser Abschnitt fasst die Systemadministratoranwendungen, die Netzwerkdienstprogramme und die Tools zur Suche und Bereinigung von Programmfehlern zusammen. Sie können diese standardmäßigen Systemadministrations-Tools und Protokolldateien für die Suche und Beseitigung von allgemeinen Fehlern zu Hilfe nehmen.
Nützliche Befehle und Anwendungen für die Suche und Beseitigung von Fehlern
xentop
xentop zeigt Echtzeitinformationen über ein Host-System und die Gast-Domains an.
xm
Verwendet dmesg und log
  • vmstat
  • iostat
  • lsof
Die Befehle iostat, mpstat und sar werden alle vom sysstat-Paket bereitgestellt.
Die folgenden Prokolldateien und erweiterten Tools zur Suche und Bereinigung von Programmfehlern können Sie für die Fehlersuche und -beseitigung zu Hilfe nehmen:
  • XenOprofile
  • systemtap
  • crash
  • sysrq
  • sysrq t
  • sysrq w
Diese Netzwerk-Tools können bei der Suche und Beseitigung von Netzwerkfehlern bei Virtualisierung helfen:
  • 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 ist ein Netzwerk-Tool, das die Konfiguration der Ethernet-Bridge im Virtualisierungs-Linux-Kernel untersucht und konfiguriert. Sie müssen über Root-Rechte verfügen, um diese Beispielbefehle ausführen zu können:
    # 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
    
Nachfolgend sind einige weitere hilfreiche Befehle aufgeführt, die Sie zur Suche und Beseitigung von Fehlern bei der Virtualisierung auf Red Hat Enterprise Linux 5 verwenden können. Alle genannten Dienstprogramme sind im Server-Depot von Red Hat Enterprise Linux 5 zu finden.
  • strace ist ein Befehl zum Nachverfolgen von Systemaufrufen und Ereignissen, die von anderen Prozessen empfangen oder verwendet werden.
  • vncviewer: connect to a VNC server running on your server or a virtual machine. Install vncviewer using the yum install vnc command.
  • vncserver: startet einen Remote-Desktop auf Ihrem Server. Gibt Ihnen die Möglichkeit, grafische Benutzeroberflächen wie z. B. virt-manager über eine Remote-Sitzung auszuführen. Installieren Sie vncserver mit Hilfe des Befehls yum install vnc-server.

34.2. Überblick über Protokolldateien

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:
  • Das Xen-Konfigurationsverzeichnis ist /etc/xen/. Dieses Verzeichnis enthält den xend-Daemon und andere Konfigurationsdateien der virtuellen Maschine. Die Netzwerkskriptdateien befinden sich im script-Verzeichnis.
  • Alle Xen-Protokolldateien werden im /var/log/xen-Verzeichnis gespeichert.
  • Das Standardverzeichnis für alle dateibasierten Images ist das /var/lib/libvirt/images-Verzeichnis.
  • Xen-Kernel-Information wird im /proc/xen/-Verzeichnis gespeichert.

34.3. Beschreibung der Protokolldateien

Xen ist mit dem xend-Daemon und dem qemu-dm-Prozess ausgestattet. Beide Dienstprogramme schreiben mehrere Protokolldateien in das Verzeichnis /var/log/xen/:
  • xend.log ist die Protokolldatei, die sämtliche Daten enthält, die vom xend-Daemon gesammelt werden, unabhängig davon, ob es sich dabei um ein normales Systemereignis oder eine durch den Benutzer initiierte Aktion handelt. Alle Operationen der virtuellen Maschine (wie z. B. erstellen, herunterfahren, zerstören etc.) werden hier aufgezeichnet. xend.log ist normalerweise die erste Anlaufstelle, wenn Sie Problemen mit der Leistung oder mit Ereignissen nachgehen. Diese Datei enthält detaillierte Einträge und Umstände der Fehlermeldungen.
  • xend-debug.log ist die Protokolldatei, die Einträge von Ereignisfehlern von xend sowie der Virtualisierungssubsysteme (wie beispielsweise Framebuffer, Python-Skripte etc.) beinhaltet.
  • xen-hotplug-log ist die Protokolldatei, die Daten von Hotplug-Ereignissen beinhaltet. Falls ein Gerät oder ein Netzwerkskript sich nicht online stellen lässt, wird dieses Ereignis hier festgehalten.
  • qemu-dm.[PID].log ist die Protokolldatei, die vom qemu-dm-Prozess für jeden voll virtualisierten Gast erstellt wird. Bei der Verwendung dieser Protokolldatei müssen Sie die Prozess-ID (PID) des vorhandenen qemu-dm-Prozesses mit Hilfe des Befehls ps ermitteln, um Prozessargumente zur Isolierung des qemu-dm-Prozesses auf der virtuellen Maschine zu untersuchen. Beachten Sie bitte, dass Sie das [PID]-Symbol durch die tatsächliche PID des qemu-dm-Prozesses ersetzen müssen.
Falls Sie auf irgendwelche Fehler mit dem Virtual Machine Manager stoßen, können Sie die generierten Daten in der Datei virt-manager.log untersuchen, welche sich im Verzeichnis /.virt-manager befindet. Beachten Sie bitte, dass der Inhalt dieser Protokolldatei bei jedem Neustart des Virtual Machine Manager überschrieben wird. Stellen Sie daher sicher, dass Sie eine Sicherungskopie der Datei virt-manager.log erstellen, bevor Sie den Virtual Machine Manager nach einem Systemfehler neu starten.

34.4. Speicherorte wichtiger Verzeichnisse

Es gibt noch weitere Dienstprogramme und Protokolldateien, an die Sie bei der Nachverfolgung, Suche und Beseitigung von Fehlern in Xen denken sollten.
  • Die Images virtueller Gäste befinden sich im Verzeichnis /var/lib/libvirt/images.
  • Wenn Sie den xend-Daemon neu starten, aktualisiert dieser die xend-database, die sich im Verzeichnis /var/lib/xen/xend-db befindet.
  • Speicherauszüge (Dumps) virtueller Maschinen (die Sie mit dem Befehl xm dump-core durchführen) befinden sich im Verzeichnis /var/lib/xen/dumps.
  • Das Verzeichnis /etc/xen enthält die Konfigurationsdateien, die Sie zur Verwaltung der Systemressourcen verwenden. Die Konfigurationsdatei des xend-Daemon ist /etc/xen/xend-config.sxp. Sie können diese Datei bearbeiten, um systemweite Änderungen zu implementieren und das Netzwerk zu konfigurieren. Allerdings wird das manuelle Bearbeiten der Dateien im /etc/xen/-Verzeichnis nicht empfohlen.
  • Die proc-Verzeichnisse sind eine weitere Quelle zum Sammeln von Systeminformationen. Diese proc-Einträge befinden sich im Verzeichnis /proc/xen:
/proc/xen/capabilities
/proc/xen/balloon
/proc/xen/xenbus/

34.5. Suche und Beseitigung von Fehlern mit Hilfe der Protokolldateien

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')
Die andere Protokolldatei, xend-debug.log ist sehr nützlich für Systemadministratoren, da sie noch detailliertere Informationen als xend.log enthält. Nachfolgend finden Sie dieselben Fehlerdaten für dasselbe Problem bei der Erstellung einer Kernel-Domain:
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
Wenn Sie sich mit einem Mitarbeiter der technischen Kundenbetreuung in Verbindung setzen, fügen Sie immer eine Kopie dieser beiden Protokolldateien an.

34.6. Suche und Beseitigung von Fehlern mit der seriellen Konsole

The serial console is helpful in troubleshooting difficult problems. If the Virtualization kernel crashes and the hypervisor generates an error, there is no way to track the error on a local host. However, the serial console allows you to capture it on a remote host. You must configure the host to output data to the serial console. Then you must configure the remote host to capture the data. To do this, you must modify these options in the grub.conf file to enable a 38400-bps serial console on com1 /dev/ttyS0:
title Red Hat Enterprise Linux (2.6.18-8.2080_xen0)
	root (hd0,2)
	kernel /xen.gz-2.6.18-8.el5 com1=38400,8n1 
	module /vmlinuz-2.618-8.el5xen ro root=LABEL=/rhgb quiet console=xvc console=tty xencons=xvc 	
	module /initrd-2.6.18-8.el5xen.img
sync_console kann beim Aufspüren eines Problems helfen, das das Hängenbleiben mit der asynchronen Hypervisor-Konsolenausgabe verursacht. "pnpacpi=off" bietet eine Umgehungsmöglichkeit für ein Problem, das die Eingabe auf einer seriellen Konsole abbricht. Die Parameter "console=ttyS0" und "console=tty" veranlassen, dass Kernel-Fehler sowohl auf der normalen VGA-, als auch auf der seriellen Konsole protokolliert werden. Anschließend können Sie ttywatch installieren und einrichten, um Daten auf einem Remote-Host, der mit einem standardmäßigen Null-Modem-Kabel verbunden ist, aufzuzeichnen. Beispielsweise können Sie auf dem Remote-Host folgendes eingeben:

Suche und Beseitigung von Fehlern mit serieller Konsole auf Itanium

To access the hypervisor via a serial console on the Itanium® architecture you must enable the console in ELILO. For more information on configuring ELILO, refer to Kapitel 29, Konfigurieren von ELILO.
ttywatch --name myhost --port /dev/ttyS0
Dies leitet die Ausgabe von /dev/ttyS0 in die Datei /var/log/ttywatch/myhost.log um.

34.7. Konsolenzugriff bei paravirtualisierten Gästen

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. Konsolenzugriff bei voll virtualisierten Gästen

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. Häufige Probleme mit Xen

Beim Versuch, den xend-Dienst zu starten, passiert nichts. Beim Eintippen von virsh list erhalten Sie folgende Meldung:
Error: Error connecting to xend: Connection refused. Is xend running?
Beim Versuch, xend start manuell auszuführen, erhalten Sie weitere Fehler:
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' )
Mit großer Wahrscheinlichkeit haben Sie Ihren Host mit einem Kernel neu gestartet, der kein xen-hypervisor-Kernel ist. Um dies zu korrigieren, müssen Sie den kernel-xen-Kernel zum Zeitpunkt des Bootens auswählen (oder den kernel-xen-Kernel als Standard in Ihrer grub.conf-Datei) definieren.

34.10. Fehler bei der Erstellung eines Gasts

Wenn Sie versuchen, einen Gast zu erstellen, erhalten Sie die Fehlermeldung "Invalid argument". Dies bedeutet üblicherweise, dass das Kernel-Image, das Sie versuchen zu booten, nicht mit dem Hypervisor kompatibel ist. Ein Beispiel dafür wäre der Versuch, einen Nicht-PAE FC5-Kernel auf einem reinen PAE FC6-Hypervisor auszuführen.
Beim Ausführen eines Yum-Updates zum Erhalt eines neuen Kernels wird der Standard-Kernel in grub.conf zurück auf einen Bare-Metal-Kernel gesetzt, anstatt auf den Virtualisierungs-Kernel.
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. Suche und Beseitigung von Fehlern mit seriellen Konsolen

Linux-Kernel können Informationen an serielle Ports ausgeben. Dies ist hilfreich bei der Suche und Bereinigung von Programmfehlern im Zusammenhang mit Kernel-Panics und Hardware-Problemen mit Grafikgeräten oder kopflosen Servern. Die Unterabschnitte dieses Kapitels behandeln das Einrichten von serieller Konsolenausgabe für Maschinen, auf denen Red Hat Enterprise Linux Virtualisierungs-Kernels laufen, sowie deren Gäste.

34.11.1. Serielle Konsolenausgabe für Xen

By default, the serial console for the Xen hypervisor is disabled and no data is output from serial ports.
Um Kernel-Informationen auf einem seriellen Port zu erhalten, bearbeiten Sie die /boot/grub/grub.conf-Datei und stellen die entsprechenden seriellen Geräteparameter ein.
Falls Ihre serielle Konsole auf com1 liegt, bearbeiten Sie /boot/grub/grub.conf und fügen dabei die Zeilen com1=115200,8n1, console=tty0 und console=ttyS0,115200 an unten gezeigter Stelle ein.
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
Falls Ihre serielle Konsole auf com2 liegt, bearbeiten Sie /boot/grub/grub.conf und fügen dabei die Zeilen com2=115200,8n1 console=com2L, console=tty0 und console=ttyS0,115200 an unten gezeigter Stelle ein.
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
Speichern Sie die Änderungen und starten den Host anschließend neu. Der Hypervisor gibt nun serielle Daten auf der seriellen Schnittstelle aus (com1, com2 usw.), die Sie im vorigen Schritt ausgewählt haben.
Beachten Sie im Beispiel mit dem com2-Port, dass der Parameter console=ttyS0 in der vmlinuz-Zeile verwendet wird. Das Verhalten, dass alle Ports als console=ttyS0 verwendet werden, ist nicht standardmäßiges Linux-Verhalten, sondern vielmehr spezifisch für die Xen-Umgebung.

34.11.2. Xen serielle Konsolenausgabe von paravirtualisierten Gästen

Dieser Abschnitt beschreibt, wie eine virtualisierte serielle Konsole für Red Hat Enterprise Linux paravirtualisierte Gäste konfiguriert wird.
Serielle Konsolenausgabe von paravirtualisierten Gästen kann abgerufen werden mittels "virsh console" oder im "Serielle Konsole"-Fenster des virt-manager. Richten Sie die virtuelle Konsole nach folgendem Verfahren ein:
  1. Melden Sie sich bei Ihrem paravirtualisierten Gast an.
  2. Bearbeiten Sie die /boot/grub/grub.conf-Datei wie folgt:
    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. Starten Sie den paravirtualisierten Gast neu.
Sie sollten Kernel-Meldungen nun auf der virt-manager "Seriellen Konsole" und der "virsh-Console" erhalten.
Protokollieren der seriellen Konsolenausgabe einer paravirtualisierten Domain
Der Xen-Daemon (xend) kann so konfiguriert werden, dass die Ausgabe von seriellen Konsolen virtueller Gäste protokolliert wird.
Um xend zu konfigurieren, bearbeiten Sie die /etc/sysconfig/xend-Datei. Ändern Sie den Eintrag:
# 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
Starten Sie den Host neu, um die Protokollierung der seriellen Konsolenausgabe des Gasts zu aktivieren.
Die Protokolle der seriellen Gastkonsolen werden in der /var/log/xen/console-Datei gespeichert.

34.11.3. Serielle Konsolenausgabe von voll virtualisierten Gästen

Dieser Abschnitt beschreibt, wie serielle Konsolenausgabe bei voll virtualisierten Gästen aktiviert wird.
Die serielle Konsolenausgabe von voll virtualisierten Gästen kann mit Hilfe des "virsh console"-Befehls eingesehen werden.
Beachten Sie, dass serielle Konsolen voll virtualisierter Gäste einigen Einschränkungen unterliegen. Zu diesen Einschränkungen gehört derzeit:
  • Eine Protokollierung der Ausgabe mit xend ist nicht verfügbar.
  • Ausgabedaten werden u. U. verworfen oder zerstückelt.
Der serielle Port heißt ttyS0 auf Linux bzw. COM1 auf Windows.
Sie müssen das virtualisierte Betriebssystem dahingehend konfigurieren, dass Informationen zum virtuellen seriellen Port ausgegeben werden.
Um Kernel-Information von einem voll virtualisierten Linux-Gast in die Domain auszugeben, bearbeiten Sie die /boot/grub/grub.conf-Datei und fügen die Zeile "console=tty0 console=ttys0,115200" ein.
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
Starten Sie den Gast neu.
Sehen Sie die seriellen Konsolenmeldungen mit Hilfe des "virsh console"-Befehls an.

Anmerkung

Serielle Konsolenmeldungen von voll virtualisierten Domains werden nicht in /var/log/xen/console protokolliert, wie dies für paravirtualisierte Gäste der Fall ist.

34.12. Xen-Konfigurationsdateien

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"
Beachten Sie, dass serial="pty" der Standardwert für die Konfigurationsdatei ist. Nachfolgend sehen Sie ein Beispiel einer Konfigurationsdatei für einen voll virtualisierten Gast:
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'

Xen-Konfigurationsdateien

Das Bearbeiten von Xen-Konfigurationsdateien wird nicht unterstützt. Verwenden Sie virsh dumpxml und virsh create (oder virsh edit), um die libvirt-Konfigurationsdateien (xml-basiert) zu bearbeiten, welche Fehlerüberprüfung und Sicherheitskontrollen bieten.

34.13. Interpretation von Xen-Fehlermeldungen

Sie erhalten den folgenden Fehler:
failed domain creation due to memory shortage, unable to balloon domain0
Eine Domain kann scheitern, falls nicht genügend RAM zur Verfügung steht. Domain0 komprimiert sich nicht genug, um Platz für einen neu erstellten Gast zu bieten. Sie können die Datei xend.log auf diesen Fehler überprüfen:
[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
Sie können die Menge des von domain0 verwendeten Speichers mit Hilfe des Befehls xm list domain0 überprüfen. Falls domain0 nicht komprimiert wurde, können Sie mit Hilfe des Befehls virsh setmem dom0 NewMemSize den Speicher erneut überprüfen.
Sie erhalten den folgenden Fehler:
wrong kernel image: non-PAE kernel on a PAE
Diese Meldung zeigt an, dass Sie versuchen, ein nicht unterstütztes Gast-Kernel-Image auf Ihrem Hypervisor auszuführen. Dies passiert, wenn Sie versuchen, einen nicht-PAE paravirtualisierten Gast-Kernel auf einem Red Hat Enterprise Linux 5 Host zu booten. Das Red Hat kernel-xen-Paket unterstützt lediglich Gast-Kernel mit PAE- und 64-Bit-Architekturen.
Geben Sie diesen Befehl ein:
# 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)
Falls Sie einen 32-Bit nicht-PAE-Kernel ausführen wollen, müssen Sie Ihren Gast als voll virtualisierte virtuelle Maschine ausführen. Wenn Sie auf paravirtualisierten Gästen einen 32-Bit PAE-Gast ausführen wollen, benötigen Sie einen 32-Bit PAE-Hypervisor. Wenn Sie auf paravirtualisierten Gästen einen 64-Bit PAE-Gast ausführen wollen, benötigen Sie einen 64-Bit PAE-Hypervisor. Für voll virtualisierte Gäste müssen Sie einen 64-Bit-Gast mit einem 64-Bit-Hypervisor ausführen. Der 32-Bit PAE-Hypervisor, der mit RHEL 5 i686 geliefert wird, unterstützt lediglich das Ausführen von 32-Bit PAE paravirtualisierten und 32-Bit voll virtualisierten Gast-Betriebssystemen. Der 64-Bit Hypervisor unterstützt nur 64-Bit paravirtualisierte Gäste.
Dies passiert, wenn Sie den voll virtualisierten HVM-Gast auf ein Red Hat Enterprise Linux 5 System verschieben. Ihr Gast scheitert möglicherweise beim Booten und Sie erhalten einen Fehler auf dem Konsolenbildschirm. Überprüfen Sie den PAE-Eintrag in Ihrer Konfigurationsdatei und stellen Sie sicher, dass pae=1 gesetzt ist. Sie sollten eine 32-Bit-Distribution verwenden.
Sie erhalten den folgenden Fehler:
Unable to open a connection to the Xen hypervisor or daemon
Dies passiert, wenn die "virt-manager"-Applikation beim Start scheitert. Dieser Fehler tritt dann auf, wenn kein localhost-Eintrag in der Konfigurationsdatei /etc/hosts existiert. Überprüfen Sie diese Datei und stellen Sie sicher, dass der localhost-Eintrag aktiviert ist. Nachfolgend sehen Sie ein Beispiel eines falschen localhost-Eintrags:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
Nachfolgend sehen Sie ein Beispiel für einen korrekten localhost-Eintrag:
# 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
Sie bekommen folgenden Fehler (in der xen-xend.logfile -Datei):
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.
Zusätzlich weist die Datei xend.log die folgenden Fehler auf:
[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',]
Sie erhalten folgende Python-Fehler (Deprecation):
# 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 generiert diese Meldungen bei einer ungültigen (oder fehlerhaften) Konfigurationsdatei. Um dieses Problem zu lösen, müssen Sie die fehlerhafte Konfigurationsdatei ändern oder eine neue generieren.

34.14. Aufbau der Protokollverzeichnisse

Die grundlegende Verzeichnisstruktur in einer Red Hat Enterprise Linux 5 Virtualisierungsumgebung ist folgende:
/etc/xen/-Verzeichnis beinhaltet
  • Konfigurationsdateien, die vom xend-Daemon verwendet werden.
  • das scripts-Verzeichnis, das die Skripte für Virtualisierungsnetzwerke beinhaltet.
/var/log/xen/
  • Verzeichnis, das alle Protokolldateien im Zusammenhang mit Xen beinhaltet.
/var/lib/libvirt/images/
  • Das Standardverzeichnis für Image-Dateien virtueller Maschinen.
  • Falls Sie ein anderes Verzeichnis für Ihre Images virtueller Maschinen verwenden, stellen Sie sicher, dass Sie dieses Verzeichnis zu ihrer SELinux-Richtlinie hinzufügen und vor Beginn der Installation neu kennzeichnen.
/proc/xen/
  • Informationen im Zusammenhang mit Xen im /proc-Dateisystem.

Kapitel 35. Suche und Beseitigung von Fehlern (Troubleshooting)

Dieses Kapitel behandelt häufige Probleme mit Red Hat Enterprise Linux Virtualisierung und deren Lösungen.

35.1. Identifizieren von verfügbarem Speicher und Partitionen

Überprüfen Sie, ob der Blocktreiber geladen ist und ob die Geräte und Partitionen für den Gast erreichbar sind. Dies kann durch den Befehl "cat /proc/partitions" geschehen, wie unten angezeigt.
# cat /proc/partitions
major minor  #blocks   name 
 202    16  104857600  xvdb
   3     0    8175688  hda

35.2. Nach Neustart von Xen-basierten Gästen bleibt die Konsole hängen

Occasionally, a Xen guest's console freezes when the guest boots. The console still displays messages but the user cannot log in.
Um dieses Problem zu beheben, fügen Sie die folgende Zeile zur /etc/inittab-Datei hinzu:
1:12345:respawn:/sbin/mingetty xvc0
Nachdem Sie die Datei abgespeichert haben, führen Sie einen Neustart durch. Die Konsolensitzung sollte nun wie erwartet interaktiv sein.

35.3. Virtualisierte Ethernet-Geräte werden nicht von den Netzwerk-Tools erkannt

Die Netzwerk-Tools können die Xen Virtual Ethernet-Netzwerkkarte innerhalb des Gastbetriebssystems nicht erkennen. Überprüfen Sie dies, indem Sie folgendes ausführen (für Red Hat Enterprise Linux 4 und Red Hat Enterprise Linux 5):
cat /etc/modprobe.conf
Oder (für Red Hat Enterprise Linux 3):
cat /etc/modules.conf
Die Ausgabe sollte die folgende Zeile enthalten sowie eine ähnliche Zeile für jede zusätzliche Schnittstelle.
alias eth0 xen-vnif
Um dieses Problem zu beheben, müssen Sie für jede paravirtualisierte Schnittstelle für den Gast die Alias-Zeilen hinzufügen (z. B. alias eth0 xen-vnif).

35.4. Fehler bei Loop-Gerät

Falls dateibasierte Gast-Images verwendet werden, müssen Sie evtl. die Anzahl der konfigurierten Loop-Geräte erhöhen. Die standardmäßige Konfiguration erlaubt bis zu acht aktive Loop-Geräte. Falls mehr als acht dateibasierte Gäste oder Loop-Geräte gebraucht werden, kann dies unter /etc/modprobe.conf eingestellt werden. Bearbeiten Sie /etc/modprobe.conf und fügen Sie die nachfolgende Zeile ein:
                options loop max_loop=64
Dieses Beispiel verwendet 64, aber Sie können auch eine andere Anzahl als maximalen Loop-Wert spezifizieren. Sie müssen evtl. auch Loop-Geräte unterstützte Gäste implementieren. Um dies für ein Loop-Gerät unterstützten Gast für einen paravirtualisierten Gast anzulegen, verwenden Sie phy: block device oder tap:aio. Um dasselbe für einen voll virtualisierten Gast durchzuführen, verwenden Sie den Befehl phy: device oder file: file.

35.5. Domain-Erstellung schlägt fehl aufgrund von zu wenig Arbeitsspeicher

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. Fehler durch falsches Kernel-Image

Paravirtualisierte Gäste können den kernel-xen-Kernel nicht verwenden. Verwenden Sie für paravirtualisierte Gäste ausschließlich den Standard-Kernel.
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”.
Um dieses Problem zu lösen, müssen Sie überprüfen, ob Sie tatsächlich einen kernel-xen auf Ihrem Gast installiert haben und dieser als Standard-Kernel in Ihrer /etc/grub.conf-Konfigurationsdatei gebootet wird.
Falls Sie kernel-xen auf Ihrem Gast installiert haben, können Sie Ihren Gast starten:
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. Fehler durch falsches Kernel-Image – nicht-PAE-Kernel auf einer PAE-Plattform

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:
  • Die paravirtualisierten Gäste müssen mit dem Architekturtyp Ihres Hypervisors übereinstimmen. Um einen 32 Bit PAE Gast auszuführen, müssen Sie einen 32 Bit PAE Hypervisor haben.
  • Um einen 64 Bit PAE Gast auszuführen, muss Ihr Hypervisor ebenfalls eine 64 Bit Version sein.
  • Für voll virtualisierte Gäste muss Ihr Hypervisor 32 Bit oder 64 Bit für einen 32 Bit Gast sein. Sie können einen 32 Bit (PAE und nicht-PAE) Gast auf einem 32 Bit oder 64 Bit Hypervisor ausführen.
  • Um einen 64 Bit vollvirtualisierten Gast auszuführen, muss Ihr Hypervisor ebenfalls 64 Bit sein.

35.8. Voll virtualisierter 64 Bit Gast kann nicht hochfahren

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. Ein fehlender Localhost-Eintrag führt zum Fehlschlagen von virt-manager

Die virt-manager-Anwendung kann fehlschlagen und eine Fehlermeldung wie diese anzeigen: “Unable to open a connection to the Xen hypervisor/daemon”. Dies wird in der Regel durch einen fehlenden localhost-Eintrag in der /etc/hosts-Datei verursacht. Vergewissern Sie sich, dass Sie einen localhost-Eintrag haben. Falls dieser in /etc/hosts fehlt, fügen Sie einen neuen Eintrag für localhost hinzu. Ein falscher /etc/hosts-Eintrag könnte etwa wie folgt aussehen:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
Der richtige Eintrag sollte etwa wie folgt aussehen:
# 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. Microcode-Fehler beim Hochfahren des Gasts

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. Python-Warnmeldungen (Deprecation) beim Start einer virtuellen Maschine

Gelegentlich wird Python Meldungen generieren wie die unten gezeigte. Die Ursache dafür ist häufig eine fehlerhafte oder ungültige Konfigurationsdatei. Eine Konfigurationsdatei, die Nicht-ASCII Zeichen enthält, wird zu diesen Fehlern führen. Die Lösung besteht darin, die Konfigurationsdatei zu korrigieren oder eine neue zu erstellen.
Eine andere mögliche Ursache ist eine falsche Konfigurationsdatei in Ihrem aktuellen Arbeitsverzeichnis. “xm create” sucht zunächst im aktuellen Verzeichnis nach einer Konfigurationsdatei und anschließend in /etc/xen.
# xm shutdown win2k3xen12
# xm create win2k3xen12
Using config file "win2k3xen12".
/usr/lib64/python2.4/site-packages/xen/xm/opts.py:520: DeprecationWarning:
Non-ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
execfile(defconfig, globs, locs)
Error: invalid syntax (win2k3xen12, line 1)

35.12. Aktivieren der Intel VT und AMD-V Virtualisierungs-Hardware-Erweiterungen im BIOS

Dieser Abschnitt beschreibt, wie Hardware-Virtualisierungserweiterungen identifiziert und in Ihrem BIOS aktiviert werden können, falls diese deaktiviert sind.
Die Intel VT Erweiterungen können im BIOS deaktiviert werden. Bestimmte Laptop-Hersteller haben die Intel VT Erweiterungen standardmäßig in Ihren CPUs deaktiviert.
Die Virtualisierungserweiterungen können für AMD-V nicht im BIOS deaktiviert werden.
The virtualization extensions are sometimes disabled in BIOS, usually by laptop manufacturers. Refer to Abschnitt 35.12, „Aktivieren der Intel VT und AMD-V Virtualisierungs-Hardware-Erweiterungen im BIOS“ for instructions on enabling disabled virtualization extensions.
Vergewissern Sie sich zunächst, dass die Virtualisierungserweiterungen im BIOS aktiviert sind. Die BIOS-Einstellungen für Intel® oder AMD-V befinden sich normalerweise in den Chipsatz oder Prozessor-Menüs. Die Menünamen können jedoch von den Angaben in diesem Handbuch abweichen, und die Einstellungen für die Virtualisierungserweiterungen liegen möglicherweise unter Sicherheitseinstellungen oder anderen obskuren Menüs.
Prozedur 35.1. Aktivieren der Virtualisierungserweiterungen im 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. Schalten Sie die Maschine aus und nehmen Sie sie zusätzlich vom Netz.
  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. Schalten Sie die Maschine aus und nehmen Sie sie zusätzlich vom Netz.
  6. Führen Sie cat /proc/cpuinfo | grep vmx svm aus. Falls der Befehl eine Ausgabe liefert, sind die Virtualisierungserweiterungen nunmehr aktiviert. Falls keine Ausgabe erscheint, verfügt Ihr System eventuell nicht über die Virtualisierungserweiterungen oder es wurden nicht die richtigen BIOS-Einstellungen aktiviert.

35.13. KVM-Netzwerkleistung

Standardmäßig wird KVM virtuellen Maschinen eine virtuelle Realtek 8139 (rtl8139) NIC (Network Interface Controller) zugewiesen.
Die rtl8139 virtualisierten NICs funktionieren in den meisten Umgebungen einwandfrei. Allerdings kann es bei diesem Gerät auf einigen Netzwerken, z. B. auf einem 10 Gigabit Ethernet Netzwerk, zu Leistungseinbußen kommen.
Sie können dieses Problem umgehen, indem Sie auf eine virtualisierte NIC eines anderen Typs wechseln, z. B. Intel PRO/1000 (e1000) oder virtio (der paravirtualisierte Netzwerktreiber).
Um zum e1000-Treiber zu wechseln:
  1. Fahren Sie das Gastbetriebssystem herunter.
  2. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name):
    # virsh edit GUEST
    Der virsh edit-Befehl verwendet die $EDITOR-Shell-Variable, um festzustellen, welcher Texteditor benutzt werden soll.
  3. Suchen Sie in der Konfiguration den Abschnitt über die Netzwerkschnittstellen. Dieser Abschnitt sieht etwa wie folgt aus:
    <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. Speichern Sie die Änderungen und beenden den Texteditor.
  6. Starten Sie das Gastbetriebssystem neu.
Alternativ können Sie neue virtualisierte Gäste mit einem anderen Netzwerktreiber installieren. Dies kann ggf. erforderlich sein, falls Sie Schwierigkeiten damit haben, Gäste über eine Netzwerkverbindung zu installieren. Für dieses Verfahren müssen Sie bereits mindestens eine virtuelle Maschine erzeugt haben (etwa von CD oder DVD), um diese als Vorlage zu verwenden.
  1. Erzeugen Sie eine XML-Vorlage anhand einer vorhandenen virtuellen Maschine:
    # virsh dumpxml GUEST > /tmp/guest.xml
    
  2. Kopieren und bearbeiten Sie die XML-Datei und aktualisieren Sie die eindeutigen Felder: Name der virtuellen Maschine, UUID, Disk-Image, MAC-Adresse und andere eindeutige Parameter. Beachten Sie, dass Sie die Zeilen für die UUID und MAC-Adresse löschen können, auf diese Weise wird virsh eine UUID und MAC-Adresse generieren.
    # cp /tmp/guest.xml /tmp/new-guest.xml
    # vi /tmp/new-guest.xml
    
    Fügen Sie im Abschnitt über die Netzwerkschnittstellen die Modell-Zeile hinzu:
     <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  3. Erzeugen Sie die neue virtuelle Maschine:
    # virsh define /tmp/new-guest.xml
    # virsh start new-guest
    
Die Netzwerkleistung sollte mit dem e1000- oder virtio-Treiber besser sein. (BZ#517181)

Kapitel 36. Suche und Beseitigung von Fehlern (Troubleshooting) bei Xen paravirtualisierten Treibern

Dieses Kapitel beschäftigt sich mit Problemen, die unter Umständen bei der Verwendung von paravirtualisierten Treibern mit Xen-Hosts und voll virtualisierten Red Hat Enterprise Linux Gästen auftreten können.

36.1. Protokolldateien und -verzeichnisse der Red Hat Enterprise Linux 5 Virtualisierung

/var/log/xen/
Das Verzeichnis, das alle Protokolldateien enthält, die vom xend-Daemon und vom qemu-dm-Prozess generiert wurden.
xend.log
  • Diese Protokolldatei wird von xend benutzt, um jegliche Ereignisse zu protokollieren, die entweder durch normale Systemereignisse oder durch anwenderinitiierte Ereignisse generiert wurden.
  • Alle Operationen der virtuellen Maschine, wie z. B. erstellen, herunterfahren, löschen etc. werden in dieser Protokolldatei aufgezeichnet.
  • Diese Protokolldatei ist im Falle eines Problems in der Regel die erste Anlaufstelle. In vielen Fällen wird es Ihnen möglich sein, die Fehlerursache zu erkennen, indem Sie die Protokolldatei durchsehen und die Einträge überprüfen, die kurz vor Auftreten der Fehlermeldung protokolliert wurden.
xend-debug.log
  • Zeichnet Fehlerereignisse von xend und seinen Subsystemen (von Framebuffer und Python-Skripten) auf.
xen-hotplug.log
  • Protokolliert Ereignisse von Hotplugs.
  • Ereignismeldungen von Geräten, die nicht online gehen oder Netzwerk-Bridges, die nicht online sind, werden in dieser Datei protokolliert.
qemu-dm.PID.log
  • Diese Datei wird vom qemu-dm-Prozess erzeugt, welcher für jeden voll virtualisierten Gast gestartet wird.
  • Die PID wird ersetzt durch die PID des entsprechenden qemu-dm-Prozesses.
  • Sie können die PID eines bestimmten qemu-dm-Prozesses abfragen, indem Sie den ps-Befehl ausführen. Anhand der Prozessargumente können Sie die virtuelle Maschine identifizieren, zu welcher der qemu-dm-Prozess gehört.
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.

Anmerkung

Diese Protokolldatei wird jedesmal überschrieben, wenn Sie virt-manager starten. Falls Sie einem Problem mit virt-manager nachgehen, stellen Sie deshalb nach Auftreten des Fehlers sicher, dass Sie die Protokolldatei speichern, bevor Sie virt-manager neu starten.
/var/lib/libvirt/images/
Standardverzeichnis für dateibasierte Gast-Images.
/var/lib/xen/xend-db/
Verzeichnis, das die xend-Datenbank enthält, welche bei jedem Neustart des Daemons erzeugt wird.
/etc/xen/
Speichert eine Reihe von Konfigurationsdateien für den Xen-Hypervisor.
  • /etc/xen/xend-config.sxp ist die Hauptkonfiguration für den xend-Daemon. Die xend-config.sxp-Datei aktiviert oder deaktiviert Migration und andere Funktionen, die nicht durch libvirt konfiguriert werden. Verwenden Sie die libvirt-Tools für alle anderen Funktionen.
/var/lib/xen/dump/
Enthält Speicherauszüge, generiert von virtuellen Maschinen oder durch Benutzung des xm dump-core-Befehls.
/proc/xen/
Enthält xen-kernel-Informationen in den folgenden Dateien:
  • /proc/xen/capabilities
  • /proc/xen/privcmd
  • /proc/xen/balloon
  • /proc/xen/xenbus
  • /proc/xen/xsd_port
  • /proc/xen/xsd_kva

36.2. Paravirtualisierter Gast kann nicht auf einem Red Hat Enterprise Linux 3 Gastbetriebssystem geladen werden

Red Hat Enterprise Linux 3 verwendet Kernel-RPMs, die spezifisch für die Prozessorarchitektur sind. Aufgrunddessen kann das Laden der paravirtualisierten Treiber ggf. fehlschlagen, falls die paravirtualisierten Treiber-RPMs nicht mit der Kernel-Architektur übereinstimmen.
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. Während der Installation des paravirtualisierten Treibers auf Red Hat Enterprise Linux 3 wird eine Warnmeldung angezeigt

Die Installation der paravirtualisierten Treiber auf einem Red Hat Enterprise 3 Kernel vor 2.4.21-52 kann zu einer Warnmeldung führen, die besagt, dass die Module mit einer neueren Version als die des laufenden Kernels kompiliert wurden.
Diese Meldung, siehe unten, kann bedenkenlos ignoriert werden.
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
Der wichtige Teil dieser Nachricht ist die letzte Zeile, welche besagen sollte, dass das Modul mit Warnungen geladen wurde.

36.4. Manuelles Laden der paravirtualisierten Treiber

Falls die paravirtualisierten Treiber aus welchem Grund auch immer nicht automatisch während des Startprozesses geladen wurden, können Sie versuchen, diese manuell zu laden.
Dies ermöglicht Ihnen, Netzwerk- oder Speichereinheiten neu zu konfigurieren oder auch herauszufinden, weshalb das Laden überhaupt erst fehlgeschlagen ist. Die unten aufgeführten Schritte sollten die paravirtualisierten Treibermodule laden.
Lokalisieren Sie zunächst die paravirtualisierten Treibermodule in Ihrem System.
# cd /lib/modules/`uname -r`/
# find . -name 'xen_*.ko' -print
Notieren Sie sich den Speicherort und laden Sie die Module manuell. Ersetzen Sie {LocationofPV-drivers} durch den korrekten Speicherort, den Sie sich aus der Ausgabe der Befehle oben notiert haben.
# 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. Überprüfen des erfolgreichen Ladens der paravirtualisierten Treiber

Zunächst einmal sollten Sie sich vergewissern, dass die Treiber tatsächlich in Ihr System geladen wurden.
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. Das System hat einen begrenzten Datendurchsatz mit paravirtualisierten Treibern

If network throughput is still limited even after installing the para-virtualized drivers and you have confirmed they are loaded correctly (refer to Abschnitt 36.5, „Überprüfen des erfolgreichen Ladens der paravirtualisierten Treiber“). To fix this problem, remove the 'type=ioemu' part of 'vif=' line in your guest's configuration file.

Glossary

Dieses Glossar definiert die Ausdrücke, die in diesem Installationshandbuch verwendet werden.
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).
Gastsystem
Also known as guests, virtual machines, virtual servers or domU.
Hardware Virtual Machine
See Full virtualization.
Host
The host operating system, also known as dom0.
The host operating system environment runs the virtualization software for Fully Virtualized and Para virtualized guest systems.
Hypervisor
The hypervisor is the software layer that abstracts the hardware from the operating system permitting multiple operating systems to run on the same hardware. The hypervisor runs on a host operating system allowing other virtualized operating systems to run on the host's hardware.
The Kernel-based Virtual Machine (KVM) and Xen) hypervisors are provided with Red Hat Enterprise Linux 5.
I/O
Kurz für Eingabe/Ausgabe (Input/Output). Der Begriff I/O beschreibt alle Programme, Operationen oder Geräte, die Daten von bzw. auf einen Computer oder von bzw. auf ein Peripheriegerät übertragen. Jede Datenübertragung ist eine Ausgabe für ein Gerät und eine Eingabe für das andere Gerät. Geräte wie z. B. Tastatur und Maus sind ausschließlich Eingabegeräte, während Geräte wie z. B. Drucker ausschließlich Ausgabegeräte sind. Eine beschreibbare CD-ROM ist sowohl ein Eingabe- als auch ein Ausgabegerät.
Itanium®
Die Intel Itanium® Prozessorarchitektur.
Kernel SamePage Merging
Das Kernel SamePage Merging (KSM) Modul wird vom KVM-Hypervisor genutzt, um KVM-Gästen das gemeinsame Verwenden von identischen Speicherseiten zu ermöglichen. Bei den gemeinsam verwendeten Seiten handelt es sich in der Regel um gemeinsame Bibliotheken oder andere identische, stark benutzte Daten. KSM kann die Leistung bestimmter Gäste erhöhen, indem diese Bibliotheken für verschiedene Gäste im Cache vorgehalten werden und die Gastdichte erhöht wird.
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 besteht aus einer Gruppe von Linux Kernel-Modulen, die Geräte, Speicher und Management-APIs für das Hypervisor-Modul steuern. Virtualisierte Gäste werden als Linux-Prozesse und Threads ausgeführt, die von diesen Modulen gesteuert werden.
LUN
Logical Unit Number (LUN) ist die Nummer, die einer logischen Einheit (einer SCSI-Protokolleinheit) zugeordnet ist.
MAC-Adressen
Die Media-Access-Control-Adresse ist eine Hardware-Adresse eines Netzwerkschnittstellen-Controllers. Im Zusammenhang mit der Virtualisierung müssen MAC-Adressen für die virtuellen Netzwerkschnittstellen generiert werden, wobei jede MAC-Adresse einzigartig auf ihrer lokalen Domain sein muss.
Migration
Migration bezeichnet den Vorgang, virtualisierte Gäste von einem Host auf einen anderen zu verschieben. Eine Migration kann "offline" erfolgen (wobei der Gast erst angehalten und dann verschoben wird) oder "live" (wobei der Gast im laufenden Betrieb verschoben wird). Sowohl Xen voll virtualisierte Gäste als auch Xen paravirtualisierte Gäste und KVM voll virtualisierte Gäste können migriert werden.
Migration ist eine Schlüsseleigenschaft der Virtualisierung, da die Software vollständig von der Hardware getrennt ist. Migration ist hilfreich für:
  • Lastverteilung – Wenn ein Host überlastet ist, können Gäste auf Hosts mit geringerer Auslastung verlagert werden.
  • Hardware Failover – Wenn Hardware-Geräte auf dem Host ausfallen, können Gäste sicher verschoben werden, so dass der Host in der Zwischenzeit sicher abgeschaltet und repariert werden kann.
  • Energie sparen – In Zeiten mit geringer Auslastung können Gäste auf die Hosts umverteilt werden, so dass einige Host-Systeme abgeschaltet werden können, um Energie zu sparen.
  • Geografische Migration – Gäste können zugunsten geringerer Latenz oder in außergewöhnlichen Umständen an einen anderen Standort umziehen.
Zur Speicherung von Gast-Images wird gemeinsam genutzter Netzwerkspeicher verwendet. Ohne diesen gemeinsamen Speicher wäre eine Migration nicht möglich.
Eine Offline-Migration hält zunächst den Gast an und verschiebt dann ein Image des Gastspeichers zum Ziel-Host. Der Gast wird auf dem Ziel-Host wieder gestartet, und der Speicher, den der Gast auf dem ursprünglichen Host belegt hatte, wird frei.
Die Zeit, die eine Offline-Migration dauert, hängt von der Netzwerkbandbreite und Latenz ab. Ein Gast mit 2 GB Speicher sollte über eine 1 Gbit Ethernet-Verbindung einige Sekunden brauchen.
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.
Die Zeit, die eine Offline-Migration dauert, hängt von der Netzwerkbandbreite und Latenz sowie der Aktivität auf dem Gast ab. Bei hoher CPU-Beanspruchung oder umfassenden I/O-Vorgängen dauert die Migration deutlich länger.
Paravirtualisiert
See Para-virtualization.
Paravirtualisierte Treiber
Paravirtualisierte Treiber sind Gerätetreiber, die auf voll virtualisierten Linux-Gästen laufen. Diese Treiber steigern die Leistungsfähigkeit von Netzwerk- und Blockgerät-I/O für vollvirtualisierte Gäste.
Paravirtualisierung
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.
Seit Fedora 9 wird kein spezieller Kernel mehr benötigt. Sobald dieser Patch im Haupt-Linux-Baum akzeptiert ist, werden alle Linux-Kernel nach dieser Version Paravirtualisierung aktiviert oder verfügbar haben.
PCI passthrough
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
phy device
The phy device parameter allows guest's to access physical disks. Physical disks includes:
  • LVM volumes (for example, /dev/VolGroup00/LogVol02),
  • disk partitions (for example, /dev/sda5), and
  • whole block devices (for example, /dev/sda).
Physical mode provides the best performance as the hypervisor bypasses extra layers of software on the host at the price of slightly less flexibility in managing the device.
Security Enhanced Linux
Security Enhanced Linux, kurz SELinux, verwendet Linux Security Modules (LSM) im Linux-Kernel, um mit Hilfe einer Reihe von Sicherheitsrichtlinien minimal notwendige Privilegien zu implementieren.
tap:aio
The tap:aio parameter sets the Xen hypervisor to use an advanced access mode designed for safety and performance. File-based, are accessed using a kernel thread and a user-space process. The tap:aio method respects guest flush requests which makes it safer than the file driver. The virtualization tools use tap:aio by default for accessing file-based guest disks on the Xen Hypervisor.
Universally Unique Identifier
Universally Unique Identifiers (UUIDs) sind Teil eines standardisierten Verfahrens zur Identifizierung von Systemen, Geräten und bestimmten Software-Objekten in verteilten Rechnernetzen. Bei der Virtualisierung verwendete UUID-Typen sind u. a.: ext2 und ext3-Dateisystem-Identifier, RAID-Gerät-Identifier, iSCSI- und LUN-Gerät-Identifier, MAC-Adressen und virtuelle Maschinen-Identifier.
Virtualisierung
Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer on top of an operating system, to abstract hardware. The hypervisor allows multiple operating systems to run on the same physical system by giving the guest operating system virtualized hardware. There are various methods for virtualizing operating systems:
  • Hardware-assisted virtualization is the technique used for full virtualization with Xen and KVM.
  • Para-virtualization is a technique used by Xen to run Linux guests.
  • Software-Virtualisierung oder Emulation. Software-Virtualisierung nutzt Binärübersetzung und andere Emulationstechniken, um unmodifizierte Betriebssysteme auszuführen. Software-Virtualisierung ist deutlich langsamer als hardware-unterstützte Virtualisierung oder Paravirtualisierung. Software-Virtualisierung in Form von QEMU wird von Red Hat Enterprise Linux nicht unterstützt.
Red Hat Enterprise Linux 5 supports hardware-assisted, full virtualization with the Xen and KVM hypervisors and software para-virtualization with the Xen hypervisor for hosting Red Hat Enterprise Linux guests.
Virtualized CPU
Ein System besitzt eine Anzahl virtueller CPUs (auch: VCPUs) relativ zur Anzahl der physischen Prozessorkerne. Die Anzahl der VCPUs ist begrenzt und repräsentiert die maximale Anzahl von virtuellen CPUs, die virtuellen Gastmaschinen zugewiesen werden können.
Virtuelle Maschinen
Eine virtuelle Maschine ist eine Software-Implementierung einer physischen Maschine oder Programmiersprache (z. B. Java Runtime Environment oder LISP). Virtuelle Maschinen im Zusammenhang mit Virtualisierung sind Betriebssysteme, die auf virtualisierter Hardware laufen.
Voll virtualisiert
See Full virtualization.
Volle Virtualisierung
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.
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.

Zusätzliche Informationsquellen

Um mehr über Virtualisierung und Red Hat Enterprise Linux zu erfahren, werfen Sie einen Blick auf die folgenden Quellen.

A.1. Online-Informationsquellen

  • http://www.cl.cam.ac.uk/research/srg/netos/xen/ Die Projekt-Website des Xen™-Paravirtualisierung Maschinenmanagers, von dem das Red Hat kernel-xen-Paket abgeleitet ist. Die Seite pflegt die Upstream Xen-Projekt-Binärdateien und den Quellcode und enthält darüberhinaus weitere Informationen, Überblick über Architekturen, Dokumentationen und Links zum Thema Xen sowie damit verbundenen Technologien.
  • Die Website der Xen-Gemeinschaft
  • http://www.libvirt.org/ ist die offizielle Website der libvirt-Virtualisierungs-API.
  • http://virt-manager.et.redhat.com/ ist die Projekt-Website für den Virtual Machine Manager (virt-manager), der grafischen Anwendung zur Verwaltung von virtuellen Maschinen.

A.2. Installierte Dokumentation

  • /usr/share/doc/xen-<version-number>/ ist das Verzeichnis, das umfassende Informationen über den Xen-Paravirtualisierungs-Hypervisor und damit verbundene Verwaltungs-Tools enthält, inklusive verschiedener Beispielkonfigurationen, hardware-spezifische Informationen sowie der aktuellen Xen-Upstream-Benutzerdokumentation.
  • man virsh und /usr/share/doc/libvirt-<version-number> — Enthält Unterbefehle und -optionen für das virsh-Dienstprogramm zur Verwaltung virtueller Maschinen, sowie umfassende Informationen über die libvirt-Virtualisierungsbibliothek-API.
  • /usr/share/doc/gnome-applet-vm-<version-number> — Dokumentation für das grafische Menüleisten-Applet von GNOME, das lokal laufende virtuelle Maschinen überwacht und verwaltet.
  • /usr/share/doc/libvirt-python-<version-number> — Liefert Details zu den Python-Bindings für die libvirt-Bibliothek. Das Paket libvirt-python ermöglicht Python-Entwicklern das Erstellen von Programmen, die eine Schnittstelle zur libvirt-Virtualisierungs-Management-Bibliothek darstellen.
  • /usr/share/doc/python-virtinst-<version-number> — Liefert Dokumentation zum Befehl virt-install, der beim Starten der Installation von Fedora- und Red Hat Enterprise Linux-Distributionen innerhalb virtueller Maschinen behilflich ist.
  • /usr/share/doc/virt-manager-<version-number> — Liefert Dokumentation zum Virtual Machine Manager, einem grafischen Tool zur Verwaltung von virtuellen Maschinen.

Kolophon

Dieses Handbuch wurde im DocBook XML v4.3 Format verfasst.
This book is based on the work of Jan Mark Holzer, Chris Curran and Scott Radvan.
Weitere mitwirkende Autoren sind:
  • Don Dutile trug zur technischen Bearbeitung des Abschnitts über paravirtualisierte Treiber bei.
  • Barry Donahue trug zur technischen Bearbeitung des Abschnitts über paravirtualisierte Treiber bei.
  • Rick Ring trug zur technischen Bearbeitung des Abschnitts über den Virtual Machine Manager bei.
  • Michael Kearey trug zur technischen Bearbeitung der Abschnitte über die Verwendung von XML-Konfigurationsdateien mit Virsh und virtualisierten Floppy-Laufwerken bei.
  • Marco Grigull trug zur technischen Bearbeitung des Abschnitts über Software-Kompatibilität und Performance bei.
  • Eugene Teo trug zur technischen Bearbeitung des Abschnitts über die Verwaltung von Gästen mit virsh bei.
Jeffrey Fearn schrieb das Publishing-Tool Publican, mit dem dieses Buch erstellt wurde.
Das Red Hat Lokalisierungs-Team sind:
  • Vereinfachtes Chinesisch
    • Leah Wei Liu
  • Traditionelles Chinesisch
    • Chester Cheng
    • Terry Chuang
  • Japanisch
    • Kiyoto Hashida
  • Koreanisch
    • Eun-ju Kim
  • Französisch
    • Sam Friedmann
  • Deutsch
    • Hedda Peters
  • Italienisch
    • Francesco Valente
  • Brasilianisches Portugiesisch
    • Glaucia de Freitas
    • Leticia de Lima
  • Spanisch
    • Angela Garcia
    • Gladys Guerrero
  • Russisch
    • Yuliya Poyarkova