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.
Últimos Comentarios