Proxmox VE

Proxmox Virtual Environment

Instalar Proxmox

Pasos para instalar Proxmox

Requisitos previos:

Para instalaciones en servidores con arranque redundante (discos en raid1).

Es conveniente configurar un raid1 (en la controladora del servidor) con los discos de arranque como un sólo volumen

Arrancaremos el servidor con el medio de arranque con la ISO de Proxmox en USB o CD, que podemos crear con la herramienta ventoy

En cuanto arranque veremos la siguiente pantalla

proxmox7-t_01.png

Ejecutaremos el proceso de instalación pulsando Install Proxmox VE, en el mismo nos pedirá el nombre de la máquina que debe de ser un nombre de dominio completo, seleccionar el disco de arranque y el formato del mismo (LVM, ZFS, etc). Una dirección de correo electrónico, la dirección IP, puerta de enlace y DNS.

Una vez instalado, seguiremos los siguientes pasos:

Cambiar los repositorios

Cambiar los repositorios por los que aparecen aquí en https://pve.proxmox.com/wiki/Package_Repositories

Para ello debemos ir al fichero /etc/apt/sources.list.d/pve-enterprise.list y modificarlo aparecerá una línea como la siguiente:

deb https://enterprise.proxmox.com/debian/pve stretch pve-enterprise

La comentamos introduciendo el símbolo # al principio de la línea

#deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise

Editamos el fichero /etc/apt/sources.list

deb http://ftp.debian.org/debian buster main contrib
deb http://ftp.debian.org/debian buster-updates main contrib

# security updates
deb http://security.debian.org/debian-security buster/updates main contrib

Agregamos el repositorio de Proxmox gratuito (No subscription)

deb http://ftp.debian.org/debian buster main contrib
deb http://ftp.debian.org/debian buster-updates main contrib

# PVE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve buster pve-no-subscription

# security updates
deb http://security.debian.org/debian-security buster/updates main contrib

Instalar ntp

A continuación instalaremos el servicio ntp imprescindible si vamos a configurar un cluster de Proxmox, o bien Ceph

Configurar la red

En primer lugar deberemos de instalar el open-vswitch, una vez instalado, deberemos de planificar con sumo cuidado nuestra topología de red para Proxmox. Dependiendo del tipo de despliegue seleccionaremos las redes segmentadas en VLAN que vamos a utilizar. A modo de ejemplo:

Dependiendo del número de tarjetas, es conveniente que todas vayan a pares mediante un Bond balance-slb y que vayan cada una a un switch diferente a efectos de garantizar la redundancia y disponibilidad de las comunicaciones.

Es decir si tenemos 4 interfaces 10G en el equipo, podemos destinar 2 al cluster, al Ceph y a la gestión, y las otras dos al almacenamiento y backup.

Comprobar el sistema de archivos de un contenedor LXC en Proxmox

Es muy sencillo chequear el sistema de archivos de un contenedor LXC en Proxmox desde la línea de comandos. Tan sólo tenemos que recurrir al comando pct (Proxmox Container Toolkit).

Por ejemplo, supongamos que queremos comprobar el sistema de archivos del contenedor 135:

Primero pararemos el contenedor:

pct stop 135

Una vez detenido, realizamos el fsck:

pct fsck 135
fsck from util-linux 2.33.1
/var/lib/vz/images/135/vm-145-disk-0.raw: clean, 34327/524288 files, 296495/2097152 blocks

Conectar con un Ceph Remoto en Proxmox

Ejemplo de configuración para un clúster Ceph externo (/etc/pve/storage.cfg)

rbd: ceph-external
        monhost 10.1.1.20 10.1.1.21 10.1.1.22
        pool ceph-external
        content images 
        username admin

Sugerencia Puede utilizar la utilidad rbd para realizar tareas de administración de bajo nivel.

Autenticación

Si utiliza la autenticación cephx, debe copiar el archivo de claves de su clúster Ceph externo a un host Proxmox VE.

Cree el directorio /etc/pve/priv/ceph

con

mkdir /etc/pve/priv/ceph

Luego copia el keyring

scp <cephserver>: /etc/ceph/ceph.client.admin.keyring /etc/pve/priv/ceph/<STORAGE_ID>.keyring

El keyring debe tener un nombre que coincida con su <STORAGE_ID>. Copiar el keyring generalmente requiere privilegios de root.

Si Ceph se instala localmente en el clúster PVE, esto lo hace automáticamente pveceph o en la GUI.

Funciones de almacenamiento

El backend rbd es un almacenamiento a nivel de bloque e implementa la funcionalidad completa de instantáneas y clones.

Convertir imagenes vmdk, raw, qcow2, vdi y vpc con qemu-img

a herramienta de línea de comandos qemu-img permite manipular y convertir varios formatos de imagen de disco (vmdk, raw, qcow2, vdi y vpc), utilizados principalmente por sistemas de virtualización como VMware, KVM, Xen, Virtualbox o Hyper-V.

El funcionamiento es realmente sencillo, lo primero que debemos revisar es que la herramienta está instalada. En caso contrario, podemos instalarla desde apt:

# whereis qemu-img
qemu-img: /usr/bin/qemu-img /usr/share/man/man1/qemu-img.1.gz

A la hora de hacer la conversión, simplemente tenemos que tener en cuenta el formato e imagen de disco origen y destino. Si no especificamos el formato de origen (-f ) qemu-img intenta detectarlo de forma automática. El formato destino se especifica con -O y seguido la imagen de origen y destino. El siguiente ejemplo convierte una imagen de disco de formato qcow2 (KVM) a vmdk (VMware):

# qemu-img convert -f qcow2 -O vmdk imagen_origen.qcow2 imagen_destino.vmdk

Otro ejemplo en el que convertimos de imagen raw (.img) a qcow2:

# qemu-img convert -f raw -O qcow2 image_origen.img imagen_destino.qcow2

Una vez que tenemos la imagen convertida, por ejemplo a vmdk, tendríamos que crear una nueva máquina virtual y en el proceso de creación asignarle el disco .vmdk que hemos creado con la conversión («Use an existing virtual disk»). Existen otras opciones interesantes como activar la compresión para la imagen de destino (sólo en qcow):

# qemu-img convert -c -f raw -O qcow2 disco_virtual.img disco_virtual_destino.qcow2

Iscsi Proxmox

En primer lugar instalaremos los paquetes necesarios

apt update -y
apt-get install open-iscsi multipath-tools

A continuación deberemos de tener acceso al portal iSCSI de nuestro almacenamiento. En nuestro caso usaremos por ejemplo la 10.0.15.x, como tenemos 8 caminos ya que disponemos de un almacenamiento con 8 interfaces iSCSI que serán 10.0.15.11-14 para la controladora A y 10.0.15.21-24 para la B

iscsiadm -m discovery -t sendtargets -p 10.0.15.11


multipath -ll

root@teststorage:/etc/multipath# multipath -ll
mpath0 (3600c0ff00027f44e1231865801000000) dm-0 HP,MSA 2040 SAN
size=8.2T features='3 queue_if_no_path queue_mode mq' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| `- 2:0:0:0 sdb 8:16 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
  |- 3:0:0:0 sda 8:0  active ready running
  `- 4:0:0:0 sdc 8:32 active ready running

iscsiadm -m discovery -t sendtargets -p 10.200.15.11

iscsiadm -m discovery -t sendtargets -p 10.200.15.14

iscsiadm -m node --login

nano multipath.conf

cat multipath.conf

Tenemos que buscar el wwid

nano /etc/multipath/wwids

Contendrá lo siguiente

# Multipath wwids, Version : 1.0
# NOTE: This file is automatically maintained by multipath and multipathd.
# You should not need to edit this file in normal circumstances.
#
# Valid WWIDs:
/3600c0ff00027f44e1231865801000000/

cat wwids

nano /etc/iscsi/iscsid.conf

iqn.1986-03.com.hp:storage.msa2040.162127e7a9

systemctl enable open-iscsi

systemctl enable iscsid

systemctl enable multipath-tools

iscsid open-iscsi

systemctl enable multipath-tools

nano /etc/multipath.conf

defaults {
    find_multipaths        "on"
        polling_interval        2
        path_selector           "round-robin 0"
        path_grouping_policy    multibus
        uid_attribute           ID_SERIAL
        rr_min_io               100
        failback                immediate
        no_path_retry           queue
        user_friendly_names     yes
}
blacklist {
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^(td|hd)[a-z]"
        devnode "^dcssblk[0-9]*"
        devnode "^cciss!c[0-9]d[0-9]*"
        device {
                vendor "DGC"
                product "LUNZ"
        }
        device {
                vendor "EMC"
                product "LUNZ"
        }
        device {
                vendor "IBM"
                product "Universal Xport"
        }
        device {
                vendor "IBM"
                product "S/390.*"
        }
        device {
                vendor "DELL"
                product "Universal Xport"
        }
        device {
                vendor "SGI"
                product "Universal Xport"
        }
        device {
                vendor "STK"
                product "Universal Xport"
        }
        device {
                vendor "SUN"
                product "Universal Xport"
        }
        device {
                vendor "(NETAPP|LSI|ENGENIO)"
                product "Universal Xport"
        }
}
blacklist_exceptions {
        wwid "3600c0ff00027f44e1231865801000000"
}

multipaths {
  multipath {
        wwid "3600c0ff00027f44e1231865801000000"
        alias mpath0
  }
}

Más información


https://elkano.org/blog/set-up-multipath-iscsi-targets-on-debian/

Mariadb.service: Failed to set up mount namespacing: Permission denied

Después de actualizar el sistema de un contenedor Proxmox a Debian Buster o algún cambio en Proxmox, el servicio mariadb no arranca y muestra el siguiente error:

mariadb.service: Failed to set up mount namespacing: Permission denied

Una posible solución es crear un fichero de configuración personalizado para el servicio mariadb:

systemctl edit mariadb

Al ejecutar el comando anterior, se creará un fichero /etc/systemd/system/mariadb.service.d/override.conf en el que introduciremos las siguientes líneas:

# /lib/systemd/system/mariadb.service
[Service]
ProtectHome=false
ProtectSystem=false
PrivateDevices=false

Una vez añadida la configuración ejecutamos el comando:

systemctl daemon-reload

Y, por último, arrancamos el servicio

systemctl start mariadb

Migrar de VMware a Proxmox

Instalar el mergeide que se puede descargar de varias ubicaciones, o desde aquí MergeIDE.zip

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.

Captura de pantalla 2023-08-10 a las 9.49.30.png

Comprobar que no están instaladas las VMWARE Tools

SI están instaladas, desinstalarlas y reiniciar

Apagar la máquina de VMWare

Copiar los archivos .vmdk a un almacenamiento en red.

Cuando copiamos los vmdk, hay dos archivos para cada disco, un vmdk y un flat-vmdk (por ejemplo si tenemos un disco que se llama midisco, tendremos un midisco.vmdk y un midisco-flat.vmdk). El primer archivo es un descriptor, y el segundo es el disco en sí.

Hay dos formas de realizar el proceso, con conversión de disco y después crear la máquina, o bien creando la máquina e importando el disco

Conversión de disco

Ejecutar el convertidor de vmdk a qcow2 sobre el midisco.vmdk. Para ello, ambos ficheros vmdk deben de estar en la misma carpeta.

El comando para realizar esto es:

qemu-img convert -f vmdk midisco.vmdk -O qcow2 midisco.qcow2

Una vez ha terminado el proceso de conversión que será largo, creamos una máquina virtual nueva, con disco en formato IDE y almacenamiento en la unidad de red, ya que si la creamos en ceph o en lvm o cualquier sistema de archivos local, creará un fichero de bloques y no un fichero convencional.

Una vez creada la máquina, si el ID es por ejemplo 500, tendremos un archivo que se llamará 500.qcow2.

Ahora hacemos backup de este archivo (lo podemos llamar old500.qcow2) y renombramos el archivo midisco.qcow2 como 500.qcow2.

Importando el disco

Otra opción es crear la máquina virtual y desde línea de comando ejecutar:

qm importdisk <machine-number> vmdk storage (lvm, nfs, etc)

machine-number es el número de la máquina creada, y storage es el nombre del almacenamiento donde la vamos a almacenar.

Procesos a realizar

Arrancamos la máquina, si todo va bien, arrancará el sistema operativo. Si no es así. Podemos hacer un truco, que es quitar el disco de la máquina virtual, y después agregarle de nuevo el disco que aparecerá como unused (doble click en unused disk)

Si arranca la máquina, ahora le instalamos los drivers del virtio que los puedes descargar de aquí.

Si no tienes ningún dispositivo virtio (red, etc), para poner el disco en virtio (que es más mejor), lo que hacemos es crearnos un disco de por ejemplo 5 Gb con virtio y asignarlo a la máquina.

Cuando arranque, nos pedirá los drivers del virtio para el disco, se los instalamos, y cuando arranque la próxima vez, si reconoce el disco, apagamos, quitamos el disco IDE, luego añadimos el disco de arranque que acabamos de desconectar y le decimos que es virtio (doble click en unused disk) y luego, muy importante, vamos a opciones y cambiamos el orden de arranque para que arranque del virtio en lugar del disco IDE (si no haces esto, te llevas un susto que para que….)

Y ya debería todo de funcionar correctamente.

En nuestro canal de Youtube, tienes un vídeo con el proceso completo.

No olvides suscribirte para estar informado de las novedades del canal.

Proxmox Varios

Ubicación de las VM en Proxmox

La ubicación de las VM en Proxmox es:

/etc/pve/qemu-server/<VMID>

Qemu-guest-agent

Introducción

Quemu-guest-agent es un daemon que se instala en el sistema operativo de la máquina KVM invitado. Se utiliza para intercambiar información entre el host Proxmox y el invitado, y para ejecutar comandos en el invitado.

En Proxmox VE, qemu-guest-agent se usa principalmente para dos cosas:

Para apagar correctamente el invitado, en lugar de depender de los comandos de ACPI o las políticas de Windows

Para congelar el sistema de archivos invitado al hacer una copia de seguridad (en Windows, usa el servicio de instantáneas de volumen VSS).

Instalación

Host Proxmox

Debe instalar el agente invitado en cada VM y luego habilitarlo, puede hacerlo en la interfaz web (GUI) de Proxmox VE

Qemu-guest-agent.png

O bien desde la linea de comando:

qm set VMID --agent 1

En este caso:

qm set 160 --agent 1

Invitado

Linux

En Linux, simplemente tiene que instalar qemu-guest-agent, según el sistema.

Mostramos aquí los comandos para sistemas basados en Debian / Ubuntu y Redhat:

en sistemas basados en Debian / Ubuntu (con apt-get) ejecuta:

apt install qemu-guest-agent

O bien

apt-get install qemu-guest-agent

Para sistemas basados en Redhat

yum install qemu-guest-agent

Una vez instalado, es necesario que se active, para ello ejecutaremos

systemctl start qemu-guest-agent

Para que se ejecute al inicio del sistema cada vez

systemctl enable qemu-guest-agent

Windows

Primero debe descargar el controlador virtio-win iso

Luego instala el controlador virtio-serial:

Monta la ISO en tu máquina virtual de Windows (virtio - *. Iso)

Vete al Administrador de dispositivos de Windows

Busque "Controlador de comunicaciones simple PCI"

Haz clic en el botón derecho -> Actualizar controlador y seleccione la iso montada en DRIVE: \ vioserial \ <OSVERSION> \ donde <OSVERSION> es su versión de Windows (por ejemplo, 2k12R2 para Windows 2012 R2)

Después de eso, debes instalar el qemu-guest-agent:

Ir al ISO montada en el explorador

El instalador del agente invitado está en el directorio guest-agent.

Ejecuta el instalador con un doble clic (ya sea qemu-ga-x86_64.msi (64 bits) o qemu-ga-i386.msi (32 bits)

Después de eso, qemu-guest-agent debería estar en funcionamiento. Puede validar esto en la lista de servicios de Windows, o en un PowerShell con:

PS C:\Users\Administrator> Get-Service QEMU-GA

Status   Name               DisplayName
------   ----               -----------
Running  QEMU-GA            QEMU Guest Agent

Si no se está ejecutando, puedes usar el panel de control de Servicios para iniciarlo y asegurarte de que se inicie automáticamente en el próximo inicio.

Comprobando que la comunicación con el agente invitado está funcionando

La comunicación con el agente invitado se realiza a través de un socket Unix ubicado en /var/run/qemu-server/<vmid>.qga Puedes probar el agente de comunicación con el comando

qm agent <vmid> ping

Si qemu-guest-agent se está ejecutando correctamente en la VM, devolverá un mensaje de error.

root@hv101:~# qm agent 160 ping
root@hv101:~#

Más información

https://wiki.qemu.org/Features/GuestAgent

 

Usar Proxmox LXC

A diferencia de las máquinas virtuales KVM, que se pueden instalar desde imágenes ISO, los contenedores LXC solo se pueden implementar mediante plantillas de contenedor. Las plantillas de contenedor no son las mismas que las plantillas que creamos para KVM en el capítulo anterior. Las plantillas LXC de varios sistemas operativos y un contenedor específico de la aplicación se pueden descargar directamente desde el repositorio de Proxmox. Para ver una lista de plantillas disponibles ya descargadas, debemos seleccionar un almacenamiento adjunto que pueda almacenar plantillas de contenedores y hacer clic en la pestaña Contenido, como se muestra en la siguiente captura de pantalla:

Proxmox_LXC_Storage.png

En la captura de pantalla anterior, podemos ver que tenemos una plantilla de contenedor de Ubuntu que ya está descargada en nuestro almacenamiento local. Para ver una lista de plantillas LXC disponibles y descargarlas del repositorio de Proxmox, debemos hacer clic en el menú Plantillas para abrir el cuadro de diálogo:

Proxmox_templates_Repo.png

Hay más de 100 plantillas disponibles para descargar desde este cuadro de diálogo. Si no puedes ver la lista completa y solo muestra la Sección: plantillas del sistema, ejecuta el siguiente comando desde la CLI para actualizar la lista de plantillas:

pveam update

Para descargar una plantilla, simplemente selecciónela y haga clic en el botón Descargar. La plantilla descargada ahora estará disponible en el almacenamiento. La ubicación predeterminada para almacenar las plantillas de contenedores para el almacenamiento local es la siguiente:

/mnt/pve/<storage>/template/cache

En nuestro caso, tenemos un volumen NFS denominado isos, en el que se almacenan tanto plantillas como imágenes ISO, a fin de ahorrar espacio en el almacenamiento local de los nodos.

También se puedes descargar desde consola mediante el comando:

La sintaxis es la siguiente:

pveam download <almacenamiento> <nombre_de_la_imagen>

Ejemplo

pveam download isos debian-10.0-standard_10.0-1_amd64.tar.gz

 

LXC Unprivileged container

Los contenedores sin privilegios son cuando el contenedor se crea y se ejecuta como usuario en lugar de root. Esta es la forma más segura de usar un contenedor porque si la seguridad del contenedor se ve comprometida y el intruso sale del contenedor, se encontrará como un usuario nobody con privilegios extremadamente limitados.

Los contenedores sin privilegios no necesitan ser propiedad del usuario, ya que se ejecutan en espacios de nombres de usuario. Esta es una función del kernel que permite la asignación del UID de un host físico en un espacio de nombres dentro del cual puede existir un usuario con UID 0. Los contenedores sin privilegios también se pueden ejecutar como root. Al asignar un UID y un GID específicos a root, podemos crear contenedores sin privilegios en todo el sistema y ejecutarlos como raíz.
Los contenedores privilegiados son cuando son creados y ejecutados solo por el usuario raíz. Estos contenedores no son seguros porque todos los procesos aún se ejecutan como root. Todos los contenedores creados a través de la GUI de Proxmox o las herramientas PCT son contenedores privilegiados.

Si la seguridad total o el aislamiento completo de la máquina virtual es la principal preocupación para un entorno, es mejor usar una máquina virtual KVM, porque KVM es una máquina virtual totalmente independiente sin ninguna dependencia del sistema operativo host ni recursos compartidos.

Proxmox_create_lxc.png

Como podemos ver en la imagen, por defecto los contenedores LXC se crean como Unprivileged container

 

 

Proxmox LXC ACL

Las listas de control de acceso o ACL nos permiten establecer una propiedad de archivos más precisa que los modelos tradicionales de acceso de usuarios o grupos de Linux. De forma predeterminada, Proxmox crea contenedores LXC con ACL. Para crear un contenedor sin ACL, selecciona Disabled en el menú desplegable.

Proxmox_LXC_ACL.png

Gestión de un contenedor LXC

En Proxmox, cada contenedor LXC tiene dos archivos de configuración. Uno define la asignación de recursos sin procesar, mientras que el otro, utilizado por Proxmox, se usa para definir un contenedor. El archivo de configuración del contenedor Proxmox se puede encontrar en la siguiente ubicación:

/etc/pve/local/lxc/<container_id>.conf

Por ejemplo supongamos un LXC on id 900

El archivo

/etc/pve/local/lxc/900.conf contiene:

arch: amd64
cores: 4
features: nesting=1
hostname: test
memory: 4096
nameserver: 1.1.1.1 9.9.9.9
net0: name=eth0,bridge=vmbr0,hwaddr=CA:A7:6E:28:7B:93,ip=dhcp,tag=18,type=veth
ostype: debian
rootfs: local-lvm:vm-900-disk-0,size=8G
searchdomain: ateinco.net
swap: 0
unprivileged: 1

El archivo de configuración del contenedor sin procesar se puede encontrar en la siguiente ubicación:

/var/lib/lxc/<container_id>/config

En nuestro caso en /var/lib/lxc/900/config contiene:

arch: amd64
cores: 4
features: nesting=1
hostname: test
memory: 4096
nameserver: 1.1.1.1 9.9.9.9
net0: name=eth0,bridge=vmbr0,hwaddr=CA:A7:6E:28:7B:93,ip=dhcp,tag=18,type=veth
ostype: debian
rootfs: local-lvm:vm-900-disk-0,size=8G
searchdomain: ateinco.net
swap: 0
unprivileged: 1
root@hv201:/etc/pve/local/lxc# pwd
/etc/pve/local/lxc
root@hv201:/etc/pve/local/lxc# cd /var/lib/lxc/
root@hv201:/var/lib/lxc# cd 900
root@hv201:/var/lib/lxc/900# cat config
lxc.cgroup.relative = 0
lxc.cgroup.dir.monitor = lxc.monitor/900
lxc.cgroup.dir.container = lxc/900
lxc.cgroup.dir.container.inner = ns
lxc.arch = amd64
lxc.include = /usr/share/lxc/config/debian.common.conf
lxc.include = /usr/share/lxc/config/debian.userns.conf
lxc.seccomp.profile = /var/lib/lxc/900/rules.seccomp
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.mount.auto = sys:mixed
lxc.monitor.unshare = 1
lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536
lxc.tty.max = 2
lxc.environment = TERM=linux
lxc.uts.name = test
lxc.cgroup2.memory.max = 4294967296
lxc.cgroup2.memory.swap.max = 0
lxc.rootfs.path = /var/lib/lxc/900/rootfs
lxc.net.0.type = veth
lxc.net.0.veth.pair = veth900i0
lxc.net.0.hwaddr = CA:A7:6E:28:7B:93
lxc.net.0.name = eth0
lxc.net.0.script.up = /usr/share/lxc/lxcnetaddbr
lxc.cgroup2.cpuset.cpus = 11,14,17,21

Hay otro directorio para el sistema de archivos raíz que es un punto de montaje para el espacio de almacenamiento asignado dentro del contenedor. La ubicación del directorio es

/var/lib/lxc/<container_id>/rootfs/

Veamos pues que archivos y carpetas contiene nuestro contenedor:

root@hv201:/var/lib/lxc/900# ls -la
total 24
drwxr-xr-x  4 root root 4096 Mar 17 19:36 .
drwxr-xr-x 12 root root 4096 May 11 11:31 ..
drwxr-xr-x  2 root root 4096 Jan  6 12:43 apparmor
-rw-r--r--  1 root root  864 Mar 17 19:36 config
drwxr-xr-x  2 root root 4096 Dec 15 12:09 rootfs
-rw-r--r--  1 root root  265 Mar 17 19:36 rules.seccomp

Vemos que la carpeta rootfs está vacía.

root@hv201:/var/lib/lxc/900/rootfs# ls -la
total 8
drwxr-xr-x 2 root root 4096 Dec 15 12:09 .
drwxr-xr-x 4 root root 4096 Mar 17 19:36 ..

En Proxmox, este directorio no se utiliza para almacenar datos de contenedores. Para el almacenamiento local, se crea la imagen del disco virtual del contenedor en la carpeta:

/var/lib/vz/images/<container_id>/

Para el almacenamiento compartido, la imagen del disco virtual del contenedor se crea en:

/mnt/pve/<storage>/images/container_id/

Podemos ajustar los recursos asignados para un contenedor en tiempo real sin apagar y encender el contenedor. Esta característica se conoce como hotplug para máquinas virtuales KVM. Sin embargo, para los contenedores LXC, esta característica está integrada en la tecnología del contenedor sin necesidad de ninguna modificación de configuración adicional.

La RAM y la CPU se pueden modificar como hemos comentado sin apagar el contenedor, pero para el disco solo podemos aumentar el tamaño del almacenamiento asignado, pero no podemos disminuirlo. Podemos escribir un valor en GB o usar las flechas arriba y abajo para ajustar el tamaño. Es importante señalar aquí que el valor que seleccionaremos aquí no es el tamaño total del espacio asignado. Este valor se suma al espacio ya asignado. Por ejemplo, en nuestro contenedor de ejemplo #900, el espacio asignado actualmente es de 8 GB. Entonces, si queremos aumentar eso a un tamaño total de 10 GB, escribiremos 2 en el cuadro de diálogo, lo que aumentará el tamaño en 2 GB. Haz clic en el botón Cambiar tamaño de disco en el cuadro de diálogo para modificarlo.

Cambiar_disco_LXC.png

Migrar máquina Windows a Proxmox

Procedimiento para la migración de una máquina física a virtual con Windows

Preparativos:

Instalar los drivers mergeide en la máquina que se va a migrar.

Realizar una copia completa del sistema, para esto se puede usar Acronis, Clonezilla o alguna herramienta similar.

Provisionar una nueva maquina en Proxmox y proceder a restaurar la máquina desde la imagen creada. Esta máquina debe de tener un disco con interfaz IDE o SATA a fin de garantizar el primer arranque

Descargar los drivers virtio desde fedora


Reiniciar los servicios de Proxmox

Si nuestro servidor Proxmox queda inactivo por cualquier problema y no podemos acceder a la administración web, para poder solucionar esto podemos probar a reiniciar los servicios de Proxmox

killall -9 corosync
systemctl restart pve-cluster
systemctl restart pvedaemon
systemctl restart pveproxy
systemctl restart pvestatd

Ceph

Formato de los OSD

Los OSD pueden estar en filestore (obsoleto), discos LVM o discos XFS.

Se han observado problemas en versiones desde la Pacific con los XFS, por lo que es recomendable convertirlos a LVM. Para ello, es suficiente con recrearlos (antes de la actualización, en Octopus):

  1. Identificar los discos que hay que recrear y anotar sus identificadores.
  2. Activar noout para limitar en lo posible el rebalanceo.
  3. Por cada disco:
    1. Marcarlo "out"
    2. Esperar a que Ceph rebalancee
    3. Pararlo ("Stop")
    4. Limpiarlo (en Proxmox, More/Destroy)
    5. Volverlo a crear (en Proxmox, Create: OSD)
  4. Desactivar noout al acabar.

Cluster autocontenido de Ceph (sin Proxmox)

Ceph tiene un director llamado Cephadm que permite crear y gestionar clusters con una cantidad aceptable de dolor.

Para crear un cluster con Ceph y gestionarlo con Cephadm, se parte de un grupo de servidores Debian, preferiblemente recién instalados.

Instalación

Para una instalación a lo Debian, el método más recomendable es el indicado en el manual como método manual.

Solamente se necesita un repo y una clave para la instalación.

Añadir el repo y clave de Ceph

$ sudo tee "deb https://download.ceph.com/debian-quincy/ bullseye main" /etc/apt/sources.list.d/ceph.list
$ wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -

Operaciones

Añadir OSDs

$ sudo ceph orch daemon add osd servidor:/dev/disco

Lavar discos

$ sudo ceph orch device zap --force servidor /dev/disco

Migrar de Máquina física a Proxmox

Pasos previos

Instalar el mergeide que se pude descargar de varias ubicaciones, o desde aquí MergeIDE.zip

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.

Captura de pantalla 2023-08-10 a las 9.49.30.png

Si no se instalan las claves de registro del mergeide, puede que también funcione, pero va a ser un poco más complicado (atención a lo de "puede que también funcione) porque a veces no

Generar imagen de la máquina física

Una vez instalado el Mergeide, procedemos a arrancar la máquina desde un sistema Linux desde CD o USB, recomendamos la utilidad GRML que se puede descargar de grml.org

Una vez que se ha arrancado la máquina, deberemos de tener un disco extraíble o una unidad de red a la que copiar nuestro archivo de imagen que generaremos con la utilidad ddrescue. El manual de esta utilidad lo podemos localizar aquí

Montamos la unidad de disco extraible o el NFS en el Linux o en el grml.

En nuestro ejemplo la vamos a llamar copia

mkdir /mnt/copia

Montamos el disco

mount /dev/sdb1 /mnt/copia

O bien si es un NTFS

mount -t ntfs /dev/sdb1 /mnt/copia

Ejecutaremos el comando ddrescue

ddrescue -d -f -r3 /dev/sda /mnt/copia/windows_2019.img rescue.log

Copiar el archivo img a un almacenamiento en red.

Convertir imagen de máquina física a Proxmox

Para esto existen dos formas

qemu-img convert

Ejecutar el convertidor de vmdk a qcow2 sobre el midisco.vmdk. Para ello, ambos ficheros vmdk deben de estar en la misma carpeta.

El comando para realizar esto es:

qemu-img convert -f raw midisco.raw -O qcow2 midisco.qcow2

Una vez ha terminado el proceso de conversión que será largo, creamos una máquina virtual nueva, con disco en formato IDE y almacenamiento en la unidad de red, ya que si la creamos en ceph o en lvm o cualquier sistema de archivos local, creará un fichero de bloques y no un fichero convencional.

Una vez creada la máquina, si el ID es por ejemplo 500, tendremos un archivo que se llamará 500.qcow2.

Ahora hacemos backup de este archivo (lo podemos llamar old500.qcow2) y renombramos el archivo midisco.qcow2 como 500.qcow2.

qm importdisk (la más cómoda)

Otra opción es crear la máquina virtual y desde línea de comando ejecutar:

qm importdisk <machine-number> windows_1029.img storage (lvm, nfs, etc)

NOTA IMPORTANTE Personalmente, una vez creada la máquina y para seguir el orden (vmxxx-disk0, vmxxx-disk1) es aconsejable borrar el disco de la máquina recién creada y que el proceso de importación del disco cree el disco con el ID 0

machine-number es el número de la máquina creada, y storage es el nombre del almacenamiento donde la vamos a almacenar.

Esto nos creará un disco sin asignar en la máquina, que asignaremos con el interfaz SATA como interfaz de disco.

Cambiaremos el orden de arranque para que haga el arranque desde el disco SATA recién asignado

Arrancamos la máquina, si todo va bien, arrancará el sistema operativo. Si no es así. Podemos hacer un truco, que es quitar el disco de la máquina virtual, y después agregarle de nuevo el disco que aparecerá como unused (doble click en unused disk)

Si arranca la máquina, ahora le instalamos los drivers del virtio que los puedes descargar de aquí.

Si no tienes ningún dispositivo virtio (red, etc), para poner el disco en virtio (que es más mejor), lo que hacemos es crearnos un disco de por ejemplo 5 Gb con virtio y asignarlo a la máquina.

Cuando arranque, nos pedirá los drivers del virtio para el disco, se los instalamos, y cuando arranque la próxima vez, si reconoce el disco, apagamos, quitamos el disco IDE o SATA, luego añadimos el disco de arranque que acabamos de desconectar y le decimos que es virtio (doble click en unused disk) y luego, muy importante, vamos a opciones y cambiamos el orden de arranque para que arranque del virtio en lugar del disco IDE (si no haces esto, te llevas un susto que para que….)

Y ya debería todo de funcionar correctamente.

Enlace al vídeo en youtube

Por último os pasamos un enlace a un vídeo en YouTube, donde se explica el proceso

 

Exportar una máquina virtual OVA de VmWare para importar en Proxmox

Como en anteriores ocasiones, si tenemos una máquina Windows, lo primero que tendremos que hacer es instalar el MergeIde.zip en la máquina antes de exportar

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.

Captura de pantalla 2023-08-10 a las 9.49.30.png

"ExportarA continuación procederemos a crear el archivo OVA que se puede hacer desde las plataformas de Virtualización habituales

VMWARE

En VMWare seleccionaremos la máquina virtual, y en archivo seleccionaremos "Exportar" y "Exportar Plantilla de OVF"

Exportar_OVA_VMW_1.png

Ahora nos preguntará en que formato queremos exportar ls máquina virtual, hay dos opciones en OVF (Carpeta de archivos) o en OVA (Un sólo archivo)

Exportar_OVA_VMW_2.png

Seleccionaremos el Directorio en el que vamos a exportar y esperamos a que termine el proceso.


Descargar e instalar el MergeIDE

Instalar el mergeide que se puede descargar de varias ubicaciones, o desde aquí MergeIDE.zip

Este archivo es un ejecutable bat que inserta unas claves de registro. Si no se ejecuta, podemos insertarlas a mano (vienen en el archivo ZIP) como podemos ver en la imagen inferior.

Captura de pantalla 2023-08-10 a las 9.49.30.png

Migrar una máquina de Hyper V a Proxmox

A partir de una máquina de Hyper-V podemos realizar una copia del disco duro de dicha máquina y de esta forma poder migrar la máquina a Proxmox.

La secuencia consiste en copiar el disco duro que se encuentra normalmente en:

C:\Program Data\Microsoft\Windows\Virtual Hard Disks

El disco se compone al igual que en el caso de los discos vmdk de Vmware de dos archivos, un archivo con la extensión vhdx, que contiene la descripción del disco, y el archivo del disco en sí, que suele ser el nombre de la máquina y un UID con la extensión avhdx

El formato de las máquinas Hyper V es vhdx, este formato no deja de ser un formato raw de máquina virtual, para importar una máquina desde Hyper V, tendremos que ejecutar o bien una conversión de disco

Una vez copiados, podemos hacer lo siguiente para importarlo en Proxmox:

Conversión de disco

qemu-img convert -f vhdx -O raw windowsvmdisk.vhdx proxmoxdisk.raw

Este comando es el que se usa para convertir entre formatos de imágenes en qemu, cómo podemos ver en detalle en este artículo

Ahora podemos importar el disco en nuestra máquina virtual mediante el qm importdisk

Creación de la máquina e importación del disco

La otra opción  es crear la máquina virtual previamente y desde línea de comando ejecutar:

qm importdisk <machine-number> vhdx storage (lvm, nfs, etc)

machine-number es el número de la máquina creada, y storage es el nombre del almacenamiento donde la vamos a almacenar.

Esto realiza el proceso de conversión en un sólo paso.

Procesos a realizar

Arrancamos la máquina, si todo va bien, arrancará el sistema operativo. Si no es así. Podemos hacer un truco, que es quitar el disco de la máquina virtual, y después agregarle de nuevo el disco que aparecerá como unused (doble click en unused disk)

Si arranca la máquina, ahora le instalamos los drivers del virtio que los puedes descargar de aquí.

Si no tienes ningún dispositivo virtio (red, etc), para poner el disco en virtio (que es más mejor), lo que hacemos es crearnos un disco de por ejemplo 5 Gb con virtio y asignarlo a la máquina.

Cuando arranque, nos pedirá los drivers del virtio para el disco, se los instalamos, y cuando arranque la próxima vez, si reconoce el disco, apagamos, quitamos el disco IDE, luego añadimos el disco de arranque que acabamos de desconectar y le decimos que es virtio (doble click en unused disk) y luego, muy importante, vamos a opciones y cambiamos el orden de arranque para que arranque del virtio en lugar del disco IDE (si no haces esto, te llevas un susto que para que….)

Y ya debería todo de funcionar correctamente.


Migrar de OVA a Proxmox

Copiaremos el archivo OVA a una carpeta local o NFS en Proxmox.

Tenemos en primer lugar que descomprimir el archivo OVA

tar xvf debian-minimal-12.1.0.ova

En algunos casos, tendremos que instalar el tar si no está en Proxmox

Esto nos dejará tres archivos (o más si la máquina tiene más discos)

debian-minimal-12.1.0.ovf
debian-minimal-12.1.0.mf
debian-minimal-12.1.0-disk1.vmdk

El archivo ovf contiene la descripción e la máquina virtual

<?xml version="1.0" encoding="UTF-8"?>
<!--Generated by VMware ESX Server, User: root, UTC time: 2023-07-30T12:14:21.762012Z-->
<Envelope vmw:buildId="build-14320388" xmlns="http://schemas.dmtf.org/ovf/envelope/1" xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/>
  <References>
    <File ovf:href="debian-minimal-12.1.0-disk1.vmdk" ovf:id="file1" ovf:size="459838464"/>
  </References>
  <DiskSection>
    <Info>Virtual disk information</Info>
    <Disk ovf:capacity="40000" ovf:capacityAllocationUnits="byte * 2^20" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="1528823808"/>
  </DiskSection>
  <NetworkSection>
    <Info>The list of logical networks</Info>
    <Network ovf:name="VM Network">
      <Description>The VM Network network</Description>
    </Network>
  </NetworkSection>
  <VirtualSystem ovf:id="debian-minimal-12.1.0">
    <Info>A virtual machine</Info>
    <Name>debian-minimal-12.1.0</Name>
    <OperatingSystemSection ovf:id="1" vmw:osType="otherGuest">
      <Info>The kind of installed guest operating system</Info>
    </OperatingSystemSection>..........................................

Ejecutaremos el comando qm importovf

qm importovf <vmid> <manifest> <storage> [OPTIONS]

vmid es el ide nuestra nueva máquina, manifest es el archivo ovf y storage es el almacenamiento destino

En este caso lo hacemos con --dryrun que no modifica nada, y nos permite comprobar que todo está correcto.

qm importovf 202 debian-minimal-12.1.0.ovf local-lvm --dryrun
{
   "disks" : [
      {
         "backing_file" : "/mnt/pve/NAS/debian-minimal-12.1.0-disk1.vmdk",
         "disk_address" : "scsi0",
         "virtual_size" : 41943040000
      }
   ],
   "qm" : {
      "cores" : "2",
      "memory" : "2048",
      "name" : "debian-minimal-12.1.0"
   }
}

Como vemos, ha pasado los chequeos

Ahora podemos ejecutar el comando sin el dry-run y nos creará la máquina virtual

root@pve:/mnt/pve/NAS# qm importovf 202 debian-minimal-12.1.0.ovf local-lvm
  Logical volume "vm-202-disk-0" created.
transferred 0.0 B of 39.1 GiB (0.00%)
transferred 400.0 MiB of 39.1 GiB (1.00%)
transferred 804.0 MiB of 39.1 GiB (2.01%)
transferred 1.2 GiB of 39.1 GiB (3.01%)
transferred 1.6 GiB of 39.1 GiB (4.01%)
transferred 2.0 GiB of 39.1 GiB (5.02%)
transferred 2.4 GiB of 39.1 GiB (6.02%)
transferred 2.7 GiB of 39.1 GiB (7.02%)
transferred 3.1 GiB of 39.1 GiB (8.02%)
transferred 3.5 GiB of 39.1 GiB (9.03%)
transferred 3.9 GiB of 39.1 GiB (10.03%)
transferred 4.3 GiB of 39.1 GiB (11.03%)
transferred 4.7 GiB of 39.1 GiB (12.04%)
transferred 5.1 GiB of 39.1 GiB (13.04%)
transferred 5.5 GiB of 39.1 GiB (14.04%)
transferred 5.9 GiB of 39.1 GiB (15.05%)
transferred 6.3 GiB of 39.1 GiB (16.05%)
transferred 6.7 GiB of 39.1 GiB (17.05%)
transferred 7.1 GiB of 39.1 GiB (18.06%)
transferred 7.4 GiB of 39.1 GiB (19.06%)
transferred 7.8 GiB of 39.1 GiB (20.06%)
transferred 8.2 GiB of 39.1 GiB (21.06%)
transferred 8.6 GiB of 39.1 GiB (22.07%)
transferred 9.0 GiB of 39.1 GiB (23.07%)
transferred 9.4 GiB of 39.1 GiB (24.07%)
transferred 9.8 GiB of 39.1 GiB (25.08%)
transferred 10.2 GiB of 39.1 GiB (26.08%)
transferred 10.6 GiB of 39.1 GiB (27.08%)
transferred 11.0 GiB of 39.1 GiB (28.09%)
transferred 11.4 GiB of 39.1 GiB (29.09%)...............
...........................................
transferred 38.0 GiB of 39.1 GiB (97.30%)
transferred 38.4 GiB of 39.1 GiB (98.30%)
transferred 38.8 GiB of 39.1 GiB (99.31%)
transferred 39.1 GiB of 39.1 GiB (100.00%)
transferred 39.1 GiB of 39.1 GiB (100.00%)
root@pve:/mnt/pve/NAS#

En ese momento tendremos una nueva máquina virtual en nuestro Proxmox con el ID 202

ova-01.png

Vemos que ha configurado todo, tal como venía en el fichero ovf

ova-02.png

Y ahora podremos realizar los cambios necesarios una vez arranque (MAC, tipo de disco, procesador, etc)

ova-03.png

Problemas que podemos encontrarnos

Algunas veces el disco del archivo manifest (ovf) no está demasiado bien definido, y nos puede dar problemas

root@pve:/mnt/pve/NAS/PF# qm importovf 204 PacketFence-ZEN-v13.0.0.ovf local-lvm --dryrun
warning: unable to parse the VM name in this OVF manifest, generating a default value
invalid host ressource /disk/vmdisk1, skipping
{
   "disks" : [],
   "qm" : {
      "cores" : "4",
      "memory" : "12288"
   }
}

En este caso, ejecutaremos, pero no nos creará el disco

root@pve:/mnt/pve/NAS/PF# qm importovf 204 PacketFence-ZEN-v13.0.0.ovf local-lvm
warning: unable to parse the VM name in this OVF manifest, generating a default value
invalid host ressource /disk/vmdisk1, skipping

ova-04.png

Como vemos nos ha creado una máquina sin nombre, y sin disco.

No hay problema, importamos posteriormente el disco.

root@pve:/mnt/pve/NAS/PF# qm importdisk 204 PacketFence-ZEN-v13.0.0-disk1.vmdk local-lvm
importing disk 'PacketFence-ZEN-v13.0.0-disk1.vmdk' to VM 204 ...
  Logical volume "vm-204-disk-0" created.
transferred 0.0 B of 195.3 GiB (0.00%)
transferred 2.0 GiB of 195.3 GiB (1.00%)
transferred 3.9 GiB of 195.3 GiB (2.00%)
transferred 5.9 GiB of 195.3 GiB (3.00%)
transferred 7.8 GiB of 195.3 GiB (4.00%)
transferred 9.8 GiB of 195.3 GiB (5.00%)
transferred 11.7 GiB of 195.3 GiB (6.00%)
transferred 13.7 GiB of 195.3 GiB (7.00%)
transferred 15.6 GiB of 195.3 GiB (8.00%)
transferred 17.6 GiB of 195.3 GiB (9.00%)
transferred 19.5 GiB of 195.3 GiB (10.00%)
transferred 21.5 GiB of 195.3 GiB (11.00%)
transferred 23.4 GiB of 195.3 GiB (12.00%)
transferred 25.4 GiB of 195.3 GiB (13.00%)
transferred 27.3 GiB of 195.3 GiB (14.00%)
transferred 29.3 GiB of 195.3 GiB (15.00%)
transferred 31.2 GiB of 195.3 GiB (16.00%)
transferred 33.2 GiB of 195.3 GiB (17.00%)
..........................................
transferred 183.6 GiB of 195.3 GiB (94.00%)
transferred 185.5 GiB of 195.3 GiB (95.00%)
transferred 187.5 GiB of 195.3 GiB (96.00%)
transferred 189.5 GiB of 195.3 GiB (97.00%)
transferred 191.4 GiB of 195.3 GiB (98.00%)
transferred 193.4 GiB of 195.3 GiB (99.00%)
transferred 195.3 GiB of 195.3 GiB (100.00%)
transferred 195.3 GiB of 195.3 GiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-204-disk-0'

Nos habrá creado un Unsued Disk 0, que si hacemos doble click sobre él, lo podremos asignar a la máquina

ova-05.png

Simplemente hacemos doble click en el disco Unused Disk 0

ova-06.png

Escogemos el tipo de Bus/Device (IDE, SATA, etc) en nuestro caso Virtio

ova-07.png

Y ya lo tenemos todo a falta de renombrar la máquina

ova-08.png 



Conservar ajustes de una máquina física en Proxmox

Muchos sistemas y muchas aplicaciones verifican la información del BIOS durante el proceso de instalación o bien para conservar los datos de licencia de algún software y si están instaladas en un hardware diferente al que fueron producidas, la instalación falla con un mensaje como este: "Este sistema no es una plataforma compatible".

Para ver los datos de la máquina podemos ejecutar lo siguiente

# dmidecode 2.11
SMBIOS 2.6 present.
35 structures occupying 1145 bytes.
Table at 0x000FB330.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: HP
Version: O41
Release Date: 07/29/2011
...
...
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: HPE
Product Name: ProLiantDL380Gen10
Version:U30
Serial Number: 123456AB
UUID: 1E3BD500-1DD2-11B2-8000-009C02ABDD39
Wake-up Type: Power Switch
SKU Number: P24841-B21
Family:
…

Esto nos da la información de la máquina física, para proceder cuando instalemos o migremos una máquina a un entorno Proxmox, podríamos necesitar dicha información

A efectos de realizar esto, agregamos esta información en la configuración de la máquina virtual

<os>
  <type arch=’x86_64′ machine=’pc-1.0′>hvm</type>
  <boot dev=’hd’/>
  <bootmenu enable=’yes’/>
  <smbios mode=’sysinfo’/>
</os>
<sysinfo type=’smbios’>
  <bios>
      <entry name=’vendor’>HP</entry>
      <entry name=’version’>P71</entry>
  </bios>
  <system>
      <entry name=’manufacturer’>HP</entry>
      <entry name=’product’>ProLiant DL360p Gen8</entry>
      <entry name=’serial’>CZJ3210VK4</entry>
      <entry name=’sku’>646901-421</entry>
  </system>
</sysinfo>

O bien desde la interfaz gráfica (necesitaremos apagar la máquina)

WIndows_machine.png

Entramos en opciones, y en el apartado SMBIOS Settings, hacemos doble click

Windows_machine_02.png

Rellenaremos con los valores que hemos obtenido con el comando dmidecode.

Windows_machine_03.png

Pulsamos OK, y la máquina ahora tendrá los valores que tenía la máquina original

Windows_machine_04.png

Por lo que a nivel de datos de hardware será la misma que la máquina física que teníamos

Si esto nos ocurre también con el número de serie de algún disco, la solución la tenemos aquí.





Números de serie de discos en Proxmox

Como habíamos comentado en el apartado de conservar los valores de los parámetros físicos de una máquina física en una máquina virtual, también puede ocurrir algo parecido con los discos.

Muchas aplicaciones en su instalación guardan el valor del número de serie del disco de la máquina, por lo que una migración puede dejar el registro del aplicativo inservible.

Cambiar o establecer el número de serie de un disco en Proxmox VE

Para solucionar esto, os vamos a contar como definir un número de serie determinado en un disco duro en Proxmox VE.

Pongamos el ejemplo de una máquina con discos virtio.

El comando para establecer un número de serie determinado a los discos sería este para por ejemplo 3 discos de una máquina virtual.

root@hv9:~# qm set 9995 --virtio1 local-lvm:vm-9995-disk-1,serial=vm9995disk1
update VM 9995: -virtio1 local-lvm:vm-9995-disk-1,serial=vm9995disk1
root@hv9:~# qm set 9995 --virtio2 local-lvm:vm-9995-disk-2,serial=vm9995disk2
update VM 9995: -virtio2 local-lvm:vm-9995-disk-2,serial=vm9995disk2
root@hv9:~# qm set 9995 --virtio3 local-lvm:vm-9995-disk-3,serial=vm9995disk3
update VM 9995: -virtio3 local-lvm:vm-9995-disk-3,serial=vm9995disk3
root@hv9:~#

Los discos ahora quedarían pendientes de apagar y reiniciar la máquina para que los valores queden grabados

Discos_SN_proxmox.png

SI el número de serie que necesitamos es otro, bastará con obtener el número de serie original del disco y escribirlo.

Otras controladoras

Esto lo hemos visto para virtio, pero en el caso de otras controladores el proceso es el mismo, supongamos que el número de serie de nuestro disco es 12345678, en el caso de una controladora IDE

HDD_SN_02.png

El comando sería

qm set 104 --ide1 local-lvm:vm-104-disk-1,serial=12345678

Como vemos la sintaxis es qm set [número o id de la máquina]  --controlador (virtio,ide,scsi,sata) y el número, el nombre del archivo o del objeto disco (incluyendo el almacenamiento) y el número de serie.

Vemos otros ejemplos

HDD_SN_03.png

En este caso el comando sería

qm set 104 --sata0 local-lvm:vm-104-disk-1,serial=12345678

 

 

 

 

Usuarios y Grupos en Proxmox VE

El sistema de usuarios y grupos en Proxmox, nos permite definir permisos granulares, si necesitamos conceder acceso en nuestra organización a diferentes perfiles de cara a que ellos mismos se gestionen sus máquinas y su infraestructura.

Para ello empezaremos a ver como funcionan los usuarios, los grupos y los sistemas de autenticación que soporta Proxmox VE

Sistemas de autenticación

Proxmox VE admite múltiples fuentes de autenticación, por ejemplo Linux PAM (usuarios del sistema Linux subyacente), un servidor de autenticación Proxmox VE integrado, LDAP, Microsoft Active Directory y OpenID Connect. Estas opciones de configuración, se explican en el siguiente artículo.

Al utilizar la administración de permisos y usuarios basada en roles para todos los objetos (VM, almacenamiento, nodos, etc.), se puede definir el acceso granular como hemos comentado antes.

Usuarios

Proxmox VE almacena los atributos del usuario en /etc/pve/user.cfg. Las contraseñas no se almacenan aquí; en cambio, los usuarios están asociados con los dominios de autenticación que se describen en los diferentes sistemas de autenticación que explicaremos. Por lo tanto, un usuario suele identificarse internamente por su nombre de usuario y dominio en el formato <userid>@<realm>.

Por ejemplo para acceder con un usuario del propio sistema el realm será pam (eduardo@pam), en el caso de usuarios del servidor de autenticación de Proxmox VE Integrado el realm será pve (eduardo@pve)

Cada entrada de usuario en este archivo contiene la siguiente información:

Precaución Cuando deshabilitas o eliminas un usuario, o si la fecha de vencimiento establecida ya pasó, este usuario no podrá iniciar sesión, ni iniciar nuevas tareas. Todas las tareas que ya haya iniciado este usuario (por ejemplo, sesiones de terminal) no finalizarán automáticamente por dicho evento, por lo que permanecerán en ejecución.

Usuarios especiales

Administrador del sistema (root/pam)

El usuario root del sistema siempre puede iniciar sesión a través del dominio PAM de Linux y es un administrador ilimitado. Este usuario no se puede eliminar, pero aún se pueden cambiar los atributos. Los correos del sistema se enviarán a la dirección de correo electrónico asignada a este usuario.

Grupos

Cada usuario puede ser miembro de varios grupos. Los grupos son la forma recomendada de organizar los permisos de acceso, ya que de esa forma tendremos mejor control de los que hace cada usuario, sin tener que asignar permisos específicos usuario por usuario, que puede dejar fallos de seguridad. Siempre debes otorgar permisos a grupos en lugar de a usuarios individuales. De esa manera tendrás una lista de control de acceso (ACL) mucho más fácil de mantener.



Dominios de autenticación en Proxmox VE

En Proxmox VE, como comentamos en el apartado de usuarios, disponemos de varios dominios o reinos (realm) de autenticación dependiendo de que opciones usemos para autenticar a los usuarios.

Como los usuarios de Proxmox VE son los homólogos de los usuarios que existen en algún dominio externo, los dominios deben configurarse en /etc/pve/domains.cfg. Están disponibles los siguientes dominios (métodos de autenticación):

Autenticación estándar PAM de Linux

Linux PAM es el método para la autenticación de usuarios en todo el sistema. Estos usuarios se crean en el sistema host linux con comandos como adduser. Si existen usuarios de PAM en el sistema host de Proxmox VE, se pueden agregar las entradas correspondientes a Proxmox VE para permitir que estos usuarios inicien sesión a través de su nombre de usuario y contraseña del sistema.

Linux PAM corresponde a los usuarios del sistema host, debe existir un usuario del sistema en cada nodo en el que el usuario pueda iniciar sesión. El usuario se autentica con su contraseña habitual del sistema. Este dominio se agrega de forma predeterminada y no se puede eliminar. En términos de configuración, un administrador puede optar por requerir autenticación de dos factores con inicios de sesión desde el dominio y establecer el dominio como el dominio de autenticación predeterminado.

Servidor de autenticación Proxmox VE

Este es un almacén de contraseñas similar al que usa Unix, que almacena contraseñas hash en /etc/pve/priv/shadow.cfg. Las contraseñas se codifican mediante el algoritmo hash SHA-256. Este es el mejor sistema para instalaciones de pequeña escala (o incluso de mediana escala), donde los usuarios no necesitan acceso a nada fuera de Proxmox VE. En este caso, los usuarios se administran completamente por Proxmox VE y pueden cambiar sus propias contraseñas a través de la GUI.

El ámbito del servidor de autenticación Proxmox VE es un almacén de contraseñas simple similar a Unix. El dominio se crea de forma predeterminada y, al igual que con Linux PAM, los únicos elementos de configuración disponibles son la capacidad de requerir autenticación de dos factores para los usuarios del dominio y establecerlo como el dominio predeterminado para iniciar sesión.

A diferencia de otros tipos de dominio de Proxmox VE, los usuarios se crean y autentican completamente a través de Proxmox VE, en lugar de autenticarse contra otro sistema. Por lo tanto, se le solicita que establezca una contraseña para este tipo de usuario al momento de su creación.

LDAP

LDAP (Protocolo ligero de acceso a directorios) es un protocolo abierto multiplataforma para la autenticación mediante servicios de directorio. OpenLDAP es una implementación popular de código abierto del protocolo LDAP.

También puede utilizar un servidor LDAP externo para la autenticación de usuarios (por ejemplo, OpenLDAP). En este tipo de dominio, los usuarios se buscan bajo un nombre de dominio base (base_dn), utilizando el atributo de nombre de usuario especificado en el campo Nombre de atributo de usuario (user_attr).

Se puede configurar un servidor y un servidor de backup opcional, y la conexión se puede cifrar mediante SSL. Además, se pueden configurar filtros para directorios y grupos. Los filtros le permiten limitar aún más el alcance del dominio.

Por ejemplo, si un usuario está representado a través del siguiente conjunto de datos LDIF:

# etaboada of Group Tecnocratas at tecnocractica.net
dn: uid=user1,ou=Tecnocratas,dc=tecnocratica,dc=net
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: etaboada
cn: Prueba usuario
sn: Pruebas
description: Usuario de prueba.

El nombre de dominio base sería ou=Tecnocratas,dc=tecnocratica,dc=net y el atributo de usuario sería uid.

Captura de pantalla 2024-01-28 a las 9.02.44.png

Si Proxmox VE necesita autenticarse (vincularse) al servidor LDAP antes de poder consultar y autenticar usuarios, se puede configurar un nombre de dominio de vinculación a través de la propiedad bind_dn en /etc/pve/domains.cfg. Luego, su contraseña debe almacenarse en /etc/pve/priv/ldap/<realmname>.pw (por ejemplo, /etc/pve/priv/ldap/tecnocratica.pw). Este archivo debe contener una sola línea con la contraseña sin formato.

Para verificar los certificados, debe configurar capath. Puede configurarlo directamente en el certificado CA de su servidor LDAP o en la ruta del sistema que contiene todos los certificados CA confiables (/etc/ssl/certs). Además, debe configurar la opción de verificación, que también se puede realizar a través de la interfaz web.

Las principales opciones de configuración para un dominio de servidor LDAP son las siguientes:

Para permitir que un usuario en particular se autentique utilizando el servidor LDAP, también debe agregarlo como usuario de ese dominio desde el servidor Proxmox VE. Esto se puede realizar automáticamente con la sincronización.

Directorio activo de Microsoft (AD)

Microsoft Active Directory (AD) es un servicio de directorio para redes de dominio de Windows y Proxmox VE lo admite como dominio de autenticación. Soporta LDAP como protocolo de autenticación, ya que es un LDAP extendido.

Captura de pantalla 2024-01-28 a las 9.00.26.png

Como podemos ver la configuración es muy parecida a la de LDAP, ya que al fin y al cabo, AD es compatible con LDAP

Para permitir que un usuario en particular se autentique utilizando el servidor LDAP, también debe agregarlo como usuario de ese dominio desde el servidor Proxmox VE. Esto se puede llevar a cabo automáticamente con la sincronización. Para configurar Microsoft AD como dominio, se debe especificar una dirección de servidor y un dominio de autenticación. Active Directory admite la mayoría de las mismas propiedades que LDAP, como un servidor de respaldo opcional, un puerto y cifrado SSL. Además, los usuarios pueden agregarse a Proxmox VE automáticamente mediante operaciones de sincronización, después de la configuración.

Al igual que con LDAP, si Proxmox VE necesita autenticarse antes de vincularse al servidor AD, debe configurar la propiedad Vincular usuario (bind_dn). Esta propiedad suele ser necesaria de forma predeterminada para Microsoft AD.

Los principales ajustes de configuración de Microsoft Active Directory son:

Sincronización de dominios basados en LDAP

Es posible sincronizar automáticamente usuarios y grupos para dominios basados en LDAP (LDAP y Microsoft Active Directory), en lugar de tener que agregarlos a Proxmox VE manualmente. Puede acceder a las opciones de sincronización desde la ventana Agregar/Editar del panel de Autenticación de la interfaz web o mediante los comandos pveum realm add/modify. Luego puede realizar la operación de sincronización desde el panel de Autenticación de la GUI o utilizando el siguiente comando:

pveum realm sync <realm>

Los usuarios y grupos se sincronizan con el archivo de configuración de todo el cluster en el archivo /etc/pve/user.cfg.

Atributos a propiedades

Si la respuesta de sincronización incluye atributos de usuario, se sincronizarán con la propiedad de usuario correspondiente en user.cfg. Por ejemplo: nombre o apellido.

Si los nombres de los atributos no coinciden con las propiedades de Proxmox VE, puede establecer un mapa personalizado de campo a campo en la configuración utilizando la opción sync_attributes.

La forma en que se manejan dichas propiedades si algo desaparece se puede controlar a través de las opciones de sincronización.

Configuración de sincronización

Las opciones de configuración para sincronizar dominios basados en LDAP se pueden encontrar en la pestaña Opciones de sincronización de la ventana Agregar/Editar.

Las opciones de configuración son las siguientes:

Opciones de sincronización

Además de las opciones especificadas en la sección anterior, también puede configurar otras opciones que describen el comportamiento de la operación de sincronización.

Estas opciones se configuran como parámetros antes de la sincronización o como valores predeterminados a través de la opción de reino sync-defaults-options.

Las principales opciones de sincronización son:

Carácteres reservados

Ciertos caracteres están reservados (consulta la RFC2253) y no se pueden usar fácilmente en valores de atributos en DN sin utilizar escapes adecuados.

Los siguientes carácteres necesitan secuencia de escape:

Para utilizar dichos caracteres en DN, escribe el valor del atributo entre comillas dobles. Por ejemplo, para vincularse con un usuario con el ejemplo CN (nombre común), usuario, utilice CN="Ejemplo, usuario",OU=people,DC=example,DC=com como valor para bind_dn.

Esto se aplica a los atributos base_dn, bind_dn y group_dn.

Los usuarios con dos puntos y barras diagonales no se pueden sincronizar ya que son caracteres reservados en los nombres de usuario.

Conexión OpenID

OpenID Connect se implementa como una capa de identidad sobre el protocolo OATH 2.0. Permite a los clientes verificar la identidad del usuario, basándose en la autenticación realizada por un servidor de autorización externo. Existen diferentes productos que proporcionan dicha funcionalidad.

Las principales opciones de configuración de OpenID Connect son:

URL del emisor (issuer-url): Esta es la URL del servidor de autorización. Proxmox utiliza el protocolo OpenID Connect Discovery para configurar automáticamente más detalles.

Si bien es posible utilizar URL http:// no cifradas, recomendamos encarecidamente utilizar conexiones https:// cifradas. ya que en la comunicación se intercambian datos confidenciales que pueden ser aprovechados para obtener acceso no autorizado.

Captura de pantalla 2024-01-28 a las 9.03.40.png

Mapa de nombres de usuario

La especificación OpenID Connect define un único atributo único (claim en términos de OpenID) denominado sujeto. De forma predeterminada, utilizamos el valor de este atributo para generar nombres de usuario de Proxmox VE, simplemente agregando @ y el nombre del dominio: ${subject}@${realm}.

Desafortunadamente, la mayoría de los servidores OpenID usan cadenas aleatorias para el asunto, como

K5ZZI1NADAUCEA0STSB9, por lo que un nombre de usuario típico sería K5ZZI1NADAUCEA0STSB9@yourrealm. Si bien es único, es difícil para los humanos recordar estas cadenas aleatorias, lo que hace imposible asociar a usuarios reales con esto.

La configuración de claim de nombre de usuario le permite usar otros atributos para la asignación del nombre de usuario. Es prefible configurarlo como nombre de usuario si el servidor OpenID Connect proporciona ese atributo y garantiza su singularidad.

Otra opción es utilizar el correo electrónico, que también proporciona nombres de usuario legibles por humanos. Nuevamente, use esta configuración solo es factible, si el servidor garantiza la unicidad de este atributo.

Ejemplos
A continuación se muestra un ejemplo de cómo crear un dominio OpenID usando Google. Debe reemplazar --client-id y --client-key con los valores de su configuración de Google OpenID.

pveum realm add myrealm1 --type openid --issuer-url  https://accounts.google.com --client-id XXXX --client-key YYYY --username-claim email

El comando anterior utiliza el correo electrónico --username-claim, de modo que los nombres de usuario en el lado de Proxmox VE se vean como ejemplo.usuario@google.com@myrealm1.

Doble Factor de autenticación en Proxmox VE

En primer lugar y como "disclaimer"

NO ES ACONSEJABLE PONER UN PROXMOX EN PRODUCCIÓN SIN NINGÚN TIPO DE PROTECCIÓN.

Dicho esto, si necesitas hacerlo, te aconsejamos pone un firewall basado en iptables, o mejor aún en nftables

Hay dos formas de utilizar la autenticación de dos factores:

Puede ser requerido por el dominio o realm de autenticación, ya sea a través de TOTP (contraseña de un solo uso basada en tiempo) o YubiKey OTP. En este caso, a un usuario recién creado se le deben agregar sus claves inmediatamente, ya que no hay forma de iniciar sesión sin el segundo factor. En el caso de TOTP, los usuarios también pueden cambiar el TOTP más adelante, siempre que puedan iniciar sesión primero.

Alternativamente, los usuarios pueden optar por optar por la autenticación de dos factores más adelante, incluso si el realmno la aplica.

Segundos factores de autenticación disponibles

Puedes configurar varios segundos factores para evitar una situación en la que perder tu teléfono inteligente o tu llave de seguridad lo bloquee permanentemente de tu cuenta.

Los siguientes métodos de autenticación de dos factores están disponibles además de TOTP aplicado por realm y YubiKey OTP:

TOTP

Contraseña de un solo uso basada en tiempo configurada por el usuario. Un código corto derivado de un secreto compartido y la hora actual, cambia cada 30 segundos.

WebAuthn

Autenticación web. Un estándar general para la autenticación. Se implementa mediante varios dispositivos de seguridad, como claves de hardware o módulos de plataforma confiable (TPM) desde un ordenador o teléfono inteligente.

Claves de recuperación de un solo uso.

Una lista de claves que deben imprimirse y guardarse bajo llave en un lugar seguro o guardarse digitalmente en un vault o sistema de almacenamiento de claves electrónico. Cada clave se puede utilizar sólo una vez. Estos son perfectos para garantizar que no quede bloqueado, incluso si todos los demás factores secundarios se pierden o se corrompen.

Antes de que WebAuthn fuera compatible, el usuario podía configurar U2F. Aún se pueden utilizar los factores U2F existentes, pero se recomienda cambiar a WebAuthn, una vez que esté configurado en el servidor.

Autenticación de dos factores (TFA) reforzada en el Realm

Esto se puede hacer seleccionando uno de los métodos disponibles a través del cuadro desplegable de TFA al agregar o editar un dominio o realm de autenticación. Cuando un dominio tiene TFA habilitado, se convierte en un requisito y solo los usuarios con TFA configurado podrán iniciar sesión.

Actualmente hay dos métodos disponibles:

Time-based OATH (TOTP)

Esto utiliza el algoritmo estándar HMAC-SHA1, donde la hora actual se codifica con la clave configurada por el usuario. Los parámetros de tiempo transcurrido y longitud de la contraseña son configurables.

Un usuario puede tener varias claves configuradas (separadas por espacios) y las claves se pueden especificar en Base32 (RFC3548) o notación hexadecimal.

Proxmox VE proporciona una herramienta de generación de claves (oathkeygen) que imprime una clave aleatoria en notación Base32, que se puede usar directamente con varias herramientas OTP, como la herramienta de línea de comandos oathtool, o en Android Google Authenticator, Authy, FreeOTP, andOTP o aplicaciones similares. 

OTP de YubiKey

Para autenticarse a través de una YubiKey, se debe configurar una ID de API de Yubico, una CLAVE de API y una URL del servidor de validación, y los usuarios deben tener una YubiKey disponible. Para obtener la ID de clave de una YubiKey, puede activar la YubiKey una vez después de conectarla a través de USB y copiar los primeros 12 caracteres de la contraseña ingresada en el campo de ID de clave del usuario.

Consulta la documentación de YubiKey OTP para saber cómo utilizar YubiCloud o alojar t propio servidor de verificación.

Límites y bloqueo de la autenticación de dos factores

Un segundo factor está destinado a proteger a los usuarios si su contraseña se filtra o se adivina de alguna manera. Sin embargo, algunos factores aún podrían romperse mediante la fuerza bruta. Por este motivo, los usuarios quedarán bloqueados después de demasiados intentos fallidos de inicio de sesión del segundo factor.

Para TOTP, 8 intentos fallidos desactivarán los factores TOTP del usuario. Se desbloquean al iniciar sesión con una clave de recuperación. Si TOTP era el único factor disponible, se requiere la intervención del administrador y se recomienda encarecidamente solicitar al usuario que cambie su contraseña de inmediato.

Dado que FIDO2/Webauthn y las claves de recuperación son menos susceptibles a ataques de fuerza bruta, el límite es mayor (100 intentos), pero todos los segundos factores se bloquean durante una hora cuando se exceden.

Un administrador puede desbloquear la autenticación de dos factores de un usuario en cualquier momento a través de la lista de usuarios en la interfaz de usuario o mediante el siguiente comando:

 pveum user tfa unlock etaboada@pve

Autenticación TOTP configurada por el usuario

Los usuarios pueden optar por habilitar TOTP o WebAuthn como segundo factor al iniciar sesión, a través del botón TFA en la lista de usuarios (a menos que el realm use YubiKey OTP).

Los usuarios siempre pueden agregar y usar claves de recuperación únicas. Después de abrir la ventana TFA, se presenta al usuario un cuadro de diálogo para configurar la autenticación TOTP. El campo Secreto contiene la clave, que se puede generar aleatoriamente mediante el botón Aleatorizar. Se puede agregar un nombre de emisor opcional para proporcionar información a la aplicación TOTP sobre a qué pertenece la clave. La mayoría de las aplicaciones TOTP mostrarán el nombre del emisor junto con los valores OTP correspondientes. El nombre de usuario también está incluido en el código QR de la aplicación TOTP.

Después de generar una clave, se mostrará un código QR, que se puede usar con la mayoría de las aplicaciones OTP, como FreeOTP o Authy. Luego, el usuario debe verificar la contraseña de usuario actual (a menos que haya iniciado sesión como root), así como la capacidad de usar correctamente la clave TOTP, escribiendo el valor OTP actual en el campo Código de verificación y presionando el botón Aplicar.

Captura de pantalla 2024-01-28 a las 9.42.35.png

TOTP

No se requiere configuración del servidor. Simplemente instala una aplicación TOTP en tu teléfono inteligente (por ejemplo, FreeOTP o Authy) y usa la interfaz web de Proxmox Backup Server para agregar un factor TOTP.

Captura de pantalla 2024-01-28 a las 9.41.35.png

WebAuthn

Para que WebAuthn funcione, es necesario tener dos cosas:

  1. Un certificado HTTPS confiable (por ejemplo, usando Let's Encrypt). Si bien probablemente funcione con un certificado que no sea de confianza, algunos navegadores pueden advertir o rechazar operaciones de WebAuthn si no es de confianza.
  2. Configure la configuración de WebAuthn ( Centro de datos → Opciones → Configuración de WebAuthn en la interfaz web de Proxmox VE). Esto se puede completar automáticamente en la mayoría de las configuraciones.

Una vez que se haya cumplido ambos requisitos, puedes agregar una configuración de WebAuthn en el panel Two Factor en Centro de datos → Permisos → Two Factor.

Captura de pantalla 2024-01-28 a las 9.41.48.png

Claves de recuperación

Los códigos de clave de recuperación no necesitan ninguna preparación; simplemente puedes crear un conjunto de claves de recuperación en el panel Two Factor en Centro de datos → Permisos → Two Factor.

Nota Solo puede haber un conjunto de claves de recuperación de un solo uso por usuario en cualquier momento.

Captura de pantalla 2024-01-28 a las 9.42.15.png

Configuración de Webauthn del lado del servidor

Para permitir a los usuarios utilizar la autenticación WebAuthn, es necesario utilizar un dominio válido con un certificado SSL válido; de lo contrario, algunos navegadores pueden advertir o negarse a autenticarse por completo.

Nota ¡Cambiar la configuración de WebAuthn puede inutilizar todos los registros de WebAuthn existentes!

Esto se hace a través de /etc/pve/datacenter.cfg. Por ejemplo:

webauthn: rp=hv9.tecnocratica.net,origin=https://hv9.tecnocratica.net:8006,id=hv9.tecnocratica.net
Configuración U2F del lado del servidor

Nota Se recomienda utilizar WebAuthn en su lugar.

Para permitir a los usuarios utilizar la autenticación U2F, puede ser necesario utilizar un dominio válido con un certificado SSL válido; de lo contrario, algunos navegadores pueden imprimir una advertencia o rechazar el uso de U2F por completo. Inicialmente, es necesario configurar un AppId [1].

Nota ¡Cambiar el AppId inutilizará todos los registros U2F existentes!

Esto se hace a través de /etc/pve/datacenter.cfg. Por ejemplo:

u2f: appid=https://hv9.tecnocratica.net:8006

Para un solo nodo, AppId puede ser simplemente la dirección de la interfaz web, exactamente como se usa en el navegador, incluido https:// y el puerto, como se muestra arriba. Ten en cuenta que algunos navegadores pueden ser más estrictos que otros al hacer coincidir los AppIds.

Cuando se utilizan varios nodos, es mejor tener un servidor https independiente que proporcione un archivo appid.json, ya que parece ser compatible con la mayoría de los navegadores. Si todos los nodos usan subdominios del mismo dominio de nivel superior, puede ser suficiente usar el TLD como AppId. Sin embargo, cabe señalar que es posible que algunos navegadores no lo acepten.

Nota Un AppId incorrecto generalmente producirá un error, pero nos hemos encontrado con situaciones en las que esto no sucede, particularmente cuando se usa un AppId de dominio de nivel superior para un nodo al que se accede a través de un subdominio en Chromium. Por este motivo, se recomienda probar la configuración con varios navegadores, ya que cambiar el AppId más adelante inutilizará los registros U2F existentes.

Activando U2F como usuario

Para habilitar la autenticación U2F, abre la pestaña U2F de la ventana TFA, escribe la contraseña actual (a menos que hayas iniciado sesión como root) y presiona el botón Registrar. Si el servidor está configurado correctamente y el navegador acepta el AppId proporcionado por el servidor, aparecerá un mensaje solicitando al usuario que presione el botón en el dispositivo U2F (si es una YubiKey, la luz del botón debe encenderse y apagarse de manera constante, aproximadamente dos veces por segundo).

Es posible que los usuarios de Firefox necesiten habilitar security.webauth.u2f a través de about:config antes de poder usar un token U2F.

 

Permisos en Proxmox VE - Roles y Privilegios

Como comentamos en la gestión de usuarios y grupos en Proxmox VE, el motivo de esto era usar estas configuraciones para asignar determinados permisos a los usuarios o grupos. En este artículo, veremos los permisos disponibles.

Gestión de permisos en Proxmox VE

Para que un usuario pueda realizar una acción (como listar, modificar o eliminar partes de la configuración de una VM), el usuario debe tener los permisos adecuados.

Proxmox VE utiliza un sistema de gestión de permisos basado en roles y rutas. Una entrada en la tabla de permisos permite que un usuario, grupo o token asuma un rol específico al acceder a un objeto o ruta. Esto significa que dicha regla de acceso se puede representar como una tripleta de (ruta, usuario, rol), (ruta, grupo, rol) o (ruta, token, rol), donde el rol contiene un conjunto de acciones permitidas y el camino que representa el objetivo de estas acciones.

Roles

Un rol es simplemente una lista de privilegios. Proxmox VE viene con una serie de funciones predefinidas que satisfacen la mayoría de los requisitos.

Puedes ver el conjunto completo de roles predefinidos en la GUI.

Captura de pantalla 2024-01-28 a las 9.53.01.png

Puedes agregar nuevos roles a través de la GUI o la línea de comando.

Captura de pantalla 2024-01-28 a las 9.55.57.png

Si pulsamos en crear, podremos crear un rol nuevo.

Captura de pantalla 2024-01-28 a las 9.53.51.png

De esta forma, se pueden asignar uno o más roles predefinidnos al un rol nuevo

Captura de pantalla 2024-01-28 a las 9.54.57.png

Para agregar un rol a través de la línea de comando, puede usar la herramienta CLI pveum, por ejemplo:

pveum role add VM_Power-only --privs "VM.PowerMgmt VM.Console"
pveum role add Sys_Power-only --privs "Sys.PowerMgmt Sys.Console"

Privilegios

Un privilegio es el derecho a realizar una acción específica. Para simplificar la administración, las listas de privilegios se agrupan en roles, que luego se pueden usar en la tabla de permisos. Ten en cuenta que los privilegios no se pueden asignar directamente a usuarios y rutas sin ser parte de un rol.

Actualmente Proxmox VE admite los siguientes privilegios:

Privilegios relacionados con el nodo/sistema
Privilegios relacionados con la máquina virtual
Privilegios relacionados con el almacenamiento

Ambos Permissions.Modify y Sys.Modify deben gestionarse con cuidado, ya que permiten modificar aspectos del sistema y su configuración que son peligrosos o sensibles.


Advertencia Lee atentamente la sección sobre herencia que se detalla a continuación para comprender cómo se propagan los roles asignados (y sus privilegios) a lo largo del árbol de ACL.

Objetos y rutas

Los permisos de acceso se asignan a objetos, como máquinas virtuales, almacenamientos o grupos de recursos. Usamos rutas similares a sistemas de archivos para abordar estos objetos. Estas rutas forman un árbol natural y, opcionalmente, los permisos de niveles superiores (rutas más cortas) se pueden propagar hacia abajo dentro de esta jerarquía.

Los paths pueden tener plantillas. Cuando una llamada API requiere permisos en una ruta con plantilla, la ruta puede contener referencias a parámetros de la llamada API. Estas referencias se especifican entre llaves. Algunos parámetros se toman implícitamente del URI de la llamada API. Por ejemplo, la ruta de permiso /nodes/{node} al llamar a /nodes/mynode/status requiere permisos en /nodes/mynode, mientras que la ruta {path} en una solicitud PUT a /access/acl se refiere al parámetro de ruta del método.

Algunos ejemplos son:

Herencia

Como se mencionó anteriormente, las rutas de los objetos forman un sistema de archivos similar a un árbol, y los objetos que se encuentran en ese árbol pueden heredar los permisos (el indicador de propagación está configurado de forma predeterminada). Usamos las siguientes reglas de herencia:

Pools

Los pools se pueden utilizar para agrupar un conjunto de máquinas virtuales y almacenes de datos. Luego puedes simplemente establecer permisos en los pools (/pool/{poolid}), que heredan todos los miembros del grupo. Esta es una excelente manera de simplificar el control de acceso.

 

Proxmox API acceso con Ticket y API Tokens

Existen varias formas de acceder al API de Proxmox. Una es usando un token generado de forma temporal (ticket) que nos devuelve una llamada a nuestros Proxmox (Ya sea un Proxmox VE, un Proxmox Backup Server o un Proxmox Mail Gateway)

Un ticket es un valor de texto aleatorio firmado que incluye el usuario y la hora de creación. Los tickets están firmados por la clave de autenticación de todo el clúster que se rota una vez al día.

Además, cualquier solicitud de escritura (POST/PUT/DELETE) debe incluir un token de prevención CSRF dentro del encabezado HTTP. Los siguientes ejemplos utilizan la herramienta de línea de comando curl.

Ejemplo: obtener un nuevo ticket y el token de prevención CSRF
Advertencia, los parámetros de la línea de comando son visibles para todo el sistema; evita ejecutar lo siguiente en hosts que no sean de confianza ya que se muestran los datos de usuario y password.

curl -k -d 'username=root@pam' --data-urlencode 'password=nocopiesestepasswordquenotevaafuncionar' https://10.0.0.1:8006/api2/json/access/ticket

Esto nos devolverá en JSON como el del ejemplo que mostramos

{ 
  "data": { 
    "CSRFPreventionToken":"EDUEDUE2:IoLu1UzvOmeBOVuHf+b6QaZpxOZnPYY",  
    "ticket":"PVE:root@pam:EDUEDUE2::6to03dN5AL66ecT0VPUboLB18oxg...", 
    "username":"root@pam"
  }
}

NOTA: Los tickets tienen una duración limitada de 2 horas. Pero simplemente puede obtener un ticket nuevo pasando el ticket antiguo como contraseña al método /access/ticket antes de que expire su vida útil.

Debes pasar el ticket devuelto con una cookie a cualquier solicitud posterior

curl -k -b "PVEAuthCookie=PVE:root@pam:EDUEDUE2::6to03dN5AL66ecT0VPUboLB18oxg..." https://10.0.0.1:8006/api2/json/

Nos devolverá la información básica del api

{
  "data": [
    { "subdir": "version" },
    { "subdir": "cluster" },
    { "subdir": "nodes" },
    { "subdir": "storage" },
    { "subdir": "access" },
    { "subdir": "pools" }
  ]
}

Además, cualquier solicitud de escritura (POST, PUT, DELETE) debe incluir el encabezado CSRFPreventionToken:

curl -XDELETE -H "CSRFPreventionToken:EDUEDUE2:IoLu1UzvOmeBOVuHf+b6QaZpxOZnPYY" ......

La otra forma es mediante un API Token

API Token

Los tokens API permiten el acceso stateless (sin estado) a la mayoría de las partes de la API REST desde otro sistema, software o cliente API. Se pueden generar tokens para usuarios individuales y se les pueden otorgar permisos y fechas de vencimiento separados para limitar el alcance y la duración del acceso. Si el token API se ve comprometido, se puede revocar sin deshabilitar al usuario.

Los tokens API vienen en dos tipos básicos:

Privilegios separados: el token debe tener acceso explícito con ACL. Sus permisos efectivos se calculan cruzando los permisos de usuario y token.

Privilegios completos: los permisos del token son idénticos a los del usuario asociado.

Precaución El valor del token solo se muestra/devuelve una vez cuando se genera el token. ¡No se puede volver a recuperar a través de la API más adelante!
Para usar un token de API, establece en el encabezado HTTP la Autorización

curl -H "Authorization: PVEAPIToken=eduardo@pbs!pruebas=aaaaaaaaa-bbb-cccc-dddd-ef0123456789" https://10.0.0.1:8006/api2/json/


Usar el API de Proxmox VE

Vamos a poner algún ejemplo del uso del API de Proxmox VE

Para ello debemos de tener nuestro cookie temporal y el token de crsf

Ejemplo: Crear un contenedor LXC mediante al API de Proxmox

curl -s -D/dev/stderr -k \
    -H "$(<header)" -b "$(<cookie)" \
    -XPOST \
    -d hostname=test.tecnocratica.net \
    -d password=12345 \
    -d rootfs=localThin:4 \
    -d ostemplate=iso-templates:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst \
    -d vmid=602 \
    -d 'net0=name%3Deth0,bridge%3Dvmbr0' \
    "https://grupo10.tecnocratica.net:8006/api2/json/nodes/hv302/lxc"

Como vemos, hay múltiples acciones que podemos ejecutar en el API de Proxmox VE

En la documentación, podemos ver los diferente métodos para usar el API de Proxmox VE

https://pve.proxmox.com/pve-docs/api-viewer/index.html

Captura de pantalla 2024-01-28 a las 12.13.39.png

Navegando por cada una de las opciones, podemos ver los PUT, GET, etc de cada una.

Siguiendo el ejemplo anterior, vemos el método GET, que nos devuelve valores de una determinada máquina

Captura de pantalla 2024-01-28 a las 12.16.24.png

Para crearla, usamos el método POST, en la ruta que hemos mostrado antes del cual que crea la máquina, podemos ver los parámetros que soporta. En la imagen se muestra parte de ellos.

Captura de pantalla 2024-01-28 a las 12.17.26.png

 

Como vemos, mediante el API de Proxmox, podemos gestionar toda nuestra infraestructura y automatizarla (que es como lo hacemos en Tecnocrática) ya que de otra forma sería muy difícil gestionar miles de máquinas sin la ayuda del API para la orquestación, provisión y mantenimiento.

 

 

Pools de recursos en Proxmox VE

Al igual que existen grupos de usuarios en Proxmox VE a fin de facilitar y tener más controlado el acceso de usuarios, existe una figura denominada Pool (no confundir con un pool de ceph).

Los pools o grupos de recursos, se pueden utilizar para agrupar un conjunto de máquinas virtuales y almacenes de datos. Luego puedes simplemente establecer permisos en los grupos (/pool/{poolid}), que heredan todos los miembros del grupo. Esta es una excelente manera de simplificar el control de acceso.

Creación de un pool

Para crear un pool, en la sección de Datastore de nuestro Proxmox, o cluster de Proxmox, simplemente buscaremos en la opción de menú permisos (permissions) y al desplegarla, nos aparecerá la opción de Pools

Captura de pantalla 2024-02-01 a las 14.29.25.png

Ahora en la parte derecha arriba, tenemos la opción crear

Captura de pantalla 2024-02-01 a las 14.31.52.png

Si pulsamos en crear, aparecerá la opción de proporcionar un nombre y un comentario al pool

Captura de pantalla 2024-02-01 a las 14.32.01.png

Gestión de Pools

Una vez que se ha creado un Pool, nos aparecerá al final en la sección Datacenter en la vista de servers (Server View)

Captura de pantalla 2024-02-01 a las 14.34.23.png

En la sección de Resource Pool en (Folder view)

Captura de pantalla 2024-02-01 a las 14.35.38.png

o bien al principio en Pool View

Captura de pantalla 2024-02-01 a las 14.35.28.png

Seleccionamos la opción de pools y nos aparecerán los pools de Proxmox que hemos creado. En el summary, veremos al información del pool.

Captura de pantalla 2024-02-01 a las 14.37.47.png

En members, veremos los recursos del pool (Máquinas virtuales y almacenamiento)

Captura de pantalla 2024-02-01 a las 14.39.21.png

En el apartado permissions, veremos los usuarios, grupos y tokens de API que tienen acceso al pool, así como el tipo o nivel de acceso, tal y como contamos en este artículo

Captura de pantalla 2024-02-01 a las 14.39.57.png