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…

J'ai voulu tester du let's encrypt (oui…) sur une VM Alpine. Apparemment il y a enfin un setup simple, qui fait ce qu'on veut et qui juste marche. Mais je n'ai pas encore pu tester le renouvellement auto évidemment.
Avec les paquets, on peut installer acme-client-plus et acme-client. Le dernier est le client ACME d'OpenBSD, écrit en C et avec pas mal de fontionnalités (mais pas les wildcard si j'ai bien compris). Le premier est un script shell et les quelques fichiers de conf pour qu'il renouvelle au besoin.
Plus rien à copier, mettre en place, installer, il suffit de faire un "acme-client-plus issue" et hop on a son certificat (une fois qu'on a corrigé nos erreurs de DNS/routage/config serveur web/…). Un peu comme le script que j'avais mis en place il y a longtemps, à la main. Là c'est pareil mais en tout prêt.
À voir au renouvellement… !

On peut ajouter dans Qemu via virtio une source de random qui remonte de l'hôte. A priori c'est pour accéder aux sources "matérielles" mais on peut aussi coller ça sur par exemple /dev/urandom.
J'ai testé pour voir, et ça a effectivement débloqué le "problème" que je vois, à savoir que ssh boot tellement avant que urandom soit setup qu'il attend des fois plus d'une minute d'avoir de l'entropie. Pas très important, juste pour le level up/connaissance.
Je n'ai pas eu besoin de lier cette sources au random "kernel" d'une manière ou d'une autre genre avec hwrng comme proposé par-ci par-là.

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…

Si jamais systemctl --user marche pas avec cette erreur, il suffit de définir la variable d'environnement qui va bien pour débloquer la situation :
XDG_RUNTIME_DIR=/run/user/$(id -u)
Pas besoin de bricoler avec du dbus ou quoi. On peut l'exporter dans son bashrc par exemple. Probablement dû à un sshd configuré sans PAM dans mon cas mais il y a sûrement d'autres raisons possibles.

Fichiers sysfs faciles à accéder pour voir les compteurs des interfaces réseau sans passer par une commande ou parser des sorties plus ou moins obsolètes comme ifconfig. Exemple pour le rx :
/sys/class/net/*/statistics/rx_bytes
/sys/class/net/*/statistics/rx_packets

Cacher un exchange où les administrateurs n'ont pas activé IMAP derrière davmail, ça devient presque supportable niveau réactivité quand on passe en accès EWS au lieu du webdav, comme suggéré sur le lien ci-lié.
Attention, ne pas mettre d'espace après l'URL :-' https://sourceforge.net/p/davmail/mailman/message/33184515/

3.3V apparemment ça marche ? Bah moi d'abord j'ai fait tourner un RPi zero WH avec du 3V, na.
En fait j'ai oublié de vérifier la tension sur le transfo avant de brancher le RPi, je l'avais mis au minimum pour un petit ventilateur… ça aurait pu faire de la casse.
Au contraire, tout fonctionnait même le WiFi et l'HDMI. Juste pas l'USB…
J'ai aussi de la corruption sur certains fichiers, mais j'ai passé les mises à jour pendant la période 3V donc je pense que le contrôleur de la carte SD a fait ce qu'il a pu (ou que la carte est foireuse de toutes façons).
À noter qu'une libpam corrompue, ça te laisse à la porte de ta machine comme une merde, que ce soit SSH ou login. Normal mais bon… après réinstallation du paquet ça va quand même mieux.

Ennuyé d'avoir à utiliser du Outlook/OWA/Exchange pour gérer sa boite mail d'une entité full-Microsoft ?
J'avais testé il y a plus de 5 ans davmail sur mon poste de stagiaire mais plutôt pas très concluant… il me semble que ça fonctionnait un peu mais que j'avais des problèmes, en tous cas j'avais laissé tombé et me suis farcis OWA depuis (et c'est bien bien relou).
L'autre jour en discutant avec un autre utilisateur de ce système, il m'a expliqué qu'il utilisait davmail sur son poste directement, et j'ai re-regardé un peu.
Il y a même un mode serveur. Aujourd'hui, je me suis dit que c'était le moment de tenter, et j'ai fait rapidement une petite VM sur mon desktop à la maison avec une Alpine basique et ça…
Tout a fonctionné comme sur des roulettes. La seule chose que j'ai changé de la configuration d'exemple à part les spécificités de connexion, c'est l'activation d'IMAP IDLE, qui derrière faire un polling… j'ai mis une minute pour mimer le comportement de l'interface web qui est instantanée. S'ils sont pas content de la charge ils avaient qu'à cocher la case IMAP dans leur Exchange, chose que je réclame régulièrement depuis le début sans succès.

Donc voilà, Exchange/OWA/Outlook on peut rendre ça compatible avec le rste du monde via davmail. Ça reste tout aussi crade derrière mais un peu plus utilisable, puisqu'on peut utiliser un vrai client mail (je découvre Thunderbird dans la foulée…).
Pour ouvrir à plus de gens, il resterait à chiffrer les communications entre le client et davmail, il y a les options mais je me suis pas encore foulé avec les certificats puisque pour l'instant ça ne sort pas de mon PC…

Les applications CUDA indexent les GPU de la machine par défaut dans l'ordre de performance supposée, alors que dans nvidia-smi le listing est donné par ordre PCI.
On peut changer le comportement dans les applications avec CUDA_DEVICE_ORDER=PCI_BUS_ID dans l'environnement.