Description
Pour rappel, l’hyperviseur vmm(4) sous OpenBSD n’a pas de support vidéo pour les VM invités. Seule la console série est prise en charge.
Quand vous faites de la virtualisation sous OpenBSD amd64 ou i386, OpenBSD
gère tout ce qu’il faut, comme de nécessaire. Ainsi la console série est
configurée au sein du fichier de configuration /etc/boot.conf et le dispositif
tty00 est configuré correctement pour utiliser ladite console série.
Le problème est quand vous avez l’idée de créer votre VM, sous Linux par
exemple, à moins de spécifiquement répondre yes lorsqu’est demandé le
paramétrage de com0, il est possible de se retrouver avec le problème
suivant :
Pas d’écran de connexion == pas de login possible !
(où il y en a des malchanceux, et d’autres où ça roule sans soucis… je suis souvent de la première catégorie)
Pour illustrer le propos, une fois la VM OpenBSD copiée sur un hôte OpenBSD, voici le démarrage :
$ vmctl start -c vm-test
Using drive 0, partition 3.
Loading......
probing: pc0 com0 mem[638K 1022M a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.52
boot>
booting hd0a:/bsd: 14329128+3191816+337072+0+872448 [999468+128+1135344+859361]=0x14ba488
entry point at 0xffffffff81001000
[ using 2995336 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org
OpenBSD 6.8 (GENERIC) #4: Mon Jan 11 10:34:36 MST 2021
root@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056956416 (1007MB)
avail mem = 1010040832 (963MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf3f40 (10 entries)
bios0: vendor SeaBIOS version "1.11.0p3-OpenBSD-vmm" date 01/01/2011
bios0: OpenBSD VMM
acpi at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD FX-8320E Eight-Core Processor, 3211.59 MHz, 15-02-00
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,CX8,SEP,PGE,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
pvbus0 at mainbus0: OpenBSD
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00
virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio0
virtio0: irq 3
virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio1: address fe:e1:bb:d1:a9:7b
virtio1: irq 5
virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio2
scsibus1 at vioblk0: 1 targets
sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, >
sd0: 51200MB, 512 bytes/sector, 104857600 sectors
virtio2: irq 6
virtio3 at pci0 dev 4 function 0 "OpenBSD VMM Control" rev 0x00
vmmci0 at virtio3
virtio3: irq 7
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
com0: console
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (6dc570f70e2c7991.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (6dc570f70e2c7991.a): file system is clean; not checking
/dev/sd0m (6dc570f70e2c7991.m): file system is clean; not checking
/dev/sd0d (6dc570f70e2c7991.d): file system is clean; not checking
/dev/sd0f (6dc570f70e2c7991.f): file system is clean; not checking
/dev/sd0g (6dc570f70e2c7991.g): file system is clean; not checking
/dev/sd0h (6dc570f70e2c7991.h): file system is clean; not checking
/dev/sd0j (6dc570f70e2c7991.j): file system is clean; not checking
/dev/sd0i (6dc570f70e2c7991.i): file system is clean; not checking
/dev/sd0e (6dc570f70e2c7991.e): file system is clean; not checking
/dev/sd0k (6dc570f70e2c7991.k): file system is clean; not checking
/dev/sd0l (6dc570f70e2c7991.l): file system is clean; not checking
pf enabled
kern.seminfo.semmni: 10 -> 60
kern.seminfo.semmns: 60 -> 1024
starting network
reordering libraries: done.
starting early daemons: syslogd pflogd nsd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd.
starting local daemons: cron.
Thu Feb 18 12:25:45 CET 2021
Et, voilà cela s’arrête à l’affichage de l’heure… et vous allez pouvoir attendre longtemps l’écran de connexion de session qui ne viendra jamais !
Et, au cas où tu te le demandes, toi lecteur, non cela ne vient pas d’une corruption de la VM lors de la copie/synchronisation, des tests à base de somme de contrôle sha256 ont été faits avant la copie et après celle-ci, tel que :
Sur la station Linux :
$ cat vm-test.qcow2.sha256
73054a89bb2e0b13d78e8cb446424baa01f7761099d8681a59137655b28c979c vm-test.qcow2
Puis sur l’hôte OpenBSD :
$ sha256 vm-test.qcow2
SHA256 (vm-test.qcow2) = 73054a89bb2e0b13d78e8cb446424baa01f7761099d8681a59137655b28c979c
$ sha256 -C vm-test.qcow2.sha256 vm-test.qcow2
(SHA256) vm-test.qcow2: OK
Mais alors que faire ?!
Sur ton OS source, par exemple le Linux où la VM a été créée, avec qemu et les différents outils virt*, connectes-toi à ta VM, et fais les deux petites modifications suivantes nécessaires :
Configuration
boot.conf
Le fichier de configuration /etc/boot.conf n’a pas été créé - s’il l’est,
vérifies l’écriture. Il doit absolument contenir à minima ceci :
set tty com0
Par défaut, le taux de connexion est ainsi de 9200 baups.
Or, étant donné que le futur hôte est OpenBSD, faisons ça bien :
stty com0 115200
set tty com0
Ainsi nous configurons le taux de débit au maximum supporté, soit de 115200.
ttys
L’autre modification nécessaire à faire est de reparamétrer les informations d’initialisation du Terminal tty00.
Le fichier est /etc/ttys, et il faut commenter/supprimer la ligne correspondante
à tty00 pour ajouter la déclaration correcte suivante :
tty00 "/usr/libexec/getty std.115200" vt220 on secure
Si vous déclarez le fichier boot.conf ci-dessus a sa valeur par défaut,
configurez cette déclaration ainsi :
tty00 "/usr/libexec/getty std.9600" vt220 on secure
Et, voilà !
Une fois la VM recopiée sous OpenBSD, vous aurez à nouveau l’écran de connexion.
Documentations
- la FAQ Officielle d’OpenBSD “Configuring a Serial Console” (cf : la traduction FR faite par la communauté “OpenBSD Pour Tous”)
Remerciements
@jggimi…