Qu'est-ce qui fait réagir un système avec systemd aux événements ACPI (poweroff etc.) ? logind !
Du coup la doc qui dit qu'il faut acpid n'est plus utile : quand acpid fonctionne, il appelle un script qui vérifie juste que logind tourne et qu'un appel dbus précis est possible (voir /usr/share/acpi-support/policy-funcs).

J'ai creusé tout ça parce que une seule VM parmi une grosse dizaine ne répondait pas aux injonctions d'extinction "propre" de son hyperviseur…
Il se trouve que cette VM était à la base un conteneur LXC non-privilégié (oui j'ai testé ça un moment pour voir). Et dans ce conteneur, le service systemd-udevd était masqué…

J'ai appris plein de choses sur udev, acpi, logind.
J'ai découvert les modules noyal "button" et "evdev".
Par hasard je suis tombé sur lsinitramfs.
Pas si mal :)

Pour lancer acpid en mode debug + log : acpid -d -l -f

Proxmox est passé (il y a longtemps) d'un simple tar disque virtuel + conf à un format perso (mais ouvert) pour contenir les backup. Pourquoi pas, et il y a des raisons apparemment compréhensibles.

Cependant, on peut être amené à vouloir vérifier un backup ailleurs, sur une machine non-Proxmox (son desktop par exemple). Il existe un outil pour gérer ces sauvegardes mais apparemment pas trop dissocié ni dissociable… il vaut mieux être prévenu du coup, ce que je fais là.

Au pire du pire on peut faire comme moi et juste copier l'exécutable et les libs à la main, si on est sur une distro pas trop différente ça se passera bien (moi du coup de Debian 10 à Debian 10 ça a été crème :)).

Si on s'est trompé de nom (ou a oublié une parie) à l'installation d'une machine Proxmox, renommer n'est pas trop compliqué, suivre la doc officielle. Par contre (comme dit ici : https://memo-linux.com/proxmox-renommer-un-noeud/) il peut être nécessaire de faire un bon vieux reboot au bout, en tous cas on n'a pas réussi sans, même à relancer la plupart des services.

Sous Proxmox, il y a en fait une base sqlite qui reprend les configurations et qu'on ne croise quasiment jamais. Les fichiers texte sont matérialisés au lancement du démon PVE, et sont synchronisés (de manière bidirectionnelle, on peut les éditer) en permanence. Si on a des vieux restes par contre, et que éditer les fichiers nous est refusé (on se fait jeter sur les permissions d'écriture), il peut être nécessaire de taper dans la base. Il faut le savoir…

Après la base est pas bien méchante, c'est une seule table "tree" où il y a les fichiers quasiment tels qu'ils sont créés, que ce soit le corosync.conf ou ceux propres à PVE. Voir l'article lié sur comment purger, mais c'est sur SQL de base.

Sur une idée basée sur ce script qui affirme qu'il n'y a pas besoin de partition pour créer un disque de machine virtuelle et en utilisant extlinux, j'ai passé un peu de temps à transférer un conteneur LXC non-privilégié (fait alamano au début quand LXC 1.0 est sorti) vers une VM full qemu/kvm sous Proxmox.
Voici ce que j'ai fait :
sudo qm create 302
sudo qm set 302 -virtio0 local-zfs:10
=> création de la VM, avec un disque de 10 Go dans le zfs ; oui ça aurait pu se faire en une ligne mais entretemps j'ai réfléchi et au lieu de faire un fichier qcow2 et de le monter avec qemu-nbd et tout ce bazar je me suis dit que ça serait plus simple avec un bon vieux block device
sudo mkfs.ext4 /dev/rpool/data/vm-302-disk-0
=> pas de partition
sudo mount /dev/rpool/data/vm-302-disk-0 /mnt/
cd /mnt
=> tellement simple par rapport à un qcow2 + partition + éventuellement LVM… oui c'est pas chiffré mais pour un site d'affichage public, ça devrait aller
ssh IP-VM-avec-LXC 'sudo -S -u lxcguests lxc-usernsexec -- tar cf - /home/lxc/lxcguests/.local/share/lxc/web/rootfs/' | sudo tar xf -
=> copie avec tar pour la préservation des attributs de tout le rootfs ; lxc-usernsexec pour que tar soit exécuté dans le namespace uid du lxc (sinon root aurait été uid 100000 etc. selon ma configuration de l'époque). EDIT: Si l'on copie un LXC booté ou avec des montages, ajouter --one-file-system au tar cf pour être sûr de ne pas emporter trop de monde (/dev, /proc …) - FEDIT
sudo chroot .
apt install linux-image-amd64
=> on ajoute un noyau, ça va servir…
exit
sudo extlinux --install /mnt/
=> on le fait de l'extérieur, partition montée. d'après le man, c'est fait pour et ça nous évite de bind-mount /dev et compagnie dans le chroot ; là si on lance la VM on est déjà dans notre bootloader, qui demande quoi faire avec boot:

On peut alors booter en tapant tout à la main dans extlinux. Après un peu de tests et en regardant la config d'un autre extlinux qui fonctionne, j'ai pu arriver dans l'initramfs, puis dans un système qui boot mais avec le / en read-only.
Ma commande à la main dans extlinux (promt boot:) était :
/vmlinuz initrd=/initrd.img modules=ext4 root=/dev/vda
On utilise les liens dans / qui sont encore créés par le paquet du noyau sous Debian… :)
Ensuite j'ai posé ça dans un fichier de conf histoire de booter facilement quand même :
DEFAULT virt
LABEL virt
MENU LABEL Linux oasis
LINUX vmlinuz
INITRD initrd.img
APPEND root=UUID=db01b05e-2e90-4df7-a9b2-96a1ee04b1aa modules=ext4

J'ai aussi créé un fstab puisqu'il était vide (mais a priori pas vraiment utile du coup). L'histoire du / qui restait en read-only a perduré même avec un rw sur la cmdline linux, même avec le fstab… et est parti dès que j'ai mis systemd…
EDIT: sans fstab et avec systemd, read-only aussi ; réglé avec un fstab donc il faudrait les deux… ?

Bref ça fonctionne bien. J'ai perdu du temps à vouloir booter depuis extlinux à la main, à ne pas pouvoir monter / car pas de module ext4 (il disait juste "no such file or directory" ce con de mount…) et avec le read-only. Et j'ai aussi passé la mise à jour de jessie à stretch que j'avais jamais faite avant…

Utilisant depuis peu un serveur sous proxmox pour la virtualisation, avec du ZFS pour la gestion du raid soft et des "partitions" des VM, j'ai eu la surprise de voir une utilisation complètement folle de la RAM d'après les outils classiques (top/free/htop).
Il s'agit apparemment d'un cache ARC utilisé par ZFS qui est supposé être meilleur dans le cadre d'un serveur de fichiers (ce qui du coup n'est pas le cas mais est un cas fréquent).
D'après https://superuser.com/questions/1137416/how-can-i-determine-the-current-size-of-the-arc-in-zfs-and-how-does-the-arc-rel :
Because of how ZFS on Linux is implemented, the ARC memory behaves like cache memory (for example, it is evicted if the system comes under memory pressure), but is aggregated by the kernel as ordinary memory allocations.

Pour regarder :
arcstat, /proc/spl/kstat/zfs/arcstats, arc_summary

Pour jouer un peu :
https://www.svennd.be/tuning-of-zfs-module/
pour le désactiver :
zfs set zfs set secondarycache=none rpool
zfs set secondarycache=none rpool
cela réagit bien à un drop des caches (mais pas complètement, moi il restait dans les 400 méga) :
echo 3 > /proc/sys/vm/drop_caches

Pour l'instant j'ai remis, c'est supposé être capable de réagir en cas de demande de mémoire (mais pas toujours : some applications will require a certain amount of memory to start, or request memory on a rate that is quicker then ARC size can lower, resulting in a crash/swapping). Je verrai bien mais il vaut mieux être prévenu…

Article que j'ai trouvé très complet, avec de bonnes explications sur comment fonctionne qemu-user, à quoi ça sert etc.
Pour utiliser qemu-arm-static, j'ai dû installer le paquet qemu-user-static (ce n'est pas décrit). Le -static désinstalle le -binfmt. Bizarre. Pourtant même après ça, le bon interpréteur est tout de même utilisé automagiquement et les fichiers de "registration" des formats sont toujours là (voir /proc/sys/fs/binfmt_misc/).
En fait en rédigeant j'ai regardé et le -static rajoute de lui-même les binfmt… voir /var/lib/dpkg/info/qemu-user-static.postinst pas très homogène tout ça on dirait.

Juste pour éviter à des gens d'être surpris, maintenant sous Debian Stretch, les outils systemd pour la conteneurisation (nspawn/machinectl) sont dans un paquet séparé -- et c'est tant mieux ! :)
Après un upgrade, une fois le paquet installé, tout repart normalement.

Migrer des VM à chaud, sans stockage partagé, avec qemu/kvm ? J'avais vu passer ça, le temps que ça descende dans les distro, que j'y repense, que j'aie de quoi tester… bref là ça marche.
Il y avait un problème où il fallait créer le disque destination de la bonne taille à la main… en 2013 : c'est manifestement corrigé.
Attention, ça ne fonctionne pas avec virt-manager, il essaye de faire une migration comme si le stockage était partagé.
Donc avec virsh :
virsh migrate --live --persistent --undefinesource --copy-storage-all --verbose --desturi qemu+ssh://user@dest-machine/system vm-to-migrate
Ça demande le mot de passe pour se connecter en ssh, et c'est parti. La copie du disque prend forcément un peu de temps mais j'ai vu du trafic jusqu'à 400 Mo/s, et pendant ce temps-là la machine est toujours en fonctionnement : il y a une deuxième passe pour synchroniser le delta.
Pratique.

(La commande est issue de : http://hgj.hu/live-migrating-a-virtual-machine-with-libvirt-without-a-shared-storage/ car je n'ai pas trouvé d'exemple sur la page liée ni sur les pages proposées en bas.)

Par exemple pour le disque d'une machine virtuelle qu'on voudrait transmettre/copier/whatever, il peut être malin (ou juste amusant) de chercher à réduire la taille du fichier. On arrive donc à la notion de fichiers creux (sparse), où les blocs ne contenant que des zéros peuvent tout simplement ne pas être alloués par le système de fichiers.

Il faut donc d'abord mettre des zéros partout où le système invité de la VM n'a rien d'utile : zerofree. Petit outil simple, mais qui a besoin d'un FS non monté ou en ro. On passe donc en ro… (remount ne fonctionne pas : busy) :
echo u | sudo tee /proc/sysrq-trigger
Puis on peut lancer zerofree.

Là on se rend compte que la taille allouée ne diminue pas :
59G -rw-r--r-- 1 root root 59G mai 12 09:55 oleron.raw
59G de taille, 59G alloués… il faut donc… creuser des trous ! Et pour ça, rien de plus simple : fallocate -d
15G -rw-r--r-- 1 root root 59G mai 12 14:17 oleron.raw
Bien ! (à noter qu'on peut aussi utiliser cp --sparse=always, mais qu'il y a donc une copie du fichier (et dans ce test l'allocation était descendue à 20G au lieu de 15G avec fallocate, probablement une histoire de taille de bloc)).

Si l'on veut ensuite écrire cette image sur une clef USB, autant essayer de ne pas écrire ces trous de zéros (ce qui est pourtant le cas avec un dd simple). Pour cela on découvre l'option conv=sparse de dd. En testant je suis arrivé à cela (image de 64Gio, 20G alloués, sur clef USB3 190Mo/s) :
dd simple, bs=1M : 348,944 s, 180 MB/s
cp sparse (bs probablement 4k) : 6m55.131s (donc 415s)
dd sparse : 206,039 s, 305 MB/s
On remarque que la vitesse moyenne est plus grande que la vitesse d'écriture max constatée ! :) Bon et si on poussait le vice à faire deux clefs en parallèle ? 235,069 s, 267 MB/s !
Conclusion, avec tout cela on s'est bien amusé et on peut écrire 2 clefs de 64G utilisables (20G réels) en moins de 5 minutes :) Pour moi qui en ai 25 à faire, c'est pas si mal.

EDIT: 172,801 s, 363 MB/s avec l'image fallocate (qui fait donc 15G au lieu de 20G) en mono-dd sparse.

Pour avoir de l'UEFI dans une VM Qemu :

• installer un firmware UEFI (j'ai pris le paquet ovmf de sid à la main)
• éditer la conf de la VM (pas dispo avant virt-manager plus récent que jessie) et ajouter dans la section "os" :
  virsh edit nom-instance
  <loader readonly='yes' type='rom'>/usr/share/ovmf/OVMF.fd</loader>

Upgrade wheezy vers jessie dans un conteneur LXC sur un host lui-même déjà en jessie ? Et sans cracher sur systemd ? Facile, il suffit de rajouter à la config LXC les deux lignes proposées ici (le reste sur getty/udev est déjà de base ou inutile).
lxc.autodev = 1
lxc.kmsg = 0

machinectl n'a pas de moyen simple d'entrer dans un conteneur qui tourne (comme vzctl enter quoi). Mais la solution est toute simple, puisque ce sont de simples cgroups, on peut entrer dans l'environnement d'une VM "à la main", avec une commande qui s'appelle nsenter. Ici un exemple clair :)
A marché chez moi : sudo nsenter -t 1210 -m -u -i -n

À faire aussi pour LXC ou les containers nspawn systemd si on veut gérer des limites mémoire.
Avec systemd, quand on a le comptage mémoire par cgroup, on peut utiliser systemd-cgtop pour voir la consommation mémoire de chaque service/slice.
Par contre si on met une limite vraiment basse à un nspawn, on a une erreur inattendue :
Failed at step EXEC spawning /usr/bin/systemd-nspawn: Argument list too long

J'ai testé pour vous… les conteneurs systemd (nspawn).
Ça marche à peu près, on sent quand même que c'est tout frais (sous Debian Jessie, systemd 215).
Principalement, problème de conf avec journald, sous Debian apparemment le journal propre à systemd (le binaire) est dans du non-persistant (/run), et donc quand l'unit nspawn persistante cherche à lier les journaux host/guest, entre eux, boum. Il suffit de copier l'unit systemd, mettre "auto" à l'option de journal et zou, le conteneur se lance bien avec un start et machined le voit bien (si on met dans /var/lib/container et pas /var/lib/machines).
Ça a l'air pratique d'un côté d'avoir ça intégré aux outils habituels (journal, unit, …), à voir comment ça évolue, je vais aussi tester un peu plus.

Un petit résumé des snapshot avec libvirt. Il faut dire qu'avec le man j'ai pas compris exactement ce qu'il se passait (quand on avait un snapshot RAM+disque et pas juste disque, ce que sont exactement les "metadata", ce genre de choses). Ici on sait exactement quoi (à la fin, un résumé).
Donc si on veut juste faire un snapshot disque pour pouvoir reprendre plus tard sans s'embêter, il suffit de faire :
snapshot-create <domain>
avec la VM stopped. Le snapshot est alors fait directement dans le qcow, utilisant justement le cow (copy on write). Il y a aussi des snapshots avec RAM, ou dans un qcow séparé (notion de fichier de base + delta) pratique pour backup par exemple.
Pour reprendre à un snapshot :
snapshot-revert <domain> <snapshotname>

Ma doc sur ganeti au taff… déjà beaucoup d'info, j'en rajouterai par la suite. En tous cas il y a moyen de faire un setup sympa : cluster de VM (donc on peut les bouger même si l'host tombe), avec disques directement (sans montage) dans un stockage partagé via la libgfapi de GlusterFS.
Là où je me suis bien amusé c'est avec le script pour installer GRUB dans un chroot…

J'ai récemment vu passer que LXC était sorti en version 1.0 et donc cherché un peu de doc. Un des développeurs a écrit une série de billets de blog sur LXC 1.0 en décembre, peu avant la sortie. On y découvre des choses très intéressantes comme les conteneurs non-privilégiés (c'est-à-dire, lancés par de simples utilisateurs).