Quick NetBSD serial console install on libvirt

I wanted to set up a small VM with NetBSD to test a couple of virt-install option. It turns out it you can get to the installer prompt quite fast.

get the NetBSD installer for serial console:

wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/i386/installation/cdrom/boot-com.iso 

start the install  

$ virt-install \
--connect qemu:///session \
--name netbsd \
--ram 64 \
--vcpus 2 \
--disk path=$HOME/netbsd.qcow2,size=4,bus=scsi,format=qcow2 \
--controller type=scsi,model=virtio-scsi \
--cdrom=boot-com.iso \
--virt-type kvm \
--os-variant netbsd8.0 \
--graphics none \
--arch i686 \
--console pty,target_type=serial 

This will start a VM in usermode networking, so no need to be root, but the VM won’t be reachable from the outside world, except if you add qemu usermode port forwarding.

Trois messages d'erreur parmi les plus confus sous Unix / Linux

Je conserve une collection de messages d'erreurs inattendus, en voici un florilège:

Le dossier qui n'était pas un dossier

# Création d'un répertoire de test

mkdir /tmp/my_dir

# On crée un lien symbolique vers ce répertoire

ln -s /tmp/my_dir /tmp/my_link# On efface le lien symbolique ( completion du nom en tapant deux fois Tab pour faire apparaître le slash / à la fin )
rm /tmp/my_link/
rm: impossible de supprimer « /tmp/my_link/ »: est un dossier

rmdir /tmp/my_link/
rmdir: échec de suppression de « /tmp/my_link/ »: N'est pas un dossier
# Faudrait savoir ...

#La solution 

rm /tmp/my_link 

Est-ce un bug des coreutils ( dont fait partie rm) sous Linux ?  Sous NetBSD la commande rm /tmp/my_link/ efface bien le lien symbolique.

Mount prétend que le disque dur n'existe pas

Depuis le CD d'install GNU/kFreeBSD, en exécutant un shell de secours.

#On monte la partition racine depuis le live CD

mount /dev/da4s1 /mnt

mount: mounting /dev/da4s1 on /mnt/failed: No such file or directory

Alors que /dev/da4s1 et /mnt existent bien ! La solution (discutée ici):
mount -t ufs /dev/da4s1 /mnt

Mount prétend que root n'est pas root

Depuis le CD d'install GNU/kFreeBSD, en exécutant un shell de secours.
#On monte la partition racine depuis le live CD
mount -t ufs /dev/da4s1 /mnt
mount:permission denied (are you root?)

La solution: rien à voir ici avec un problème de droits, /dev/da4s1 n'a pas été démontée proprement. Il faut tout d'abord effectuer

fsck.ufs /dev/da4s1

avant de monter la partition.

Le Vatican: combien de divisions ? Compter le nombre de processeurs disponibles sur son système

Sous Linux ( via la glibc):
getconf _NPROCESSORS_ONLN

Sous BSD:
sysctl -n hw.ncpu

Sous OpenVMS:
show cpu /brief

Sous OSX/Darwin:
sysctl machdep.cpu.core_count

Aide mémoire sysbench

Afin d'avoir de la matière pour comparer des pommes et des oranges, il est bien pratique d'avoir un petit benchmark sous le coude. Je vous présente donc sysbench, présent dans l'archive Debian/Ubuntu et dans les ports/pkgsrc BSD. Sysbench permet des comparaisons rapides et de vérifier que les cores/cpus qu'on vous annonce avec fanfare servent à quelque chose. Nous mesurons ici le temps de calcul des 10 000 premiers nombres premiers.

Machine 1:

grep "model name" /proc/cpuinfo # deux cpu/cores

model name : AMD Athlon(tm) Dual Core Processor 5400B

model name : AMD Athlon(tm) Dual Core Processor 5400B

for THREADS in 1 2 3 4 ; do printf "threads: $THREADS" ; sysbench --test=cpu --cpu-max-prime=10000 --num-threads=$THREADS run | grep "total time:" ; done

threads: 1 total time: 36.2429s

threads: 2 total time: 18.1774s

threads: 3 total time: 18.5373s

threads: 4 total time: 18.1599s

Machine 2 :

grep "model name" /proc/cpuinfo

model name : Dual-Core AMD Opteron(tm) Processor 2220

model name : Dual-Core AMD Opteron(tm) Processor 2220

model name : Dual-Core AMD Opteron(tm) Processor 2220

model name : Dual-Core AMD Opteron(tm) Processor 2220

for THREADS in 1 2 3 4 ; do printf "threads: $THREADS" ; sysbench --test=cpu --cpu-max-prime=10000 --num-threads=$THREADS run | grep "total time:" ; done

threads: 1 total time: 35.7832s

threads: 2 total time: 17.8263s

threads: 3 total time: 12.0110s

threads: 4 total time: 11.9021s

Conclusion:

Le passage de 1 à 4 cpus permet bien des gains de performance pour une application de calcul, mais ceci de manière non linéaire. Pourquoi ? De mémoire, le nombre de threads augmentent, plus le noyau doit passer de temps  à les synchroniser . J'aurais bien aimé trouver un lien pour confirmer, mais non, cette fois ci, STFW se tait (ou cherche dans le vide plus exactement)