Archivo

Archivo para la categoría ‘Virtualización’

Error de IPv6 en Docker sobre un contenedor LXC

lunes, 8 de julio de 2024 Sin comentarios

Al actualizar algunos contenedores LXC en los que mantenía algún despliegue con Docker he acabado encontrando este tipo de error:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: failed to add interface veth52242e7 to sandbox: error setting interface «veth52242e7» IPv6 to <nil>: failed to configure ipv6: failed to disable IPv6 on container’s interface eth0, set env var DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1 to ignore this error: unknown
Error: failed to start containers: 89fze5ea9d64

Debido a que en LXC el sistema de ficheros es de sólo lectura en «/proc/sys/net» se necesita aplicar una variable de entorno en la sección «Service» del fichero que inicia Docker «/etc/systemd/system/multi-user.target.wants/docker.service»:

[Service]
Environment=»DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1″

 

Categories: LXC Tags:

No se pudo encontrar montaje de controlador de memoria cgroups

martes, 15 de agosto de 2023 Sin comentarios

Tras actualizar el software de OpenSuse Tumbleweed me he encontrado con el siguiente error al intentar iniciar los contenedores LXC:

libvirtError: error interno: No se pudo encontrar montaje de controlador de memoria cgroups

Supongo que debe estar relacionado con la actualización de software LXC más que con el kernel, porque volver a la versión anterior no lo resolvía. Sin embargo, lo que sí lo resolvía era añadir los siguientes parámetros en el inicio del kernel:

cgroup_enable=memory systemd.unified_cgroup_hierarchy=0

Y se puede comprobar cómo cambia el resultado al ejecutar este comando antes y después:

cat /proc/cgroups | column -t

mount | grep cgroup

Supuestamente, el tenerlo activado nos permite controlar y limitar el acceso a los recursos de la máquina host por parte de los guest, con lo que no entiendo si está hecho a posta porque han habido cambios que ya no necesitan estos parámetros y lo implementan de otra forma o es un simple fallo en la última versión.

ACTUALIZACIÓN

Tres posibles soluciones a este problema en openSUSE Tumbleweed:

  • Ejecutar lo siguiente:
    • sudo systemctl stop virtlxcd
    • sudo virtlxcd -f /etc/libvirt/virtlxcd.conf -d
  • Cambiar el fichero «/etc/systemd/system.conf.d/80-defaults.conf» para que tenga lo siguiente:
    • [Manager]
      DefaultMemoryAccounting=yes
  • Realizar la isntalación de cockpit con podman:

zypper install patterns-microos-cockpit cockpit cockpit-bridge cockpit-kdump cockpit-machines cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-podman cockpit-storaged cockpit-system cockpit-ws

systemctl enable –now cockpit.socket
systemctl restart cockpit.socket

Acceder a https://ip:9090 y clicar en «Limited access» para obtener permisos de administración. En la sección de «Podman containers» no saldrá un mensaje para que habilitemos los servicios de podamn, el cual aceptaremos y ya está.

Categories: GNU/Linux, LXC, OpenSuse Tags:

Abrir puertos en Oracle Cloud

martes, 8 de agosto de 2023 Sin comentarios

En las instancias de servidor de Oracle Cloud, cuando despliegas alguna de sus imágenes, tienen preconfiguradas una serie de reglas en el cortafuegos que impiden la comunicación a los servicios más básicos como HTTP/HTTPS.

Puede llegar a ser realmente confuso porque, antes de averiguar que en una instalación limpia ya hay reglas de cortafuegos, hemos tenido que abrir puertos y configurar la red en el panel de control de Oracle. Así que podemos dejar el cortafuegos totalmente abierto y gestionar la entrada/salida desde el panel de control.

Con estos comando quitaríamos las reglas:

iptables -I INPUT -j ACCEPT

iptables-save > /etc/iptables/rules.v4

O si sólo queremos abrir ciertos puertos:

iptables -I INPUT 6 -m state –state NEW -p tcp –dport 80 -j ACCEPT sudo netfilter-persistent save

netfilter-persistent save

Para más información, hay un hilo de reddit donde se discute el tema.

Actualizar contenedores LXC

domingo, 8 de agosto de 2021 Sin comentarios

Si estamos trabajando con Libvirt y deseamos realizar una actualización de sistemas de forma prácticamente desatendida, este es un script que puede resultar cómodo:

#!/bin/bash

## Recoge el nombre de los contenedores y elimina la primera línea y la última
lxc_names=»$(virsh -d 0 -c lxc:/// list –name | tail -n +2 | head -n -1)»

update_lxc_machines(){
local lxc=»$1″
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq update
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y upgrade
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y clean
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y autoclean
}

for lxc_name in $lxc_names
do
update_lxc_machines «$lxc_name»
done

He tomado como referencia este otro script y lo he modificado a mis necesidades.

Categories: GNU/Linux, LXC Tags:

Qemu con su error -22 (Invalid argument)

martes, 1 de septiembre de 2020 Sin comentarios

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.

Cambiando prioridades de CPU e IO en KVM

jueves, 7 de mayo de 2020 Sin comentarios

En Proxmox creo recordar que se podía limitar el % de uso de la CPU de forma individual en cada máquina virtual. Como sustituto o equivalencia me topé con un script de Stuart Hopkins que a partir de un fichero de configuración permitía ajustar con el comando «nice» la prioridad del proceso de cada una de las instancias de nuestro KVM. Jim Klimov por su parte mejoró el script para permitir definir además qué prioridad de acceso al disco tendría cada una de esas instancias, completando de esa forma la funcionalidad del script.

El fichero de configuración tendría el siguiente aspecto:

### Note: comments or config lines from here on, e.g. no empty lines!
#
# KVM VM Priorities (NAME|NICEPRIO|IOCLASS|IOPRIO)
# IOCLASS – 1=realtime, 2=best-effort, 3=idle
# IOPRIO – 0=highest, 7=lowest
#
# e.g. MYVM|15|3|7
#
521-MaquinaVirtual|10|3|7

Por un lado tendría el nombre de la máquina virtual a la que le deseo aplicar los cambios «202-MaquinaVirtual», el «nice» a aplicar sería de 10 (-20 es la prioridad más alta, 19 la menor y 0 la por defecto), la clase de acceso al disco la mantendríamos en «idle» para que dejase paso al resto de procesos y una prioridad de 7 que es la más baja. Con todo ello pretendo que la máquina virtual suponga el menor impacto sobre los discos y que tenga un consumo de CPU moderado cuando tenga que compartirla.

Dicho lo anterior, en mi caso el script no me funcionaba porque no era capaz de leer el PID de mi máquina virtual, ya que el comando «ps» lo mostraba de la siguiente forma:

qemu-system-x86_64 -enable-kvm -name guest=521-MaquinaVirtual,debug-threads=on -S -object secret,………..

Así que cambié la línea que extrae el nombre de la máquina virtual que en un origen era así:

vm_name=$(ps -o cmd -p $vm_pid 2>/dev/null | tail -n 1 | sed -e ‘s/^[^0-9a-zA-Z]*//g’ | sed -e ‘s/^.*-name\ \([a-zA-Z0-9]*\).*/\1/’ 2>/dev/null)

Por esta otra:

vm_name=$(ps -o cmd -p $vm_pid 2>/dev/null | tail -n 1 | sed -e ‘s/^[^0-9a-zA-Z]*//g’ | awk ‘{print $4}’ 2>/dev/null| awk -F’=’ ‘{print $2}’ 2>/dev/null|awk -F’,’ ‘{print $1}’ 2>/dev/null)

No sé si será igual para todo el mundo o afecta sólo a mi configuración, pero el script es sencillo de entender y editar para ajustarlo a las necesidades de cada uno.

Y, por supuesto, con tenerlo en cron para que ajuste la configuración por si hemos reiniciado alguna máquina no cuesta mucho.

Sustituyendo NFS por sistema de archivos 9p de KVM

lunes, 4 de mayo de 2020 Sin comentarios

En una de las máquinas virtuales tenía funcionando dos aplicaciones que hacían uso intensivo de lectura/escritura de información que tengo almacenada en una unidad NFS. Toda esa actividad acababa generando un consumo considerable de CPU y, de alguna forma, mayor actividad en los discos duros de lo que sería normal.

Opté por añadir un sistema de ficheros compartido entre el sistema anfitrión e invitado para intentar no poner por medio el servicio NFS. El sistema de ficheros sería de tipo «mapped» lo que nos llevaría a una serie de inconvenientes en cuanto a permisos en los ficheros creados pero que nos dejaría escribir sin mayores problemas:

<filesystem type=»mount» accessmode=»mapped»>
<source dir=»/mnt/unidadCompartida»/>
<target dir=»unidadCompartida»/>
<alias name=»fs0″/>
<address type=»pci» domain=»0x0000″ bus=»0x00″ slot=»0x08″ function=»0x0″/>
</filesystem>

Para montar la unidad en el sistema invitado sólo hay que añadir la siguiente línea en el fichero «/etc/fstab»:

unidadCompartida /mnt/unidadCompartida 9p trans=virtio,version=9p2000.L,cache=mmap,rw 0 0

Hay que tratar de recordar añadir las opciones de «version=9p2000.L,cache=mmap» para evitar problemas con aplicaciones como «rtorrent» cuyo log nos devolvería lo siguiente:

Could not create: memory:524288 block:1 errno:22 errmsg:Invalid argument.

Para arreglar el tema de permisos en la carpeta compartida, como desde un primer momento no tuve la previsión de hacerlo de este modo, lo arreglé con una pequeña tarea en el Cron del sistema anfitrión:

*/15 * * * * /bin/chmod 777 -R /mnt/unidadCompartida/

De este modo, cada 15 minutos, se le otorga permisos a todo el mundo sobre el contenido de dicha carpeta para que otras máquinas puedan acceder a él sin problemas. Obviamente, se tiene que saber lo qué se hace y almacena en dicha carpeta, porque un 777 abarca mucho.

Contenedores LXC desde Virtual Machine Manager

sábado, 4 de abril de 2020 Sin comentarios

En una entrada anterior comenté la sustitución de Proxmox por Virtual Machine Manager y me quedó por indicar cómo administrar desde él el servicio LXC de forma remota. Y es que no permite la creación del sistema de ficheros raíz de nuestro nuevo contenedor de forma remota, por lo que hay que proveerle la ruta en la que se encuentra. Al final opté por una solución relativamente sencilla: instalar lxc pero no habilitarlo, simplemente usarlo para descargar nuestros sistemas de ficheros raíz:

apt install lxc
lxc-create -n ubuntu1804 -t download

Nos mostrará un listado y, en mi caso, seleccioné descargar una Ubuntu Bionic para arquitectura AMD64. Después, simplemente hice una copia para utilizarla para un servidor Seafile, dejando la descargada para usarla como plantilla cada vez que necesitase un nuevo contenedor:

cp -a /var/lib/lxc/ubuntu1804/rootfs/* /lxc/001-seafile/

El problema es que lo que hemos descargado es un sistema Ubuntu cuyo usuario root no tiene contraseña. Para resolverlo deberemos cargar el sistema y asignarle una contraseña:

chroot /lxc/001-seafile/

passwd

exit

Ahora sencillamente podríamos desinstalar el paquete «lxc» y simplemente utilizar nuestra plantilla.

Averiguar la dirección IP de una máquina virtual con KVM

sábado, 4 de abril de 2020 Sin comentarios

Con el siguiente comando el enlace de red disponible:

virsh net-list

Sabiendo el nombre del mismo («default») podremos encontrar más detalles:

virsh net-info default

Y lo interesante será que nos muestre las IP asignadas con el DHCP interno a cada una de las máquinas virtuales que tengamos:

virsh net-dhcp-leases default

Si la máquina virtual no está utilizando el DHCP interno, podemos sacar un listado de los nombres de nuestras máquinas con el siguiente comando:

virsh list

Sabiendo el nombre de la máquina (en nuestro caso suponemos que sea «Windows10») que nos interesa ejecutaremos el siguiente comando:

arp -an | grep `virsh dumpxml Windows10 | grep «mac address» | awk -F\’ ‘{ print $2}’`

Categories: Virtualización Tags: , , ,

Acceso a discos KVM

sábado, 4 de abril de 2020 Sin comentarios

Para acceder a unidades de disco utilizadas por máquinas virtuales KVM sólo tenemos que seguir algunos sencillos pasos.

Lo primero es identificar la primera unidad loopback disponible:

losetup -f

Asociaremos la unidad que nos devuelve el paso anterior con nuestra imagen de disco:

losetup /dev/loop0 /rutaKVM/discoWindows.img

A continuación podremos identificar las particiones contenidas en el fichero anterior:

kpartx -av /dev/loop0

Podemos visualizar las particiones mapeadas con el siguiente comando:

ls -la /dev/mapper/

Y al final podremos montarla del siguiente modo:

mount /dev/mapper/loop0p2 /mnt/virtualHDD/

Cuando hayamos terminado de trabajar con la unidad de disco virtual desharemos lo hecho:

umount /mnt/virtualHDD/

kpartx -dv /dev/loop0

losetup -d /dev/loop0

Si lo que tenemos es un disco con formato «qcow2» podemos recurrir a otra estrategia. Habilitamos el módulo NBD (Network Block Devices):

modprobe nbd max_part=8

Conectamos al dispositivo como si fuese una unidad de red:

qemu-nbd –connect=/dev/nbd0 /rutaKVM/discoWindows.qcow2

Buscamos las particiones del disco:

fdisk /dev/nbd0 -l

Montamos la que deseemos:

mount /dev/nbd0p1 /mnt/virtualHDD/

Y para cuando terminemos, deshacemos lo hecho:

umount /mnt/virtualHDD/
qemu-nbd –disconnect /dev/nbd0
rmmod nbd