Cristian Vicente

Hace unos meses moví todas las máquinas virtuales de Proxmox a Ubuntu 18.04 LTS y todo iba bien hasta que decidir actualizar a Ubuntu 20.04 LTS. Resulta que esta última versión incluye el kernel 5.4 que trae consigo una serie de modificaciones más restrictivas con respecto al acceso de zonas de memoria reservadas y que afectas a las agrupaciones IOMMU mal hechas por parte de algunas BIOS. El error que saltaba era similar al siguiente:

failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument)

Hice diversas modificaciones sobre el kernel para intentar evitar la restricción del mapeo de memoria sin ningún éxito. Probé a actualizar al kernel 5.8 de la rama de desarrollo de Ubuntu para acabar teniendo el mismo problema. La única solución era volver a Ubuntu 18.04 o directamente probar una distribución que trabajase con el kernel 5.3 que era el último que se sabía que funcionaba de forma permisiva en ese aspecto. Por tanto terminé con OpenSuse 15.2.

Todo ello me llevo a cuestionarme si el hardware (HP Gen8) que estaba intentando hacer funcionar merecía la pena tanto tiempo invertido o simplemente comprar otro equipo mejor preparado. Tras visitar numerosas webs me encontré con que la información relativa a las agrupaciones IOMMU no se ofrecen por parte de los fabricantes de placa base y que, futuras actualizaciones de la BIOS podían afectarlas. Lo que parece ser más orientativo es que las placas base más caras suelen ser mejores en ese aspecto y que para plataformas AMD hay que llevar cuidado con las actualizaciones de AGESA. Con lo que al final supone una lotería y voy a estirar el kernel 5.3 todo lo que pueda, a ver si en un futuro se publica algún método para seguir usando este hardware.

Debido al hardware específico (HP Miniserver Gen8) que tengo y que para poder resolver los problemas de su BIOS con la paravirtualización se necesita aplicar un parche en el kernel que me dejó de funcionar en Proxmox en la última actualización, pues decir librarme de la comodidad de Proxmox en busca de algo más flexible.

Quería una distribución con software relativamente actualizado y documentado en el que me sintiese cómodo. Opté por una Ubuntu 18.04 para servidores que, aunque no está entre mis favoritas para el uso cotidiano, es bastante cómoda para funciones de servidor.

Software de virtualización

Después de la instalación básica necesitaba una serie de herramientas para virtualizar máquinas:

apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils

adduser `id -un` libvirt

Preparación previa del hardware

Hice que no cargase ningún driver de la gráfica a la que tenía pensada hacerle passthrough :

echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf

echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf

echo blacklist snd_hda_intel > /etc/modprobe.d/blacklist-nvidia-nouveau.conf

Con el comando «lpsci -nn» encontré los datos de la gráfica que me interesaban:

07:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)
07:00.1 Audio device [0403]: NVIDIA Corporation GP107GL High Definition Audio Controller [10de:0fb9] (rev a1)

Y edité el fichero de configuración de Grub «/etc/default/grub»:

GRUB_CMDLINE_LINUX=»intel_iommu=on vfio_pci.ids=10de:1c82,10de:0fb9″

Para terminar de curarme en salud, creé el fichero «/etc/modprobe.d/vfio_pci.conf»:

options vfio_pci ids=10de:1c82,10de:0fb9

Y edité el de «/etc/initramfs-tools/modules»:

vfio
vfio_iommu_type1
vfio_virqfd
options vfio_pci ids=10de:1c82,10de:0fb9
vfio_pci ids=10de:1c82,10de:0fb9
vfio_pci

¿Excesivo? Puede ser. Quizás sobrase con sólo haber editado el fichero de Grub, pero se llega a un punto en el cual has dado tantas vueltas sobre lo mismo que no te fías con hacer lo mínimo indispensable.

Finalmente toca rehacer el arranque con los siguientes comandos:

update-grub
update-initramfs -u

Compilación del kernel

Editamos las fuentes de apt para poder descargar el fuente del software «/etc/apt/sources.list»:

deb-src http://es.archive.ubuntu.com/ubuntu/ bionic main restricted

deb-src http://es.archive.ubuntu.com/ubuntu/ bionic-updates main restricted

Descargamos el software necesario:

apt update

apt-get build-dep linux linux-image-$(uname -r) git fakeroot dkms default-jdk

Es posible que nos topemos con el siguiente error:

la descarga se realiza de forma desprotegida como superusuario, ya que al archivo «linux-signed_4.15.0-91.92.dsc» el usuario «_apt» no pudo acceder. – pkgAcquire::Run

Para solventarlo nos basta con hacer lo siguiente:

chown _apt /var/lib/update-notifier/package-data-downloads/partial/

Dentro de la carpeta «/usr/src/» descargaremos los fuentes del kernel de Ubuntu Bionic:

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git

Editaremos el fichero «/usr/src/ubuntu-bionic/drivers/iommu/intel-iommu.c» donde pone:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.\n»);
return -EPERM;
}

Pondremos lo siguiente:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. PARCHEADO.\n»);
}

En este paso, si tratamos de compilar el kernel nos encontraremos con un error relacionado con el script «ubuntu-bionic/debian/scripts/retpoline-check» y que tuve que modificar de este código:

count=$( diff -u «$prev» «$curr» | grep ‘^+[^+]’ | wc -l )
if [ «$count» != 0 ]; then
rc=1

A este otro:

count=$( diff -u «$prev» «$curr» | grep ‘^+[^+]’ | wc -l )
if [ «$count» != 0 ]; then
rc=0

Sé que está relacionado con las mitigaciones sobre las CPU de Intel pero no es algo que en esta máquina me importase mucho.

Desde el directorio de «/usr/src/ubuntu-bionic» lancé la compilación que duró un periodo de tiempo considerable:

fakeroot debian/rules clean

fakeroot debian/rules binary

De dicho proceso se generaron una serie de paquetes .deb que instalé:

dpkg -i *.deb

Una vez instalado el kernel modificado, ahora sólo necesitaba que el equipo siempre arrancase con él, con lo que había que realizar algunos cambios en el cargador de arranque. Para saber qué modificaciones tenía que aplicar lancé el siguiente comando:

sed -nre «/submenu|menuentry/s/(.? )'([^’]+)’.*/\1 \2/p» < /boot/grub/grub.cfg

Me devolvió el listado visual de Grub que tenía que tener en cuenta:

menuentry Ubuntu
submenu Opciones avanzadas para Ubuntu
menuentry Ubuntu, con Linux 4.15.0-91-generic
menuentry Ubuntu, con Linux 4.15.0-91-generic (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-88-lowlatency
menuentry Ubuntu, con Linux 4.15.0-88-lowlatency (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-88-generic
menuentry Ubuntu, con Linux 4.15.0-88-generic (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-76-generic
menuentry Ubuntu, con Linux 4.15.0-76-generic (recovery mode)

Entonces edité el fichero «/etc/default/grub» acorde:

GRUB_DEFAULT=»Opciones avanzadas para Ubuntu>Ubuntu, con Linux 4.15.0-88-generic«

Y además bloquee la posibilidad de que sufriese cambios a través de alguna actualización del gestor de paquetes y regeneré la configuración de Grub:

apt-mark hold 4.15.0-88-generic

update-grub

Si en un futuro queremos actualizar el kernel, para desbloquear el que tenemos modificado bastará con lanzar el comando «apt-mark unhold 4.15.0-88-generic».

Tras un reinicio del equipo y con el comando «dmesg | grep -i vfio» deberíamos poder ver lo siguiente:

[230727.140577] vfio-pci 0000:07:00.1: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. PARCHEADO.
[230727.730169] vfio_ecap_init: 0000:07:00.0 hiding ecap 0x19@0x900

Configuración del puente de red

Para que las máquinas virtuales puedan tener acceso directo a nuestra y así poder hacer uso de los recursos que en ella se encuentran hay que configurar un puente de red. Modificaremos el fichero «/etc/netplan/01-netcfg.yaml»:

network:
version: 2
renderer: networkd

ethernets:
eno2:
dhcp4: false
dhcp6: false

bridges:
br0:
interfaces: [eno2]
addresses: [192.168.1.10/24]
gateway4: 192.168.1.1
mtu: 1500
nameservers:
addresses: [192.168.1.1]
parameters:
stp: true
forward-delay: 4
dhcp4: no
dhcp6: no

El dispositivo «eno2» sería nuestra tarjeta de red con conectividad y «br0» sería al puente hacia nuestras máquinas virtuales. Hay que tener en cuenta que yo he preferido establecer una IP fija para mi tarjeta con conectividad física pero se podría haber dejado con DHCP.

Gestión web del servidor

Para poder gestionar de manera fácil el servidor a través de un entorno web, he optado por hacer uso de Cockpit, el cual se puede instalar de la siguiente forma:

apt install cockpit cockpit-machines cockpit-docker cockpit-system cockpit-packagekit

Ahora podremos gestionar el servidor desde http://127.0.0.1:9090

Gestión de las máquinas virtuales

Si bien se pueden gestionar las máquinas virtuales de Cockpit de manera fácil, el interfaz es algo limitado con respecto a lo que podía hacer con Proxmox. Pero esto es fácilmente solucionable si las gestionamos desde Virtual Machine Manager, un software que puede estar instalado en nuestro sobremesa o portátil y que permite gestionar tanto las máquinas virtuales en local como remotas.

Jellyfin es un gestor de contenido multimedia que permite hacer streaming de nuestra música, películas, series, etc. Es como un sustituto de Plex y Emby (del cual proviene) de código totalmente abierto y gratuito.

Existe una imagen preparado con él en Turnkey que nos permite tener funcionando el sistema en cuestión de pocos minutos.

Si queremos tener la posibilidad de trascodificar nuestro contenido puede ser que nos salga el siguiente error al querer utilizar, por ejemplo, nuestro navegador:

PlaybackErrorNoCompatibleStream

Para darle solución sólo tendremos que instalar ffmpeg de la siguiente forma:

apt install ffmpeg

Después, desde el panel de control de Jellyfin dentro de la sección de «Reproducción» tendremos que poner la siguiente ruta en «Ruta de FFmpeg:»:

/usr/bin/ffmpeg

Si al intentar desplegar un template en un container de Proxmox obtenemos los siguientes errores:

tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted

Es debido a que, por defecto, los CT se despliegan con la opción marcada de «Unprivileged container» y algunas imágenes necesitan acceso a ciertas zonas como los «random» o «unrandom». Para solucionarlo sólo hay que desmarcar la opción en la primera pantalla de creación del CT.

Instalar un cliente VPN en un contenedor de Proxmox (LXC) no debería ser un gran problema, simplemente realizar un «apt install openvpn», configurar la conexión con el servidor VPN y ya está. Pero no, existen problemas con la interfaz de red TUN/TAP a la que intenta tener acceso OpenVPN debido a que no existe:

ERROR: Cannot open TUN/TAP dev /dev/net/tun

Para solucionarlo hay que ir al fichero de configuración del contenedor («/etc/pve/lxc/XXX.conf») y añadir las siguientes líneas:

lxc.cgroup.devices.allow: c 10:200 rwm
lxc.hook.autodev: sh -c «modprobe tun; cd ${LXC_ROOTFS_MOUNT}/dev; mkdir net; mknod net/tun c 10 200; chmod 0666 net/tun»

Esto nos permitirá poder hacer uso de OpenVPN desde que la máquina arranca, ya que generar la estructura en un script de «init.d» o «crontab», a pesar de que funciona si iniciamos a mano OpenVPN, no lo hará de forma no asistida.

A pesar de todo lo anterior, veremos que perdemos cierta conectividad con la máquina y el log del sistema («/var/log/syslog») se nos llenará de mensajes del siguiente tipo:

Dec 21 07:12:11 gateway kernel: martian source 98.187.15.124 from 98.187.15.97, on dev br1

Dec 21 07:12:11 gateway kernel: ll header: ff:ff:ff:ff:ff:ff:00:14:f1:e8:69:db:08:06

Quizás por una mala configuración de interfaces de red por mi parte, pero habiendo sólo una con su IP fija no creo que debiese ser problemático. Al final opté por crear una máquina virtual en vez de un contenedor con una Debian 10 y todo ha ido prácticamente a la primera (salvo lo de montar una unidad NFS al arranque, que necesita de una IP asignada de manera estática, pero eso ya es otro cuento).

Como nota final, cabe tener en cuenta que, para ahorrar consumo de CPU (hasta un 20% de ahorro con un núcleo), existe la necesidad de habilitar las instrucciones extendidas AES del procesador (si las tuviese). Para ello debemos configurar la máquina virtual con un tipo de CPU host y máquina Q35. Para comprobar que la CPU tiene dichas instrucciones sólo hay que lanzar el comando «cpuid | grep -i aes | sort | uniq» que nos devolverá algo como esto:

AES instruction = true
VAES instructions = false

Y comprobar que se carga el módulo correspondiente con el comando «sort -u /proc/crypto | grep module» que debería darnos algo tal que así:

module : aesni_intel
module : aes_x86_64
module : crc32c_generic
module : crc32c_intel
module : crc32_pclmul
module : crct10dif_pclmul
module : cryptd
module : ghash_clmulni_intel
module : kernel

Pi-Hole es un servidor intermediario de DNS que filtra las petición de aquellas URL’s que contienen publicidad, haciendo la navegación más limpia y rápida. Ideal para aquellos dispositivos donde no tenemos acceso de administración como en un teléfono móvil Android o iPhone, porque no tenemos que instalar nada más adicional en estos terminales.

Su instalación se puede hacer en una simple Raspberry Pi o, como es mi caso, un contenedor LXC en Proxmox. Después de desplegar una imagen básica de Debian desde Turnkey, descargaremos el instalador de Pi-Hole:

• wget -O basic-install.sh https://install.pi-hole.net

Tendremos que realizar una pequeña modificación porque el instalador busca el fichero «/etc/apt/sources.list», cuando nuestro sistema lo tiene en «/etc/apt/sources.list.d/sources.list». Abriremos con «nano basic-install.sh» el instalador, buscaremos (CTRL+W)  el término «APT_SOURCES» y modificaremos su valor para que quede de la siguiente forma:

• APT_SOURCES=»/etc/apt/sources.list.d/sources.list»

Con eso debería bastar pero, en mi caso, al intentar instalar las dependencias el instalador se me cortó y tuve que instalar una de ellas a mano con el siguiente comando:

• apt install php-sqlite3

Una vez instalado, sólo tendremos que cambiar las DNS de nuestros dispositivos a la IP de esta instancia.

Después de haber instalado Proxmox en un HP Gen8, mi intención era la de virtualizar LibreElenc para utilizarlo como centro multimedia y un Windows 10 para poder hacer uso de mi biblioteca de Steam. Tras un poco de modding en la pequeña torre e incorporar una GTX 1050Ti (concretamente la Gigabyte GV-N105TOC-4GL) me quedaba por delante configurar Proxmox para permitir dejar paso directo de la tarjeta gráfica a los sistemas virtualizados.

Configuración de la máquina virtual

Para ello la máquina virtual debía incorporar en su fichero de configuración («/etc/pve/qemu-server/100.conf») las siguientes opciones:

• machine: q35
• hostpci0: 07:00,pcie=1,x-vga=on

La segunda opción depende de cada equipo y es el resultado de haber obtenido lo siguiente tras lanzar el comando «lspci»:

07:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
07:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1)

Error al arrancar la máquina virtual

Cuando intentemos arrancar la máquina virtual, lo más probable es que nos indique lo siguiente:

vfio: failed to set iommu for container: Operation not permitted

Lo que parece en principio un problema de permisos tiene un trasfondo más complejo que afecta al kernel y que podemos comprobar con el comando «dmesg | grep -e DMAR -e IOMMU» que nos devolverá lo siguiente:

vfio-pci 0000:07:00.1: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.

Recompilación del kernel

La forma de solucionar el problema es recompilando el kernel tras haber incorporado un pequeño parche al mismo.

Actualizaremos el sistema e instalaremos los paquetes que vamos a necesitar:

• apt-get update
• apt-get install git nano screen patch fakeroot build-essential devscripts libncurses5 libncurses5-dev libssl-dev bc flex bison libelf-dev libaudit-dev libgtk2.0-dev libperl-dev libperl-dev asciidoc xmlto gnupg gnupg2 rsync lintian debhelper libibery-dev libdw-dev libnuma-dev libsplang2-dev libiberty-dev libslang2-dev debhelper sphinxdoc-common
• apt-get install lz4 (si utilizamos los fuentes de Ubuntu EOAN de la versión 5.4 del kernel de Proxmox)
• apt-get install pve-headers-5.4.24-1-pve (la versión dependerá del kernel que estemos tratando de compilar)

Descargaremos el código fuente del kernel que vamos a recompilar y de aquel de donde sacaremos el parche:

• cd /usr/src/
• git clone git://git.proxmox.com/git/pve-kernel.git
• git clone git://git.proxmox.com/git/mirror_ubuntu-disco-kernel.git
• mv mirror_ubuntu-disco-kernel ubuntu-disco

Hacemos una copia del parche que necesitamos y lo editamos con nano:

• cp ubuntu-disco/drivers/iommu/intel-iommu.c ubuntu-disco/drivers/iommu/intel-iommu_new.c
• nano ubuntu-disco/drivers/iommu/intel-iommu_new.c

En el editor de nano buscaremos con el comando «CTRL+W» el siguiente tecto:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.\n»);
return -EPERM;
}

Y lo cambiaremos a lo siguiente (se elimina el «return» y se añade al texto algo que nos haga saber más tarde que se está aplicando nuestro parche) :

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device was ineligible for IOMMU domain attach due to platform RMRR requirement. Parcheado.\n»);
}

De los dos ficheros generaremos un diff:

• diff -u /usr/src/ubuntu-disco/drivers/iommu/intel-iommu.c /usr/src/ubuntu-disco/drivers/iommu/intel-iommu_new.c > remove_rmrr_check.patch

Habrá que adaptar la cabecera de ese diff generado, quedando de forma similar a este (se cambian las rutas de los ficheros y sus nombres):

— a/drivers/iommu/intel-iommu.c 2019-07-17 15:44:26.908520624 +0200
+++ b/drivers/iommu/intel-iommu.c 2019-07-17 15:48:09.380083344 +0200

Moveremos el diff al lugar donde la recompilación lo buscará:

• cd /usr/src/pve-kernel/
• mv ../remove_rmrr_check.patch ./patches/kernel/

Modificaremos un script que busca ficheros con nombres problemáticos:

• nano debian/scripts/find-firmware.pl

Y comentaremos una de las primeras líneas para que quede más o menos de esta forma:

#die «strange directory name» if $dir !~ m|^(.*/)?(5.0.\d+\-\d+\-pve)(/+)?$|;

Configuraremos el Makefile:

• nano /usr/src/pve-kernel/Makefile

En él buscaremos «EXTRAVERSION» y lo dejaremos de la siguiente forma:

• EXTRAVERSION=-${KREL}-pve-removermrr

Y finalmente lanzaremos el make:

• make

Si todo ha ido bien, nos habrá generado una serie de ficheros «.deb» que instalaremos de la siguiente forma:

• dpkg -i *.deb

Si nos ha fallado por algún motivo y tenemos que relanzar de nuevo el «make» es posible que no nos deje y tengamos que añadir al fichero «Makefile» la opción «-d» quedando de esta forma:

${LINUX_TOOLS_DEB} ${HDR_DEB}: ${DST_DEB}
${DST_DEB}: ${BUILD_DIR}.prepared
cd ${BUILD_DIR}; dpkg-buildpackage –jobs=auto -b -uc -us -d
lintian ${DST_DEB}
#lintian ${HDR_DEB}
lintian ${LINUX_TOOLS_DEB}

Comprobación de la instalación

Una vez que tengamos el nuevo kernel instaldo mediante los «.deb» anteriores, reiniciaremos la máquina y cuando lancemos nuestra máquina virtual, mediante el comando «dmesg | grep -e DMAR -e IOMMU» obtendremos el mensaje:

vfio-pci 0000:07:00.1: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Parcheado.

Fuente

Las pautas han sido sacadas de lo que ahora es un pequeño tutorial pero en su día fue un verdadero quebradero de cabeza.

El HP Proliant Microserver Gen8 lleva un controladora RAID por software que conlleva una serie de limitaciones, la más importante de ellas es la imposibilidad de sacar los discos duros posteriormente y montarlos en un ordenador completamente diferente y que el RAID siga funcionando. Por ello, es práctica habitual el configurar la BIOS para que no utilice dicha controladora sino su modo SATA AHCI y realizar un posterior RAID con mdadm.

Al final tendremos 4 bahías para discos duros (las dos primeras serán SATA3 y las otras dos SATA2) y una bahía extra para el lector óptico (ODD) que funciona en SATA2 y que, en mi caso, he usado para instalar una SSD con el sistema operativo. Si bien con SATA2 sólo de pueden alcanzar los 300MB/seg frente a los 600MB/seg de un SATA3, no resulta un gran inconveniente para un sistema operativo Linux que es bastante rápido y qué sólo lo utilizaremos para hacer uso de los otros discos.

Haciendo uso de un pendrive podremos realizar la instalación de Proxmox sin mayores inconvenientes salvo uno: el sistema operativo no arranca desde el puerto donde está conectado el ODD. Curioso resulta que si hubiésemos dejado el modo RAID de la controladora, habríamos podido arrancar desde el ODD. De todos modos, para solucionarlo recurriremos a una tarjeta microSD, desde la cual sí que es capaz de arrancar, y en la cual, ayudados por un liveUSB, copiaremos el arranque de la instalación. Sólo nos quedará configurar la BIOS para arrancar desde dicha tarjeta.