No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
{{autolang}} | {{autolang}} | ||
{{admon/warning|Le mot '''hôte''' en français est un mot ambivalent puisqu'il désigne tout aussi bien celui qui reçoit que celui qui est reçu. Tout au long de cette page le mot ''hôte'' sera réservé à l'hébergeur, le système qui accueille,tandis que les autres systèmes seront baptisés ''systèmes invités'' ou ''systèmes virtualisés''.}} | {{admon/warning|Le mot '''hôte''' en français est un mot ambivalent puisqu'il désigne tout aussi bien celui qui reçoit que celui qui est reçu. Tout au long de cette page le mot '''hôte''' sera réservé à l'hébergeur, le système qui accueille,tandis que les autres systèmes seront baptisés '''systèmes invités''' ou '''systèmes virtualisés'''.}} | ||
Cette page traite de l'utilisation de Fedora pour héberger des systèmes invités (dits virtualisés). Pour des informations sur les technologies de virtualisation dans Fedora, reportez-vous à [[Tools/Virtualization |cette page dédiée]]. | Cette page traite de l'utilisation de Fedora pour héberger des systèmes invités (dits virtualisés). Pour des informations sur les technologies de virtualisation dans Fedora, reportez-vous à [[Tools/Virtualization |cette page dédiée]]. | ||
Line 97: | Line 97: | ||
=== Prise en charge du réseau === | === Prise en charge du réseau === | ||
Par défaut, ''libvirt'' crée un réseau privé pour vos invités sur la machine hôte. Ce réseau privé utilise un sous-réseau 192.168.x.x qui n'est pas directement accessible depuis le réseau sur lequel se trouve la machine hôte. Néanmoins, les invités peuvent utiliser la machine hôte comme une passerelle pour se connecter au réseau extérieur. Si vous avez besoin de fournir des services à partir de vos invités qui seront accessibles par les machines du réseau auquel appartient votre machine hôte | Par défaut, ''libvirt'' crée un réseau privé pour vos invités sur la machine hôte. Ce réseau privé utilise un sous-réseau 192.168.x.x qui n'est pas directement accessible depuis le réseau sur lequel se trouve la machine hôte. Néanmoins, les invités peuvent utiliser la machine hôte comme une passerelle pour se connecter au réseau extérieur. Si vous avez besoin de fournir des services à partir de vos invités qui seront accessibles par les machines du réseau auquel appartient votre machine hôte, vous pouvez utilisel des règles DNAT dans des iptables pour rediriger sur des ports spécifiques, ou vous pouvez configurer un environnement ponté. | ||
See the [http://wiki.libvirt.org/page/Networking libvirt networking setup page] for more information on how to setup a Bridged network. | See the [http://wiki.libvirt.org/page/Networking libvirt networking setup page] for more information on how to setup a Bridged network. |
Revision as of 18:02, 22 April 2016
Cette page traite de l'utilisation de Fedora pour héberger des systèmes invités (dits virtualisés). Pour des informations sur les technologies de virtualisation dans Fedora, reportez-vous à cette page dédiée.
Utilisation de la virtualisation dans Fedora
Fedora utilise la famille d'outils libvirt comme solution de virtualisation. Par défaut, libvirt utilise Qemu pour exécuter les instances de système invité dans Fedora.
Pour des informations sur d'autres plateforme de virtualisation, reportez-vous à http://virt.kernelnewbies.org/TechComparison.
Qemu peut émuler un machine hôte en logiciel, ou, pour un processeur donné pris en charge (voir plus bas) peut utiliser KVM pour fournir une virtualisation rapide et totale.
D'autres produits et paquets de virtualisation sont disponibles mais ne sont pas couverts par ce guide.
Installation et configuration de Fedora pour les systèmes invités virtualisés
Cette section traite de la configuration de libvirt sur votre système. Une fois cette section appliquée avec succès, vous pourrez créer des systèmes d'exploitation invités virtualisés.
Prérequis système
Les prérequis courants pour la virtualisation sur Fedora sont :
- Au moins 600 Mio d'espace disque par invité. Un système minimal en ligne de commande requiert 600 Mio d'espace disque. Les stations de travail standard de Fedora requièrent au moins 3 Gio d'espace.
- Au moins 256 MB de mémoire vive par invité, plus 256 Mio pour le système de base. Au moins 756 Mio sont recommandés pour chaque système invité d'un système d'exploitation moderne. Une bonne règle de base est de se renseigner sur la quantité de mémoire requise par le système opérant normalement et de prendre cette valeur pour l'invité virtualisé.
KVM nécessite un processeur doté d'extensions de virtualisation. On les trouve sur la plupart des processeurs grand public récents. Ces extensions sont appelées Intel VT ou AMD-V. Pour savoir si votre processeur en dispose, exécutez la commande suivante :
$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo
Si la commande ne retourne rien, votre système ne dispose pas des extensions nécessaires. Vous pouvez quand même utiliser QEMU/KVM, mais l'émulateur va adopter une solution de repli : la virtualisation logicielle. Cette dernière est vraiment bien moins rapide.
Installation des paquets nécessaires à la virtualisation
Lorsque vous installez Fedora, les paquets nécessaires à la virtualisation peuvent être installés en sélectionnant Virtualisation dans le groupe Base de l'installateur(cela peut néanmoins [http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-pkgselection-x86.html ne pus s'appliquer à votre méthode d'installation).
Pour des systèmes Fedora déjà installés, QEMU, KVM, et d'autres outils de virtualisation, peuvent être installés en exécutant la commande suivante qui installe le groupe virtualisation :
de Fedora 22 à la version actuelle :
Pour Fedora 21 ou pour des installations antérieures, remplace dnf par yum. Le paquet yum est aujourd'hui obsolète et est remplacé par dnf en tant que gestionnaire de paquets depuis Fedora 22.
su -c "dnf install @virtualization"
Cela installe les paquets obligatoires et les paquets par défaut.
$ dnf groupinfo virtualization Vérification de l'expiration des métadonnées effectuée il y a 0:00:56 sur Fri Apr 22 19:38:03 2016. Groupe : Virtualisation Description : Ces paquets offrent un environnement de virtualisation graphique. Paquets obligatoires : virt-install Paquets par défaut : libvirt-daemon-config-network libvirt-daemon-kvm qemu-kvm virt-manager virt-viewer Paquets optionnels : guestfs-browser libguestfs-tools python-libguestfs virt-top
Cela installe les paquets obligatoires, les paquets par défaut et les paquets facultatifs :
su -c "dnf group install with-optional virtualization"
Pour démarrer le service :
su -c "systemctl start libvirtd"
Pour lancer le service au démarrage du système :
su -c "systemctl enable libvirtd"
Vérifiez que les modules kvm du noyau ont été chargés correctement :
$ lsmod | grep kvm kvm_amd 55563 0 kvm 419458 1 kvm_amd
Si cette commande ne liste pas kvm_intel ou kvm_amd, kvm n'est pas configuré correctement. Voyez s'assurer que le système est compatible kvm pour des conseils sur la résolution des problèmes.
Prise en charge du réseau
Par défaut, libvirt crée un réseau privé pour vos invités sur la machine hôte. Ce réseau privé utilise un sous-réseau 192.168.x.x qui n'est pas directement accessible depuis le réseau sur lequel se trouve la machine hôte. Néanmoins, les invités peuvent utiliser la machine hôte comme une passerelle pour se connecter au réseau extérieur. Si vous avez besoin de fournir des services à partir de vos invités qui seront accessibles par les machines du réseau auquel appartient votre machine hôte, vous pouvez utilisel des règles DNAT dans des iptables pour rediriger sur des ports spécifiques, ou vous pouvez configurer un environnement ponté.
See the libvirt networking setup page for more information on how to setup a Bridged network.
Creating a Fedora guest
The installation of Fedora guests using anaconda is supported. The installation can be started on the command line via the virt-install
program or in the GUI program virt-manager
.
Creating a guest with virt-install
virt-install
is a command line based tool for creating virtualized guests. Refer to http://virt-tools.org/learning/install-with-command-line/ for understanding how to use this tool. Execute virt-install --help
for command line help.
virt-install
can use kickstart files, for example
virt-install -x ks=kickstart-file-name.ks
.
If graphics were enabled, a VNC window will open and present the graphical installer. If graphics were not enabled, a text installer will appear. Proceed with the fedora installation.
Creating a guest with virt-manager
Start the GUI Virtual Machine Manager by selecting it from the "Applications-->System Tools" menu, or by running the following command:
su -c "virt-manager"
If you encounter an error along the lines of "Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash", trying running virt-manager
not as root (without the su -c
). The GUI will prompt for the root password.
- Open a connection to a hypervisor by choosing File-->Add connection...
- Choose "qemu" for KVM, or "Xen" for Xen.
- Choose "local" or select a method to connect to a remote hypervisor
- After a connection is opened, click the new icon next to the hypervisor, or right click on the active hypervisor and select "New" (Note - the new icon is going to be improved to make it easier to see)
- A wizard will present the same questions as appear with the
virt-install
command-line utility (see descriptions above). The wizard assumes that a graphical installation is desired and does not prompt for this option. - On the last page of the wizard there is a "Finish" button. When this is clicked, the guest OS is provisioned. After a few moments a VNC window should appear. Proceed with the installation as normal.
Remote management
The following remote management options are available:
- (easiest) If using non-root users via SSH, then setup instructions are at: http://wiki.libvirt.org/page/SSHSetup
- If using root for access via SSH, then create SSH keys for root, and use
ssh-agent
andssh-add
before launchingvirt-manager
. - To use TLS, set up a local certificate authority and issue x509 certs to all servers and clients. For information on configuring this option, refer to http://wiki.libvirt.org/page/TLSSetup.
Guest system administration
When the installation of the guest operating system is complete, it can be managed using the GUI virt-manager
program or on the command line using virsh
.
Managing guests with virt-manager
Start the Virtual Machine Manager. Virtual Machine Manager is in the "Applications-->System Tools" menu, or execute:
su -c "virt-manager"
{1} If you are not root, you will be prompted to enter the root password. ChooseRun unprivileged
to operate in a read-only non-root mode.
- Choose the host you wish to manage and click "Connect" in the "Open Connection" dialog window.
- The list of virtual machines is displayed in the main window. Guests that are running will display a ">" icon. Guests that are not running will be greyed out.
- To manage a particular guest, double click on it, or right click and select "Open".
- A new window for the guest will open that will allow you to use its console, see information about its virtual hardware and start/stop/pause it.
For further information about virt-manager
consult the project website
Bugs in the virt-manager
tool should be reported in BugZilla against the 'virt-manager' component
Managing guests with virsh
The virsh
command line utility that allows you to manage virtual machines.
Guests can be managed on the command line with the virsh
utility. The virsh
utility is built around the libvirt management APIl:
virsh
has a stable set of commands whose syntax and semantics are preserved across updates to the underlying virtualization platform.virsh
can be used as an unprivileged user for read-only operations (e.g. listing domains, listing domain statistics).virsh
can manage domains running under Xen, Qemu/KVM, esx or other backends with no perceptible difference to the user
To start a virtual machine:
su -c "virsh create <name of virtual machine>"
To list the virtual machines currently running:
su -c "virsh list"
To list all virtual machines, running or not:
su -c "virsh list --all"
To gracefully power off a guest:
su -c "virsh shutdown <virtual machine (name | id | uuid)>"
To non gracefully power off a guest:
su -c "virsh destroy <virtual machine (name | id | uuid)>"
To save a snapshot of the machine to a file:
su -c "virsh save <virtual machine (name | id | uuid)> <filename>"
To restore a previously saved snapshot:
su -c "virsh restore <filename>"
To export the configuration file of a virtual machine:
su -c "virsh dumpxml <virtual machine (name | id | uuid)"
For a complete list of commands available for use with virsh
:
su -c "virsh help"
Or consult the manual page: man 1 virsh
Bugs in the virsh
tool should be reported in BugZilla against the 'libvirt' component.
Other virtualization options
QEMU/KVM without Libvirt
QEMU/KVM can be invoked directly without libvirt, however you won't be able to use tools such as virt-manager, virt-install, or virsh. Plain QEMU (without KVM) can also virtualize other processor architectures like ARM or PowerPC. See How to use qemu
Xen
Fedora can run as a Xen Guest OS and also be used as a Xen host (with the latter being true from Fedora 16; for using an earlier version of Fedora as a Xen Host, check out the experimental repo available at http://myoung.fedorapeople.org/dom0). For a guide on how to install and setup a Fedora Xen host, look at the Fedora Host Installation page on the Xen Project wiki.
OpenStack
OpenStack consists of a number services for running IaaS clouds. They are the Object Store (Swift), Compute (Nova) and Image (Glance) services. It is a Fedora 16 feature.
OpenNebula
OpenNebula is an Open Source Toolkit for Data Center Virtualization.
oVirt
The oVirt project is an open virtualization project providing a feature-rich, end to end, server virtualization management system with advanced capabilities for hosts and guests, including high availability, live migration, storage management, system scheduler, and more.
Troubleshooting, bug reporting, and known issues
For a list of known unresolved issues, as well as troubleshooting tips, please see How to debug virtualization problems