Home
admin
|
Kvm October 18th, 2016 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configurer Centos pour que virt-manager ne demande pas le mot de passe de root Gestion du temps virt-manager Docs Préparation du système Installation d'une MV Lancement d'une MV Réseau Snapshots Périphériques USB Installation cri-brri - Avril 2013
Créer dans /etc/polkit-1/rules.d le fichier suivant :
On y autorise les membres du groupe "bruno" à utiliser libvirt sans mot de passe. Source : https://wiki.archlinux.org/index.php/Libvirt#Set_up_authentication
The Network Time Protocol (NTP) daemon should be running on the host and the guest virtual machines. Make sure to install ntp and enable the ntpd service: Enable the ntpd service and add it to the default startup sequence:
Start the service:
The ntpd service will correct the effects of clock skew as long as the clock runs no more than 0.05% faster or slower than the reference time source. The ntp startup script adjusts the clock offset from the reference time by adjusting the system clock at startup time, if required. Source : Redhat
 --virt-type : kvm vs qemu
"Yes, KVM *only* works on cpus with virtualization extensions. If your cpu doesn't have those features it will fallback to qemu so you don't have a choice in that case. You can also use kqemu if you have that option but kqemu isn't being maintained very much since most of the focus is now on kvm. " Source : http://www.linux-kvm.com/content/what-virt-type-should-i-use-virt-install
http://blog.octo.com/presentation-des-hyperviseurs-xen-et-kvm/ http://doc.ubuntu-fr.org/kvm http://thegeekcorner.pagesperso-orange.fr/fr/tutoriel/kvm_linux.html http://trac.evolix.net/infogerance/wiki/HowtoKVM http://www.admin-linux.fr/?p=3969 A creuser : paravirtualisation ou virtualisation complète ? "KVM sappuie sur les extensions matériels des processeurs, il fait donc de la virtualisation complète et non de la para-virtualisation (comme Xen par exemple)." Source http://www.admin-linux.fr/?p=3969 Pour autant KVM n'est pas un émulateur ni un hyperviseur de type 2 : "Myth #1: KVM is type 2 hypervisor that is hosted by the operating system, and isnt a bare metal hypervisor. This is a persistent myth, but the truth is that KVM actually does run directly on x86 hardware. People assume it is a type 2 hypervisor because one of the ways that it is packaged is as a component of Linux - so you can be running a Linux distribution and then, from the command-line shell prompt or from a graphical user interface on that Linux box, you can start KVM. The interface makes it look like it is a hosted hypervisor running on the operating system, but the virtual machine is running on the bare metal - the host operating system provides a launch mechanism for the hypervisor and then engages in a co-processing relationship with the hypervisor. . In a sense, it is taking over part of the machine and sharing it with the Linux kernel. On x86 hardware, KVM relies on the hardware virtualization instructions that have been in these processors for seven years. Using these instructions the hypervisor and each of its guest virtual machines run directly on the bare metal, and most of the resource translations are performed by the hardware. This fits the traditional definition of a Type 1, or bare metal hypervisor. You can also get KVM packaged as a standalone hypervisor - just like VMware ESX is packaged - but initially KVM was not available in that package. One way of doing this is with Red Hat Enterprise Virtualization (RHEV)." Source : https://www.ibm.com/developerworks/community/blogs/ibmvirtualization/entry/kvm_myths_uncovering_the_truth_about_the_open_source_hypervisor?lang=en
Compatibilité matérielle
Modification du BIOS et reboot :
ouf ! Packages de base
Packages supplémentaires
Gestion graphique :
Récupération d'un machine virtuelle fonctionnant avec VirtualBox
 Attention à bien mettre les chemins absolus
A partir d'un fichier iso
Installation d'une MV windows
Par exemple :
Par défaut KVM fonctionne en NAT => si le réseau est configuré sur la machine hote ca fonctionne tout seul et configurant le client en DHCP. Le Lancement de la MV se fait ainsi :
Mais ca n'est pas toujours suffisant, car il peut être souhaitable que la machine ait une IP comme toutes les vraies machines de notre réseau. Nous allons pour cela utiliser le mode pont (bridge) : Debian : Création d'un bridge sur la machine hôte
Le bridge peut également fonctionner en DHCP :
Avec : bridge_ports = interface sur laquelle s'appuie le pont Configuration du réseau sur la machine virtuelle
On peut simplement lui indiquer que la récupération de l'IP doit se faire via le DHCP (ici pour une centos) :
Lancement des MV avec une machine hôte configurée en bridge
En root :
-net nic : Create a new Network Interface Card -net tap : Connect the host TAP network interface Notes
Au lancement de la machine virtuelle kvm lance un script pour configurer le réseau :
$switch prend pour valeur l'identifiant du pont : br0 $1, premier paramètre, a pour valeur tap0. C'est interface qui sera utilisée par la MV NetworkManager : Création d'un bridge sur la machine hôte
- ouvrir N-M (network-manager) - cliquez le + en bas à gauche - sélectionner Agrégat (pont) - donner un nom de connexion Connexion pont 1 - donner un nom dinterface : bridge0 - sélectionner ajouter dans pont de connections - dans le menu drop-down sélectionner ethernet (ou wlan en wifi) puis créer - adresse mac du périphérique, sélectionner votre carte réseau - dans le menu général, vérifier que se connecter automatiquement est coché - enregistrer - bien noter le nom de cette connexion : Esclave bridge0 1 - au besoin paramétrer votre adressage IP ou laisser en dhcp - et enregistrer encore :) L'activation du pont via l'interface graphique ne fonctionne pas tjs =>
Activation du pont en ligne de commande :
Cela va vous montrer les uuid des connections :
du coup vous faites
Si vous attendez un peu, vous verrez avec la commande ifconfig apparaitre ladresse IP non plus sur votre carte réseau réelle, mais sur votre bridge. Il faut être patient : Par défaut le bridge va mettre un peu de temps à se créer pour chaque démarrage et pour chaque vm que vous allez bridger dessus. Cela est du à une protection mise en place pour les réseaux complexes (avec multi bridges) ou des boucles de routage pourraient être faites. Cela fait parti du protocole STP.
Source : http://geekeries.de-labrusse.fr/?p=2889
Il y a un article très bien fait ici : http://www.admin-linux.fr/?p=4078
Pour attacher un périphérique USB : Sur la machine hôte, on repère le périphérique qui nous intéresse :
On peut monter ce périphérique lors du lancement de la MV avec les options -usb et -usbdevice :
Objectif : disposer pour ma machine de bureau d'une distribution stable que je puisse déplacer d'une machine à une autre sans soucis Présentation générale : j'utilise KVM. J'installe une distribution de base (debian) avec uniquement les packages nécessaires (pas de Xorg par exemple). Sur ce système de type bare metal vont tourner des MV. Les MV Linux seront accédées via XDMCP. Installation des packages
 Réseau
KVM/qemu
X pour xdmcp
Config réseau
Config disque
Avec LVM, je crée un volume logique par MV :
Installation d'une MV Debian
Accéder graphiquement à la MV
Pendant l'installation :
Après l'installation (i.e. en utilisation de tous les jours)
j'utilise XDMCP :
Note à propos de XDMCP : deux fichiers sur la MV sont à modifier pour activer les connexions XDMCP : cf https://wiki.archlinux.org/index.php/Xdmcp
Sauvegardes
On utilise les fonctionnalités de LVM :
|
| Dernières modifs |
|---|
| VNC (November 22nd, 2020) Editeurs (October 20th, 2016) Awk (October 18th, 2016) Claws Mail (October 18th, 2016) Cups (October 18th, 2016) Gimp (October 18th, 2016) Git (October 18th, 2016) |
| Contact | ||
|---|---|---|
| Pour m'envoyer un mail, Pour me laisser un commentaire :
|
