SLES 15 KVM Virtualization Setup and VM Auto-Start Guide

SUSE Linux Enterprise Server 15 can serve as a KVM host with the QEMU/KVM hypervisor and the libvirt management stack. This guide is written as a practical reference for administrators who want a repeatable setup: confirm hardware virtualization, install the supported components, choose networking and storage, create a guest, enable per-VM automatic startup, and verify that the guest returns after the host reboots.

The commands and menu paths below were checked against the SUSE Linux Enterprise Server 15 SP7 Virtualization Guide, whose current publication is dated September 10, 2026. Earlier SLES 15 service packs are similar, but package versions, daemon defaults, and available guest profiles can differ. SUSE recommends managing supported virtualization through libvirt rather than mixing libvirt with direct hypervisor-specific management.

Quick planning checklist

1. Verify that the host can run KVM

KVM requires processor virtualization support and firmware settings that expose that support to the operating system. On an x86 host, a quick first check is to look for the Intel vmx or AMD svm CPU flag. The libvirt client package also provides virt-host-validate, which performs a broader set of host checks.

egrep -c '(vmx|svm)' /proc/cpuinfo
sudo virt-host-validate qemu

A positive CPU flag count is useful, but it is not the only requirement. If validation reports that KVM is unavailable, check BIOS or UEFI settings first, especially on a newly provisioned server. SUSE's KVM host documentation states that virtualization must be supported by the CPU and enabled in BIOS/firmware. Also remember that nested virtualization is a separate feature; on SLES 15 SP7 SUSE documents nested KVM as a technology preview rather than a production-supported default.

2. Install the KVM server and libvirt management tools

The most support-aligned path is YaST. Open YaST > Virtualization > Install Hypervisor and Tools, select KVM server, and select KVM tools if you want the libvirt management stack. SUSE documents the yast2-vm package as the YaST module used for this setup.

For command-line automation, SLES groups the same functionality into installation patterns. Install both the host and management patterns:

sudo zypper install -t pattern kvm_server kvm_tools

The kvm_server pattern installs the basic QEMU/KVM host environment. The kvm_tools pattern adds libvirt-based tools for managing and monitoring guests. The exact dependency list is service-pack dependent, so installing the documented patterns is preferable to maintaining a hand-written package list unless you have a controlled minimal-host design.

Reference: SUSE: Installation of virtualization components.

3. Choose the VM network model before moving production traffic

SUSE describes a network bridge as the default and recommended connection when guests should attach directly to the host's LAN. A bridge acts like a Layer 2 switch: the host's physical interface and VM virtual interfaces participate in the same Ethernet segment. This is usually the clearest choice for infrastructure VMs that need their own LAN addresses, inbound services, DHCP reservations, or normal visibility to other machines.

A libvirt virtual network is often better when guests need isolation or simple outbound connectivity. NAT can let several guests share the host's external address while remaining on a private subnet. Routed mode forwards traffic without address translation, but requires suitable routing in the surrounding network.

If the host uses wicked, which SUSE documents as the default network management service on server hosts, create the bridge with YaST or the corresponding command-line configuration. NetworkManager systems can use nmcli. Be cautious on remote servers: moving the host IP configuration to a bridge can interrupt SSH if the change is wrong. Schedule a maintenance window or make sure you have console access.

Reference: SUSE: Preparing the VM Host Server.

4. Confirm the KVM kernel modules are loaded

After installation, verify the kernel side of KVM. Intel hosts normally use kvm_intel; AMD hosts use kvm_amd. SUSE's KVM host setup guide demonstrates loading the processor-specific module and checking it with lsmod.

sudo modprobe kvm_intel   # Intel host
# or
sudo modprobe kvm_amd     # AMD host

lsmod | grep kvm

Vous devriez voir le kvmmodule générique ainsi que le module spécifique au processeur. Si le module ne se charge pas, ne créez pas simplement une machine virtuelle en mode d'émulation logicielle. Vérifiez d'abord les paramètres de virtualisation du firmware et la compatibilité avec l'hôte, sauf si l'émulation logicielle seule fait partie intégrante de votre conception.

Référence : SUSE : Configuration d'un serveur hôte de machine virtuelle KVM .

5. Vérifiez le modèle de démon libvirt utilisé par votre Service Pack.

SLES 15 SP7 active par défaut le modèle modulaire de démons libvirt. Pour KVM, le démon d'hyperviseur principal est `libvirt` virtqemud. Les démons secondaires gèrent des fonctions telles que la virtualisation réseau et le stockage. SUSE documente toujours le libvirtddéploiement monolithique traditionnel, mais il est déconseillé d'activer les deux modèles simultanément.

Sur un hôte KVM SP7 par défaut, vérifiez le démon QEMU :

systemctl status virtqemud.service
sudo systemctl enable --now virtqemud.service

SUSE recommande de configurer le service libvirt concerné pour qu'il démarre au démarrage du système lorsque les machines virtuelles sont également configurées pour un démarrage automatique au démarrage de l'hôte. Sur une installation plus ancienne utilisant intentionnellement une architecture libvirt monolithique, vérifiez libvirtd.serviceplutôt les sockets. Avant de changer de modèle de démon sur un hôte en production, suivez la procédure de transition documentée par SUSE et arrêtez ou évacuez les machines virtuelles invitées.

Référence : SUSE : démons libvirt .

6. Préparer les supports de stockage et d'installation

Avant de créer la machine virtuelle, déterminez l'emplacement de son disque virtuel et le point de montage de l'ISO d'installation. Les valeurs par défaut conviennent à un petit hôte autonome, tandis que les installations plus importantes peuvent utiliser des volumes LVM dédiés, des systèmes de fichiers séparés, NFS, iSCSI ou d'autres solutions de stockage gérées par libvirt. La règle d'utilisation essentielle est d'éviter de saturer silencieusement le système de fichiers racine de l'hôte avec des images de machines virtuelles de plus en plus volumineuses.

Pour une machine virtuelle utilisant des fichiers, vérifiez l'espace libre avant de créer le disque :

df -h /var/lib/libvirt/images
ls -lh /data/ISOs/

Si vous utilisez un pool de stockage libvirt, vérifiez virsh pool-list --allqu'il est bien actif. Pour les systèmes de production, intégrez le stockage des machines virtuelles à votre système de surveillance des capacités et à votre plan de sauvegarde, plutôt que de considérer l'image disque comme un fichier opaque qui se gère automatiquement.

7. Créer la machine virtuelle

Vous pouvez créer une machine virtuelle invitée graphiquement avec Virtual Machine Manager ou en ligne de commande avec virt-install. SUSE décrit virt-installcomme l'outil en ligne de commande pour créer des machines virtuelles invitées via libvirt, et il est particulièrement utile pour les constructions reproductibles et l'administration à distance.

Dans le Gestionnaire de machines virtuelles, créez une nouvelle machine virtuelle, choisissez le support d'installation local, sélectionnez le système d'exploitation invité, allouez la mémoire et les processeurs virtuels, sélectionnez le stockage, puis choisissez le réseau virtuel souhaité. L'image ci-dessous utilise une image ISO de SLES 15 à titre d'exemple ; utilisez l'image d'installation et le profil correspondant à votre Service Pack sous licence.

Voici un exemple comparable en ligne de commande :

sudo virt-install   --name sles15-vm   --memory 4096   --vcpus 2   --disk path=/var/lib/libvirt/images/sles15-vm.qcow2,size=40   --cdrom /data/ISOs/SLES-15-SP7-DVD-x86_64-GM-DVD1.iso   --network bridge=br0,model=virtio   --graphics spice

Ajustez la mémoire, le nombre de cœurs de processeur, la taille du disque, le chemin d'accès à l'image ISO, la source réseau, le firmware et les options graphiques en fonction de votre charge de travail. Si vous utilisez un réseau NAT libvirt au lieu d'un pont, remplacez l'option de pont par le réseau virtuel approprié. Pour une utilisation en production, consultez la documentation de SUSE relative à la virtualisation afin de vérifier la compatibilité avec les systèmes d'exploitation invités et les périphériques pris en charge.

Référence : SUSE : Installation d'un invité avec virt-install .

8. Activer le démarrage automatique de la machine virtuelle

Le démarrage automatique des machines virtuelles est une propriété de libvirt sur chaque invité persistant. La documentation de SUSE précise que cette fonctionnalité n'est pas activée par défaut et doit être activée individuellement ; il n'existe pas d'option globale permettant de configurer toutes les machines virtuelles pour un démarrage automatique.

Activer cette option pour l'invité :

sudo virsh autostart sles15-vm

Vérifiez le paramètre :

sudo virsh dominfo sles15-vm | grep -i autostart

Pour désactiver ce comportement ultérieurement :

sudo virsh autostart --disable sles15-vm

Dans Virtual Machine Manager, la commande équivalente se trouve dans Affichage > Détails > Options de démarrage de la machine virtuelle invitée , où vous pouvez activer Démarrer la machine virtuelle au démarrage de l'hôte et appliquer la modification.

Référence : SUSE : Gestion de base des machines virtuelles invitées et démarrage automatique .

9. Testez la configuration au lieu de supposer que le démarrage automatique fonctionne.

Le test pertinent consiste en un redémarrage contrôlé de l'hôte pendant une fenêtre de maintenance. Avant le redémarrage, notez l'état actuel et vérifiez que la machine virtuelle est persistante :

sudo virsh list --all
sudo virsh dominfo sles15-vm

Redémarrez ensuite l'hôte. Une fois l'hôte redémarré, vérifiez l'état du démon de virtualisation et de la machine virtuelle :

systemctl is-active virtqemud.service
sudo virsh list --all

Si votre déploiement utilise libvirt monolithique, remplacez la vérification de service par une autre libvirtd. Une machine virtuelle démarrée automatiquement devrait passer à l'état « arrêté » runningsans intervention manuelle virsh start. Vérifiez également le service au sein de la machine virtuelle invitée, et pas seulement l'état de la machine virtuelle. Une machine virtuelle en cours d'exécution peut toujours présenter une application défaillante, une configuration réseau manquante ou un problème de récupération du système de fichiers.

Guide de dépannage

SUSE avertit qu'un arrêt forcé virsh destroyéquivaut à une coupure brutale de l'alimentation et peut entraîner une corruption du système de fichiers invité ou une perte de données. Testez le comportement d'arrêt et de redémarrage en douceur avant d'utiliser une machine virtuelle en production.

Configuration de base pratique pour un hôte KVM SLES 15 fiable

Une configuration de base propre est simple : conserver l’hôte sur un pack de services SLES 15 pris en charge, installer les modèles kvm_serveret kvm_toolsles configurations documentés, utiliser libvirt de manière cohérente, choisir délibérément une connectivité de type pont ou réseau virtuel, éviter que le stockage des machines virtuelles ne repose sur un système de fichiers racine sous-dimensionné et marquer uniquement les invités qui ont réellement besoin d’un démarrage au démarrage avec virsh autostart.

Pour SLES 15 SP7, il est important de noter un détail souvent négligé concernant les démons : les démons libvirt modulaires sont la configuration par défaut, tout comme virtqemudle service que vous validez habituellement pour KVM, plutôt que de supposer que chaque hôte actuel repose sur l'architecture monolithique traditionnelle libvirtd. Cette distinction est cruciale pour diagnostiquer une machine virtuelle correctement configurée pour le démarrage automatique, mais qui ne se lance toujours pas après un redémarrage de l'hôte.