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.
Pour installer le démon libvirt : sudo apt install libvirt-daemon-system

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.

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

Si l’on construit une image live de Debian en se basant sur une version non stable (testing ou sid), les dépôts de sécurité ne sont pas encore existants. lb build ou lb chroot vont donc planter avec une erreur de type “E: The repository ‘http://security.debian.org bullseye/updates Release’ does not have a Release file.”.

Pour éviter ceci, on peut mettre dans le fichier auto/config la ligne :

--security "false" \

Normalement ça ne devrait plus poser de problèmes. On peut aller vérifier que le fichier config/chroot contient LB_SECURITY="false".

Source

Sur les 2 machines :
apt install iperf

Sur le serveur :
iperf -s

Sur le client :
iperf -c SERVER_IP

Par défaut, cela transmet du client vers le serveur (upload). On peut inverser le sens (download) avec le flag -R.
Par défaut, le test dure 10s. Ce temps peut se controler avec le paramètre -t num_sec.
On peut changer le port par défaut (5201) avec -p 5202.

Un peu de lecture ici.

iotop

sudo apt install iotop
sudo iotop

Permet de voir, à la manière de top, l’activité I/O des disques par processus. Ne distingue toutefois pas sur quel disque l’activité se produit.

dstat

sudo apt install dstat
dstat pour avoir un aperçu général.
dstat -d -D total,sdk,md0 pour n’afficher que les infos relatives aux disques (-d), et surveiller l’ensemble des I/O dans une colonne (-D total), /dev/sdk dans un autre (-D sdk)et /dev/md0 dans une autre (-D md0).

iostat

sudo apt install sysstat
iostat pour avoir des infos générales depuis le boot.
iostat -y 1 2 pour avoir des infos uniquement dans l’intervalle temporel spécifié ; ici : 1s, analyse répétée 2 fois (1 2). Si le 2e chiffre n’est pas spécifié, l’analyse sera faite en boucle.
iostat -d pour n’inclure que l’info relative aux disques.
iostat -p sdk,md0 pour n’inclure que l’info relative à ces périphériques.
iostat -t pour inclure le timestamp

En cumulant ces options, et avec l’utilisation de watch, on tombe sur un truc comme ça :
watch -t -n 0.1 iostat -p sdk,md0 -d -t -y 1 1

nmon

sudo apt install nmon
nmon puis presser la touche d

Exemple de docker-compose (pour Medalla)

Très très très inspiré de ça : https://github.com/stefa2k/prysm-docker-compose

version: "3.6"

x-logging: &logging
        logging:
                driver: "json-file"
                options:
                        max-file: "10"
                        max-size: "100m"

services:

        medalla-prysm-beacon:
                stop_grace_period: 1m
                container_name: medalla-prysm-beacon
                image: gcr.io/prysmaticlabs/prysm/beacon-chain:${PRYSM_DOCKER_TAG}
                hostname: medalla-prysm-beacon
                command: --config-file=/config/beacon.yaml 
#               --p2p-max-peers=1000
                ports:
                        - 4000:4000
                        - 13000:13000/tcp
                        - 12000:12000/udp
                volumes:
                        - ./config/beacon.yaml:/config/beacon.yaml:ro
                        - ${VOLUMES_PATH}/prysm/beacon:/data
                <<: *logging
        medalla-prysm-validator:
                stop_grace_period: 1m
                tty: true
                stdin_open: true
                container_name: medalla-prysm-validator
                image: gcr.io/prysmaticlabs/prysm/validator:${PRYSM_DOCKER_TAG}
                hostname: medalla-prysm-validator
                depends_on:
                        - medalla-prysm-beacon
                command: --config-file=/config/validator.yaml
                volumes:
                        - ./config/validator.yaml:/config/validator.yaml:ro
                        - ${VOLUMES_PATH}/prysm/validator:/wallet
                <<: *logging

# I use a custom defined network
networks:
  default:
    external:
      name: eth_net

Les fichiers de config :

beacon.yaml

############################################################
##
## Read up on parameters on
## https://docs.prylabs.network/docs/prysm-usage/parameters/
##
############################################################

datadir: /data

###############
# Base settings
medalla: true
accept-terms-of-use: true
# p2p-max-peers: 1000

#######################
# Connectivity settings 
p2p-host-ip: ""
p2p-host-dns: ""

rpc-host: 0.0.0.0
monitoring-host: 0.0.0.0

# disable scan of local network
p2p-denylist: ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","100.64.0.0/10","169.254.0.0/16"]

# changing this also needs to be changed in docker-compose.yaml !
p2p-tcp-port: 13000

# enable db backup endpoint
enable-db-backup-webhook: true

##############################
# Connection to eth1 chain container
http-web3provider: http://goerlichain-hostname:8546
web3provider: ws://goerlichain-hostname:8546

validator.yaml :

############################################################
##
## Read up on parameters on
## https://docs.prylabs.network/docs/prysm-usage/parameters/
##
############################################################

##############
# Connectivity
beacon-rpc-provider: prysm-beacon-hostname:4000
monitoring-host: 0.0.0.0

##############
# Base settings
medalla: true
accept-terms-of-use: true

#####################################
# Validator accounts & key management
wallet-dir: /wallet

###########
# Fun Stuff
graffiti: "My funky graffiti !"

#############
# Performance
dev: true
block-batch-limit: 512
head-sync: true         

Usage général

Pour exécuter une instance du validateur pour gérer les fichiers (en adaptant les chemins de volumes) :

docker run --rm -it -v ./config/validator.yaml:/config/validator.yaml -v ${VOLUMES_PATH}/testnets/medalla/prysm/validator:/wallet --config-file=/config/validator.yaml

On peut ensuite choisir les commandes Prysm ; par exemple :

• help , qui affiche l’aide
• accounts
• wallet

On peut spécifier des drapeaux à la suite de cette commande, mais ils doivent être placés après les commandes de prysm.

Dans ma configuration, je ne sauvegarde le mot de passe nul part sur le disque ; il faut donc le fournir au lancement du validateur ; je recommande donc la comande suivante pour démarrer le validateur :
docker-compose up -d && docker attach medalla-prysm-validator, puis quitter avec Ctrl+P - Ctrl+Q.

Pour lire les logs de la beacon chain, et pouvoir les filtrer par exemple via grep, il faut rediriger la sortie d’erreur vers la sortie standard :
docker logs medalla-prysm-beacon 2>&1 | grep Synced

wallet

Le wallet représente l’ensemble des fichiers gérés par Prysm. On a un seul wallet à la fois. Il peut être de type “importé” ou déterministe (“HD”), ou avec signature distante, mais je ne traite pas ce cas ici.

Un wallet HD va recréer les clés en fonction de la graine fournie/générée ; C’est pratique, mais le validateur (exposé en permanence à Internet) est en possession de la graine, c’est à dire de la possibilité d’accéder aux clés de validations, mais également aux clés de retrait qui permettent de récupérer l’ETH2 ; d’où le risque de sécurité.
Les fichiers seront stockés dans le dossier “derived”.

Un wallet importé va pouvoir traiter, 1 par 1, les fichiers fournis via la command import (voir la section accounts). On peut donc générer nos clés de manière externe (par exemple via eth2-deposit-cli, (ou via ethdo ?)), et n’exposer que les clés de validation, d’où la sécurité augmentée.
Les fichiers seront stockés dans le dossier “direct”.

Si les dossiers “derived” et “direct” existent tous les 2, le validateur ne démarrera pas.

Les commandes :

• wallet create : permet de créer un nouveau wallet, en choisissant son type ; échouera si un wallet est déjà présent à l’emplacement indiqué
• edit-config : permet de modifier la configuration d’un wallet HD uniquement
• recover : pour recréer un wallet HD dont on a déjà la graine
• help : self-explaining

accounts

Un account représente un validateur, une paire de clés. On peut avoir plusieurs validateurs actifs en même temps. On peut rajouter un ou plusieurs validateurs aux validateurs déjà actifs.

Les commandes :

• create : crée un nouveau validateur ; implique wallet create si aucun wallet n’existe dans le dossier spécifié
• delete : permet de supprimer un ou plusieurs validateurs
• list : permet de lister les validateurs actuellement actifs dans Prysm
• backup : self-explaining. Exporte clés de validation ET clés de retrait si elles sont présentes dans Prysm
• import : permet d’ajouter une clé de validateur déjà existante. Semble ne rien faire si le wallet est de type HD ; implique la création d’un wallet de type importé si aucun wallet n’existe. On doit spécifier un dossier qui contient les fichiers keystore, et taper les mots de passe ; les mots de passe peuvent être différents pour chaque keystore, il faut alors les entrer au fur et à mesure de l’importation
• voluntary-exit : permet de quitter le pool de validateurs. Il est impossible de recommencer à valider avec ces clés, et impossible de retirer ses ethers avant la phase 1, voire la phase 2.
• help : self-explaining

Install depuis git

git clone https://github.com/ethereum/eth2.0-deposit-cli.git
# ou pour la branche de dev :
git clone https://github.com/ethereum/eth2.0-deposit-cli.git -b dev

# pour installer eth2deposit module
# à refaire à chaque update pour updater le module pip3
pip3 install ./
# si besoin de changement de version, on peut désinstaller la version en conflit avec 
pip3 uninstall eth2deposit

cd eth2.0-deposit-cli

Nouvelle graine :

./deposit.sh new-mnemonic
Si plusieurs validateurs, crée 1 deposit_data cumulatif, et plusieurs keystore.json (le nom des fichiers contient le timestamp).
On doit pouvoir ajouter l’option --chain mainnet pour passer directement la chaine cible sans avoir à la choisir.

Graine existante (pour régénerer des clés, ou générer des nouvelles clés)

!!! ATTENTION A LA DOUBLE VALIDATION !!!

./deposit.sh existing-mnemonic

Choisir l’index de départ (si 2 clés ont déjà générées et que l’on souhaite en générer une nouvelle 3e, entrer 2 ; si on veut regénérer des clés dejà existantes, entrer 0 pour toutes les générer).
Choisir le nombre de clés à générer.
Les clés sont générées dans le dossier validator_keys.

Régén avec ancienne version de la méthode de dérivation (par exemple v0.2.0)

Dans eth2deposit\deposit.py, ligne 30, hardcoder la graine à restaurer après mnemonic = en la mettant entre apostrophes.

Doc ubuntu

Config de la rotation stockée dans /etc/logrotate.d/mon-journal-a-rotater

De cette forme :

/path/to/my/logfile {
	monthly        # can be daily, weekly
	rotate 12      # keep 12 history files
	compress       # gzip the old logs
	delaycompress  # gzip old logs except the more recent one
	missingok      # does not stop if a file is missing
	notifempty     # does not rotate if file is empty
	create 644 root root # permissions, user and group for the newly created file
}

Force rotation :
logrotate -fv /etc/logrotate.d/mon-journal-a-rotater (force, and verbose)
On peut spécifier directement le fichier de configuration général, /etc/logrotate.conf, qui inclue tout ce qui se trouve dans /etc/logrotate.d/ si on veut rotater l’ensemble des logs.

Ping scan : nmap -sn 10.0.0.1-255

Nmap est plus efficace lorsqu’il est lancé avec les droits root, car il peut aller directement consulter la table ARP, alors que sans les droits root, il tente la connection sur un/des ports courants.

https://security.stackexchange.com/questions/74493/different-results-using-nmap-with-without-sudo

Parfois, même ainsi, tous les appareils en ligne ne sont pas listés (genre 10 resultats maximum). Il semble que passer l’option -v pour augmenter la verbosité aide à les visualiser tous.

Pour n’avoir que les IP affichées, on peut poser ça après notre commande nmap : | grep report | awk '{print $5}'

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

Editer le fichier auto/config pour qu’il contienne ceci :

#!/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 'buster' \
	--linux-flavours 'amd64' \
	--source 'false' \
	"${@}"

Entrer la commande lb config, puis aller éditer le fichier config/package-lists/live.list.chroot et ajouter les paquets désirés. Je propose ceci :

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

# 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

Puis entrer la commande sudo lb build.

A noter qu’il est possible de décomposer la commande sudo lb build en la succession suivante :

sudo lb bootstrap
sudo lb chroot
sudo lb binary

Il est possible d’aller modifier/ajouter manuellement des fichiers entre l’étape chroot et l’étape binary. Par exemple :

sudo mkdir ./chroot/home/user/
sudo cp /etc/skel/.* ./chroot/home/user/
sudo mkdir ./chroot/home/user/Bureau/
sudo chown 1000:1000 ./chroot/home/user -R

et y ajouter des fichiers, qui seront disponibles directement sur le bureau du live.
On peut éditer les alias :
nano chroot/home/user/.bashrc

On peut aussi ajouter le .inputrc tant qu’à faire
nano ./chroot/home/user/.inputrc

Si on souhaite recommencer la création du live, on peut utiliser la commande sudo lb clean qui ne conserve que le cache des paquets, du bootstrap et la config. On peut aussi utiliser les options --binary ou bien --chroot pour conserver les étapes antérieures.
On peut également utiliser l’option --cache pour supprimer également le cache et repartir complètement à 0.