03 Nov 2022, 00:00

xrandr, résolution virtuelle et upscaling

xrandr
donne la configuration actuelle et les différentes configurations possibles

panning : permet d’aumgmenter la taille “logique” de l’affichage (les coordonnées disponibles pour demander un affichage)

mode : l’affichage réel de l’écran physique ; peut être inférieur au panning (auquel cas l’affichage défile lorsqu’on bouge le curseur vers un bord)

scale : l’échelle entre le panning et le mode ; permet par exemple de faire rentrer un “grand” panning dans un “petit” mode Elle s’obtient en divisant la valeur du panning par la valeur du mode.

Par exemple, avec un écran physique 1366x768, si je veux un écran virtuel de 1920x1080 :

xrandr --output LVDS-1 --panning 1920x1080 --mode 1366x768
et je pourrais “défiler” dans l’écran virtuel en déplaçant la souris.

Si je veux que cette résolution virtuelle soit affichée intégralement dans l’écran :

1920/1366 = 1.40556369
1080/768 = 1.40625

ce qui donne la commande
xrandr --output LVDS-1 --panning 1920x1080 --mode 1366x768 --scale 1.40556369x1.40625

26 Sep 2022, 00:00

Live-USB Bullseye

Même procédure que pour buster avec quelques variations :

sudo aptitude install live-build live-tools
mkdir bullseye_live && cd bullseye_live
mkdir auto && cp /usr/share/doc/live-build/examples/auto/* ./auto/

config

Fichier auto/config

#!/bin/sh

set -e

lb config noauto \
	--architectures 'amd64' \
	--archive-areas 'main contrib non-free' \
	--bootappend-live 'boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr' \
	--binary-images 'iso-hybrid' \
	--distribution 'bullseye' \
	--linux-flavours 'amd64' \
	--source 'false' \
	--backports 'true' \
	"${@}"

Liste de paquets

Fichier config/package-lists/live.list.chroot

live-boot
live-config
live-config-systemd

#FIRMWARE
firmware-linux firmware-atheros firmware-b43-installer firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-iwlwifi firmware-libertas firmware-myricom firmware-netxen firmware-qlogic firmware-realtek broadcom-sta-dkms

#UTILS
nmap rcconf gparted hfsprogs ntfs-3g hfsplus hfsutils dosfstools lightdm bash-completion chntpw dcfldd bootlogd less mesa-utils numlockx ethtool grub2 ssh gdisk testdisk python-tk iftop nethogs pm-utils dmraid aptitude apt-file smartmontools debootstrap pciutils usbutils cifs-utils e2fsprogs mtools screen lvm2 net-tools mdadm lsscsi haveged rng-tools cryptsetup efibootmgr efivar ncdu wireless-tools dnsutils git iperf iperf3 lshw pmount grub-efi-ia32-bin grub-pc-bin grub-efi-amd64-bin curl dislocker

# TEAMVIEWER
libqt5webkit5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs

# DESKTOP
hplip system-config-printer xsane simple-scan mate-desktop-environment caja-open-terminal mesa-utils firefox-esr-l10n-fr chromium-l10n pulseaudio pavucontrol pavumeter mate-media-common mate-media mate-settings-daemon-dev mate-settings-daemon-common mate-settings-daemon chromium engrampa unrar pluma bluez blueman pulseaudio-module-bluetooth gddrescue ddrescueview vlc rdesktop conky network-manager-gnome webcamoid cheese webp-pixbuf-loader

Noyau, backports et pinning

On va utiliser le pinning pour demander d’installer certains paquets depuis les backports notamment les noyaux et headers.
La version de wpasupplicant fournie dans Bullseye a parfois quelques problèmes pour se connecter à un réseau. On choisit d’installer la version de bullseye-backports.
De même, si on installe le noyau de bullseye-backports, le module broadcom-sta-dkms doit venir des backports pour compiler sans erreur.

Pour ceci, on crée le fichier config/archives/backports.pref.chroot et on y met le contenu suivant :

Package: linux-image-amd64
Pin: release a=bullseye-backports
Pin-Priority: 600

Package: linux-headers-amd64
Pin: release a=bullseye-backports
Pin-Priority: 600

Package: wpasupplicant
Pin: release a=bullseye-backports
Pin-Priority: 600

Package: broadcom-sta-dkms
Pin: release a=bullseye-backports
Pin-Priority: 600

On peut bien sûr choisir d’autres paquets à installer depuis les backports, avec les mécaniques classiques de pinning.

20 Aug 2022, 00:00

Notes sur shell (sh)

Cet article se concentre sur les fonctionnalités des shells POSIX (notamment sh).

Debug

On peut mettre au début du script (ou en argument du shebang) ces directives :
set -x : toutes les commandes exécutées sont inscrites sur le terminal (standard error) avant leur exécution (avec un + en tête de ligne)
set -v : chaque ligne lue est inscrite sur le terminal (standard error)

Il me semble que ce sont des commandes “built-in” de bash ; toutefois cela semble fonctionner même si le shebang du script est /bin/sh.

Code de retour

Chaque commande/fonction exécutée renvoie un code de retour (exit code, ou encore code de retour), qui indique l’état de réussite de la commande.
C’est un entier de 0 à 255.

Généralement, 0 signifie un succès de l’opération, et tous les autres nombres un échec.

On peut définir le code de retour d’un script ou d’une fonction avec les commandes return et exit.

return & exit

return et exit servent tous 2 à interrompre l’exécution, et renvoient la valeur passée en argument (ou 0 à défaut d’argument ; et modulo 256 pour exit).
La différence entre les 2 est que return va interrompre la fonction mais rester dans le script, alors que exit va interrompre l’ensemble du script.

Récupérer la sortie d’une commande

Permet de stocker dans une variable la sortie d’une commande (standard output, et non le code de retour ; donc ce qui est affiché dans le terminal en cas d’exécution interactive). C’est la “substitution de commande”, que l’on fait avec la syntaxe
var=$(command)

On voit aussi
var=`command`
mais la première syntaxe est recommandée (notamment pour de l’imbrication de substitution, voir cette page ).

Si on récupère la sortie d’une fonction, cela contiendra la succession de toutes les sorties des commandes de la fonction.

Le retour $? d’une substitution correspond au retour de la commande/fonction, et non au retour de l’affectation de la variable.

Quelques symboles spéciaux

https://stackoverflow.com/questions/5163144/what-are-the-special-dollar-sign-shell-variables

$# : le nombre d’arguments
$1 : premier argument ; $2 : le 2e argument, etc…
$? : code renvoyé par la dernière commande executée ; renvoie 0 si aucune commande précédemment executée dans ce contexte (au sein d’un script, ou d’une session bash)
$@ : liste sous forme de vecteur de tous les paramètres : {$1, $2, $3 …}
$$ : PID du shell actuel
$IFS : séparateur de champ (actuel, car peut être changé)
$0 : nom de la commande ou du script shell

[ et test

En shell, [ est une commande ; c’est un alias de la commande test.
Celle-ci renverra vraie si la chaîne fournie est non-nulle, ou bien si l’affirmation qui suit est vraie.

[[ est une spécificité bash, et ne fonctionne pas en sh.

Arithmétique

bash possède des fonctions d’arithmétique avancées, mais ce n’est pas le cas de sh.
En shell POSIX, on peut utiliser la command expr. Par exemple :

a=1
a=$(expr $a + 1)
echo $a

qui donne 2.
Il faut bien penser à mettre les espaces autour du symbole +

Pour voir la liste des opérateurs : man expr
ou cette page.

Fonction

Déclaration :

myfunction () {
  echo $1
  echo $2
  return 0
}

À défaut de code de retour explicitement spécifié, la fonction retournera le retour de sa dernière commande exécutée.
Les paramètres de position ($1, $2 etc) sont ceux de l’appel de la fonction.

Utilisation :
myfunction 1 2 3

EN bash, on peut spécifier le mot clé “function” avant le nom de la fonction, mais ceci n’est pas reconnu en POSIX shell.

Portée

Il semble que les variables définies dans une fonction restent accessibles même après la sortie de la fonction (les variables sont par défaut globales).

Par exemple :

myfunction () {
  echo $a
  b=2
}

a=1
myfunction
echo $b

affichera “1 2”.

À l’inverse,

myfunction () {
  echo $a
  local b=2
}

a=1
myfunction
echo $b

affichera uniquement 1, la variable b étant définie localement.

if

Sous la forme
if [ blabla ]; then echo YES; fi
la condition if sera validée si test blabla renvoie 0. Par exemple blabla est une chaîne non-nulle ; ou encore blabla est une opération logique qui est vraie (par exemple 1 -eq 1, ou "abc" = "abc").

Sous la forme
if command ; then echo YES; fi
la condition sera validée si la commande/fonction “command” renvoie 0.
La commande “command” sera exécutée, et sa sortie affichée si applicable.

20 Jul 2022, 00:00

Désactiver les touches mortes (dead keys)

Très inspiré de cet article.

Les touches mortes sont des touches modificatrices qui, seules, ne produisent pas d’entrée clavier. Elles doivent être suivies d’une autre touche qui sera alors modifiée (par exemple le circonflexe, le backtick qui peut devenir un accent grave etc). Il faut répéter l’appui sur la touche pour obtenir le caractère seul.

Dans mon cas, je souhaite utiliser le backtick lors du premier appui. Pour ceci, il faut déjà identifier l’ID de l’evenement lorsque j’appuie sur la touche en question. Lancer
xev
appuyer sur la touche à paramétrer, et regarder le “keycode”. Pour le backtick, c’est 16.

Ensuite, on vérifie le comportement de cette touche (modifier l’ID si besoin) :
xmodmap -pke | grep " 16 "
qui me donne
keycode 16 = egrave 7 egrave 7 dead_grave Egrave dead_grave

Le “dead_” signifie que la touche se comporte comme une touche morte. Le “grave” signifie le backtick. On remplace donc l’entrée par :
keycode 16 = egrave 7 egrave 7 grave Egrave grave

et le backtick s’affiche directement lors du premier appui !

Je suppose que ce réglage ne tient pas un reboot, voire une déconnexion de session. À vérifier.

20 Jul 2022, 00:00

Gestion des onduleurs sous Linux : NUT

Ressources en vrac

Doc debian-fr.xyz
Doc officielle Debian
Doc ArchLinux
Doc Ubuntu, un peu vieille
https://ignace72.eu/utiliser-un-onduleur-eaton-sur-gnu-linux.html

Présentation

NUT (Network UPS Tools) est un ensemble de logiciels qui servent à surveiller les onduleurs et réagir à leur état. Il y’a :

  • le démon nut-driver (commande upsdrvctl) qui communique avec l’onduleur
  • le démon nut-server (commande upsd) qui permet de répondre à des requêtes (locales ou réseau)

Ces 2 démons doivent être lancés sur le poste qui communique en USB avec l’onduleur.

  • le logiciel upsc qui va interroger les démons upsd (en local ou sur d’autres postes)
  • le démon upsmon qui permet d’interroger différents démons upsd et lancer des alertes

Dépôt git du projet

Dans l’exemple ici, il y’a un seul pc qui contrôlera NUT et qui sera relié à l’onduleur ; on ignore donc toutes les configurations réseau.
L’onduleur utilisé est un Eaton Ellipse ECO 800.

Install de NUT et vérification du branchement de l’onduleur

apt install nut
sous Debian.
C’est un paquet virtuel qui dépend de nut-client et nut-server.
nut-client contient entre autres les exécutables upsc, upscmd, upsmon.
nut-server contient entre autre upsd, upsdrvctl.

Brancher l’onduleur via USB.
lsusb donne :
Bus 006 Device 005: ID 0463:ffff MGE UPS Systems UPS

On peut vérifier que le fichier appartient bien au groupe nut (adapter les chiffres au résultat ci-dessus) :
ls -l /dev/bus/usb/006/005

Pilote de l’onduleur

sudo nano /etc/nut/ups.conf

Chaque onduleur doit être défini sous la forme

[upsname]
       driver = <drivername>
       port = <portname>

avec éventuellement d’autres options facultatives. On peut mettre auto pour le port. Le champ desc semble être là pour mettre une description plus complète commentaire).

Pour identifier la liste des pilotes en fonction du matériel, consulter cette page.
Pour un Eaton Ellipse Eco 800, c’est usbhid-ups. Si on clique sur le nom du pilote, on accède à ses otions de configuration.

On peut aussi tester la commande nut-scanner, qui renvoie un bloc de configuration auto-detecté (+ d’infos avec sudo).

Cela me donne le bloc suivant à ajouter à la fin du fichier :

[eaton800]
    driver = usbhid-ups
    port = auto
    desc = "Eaton Ellipse ECO 800"

Lancement

On peut vérifier en lançant manuellement :
sudo upsdrvctl start eaton800

Le processus sera visible via
ps aux | grep usbhid

On peut lancer le service
sudo service nut-driver start
mais visiblement, si le service nut-server n’est pas en route, il quitte au bout de quelques secondes.

Configuration du démon upsd

Celui-ci sert à mettre les informations de l’onduleur à disposition de clients.

Lancement manuel

À fin de compréhension et de debug. On peut lancer upsd manuellement avec le chemin
/usr/lib/nut/upsd
La commande upsd intégrée dans le path (/usr/sbin/) est un script qui va lancer la commande ci-dessus uniquement si la configuration du fichier upsd.conf autorise le lancement.

Si on a l’erreur Can't connect to UPS [...] au lancement, c’est probablement que le processus driver (upsdrvctl) n’est pas lancé.
Sinon on doit avoir Connected to UPS [...]

On peut vérifier le bon lancement du processus via
ps aux | grep upsd | grep nut

Lancement via service

Cette méthode permettra le démarrage automatique de l’ensemble des services nut.
sudo nano /etc/nut/nut.conf
mettre MODE=standalone

On démarre le service :
sudo service nut-server start

Utilisateur

Il faut définir (au moins) un utilisateur dans upsd car une authentification sera nécessaire pour effectuer certaines commandes, notamment celles d’upscmd qui permettent de contrôler l’onduleur (bip, extinction etc).

Pour ceci,
sudo nano /etc/nut/upsd.users et ajouter à la fin un bloc par utilisateur, de type :

[myadmin]
        password = mypass
        #allowfrom = localhost
        actions = SET
        actions = FSD
        instcmds = all
        upsmon master

Détail des options : man upsd.users
(ou https://linux.die.net/man/5/upsd.users )
Actuellement (2022), fsd (forced shutdown) et set (définir des variables sur l’onduleur) sont les 2 seules actions.
instcmds sont les options disponibles dans upscmd -l.

Logiciels clients

upsrw ??

upscmd

upscmd permet de s’adresser directement à l’onduleur.

upscmd -l eaton800
pour voir les commandes supportées par l’onduleur (par exemple contrôler le bip, forcer l’extinction etc)

upscmd eaton800 command:enable
pour lancer la commande en question sur l’onduleur

Sur mon Ellipse ECO 800, il semlble que beeper.disable n’ait pas d’effet, et que load.off et shutdown aient le même effet : couper les prises de courant de l’onduleur ET éteindre l’onduleur, le rendant injoignable sans rallumage manuel de l’onduleur.

upsc

upsc permet de s’adresser à un démon upsd.

upsc -L [host]
pour lister tous les onduleurs détectés sur host ; si l’host n’est pas spécifié, c’est localhost.

Si on a le message d’erreur Error: Connection failure: Cannot assign requested address, c’est que upsc n’arrive pas à communiquer avec upsd ; soit que ce dernier n’est pas lancé, soit qu’il n’accepte pas la requête (voir dans ce cas la directive LISTEN du fichier upsd.conf, même s’il me semble qu’il n’est pas nécessaire de la configurer si tout se fait en local sur 1 seul poste).

upsc eaton800[@host]
pour voir les données actuelles de l’onduleur ; on peut quérir un seul attribut en le mentionnant ; par exemple
upsc eaton800 ups.status
qui peut être OL (OnLine, sur secteur), OB (OnBattery)
ou encore upsc eaton800 battery.charge

Si non a l’erreur Error: Driver not connected, c’est que upsc arrive à communiquer avec upsd, mais que upsd n’arrive pas à communiquer avec le pilote (par exemple processus pilote qui a été tué).

Si prise USB débranchée -> “Error: Data stale”

Monitoring automatique - upsmon

upsmon est le composant qui va surveiller l’état de l’onduleur, et lancer des actions selon l’état (surt batterie, batterie critique etc).
On définit au moins 1 onduleur à surveiller :

sudo nano /etc/nut/upsmon.conf

Le fichier documente chaque section.
Il faut une ligne MONITOR par onduleur ; par exemple
MONITOR eaton800@localhost 1 myadmin mypass master

Le “1” correspond au nombre d’alims qui sont alimentés par l’onduleur en question ; pour la plupart des pcs standard, qui n’ont qu’une seule alim, ce sera 1.

On peut toutefois entrer “0” si le pc surveille l’onduleur mais n’est pas branché dessus ; il effectuera les actions d’alerte (mail etc.) mais ne s’éteindra pas en cas de batterie critique. En ca cas, il faut aussi définir la variable MINSUPPLIES à 0 (pour déclarer que le poste peut fonctionner sans aucun onduleur).

master & slave

En général, un poste branché sur l’onduleur ET capable de communiquer avec lui sera considéré comme master ;
Un poste branché sur l’onduleur mais sans communication de données sera considéré comme slave.

En action automatique, un poste master ne s’éteindra que lorsque tous les slaves seront éteints.

NOTIFYCMD

https://networkupstools.org/docs/user-manual.chunked/ar01s07.html

Toujours dans upsmon.conf, on peut définir la commande appelée pour informer l’admin lorsqu’un événement se produit (coupure courant, batterie faible etc). C’est le paramètre NOTIFYCMD.

Cette commande ne sera exécutée que pour les alertes possédant le flag EXEC !! (voir plus bas)

Ce peut être un script custom, ou bien le planificateur intégré à NUT (upssched). Le message de l’événement sera envoyé à cet exécutable en tant que 1er et seul argument.

Penser aux droits d’accès ! La commande sera exécutée par l’utilisateur nut (sur Debian), il doit pouvoir y accéder en exécution.

NOTIFYMSG

Permet de personnaliser le message associé à chaque alerte.

NOTIFYFLAGS

Définit le type d’actions à effectuer pour chaque type d’alerte. Il y’a :

  • WALL : prévient chaque utilisateur sur le système
  • SYSLOG : inscrit dans le syslog
  • EXEC : lance la commande définie à NOTIFYCMD
  • IGNORE : ne rien faire

Il faut noter FLAG+FLAG+FLAG, par exemple
EXEC+SYSLOG+WALL

Lancement via service

sudo service nut-client start

upssched

upssched est un script qui permet de gérer la planification des alertes plus finement. Par exemple de définir un délai avant de déclencher l’alerte, pour ne pas êztre prévenu en cas de micro-coupure de courant.
On le configure via le fichier /etc/nut/upssched.conf.

Je n’aborde pas son usage ici.

GUI

nut-monitor
nut-cgi (interface web)

Journaux et contrôle des services

Voir les journaux de nut-driver (upsdrvctl) :

sudo journalctl -u nut-driver
sudo service nut-driver status

Voir les journaux de nut-server (upsd) :

sudo journalctl -u nut-server
sudo service nut-server status

Voir les journaux de nut-client (nut-monitor, upsmon) :

sudo journalctl -u nut-monitor
sudo service nut-monitor status
sudo service nut-client status

sudo service ups-monitor ??

29 May 2022, 00:00

Notes sur locate

La commande locate est fournie par plusieurs paquets, notamment mlocate puis plocate, qui prennent notamment en charge l’option de configuration PRUNENAMES.

L’installation du paquet crée une tache cron dans /etc/cron.daily. On peut la désactiver via chmod -x /etc/cron.daily/mlocate ou chmod -x /etc/cron.daily/plocate.

locate -i pour ne pas prendre la casse en compte.

Pour voir tous les fichiers indexés, on peut faire un locate /.

23 May 2022, 00:00

FTP - passif ou actif

Très bonne lecture : http://slacksite.com/other/ftp.html

En succint :

FTP utilise 2 canaux de communication : commande (C) et données (D). FTP n’utilise que du TCP, jamais d’UDP.

Mode actif

En mode actif, le client contacte le serveur via le canal C. Le serveur est alors autorisé à lui répondre via le même canal.

Le serveur contacte ensuite le client sur le canal D. (le serveur initie la connexion, il est actif).
Le client n’ayant “rien demandé” sur ce canal, le message est très probablement rejeté (par le pare-feu ou routeur du client).

Mode passif

Pour palier à ce problème, lorsque le client initie la connexion sur le canal C, il dit “PASV” (un genre de “j’ai besoin qui tu sois passif, tu n’arriveras pas à me joindre sinon”).
Le serveur crée alors une nouvelle “ouverture” pour le canal D, dont il informe le client, et c’est à nouveau le client qui initie la connexion sur le canal D.

Le serveur est passif, en ceci qu’il n’est à l’origine d’aucune connexion.

Plus de détails

En mode actif, les ports des canaux C et D par défaut sont :

  • serveur : 21 et 20
  • client : 2 ports random >1023 (N et N+1)

Côté serveur, il me semble que seul le port 21 a besoin d’être ouvert dans le pare-feu/routeur.

A compléter

En mode passif, il faut définir une fourchette de ports qui pourront être utilisés par le serveur pour recevoir des connexions (apparemment 1 port par connexion pourrait ne pas suffire).
Il faut ouvrir ces ports dans le pare-feu/routeur.

Une explication de pourquoi le serveur n’utilise pas le port 20 en mode passif.
En gros, dans le canal de données, rien n’identifie le client à part le port utilisé.

31 Jan 2022, 00:00

Notes sur find

Suivre les liens symboliques

Par défaut, find voit les liens symboliques comme des fichiers. Pour qu’il considère la cible du lien et non le lien lui-même, il faut utiliser find -L.

Éxécuter une ou plusieurs commandes sur les résultats

-exec echo {} \; pour une commande (ici echo)
-exec echo {} \; -exec touch {} \; - exec cat {} \; pour plusieurs commandes.

Trouver des dates de modification dans le futur

Si une arborescence contient des fichiers dont la date de modification est dans le futur, on peut utiliser -mmin -0,01 pour trouver les fichiers dont la date de modification est plus récente que 0,01 minutes (soit moins d’une seconde) :
find ./ -mmin -0,01

On peut modifier cette date avec touch (avec -exec)

Trouver les liens symboliques

Source

find ./ -type l

Trouver les liens durs

Source

find -type f -links +1 pour lister les fichiers dont les inodes sont référencés plus d’une fois (ces autres références peuvent être en dehors du répertoire dans lequel est lancé find) . Pour ensuite voir les différents fichiers qui référencent le même inode qu’un fichier précis, on peut faire find -samefile ./my-file.

Trouver les dossiers vides

find ./ -type d -empty
find /path/to/data/ -type d -empty -print -delete pour les supprimer

Classer par date

find ./ -iname "*" -printf "%T+\t%p\n" | sort

On peut rajouter awk '{print $2}' pour ne pas afficher la date.

03 Dec 2021, 00:00

Virtualisation

https://wiki.debian.org/KVM
https://www.how2shout.com/linux/how-to-install-and-configure-kvm-on-debian-11-bullseye-linux/

Pour voir si le processeur possède les extensions matérielles nécessaires pour la virtualisation matérielle :
grep -E --color '(vmx|svm)' /proc/cpuinfo

Qu’est-ce que c’est ?

kvm - QEMU

kvm est un hyperviseur type 1, en espace noyau, sous forme de module noyau pour Linux (intégré au noyau depuis la version 2.6.20). Il permet l’accès aux instructions processeur de virtualisation (Intel-VT ou AMD-V).

QEMU est un émulateur de PC (ou hyperviseur de type 2) : il simule du matériel (disques, RAM etc) pour un système invité. Grâce à kvm, il peut mettre à disposition le processeur physique, pour des performances quasi-natives.

L’un n’a pas besoin de l’autre (kvm peut servir à faire tourner une appli Linux sans OS complet, via containerization, et QEMU peut faire tourner un OS virtuel en émulant complètement un processeur), mais c’est en binôme qu’ils fonctionnent le mieux.

Pour voir si une VM utilise kvm , il faut trouver le PID de la VM, puis entrer la commande strings /proc/<PID>/cmdline|grep kvm. Si oui, on peut y lire “-enable-kvm” ou “accel=kvm”.

Il y’a un module noyau nommé kqemu, qui visait à améliorer les performances de qemu, mais celui-ci a été rendu obsolète par kvm. Son seul avantage potentiel est qu’il fournissait une accélération (logicielle) sur les processeurs ne disposant pas des extensions de virtualisation (mais en ce cas, Virtualbox reste aujourd’hui une solution correcte), si l’invité et l’hôte sont sous la même architecture.

Le paquet qemu-user permet de faire tourner un OS compilé pour une architecure différente du processeur physique ?

libvirt, virsh, virt-install, virt-manager

libvirt est une bibliothèque qui permet de gérer les machines virtuelles. Elle peut aussi se connecter à plusieurs hyperviseurs, dont kvm/QEMU, mais aussi Xen par exemple.

virt-install est une interface en ligne de commande pour simplifier la création de VM.

virsh est une interface en ligne de commande pour interagir avec libvirt, et donc créer, supprimer, modifier, démarrer, arrêter etc. les VMs.

  • un “domaine” équivaut à une machine virtuelle.
  • pour lister les VMs de la session utilisateur : virsh list --all
  • pour lister les VMs de la session système : virsh -c qemu:///system list --all
  • pour démarrer une VM système : ‘virsh -c qemu:///system start nom_de_la_vm’

virt-manager est une interface graphique pour interagir avec libvirt (même rôle que virsh, mais en GUI).

virtio

Il me semble que c’est un protocole/une interface pour mettre le matériel de l’hôte à disposition des invités, avec le moins de latence possible. Ces périphériques virtuels nécessitent des pilotes spécifiques, sans quoi ils ne seront pas disponibles, au moins sous Windows. On peut trouver ces pilotes sur cette page.
En montant l’ISO en tant que lecteur CD lors de l’installation de Windows, on peut installer les pilotes pour le contrôleur de disque, à la volée (il faut choisir le dossier qui contient directement les pilotes, il n’y a pas de récursivité).

Virtualbox

C’est simplement un émulateur. Il est plutôt simple d’utilisation, peut être utilisé par un utilisateur non privilégié, mais n’a pas de performances folles.

Xen

Hyperviseur de type 1.

kvm - QEMU

Installation

kvm est déjà présent dans le noyau par défaut. Pour installer QEMU sous Debian Bullseye : sudo apt install qemu-system-x86.
Pour installer virt-manager : sudo apt install virt-manager. Installera automatiquement qemu.

Connexion system ou session

https://blog.wikichoon.com/2016/01/qemusystem-vs-qemusession.html

QEMU peut être utilisé avec une connexion système, ou avec une connexion session.

La connexion système permet l’accès complet à toutes les ressources ; libvirtd est lancé en tant que root, les VMs en tant qu’utilisateur qemu. L’accès d’un utilisateur simple est géré via polkit. On peut ajouter le user au groupe libvirt pour lui permettre un accès aux ressources sans avoir à s’authentifier en root.
La configuration de libvirt est dans /etc/libvirt/.

La connexion session est spécifique à l’utilisateur. Tout est exécuté par l’utilisateur simple. Les configurations/pools sont stockés dans le $HOME. Cependant le réseau accessible par défaut est lent, et peu flexible (difficile à rendre accessible depuis l’extérieur). À voir avec qemu-bridge-helper pour accéder à un pont réseau (créé au préalable par l’admin) ?
La configuration de libvirt est stockée dans $HOME/.config/libvirt.

Détacher souris/clavier de la VM

Par défaut, c’est la combinaison L-Ctrl + L-Alt.

Connexion via SSH

On peut gérer les VMs d’un serveur distant via ssh. Pour ceci, via virsh : virsh --connect qemu+ssh://root@example.com/system.
Via virt-manager, il faut ajouter une connexion, et entrer l’URI qemu+ssh://root@example/system.

En ce cas, il faudra entrer certains chemins manuellement (par exemple pour définir un chemin vers un ISO ou un fichier qcow2), le bouton “Parcourir” étant grisé.

Processeur

La configuration par défaut est de “Copier la configuration du processeur de l’hôte”. Il me semble que ça donne des performances très moyennes. Il vaut mieux décocher cette case et choisir le mode host-passthrough. De même, la détection automatique de la topologie ne me donnait pas de très bons résultats. En choisissant une topologie manuelle, ça fonctionne bien mieux.
Socket : nombre de processeurs physiques sur la MB (1 dans la plupart des cas)
Coeurs : nombre de core du CPU
Chaînes : nombre de thread de chaque core

Périphériques USB ?

Réseau

https://wiki.qemu.org/Documentation/Networking

Le réseau par défaut est un réseau en NAT, et il ne démarre pas automatiquement.
Si on veut bridger une VM à une carte réseau, il faut d’abord créer le pont au niveau système ; il ne semble pas possible de bridger la VM directement à l’interface physique.

Disques

Si connexion à qemu:///system, les pools de stockage (emplacement des fichiers image de disque dur) sont définis dans /etc/libvirt/storage/ et celui par défaut pointe sur /var/lib/libvirt/images/. Les définitions de VMs (fichier XML) sont rangées dans /etc/libvirt/qemu/.

Si connexion à qemu:///session, les pools de stockage dont définis dans $HOME/.config/libvirt/storage/ et celui par défaut pointe vers $HOME/.local/share/libvirt/images/. Les définitions de VMs sont rangées dans $HOME/.config/libvirt/qemu/.

Les images sont au format qcow2.
Il est possible d’utiliser directement un périphérique de type block. Pour ceci, il faut éditer le fichier XML.

Virtualbox

L’avantage principal que je vois est le fait de pouvoir ponter facilement et à la volée la carte réseau virtuelle et n’importe quelle carte réseau (physique, pont ou virtuelle, genre tap0 ), sans préparer le réseau auparavant.

USB

Pour pouvoir passer les périphériques USB à l’invité, l’utilisateur qui lance VBox doit faire partie du groupe vboxusers :
sudo adduser $(whoami) vboxusers

Pour gérer l’USB2 / USB3 , il faut l’extension pack :
sudo apt install virtualbox-ext-pack

On peut passer les périphériques à la volée, via clic-droit sur l’icône USB en bas à droite de la fenêtre de la VM.

16 Apr 2021, 00:00

Reprendre la copie interrompu d'un fichier

Si la copie d’un fichier a été interrompue, on peut la reprendre avec rsync --append (qui va bêtement reprendre si le fichier de destination est plus petit que le fichier source) ou rsync --append-verify (qui va vérifier que les données pré-existantes sont bien les mêmes sur la source et la destination).