lae.proxmox

Instala y configura Proxmox Virtual Environment 6.x/7.x/8.x en servidores Debian.

Este rol te permite desplegar y gestionar instalaciones PVE de nodo único y clústeres PVE (3 o más nodos) en Debian Buster (10) y Bullseye (11). Con este rol puedes configurar lo siguiente:

• Definiciones de PVE RBAC (roles, grupos, usuarios y listas de control de acceso)
• Definiciones de Almacenamiento PVE
• datacenter.cfg
• Certificados HTTPS para la interfaz web de Proxmox (puedes traer los tuyos)
• Selección de repositorio PVE (por ejemplo, pve-no-subscription o pve-enterprise)
• Módulos de watchdog (IPMI y NMI) con configuración aplicable de pve-ha-manager
• Configuración del módulo ZFS y correos electrónicos de notificación ZED

Con el clustering habilitado, este rol hace (o te permite hacer) lo siguiente:

• Asegurar que todos los hosts puedan conectarse entre sí como root a través de SSH
• Inicializar un nuevo clúster PVE (o posiblemente adoptar uno existente)
• Crear o agregar nuevos nodos a un clúster PVE
• Configurar Ceph en un clúster PVE
• Crear y gestionar grupos de alta disponibilidad

Soporte/Contribuciones

Para soporte o si deseas contribuir a este rol y necesitas orientación, siéntete libre de unirte a este servidor de Discord: https://discord.gg/cjqr6Fg. Ten en cuenta que esta es una invitación temporal, así que tendrás que esperar a que @lae te asigne un rol, de lo contrario, Discord te eliminará del servidor cuando cierres sesión.

Inicio Rápido

El objetivo principal de este rol es configurar y gestionar un clúster Proxmox VE (ver ejemplo de playbook), sin embargo, este rol también puede usarse para instalar rápidamente servidores Proxmox de nodo único.

Asumo que ya tienes Ansible instalado. Necesitarás usar una máquina externa a la que estés instalando Proxmox (principalmente debido al reinicio en medio de la instalación, aunque más adelante podría manejar esto de manera diferente para este caso de uso).

Copia el siguiente playbook a un archivo llamado install_proxmox.yml:

- hosts: all
  become: True
  roles:
    - role: geerlingguy.ntp
      vars:
        ntp_manage_config: true
        ntp_servers:
          - clock.sjc.he.net
          - clock.fmt.he.net
          - clock.nyc.he.net
    - role: lae.proxmox
      vars:
        - pve_group: all
        - pve_reboot_on_kernel_update: true

Instala este rol y un rol para configurar NTP:

ansible-galaxy install lae.proxmox geerlingguy.ntp

Ahora puedes realizar la instalación:

ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER

Si tu SSH_USER tiene una contraseña sudo, pasa la opción -K al comando anterior. Si también te autenticas en el host con contraseña en lugar de con autenticación de clave pública, pasa la opción -k (asegúrate de tener sshpass instalado también). Puedes establecer esas variables antes de ejecutar el comando o simplemente reemplazarlas. Toma en cuenta que la coma es importante, ya que se espera una lista (de lo contrario, intentará buscar un archivo que contenga una lista de hosts).

Una vez completado, deberías poder acceder a tu instancia de Proxmox VE en https://$SSH_HOST_FQDN:8006.

Desplegando un clúster PVE 8.x completo

Crea un nuevo directorio de playbook. Llamamos al nuestro lab-cluster. Nuestro playbook eventualmente se verá así, pero el tuyo no tiene que seguir todos los pasos:

lab-cluster/
├── files
│   └── pve01
│       ├── lab-node01.local.key
│       ├── lab-node01.local.pem
│       ├── lab-node02.local.key
│       ├── lab-node02.local.pem
│       ├── lab-node03.local.key
│       └── lab-node03.local.pem
├── group_vars
│   ├── all
│   └── pve01
├── inventory
├── roles
│   └── requirements.yml
├── site.yml
└── templates
    └── interfaces-pve01.j2

Lo primero que notarás es que tenemos un montón de archivos .key y .pem. Estos son claves privadas y certificados SSL que este rol usará para configurar la interfaz web de Proxmox en todos los nodos. Sin embargo, no son necesarios si deseas seguir usando los certificados firmados por la CA que Proxmox configura internamente. A menudo, puedes usar Ansible Vault para cifrar las claves privadas, por ejemplo:

ansible-vault encrypt files/pve01/*.key

Esto requeriría que pases la contraseña de Vault al ejecutar el playbook.

Primero, especifiquemos nuestros hosts del clúster. Nuestro archivo inventory podría verse así:

[pve01]
lab-node01.local
lab-node02.local
lab-node03.local

Podrías tener múltiples clústeres, así que es buena idea tener un grupo para cada clúster. Ahora, especifiquemos nuestras dependencias de roles en roles/requirements.yml:

---
- src: geerlingguy.ntp
- src: lae.proxmox

Necesitamos un rol NTP para configurarlo, así que utilizamos el rol de Jeff Geerling para ello. No lo necesitarías si ya tienes configurado NTP o tienes un método diferente para configurarlo.

Ahora, establezcamos algunas variables de grupo. Primero, creemos group_vars/all para establecer las variables relacionadas con NTP:

---
ntp_manage_config: true
ntp_servers:
  - lab-ntp01.local iburst
  - lab-ntp02.local iburst

Por supuesto, reemplaza esos servidores NTP con los que prefieras.

Ahora para el cuerpo de tu playbook, las variables de grupo de pve01. Crea un archivo group_vars/pve01, agrega lo siguiente y modifícalo según tu entorno.

---
pve_group: pve01
pve_watchdog: ipmi
pve_ssl_private_key: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.key') }}"
pve_ssl_certificate: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.pem') }}"
pve_cluster_enabled: yes
pve_groups:
  - name: ops
    comment: Equipo de Operaciones
pve_users:
  - name: admin1@pam
    email: [email protected]
    firstname: Admin
    lastname: Usuario 1
    groups: [ "ops" ]
  - name: admin2@pam
    email: [email protected]
    firstname: Admin
    lastname: Usuario 2
    groups: [ "ops" ]
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "ops" ]
pve_storages:
  - name: localdir
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /plop
    maxfiles: 4
pve_ssh_port: 22

interfaces_template: "interfaces-{{ pve_group }}.j2"

pve_group se establece en el nombre del grupo de nuestro clúster, pve01 - se utilizará para asegurar que todos los hosts de ese grupo puedan conectarse entre sí y estén agrupados. Ten en cuenta que el nombre del clúster PVE se establecerá en este nombre de grupo, a menos que se especifique otra cosa mediante pve_cluster_clustername. Si dejas esto sin definir, se predeterminará a proxmox.

Aquí, pve_watchdog habilita el soporte para el watchdog IPMI y configura el administrador de HA de PVE para usarlo. Déjalo indefinido si no deseas configurarlo.

pve_ssl_private_key y pve_ssl_certificate apuntan a los certificados SSL para el clúster PVE. Aquí se utiliza una búsqueda de archivo para leer el contenido de un archivo en el playbook, por ejemplo, files/pve01/lab-node01.key. También puedes utilizar variables de host en lugar de archivos, si lo prefieres.

pve_cluster_enabled habilita al rol para realizar todas las tareas de gestión de clúster. Esto incluye crear un clúster si no existe o agregar nodos al clúster existente. Hay verificaciones para asegurarse de no mezclar nodos que ya están en clústeres existentes con diferentes nombres.

pve_groups, pve_users y pve_acls autorizan a algunos usuarios de UNIX locales (deben existir previamente) para acceder a PVE y les otorgan el rol de Administrador como parte del grupo ops. Consulta la sección Gestión de Usuarios y ACL para más información.

pve_storages permite crear diferentes tipos de almacenamiento y configurarlos. El backend debe ser compatible con Proxmox. Consulta la sección Gestión de Almacenamiento para más detalles.

pve_ssh_port te permite cambiar el puerto SSH. Si tu SSH escucha en un puerto diferente al 22, por favor establece esta variable. Si un nuevo nodo se une al clúster, el clúster PVE necesita comunicarse una vez a través de SSH.

pve_manage_ssh (true por defecto) te permite deshabilitar cualquier cambio que este módulo realice en la configuración de tu servidor SSH. Esto es útil si usas otro rol para gestionar tu servidor SSH. Ten en cuenta que establecer esto en false no está oficialmente soportado, tendrás que replicar los cambios que normalmente se hacen en ssh_cluster_config.yml y pve_add_node.yml.

interfaces_template se establece en la ruta de una plantilla que utilizaremos para configurar la red en estas máquinas Debian. Esto es solo necesario si deseas gestionar la red desde Ansible en lugar de manualmente o a través de cada host en PVE. Probablemente deberías estar familiarizado con Ansible antes de hacer esto, ya que tu método puede involucrar establecer variables de host para las direcciones IP de cada host, etc.

Vamos a sacar esa plantilla de interfaz del camino. Siéntete libre de omitir este archivo (y dejarlo indefinido en group_vars/pve01) de lo contrario. Aquí hay una que utilizo:

# {{ ansible_managed }}
auto lo
iface lo inet loopback

allow-hotplug enp2s0f0
iface enp2s0f0 inet manual

auto vmbr0
iface vmbr0 inet static
    address {{ lookup('dig', ansible_fqdn) }}
    gateway 10.4.0.1
    netmask 255.255.255.0
    bridge_ports enp2s0f0
    bridge_stp off
    bridge_fd 0

allow-hotplug enp2s0f1
auto enp2s0f1
iface enp2s0f1 inet static
    address {{ lookup('dig', ansible_hostname + "-clusternet.local") }}
    netmask 255.255.255.0

Es posible que no estés familiarizado con la búsqueda dig, pero básicamente estamos haciendo una búsqueda de registro A para cada máquina (por ejemplo, lab-node01.local) para la primera interfaz (y configurándola como un puente que utilizaremos para interfaces de VM), y luego otra búsqueda ligeramente modificada para la red de "clustering" que podríamos usar para Ceph ("lab-node01-clusternet.local"). Por supuesto, la tuya podría verse completamente diferente, especialmente si utilizas bonding, tres redes diferentes para gestión/corosync, almacenamiento y tráfico de VM, etc.

Finalmente, escribamos nuestro playbook. site.yml se verá algo así:

---
- hosts: all
  become: True
  roles:
    - geerlingguy.ntp

# Deja esto fuera si no vas a modificar la red a través de Ansible
- hosts: pve01
  become: True
  serial: 1
  tasks:
    - name: Instalar bridge-utils
      apt:
        name: bridge-utils

    - name: Configurar /etc/network/interfaces
      template:
        src: "{{ interfaces_template }}"
        dest: /etc/network/interfaces
      register: _configure_interfaces

    - block:
      - name: Reiniciar por cambios en la red
        shell: "sleep 5 && shutdown -r now 'Se encontraron cambios en la red, reiniciando'"
        async: 1
        poll: 0

      - name: Esperar a que el servidor vuelva a estar en línea
        wait_for_connection:
          delay: 15
      when: _configure_interfaces is changed

- hosts: pve01
  become: True
  roles:
    - lae.proxmox

Básicamente, ejecutamos el rol de NTP en todos los hosts (es posible que desees agregar algunas máquinas que no sean Proxmox), configuramos la red en pve01 con nuestra red de clúster separada y diseño de puente, reiniciamos para hacer que esos cambios entren en vigor, y luego ejecutamos este rol Proxmox contra los hosts para configurar un clúster.

En este punto, nuestro playbook está listo y podemos ejecutarlo.

Asegúrate de que los roles y dependencias estén instalados:

ansible-galaxy install -r roles/requirements.yml --force
pip install jmespath dnspython

jmespath es requerido para algunas de las tareas relacionadas con el clustering. dnspython solo es necesario si estás usando una búsqueda dig, que probablemente no estarás si omitiste la configuración de red. Pasamos --force a ansible-galaxy aquí para que los roles se actualicen a sus versiones más recientes si ya están instalados.

Ahora ejecuta el playbook:

ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'

El -e '{"pve_reboot_on_kernel_update": true}' debería ejecutarse principalmente la primera vez que haces la configuración del clúster Proxmox, ya que reiniciará el servidor para arrancar con un kernel PVE. Las ejecuciones posteriores deberían omitir esto, ya que deseas reiniciar secuencialmente los servidores después de que el clúster esté en funcionamiento.

Para especificar un usuario particular, usa -u root (reemplazando root), y si necesitas proporcionar contraseñas, usa -k para la contraseña SSH y/o -K para la contraseña sudo. Por ejemplo:

ansible-playbook -i inventory site.yml -K -u admin1

Esto pedirá una contraseña sudo, luego iniciará sesión en el usuario admin1 (usando autenticación de clave pública - añade -k para contraseña) y ejecutará el playbook.

¡Eso es todo! Ahora deberías tener un clúster Proxmox completamente desplegado. Puede que desees crear almacenamiento Ceph en él después (consulta Ceph para más info) y posiblemente otras tareas, pero la parte difícil está mayormente completa.

Ejemplo de Playbook

Esto configurará los hosts en el grupo pve01 como un solo clúster, así como reiniciará las máquinas si el kernel ha sido actualizado. (Solo se recomienda establecer esta bandera durante la instalación; los reinicios durante la operación deben ocurrir de forma secuencial durante un período de mantenimiento). También habilitará el watchdog IPMI.

- hosts: pve01
  become: True
  roles:
    - role: geerlingguy.ntp
        ntp_manage_config: true
        ntp_servers:
          - clock.sjc.he.net
          - clock.fmt.he.net
          - clock.nyc.he.net
    - role: lae.proxmox
        pve_group: pve01
        pve_cluster_enabled: yes
        pve_reboot_on_kernel_update: true
        pve_watchdog: ipmi

Variables del Rol

[variable]: [default] #[descripcion/purpose]
pve_group: proxmox # grupo de hosts que contiene los hosts Proxmox que se agruparán
pve_repository_line: "deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription" # configuración del repositorio apt - cambia a enterprise si es necesario (aunque TODO se puede requerir una configuración adicional)
pve_remove_subscription_warning: true # parchea los mensajes de advertencia de suscripción en proxmox si estás usando la edición comunitaria
pve_extra_packages: [] # Cualquier paquete adicional que desees instalar, por ejemplo, ngrep
pve_run_system_upgrades: false # Permitir que el rol realice actualizaciones del sistema
pve_run_proxmox_upgrades: true # Permitir que el rol realice actualizaciones de Proxmox VE
pve_check_for_kernel_update: true # Ejecuta un script en el host para comprobar las versiones del kernel
pve_reboot_on_kernel_update: false # Si se establece en true, reiniciará automáticamente la máquina en las actualizaciones del kernel
pve_reboot_on_kernel_update_delay: 60 # Número de segundos para esperar antes y después de un proceso de reinicio para proceder con la siguiente tarea en modo de clúster
pve_remove_old_kernels: true # Actualmente elimina el kernel del repositorio principal de Debian
pve_pcie_passthrough_enabled: false # Establece esto en true para habilitar el paso de PCIe.
pve_iommu_passthrough_mode: false # Establece esto en true para permitir que las VMs omitan la traducción DMA. Esto podría aumentar el rendimiento para el paso de IOMMU.
pve_iommu_unsafe_interrupts: false # Establece esto en true si tu sistema no soporta reenvío de interrupciones.
pve_mediated_devices_enabled: false # Establece esto en true si tu dispositivo soporta gtv-g y deseas habilitar la funcionalidad dividida.
pve_pcie_ovmf_enabled: false # Establece esto en true para habilitar el paso de PCI para GPU OVMF.
pve_pci_device_ids: [] # Lista de IDs de dispositivo pci (ver https://pve.proxmox.com/wiki/Pci_passthrough#GPU_Passthrough).
pve_vfio_blacklist_drivers: [] # Lista de controladores de dispositivos a excluir del host Proxmox (ver https://pve.proxmox.com/wiki/PCI(e)_Passthrough).
pve_pcie_ignore_msrs: false # Establece esto en true si se pasa a la máquina Windows para evitar que la VM se bloquee.
pve_pcie_report_msrs: true # Establece esto en false para evitar que el sistema dmesg registre informes de fallas msrs.
pve_watchdog: none # Establece esto en "ipmi" si deseas configurar un watchdog de hardware. Proxmox usa un watchdog de software (nmi_watchdog) por defecto.
pve_watchdog_ipmi_action: power_cycle # Puede ser uno de "reset", "power_cycle" y "power_off".
pve_watchdog_ipmi_timeout: 10 # Número de segundos que debe esperar el watchdog
pve_zfs_enabled: no # Especifica si se deben instalar y configurar los paquetes ZFS
# pve_zfs_options: "" # parámetros modprobe que se pasan al módulo zfs al inicio/modprobe
# pve_zfs_zed_email: "" # Debe establecerse en un correo electrónico para recibir notificaciones de ZFS
pve_zfs_create_volumes: [] # Lista de volúmenes ZFS a crear (para usar como Almacenamientos PVE). Ver sección sobre Gestión de Almacenamiento.
pve_ceph_enabled: false # Especifica si se deben instalar y configurar los paquetes Ceph. Ver a continuación un ejemplo de configuración.
pve_ceph_repository_line: "deb http://download.proxmox.com/debian/ceph-pacific bullseye main" # configuración del repositorio apt. Se establecerá automáticamente para 6.x y 7.x (más información: https://pve.proxmox.com/wiki/Package_Repositories)
pve_ceph_network: "{{ (ansible_default_ipv4.network +'/'+ ansible_default_ipv4.netmask) | ansible.utils.ipaddr('net') }}" # Red pública Ceph
# pve_ceph_cluster_network: "" # Opcional, si la red de clúster ceph es diferente de la red pública (ver https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_install_wizard)
pve_ceph_nodes: "{{ pve_group }}" # Grupo de hosts que contiene todos los nodos Ceph
pve_ceph_mon_group: "{{ pve_group }}" # Grupo de host que contiene todos los hosts de monitor Ceph
pve_ceph_mgr_group: "{{ pve_ceph_mon_group }}" # Grupo de host que contiene todos los hosts administradores Ceph
pve_ceph_mds_group: "{{ pve_group }}" # Grupo de host que contiene todos los hosts de servidor de metadatos Ceph
pve_ceph_osds: [] # Lista de discos OSD
pve_ceph_pools: [] # Lista de grupos que crear
pve_ceph_fs: [] # Lista de sistemas de archivos CephFS a crear
pve_ceph_crush_rules: [] # Lista de reglas CRUSH a crear
# pve_ssl_private_key: "" # Debe establecerse en el contenido de la clave privada a utilizar para HTTPS
# pve_ssl_certificate: "" # Debe establecerse en el contenido del certificado a utilizar para HTTPS
pve_roles: [] # Se añaden más roles con privilegios específicos. Ver sección sobre Gestión de Usuarios.
pve_groups: [] # Lista de definiciones de grupo para gestionar en PVE. Ver sección sobre Gestión de Usuarios.
pve_users: [] # Lista de definiciones de usuario para gestionar en PVE. Ver sección sobre Gestión de Usuarios.
pve_storages: [] # Lista de almacenes para gestionar en PVE. Ver sección sobre Gestión de Almacenamiento.
pve_datacenter_cfg: {} # Diccionario para configurar el archivo de configuración datacenter.cfg de PVE.
pve_domains_cfg: [] # Lista de reinos para usar como fuentes de autenticación en el archivo de configuración domains.cfg de PVE.
pve_no_log: false # Establece esto en true en producción para evitar que se filtren las credenciales de almacenamiento en los registros de ejecución. (puede usarse en otras tareas en el futuro)

Para habilitar el clustering con este rol, configura las siguientes variables adecuadamente:

pve_cluster_enabled: no # Establece esto en yes para configurar hosts para agruparse
pve_cluster_clustername: "{{ pve_group }}" # Debe establecerse en el nombre del clúster PVE
pve_manage_hosts_enabled : yes # Establece esto en no para NO configurar el archivo hosts (caso de usar vpn y el archivo hosts ya está configurado)

Las siguientes variables se utilizan para proporcionar información de red a corosync. Se conocen como ring0_addr/ring1_addr o link0_addr/link1_addr, dependiendo de la versión de PVE. Deben ser direcciones IPv4 o IPv6. También puedes configurar la prioridad de estas interfaces para indicarle a corosync qué interfaz debe manejar el tráfico del clúster (números más bajos indican mayor prioridad). Para más información, consulta el capítulo Cluster Manager en la documentación de PVE.

# pve_cluster_addr0: "{{ se predetermina a la interfaz ipv4 o ipv6 por defecto si se detecta }}"
# pve_cluster_addr1: "dirección IP o nombre de otra interfaz"
# pve_cluster_addr0_priority: 255
# pve_cluster_addr1_priority: 0

Puedes establecer opciones en el archivo de configuración datacenter.cfg:

pve_datacenter_cfg:
  keyboard: en-us

También puedes configurar grupos del administrador de alta disponibilidad:

pve_cluster_ha_groups: [] # Lista de grupos de HA a crear en PVE.

Este ejemplo crea un grupo "lab_node01" para los recursos asignados al host lab-node01:

pve_cluster_ha_groups:
  - name: lab_node01
    comment: "Mi grupo HA"
    nodes: "lab-node01"
    nofailback: 0
    restricted: 0

Todas las opciones de configuración soportadas en el archivo datacenter.cfg están documentadas en la sección del manual datacenter.cfg.

Para que el recargado en vivo de las interfaces de red funcione a través de la interfaz web de PVE, necesitas instalar el paquete ifupdown2. Ten en cuenta que esto eliminará ifupdown. Puedes especificar esto usando la variable del rol pve_extra_packages.

Puedes establecer reinos / dominios como fuentes de autenticación en el archivo de configuración domains.cfg. Si este archivo no está presente, solo están disponibles los reinos Linux PAM y servidor de autenticación Proxmox VE. Los tipos soportados son pam, pve, ad y ldap. Es posible sincronizar automáticamente usuarios y grupos para reinos basados en LDAP (LDAP y Active Directory de Microsoft) con sync: true. Un reino debe tener la propiedad default: 1 para marcarlo como predeterminado:

pve_domains_cfg:
  - name: pam
    type: pam
    attributes:
      comment: Autenticación estándar de Linux PAM
  - name: pve
    type: pve
    attributes:
      comment: Servidor de autenticación Proxmox VE
  - name: ad
    type: ad
    attributes:
      comment: Autenticación de Active Directory
      domain: tu_dominio.com
      server1: dc01.tu_dominio.com
      default: 1
      secure: 1
      server2: dc02.tu_dominio.com
  - name: ldap
    type: ldap
    sync: true
    attributes:
      comment: Autenticación LDAP
      base_dn: CN=Users,dc=tu_dominio,dc=com
      bind_dn: "uid=svc-reader,CN=Users,dc=tu_dominio,dc=com"
      bind_password: "{{ secret_ldap_svc_reader_password }}"
      server1: ldap1.tu_dominio.com
      user_attr: uid
      secure: 1
      server2: ldap2.tu_dominio.com

Dependencias

Este rol no instala NTP, así que debes configurarlo tú mismo, por ejemplo, con el rol geerlingguy.ntp como se presenta en el ejemplo de playbook.

Cuando el clustering está habilitado, este rol usa el filtro json_query, que requiere que la biblioteca jmespath esté instalada en tu host de control. Puedes instalarlo usando pip install jmespath o instalarlo a través del gestor de paquetes de tu distribución, por ejemplo, apt-get install python-jmespath.

Gestión de Usuarios y ACL

Puedes usar este rol para gestionar usuarios y grupos dentro de Proxmox VE (tanto en implementaciones de servidor único como en despliegues en clúster). Aquí hay algunos ejemplos.

pve_groups:
  - name: Admins
    comment: Administradores de este clúster PVE
  - name: api_users
  - name: test_users
pve_users:
  - name: root@pam
    email: [email protected]
  - name: lae@pam
    email: [email protected]
    firstname: Musee
    lastname: Ullah
    groups: [ "Admins" ]
  - name: pveapi@pve
    password: "Proxmox789"
    groups:
      - api_users
  - name: testapi@pve
    password: "Test456"
    enable: no
    groups:
      - api_users
      - test_users
  - name: tempuser@pam
    expire: 1514793600
    groups: [ "test_users" ]
    comment: "Usuario temporal configurado para expirar el 1 de enero de 2018 00:00:00 PST"
    email: [email protected]
    firstname: Test
    lastname: Usuario

Consulta library/proxmox_user.py enlace y library/proxmox_group.py enlace para la documentación de los módulos.

Para gestionar roles y ACLs, se emplea un módulo similar, pero la principal diferencia es que la mayoría de los parámetros solo aceptan listas (sujeto a cambios):

pve_roles:
  - name: Monitoring
    privileges:
      - "Sys.Modify"
      - "Sys.Audit"
      - "Datastore.Audit"
      - "VM.Monitor"
      - "VM.Audit"
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "Admins" ]
  - path: /pools/testpool
    roles: [ "PVEAdmin" ]
    users:
      - pveapi@pve
    groups:
      - test_users

Consulta library/proxmox_role.py enlace y library/proxmox_acl.py enlace para la documentación de los módulos.

Gestión de Almacenamiento

Puedes usar este rol para gestionar el almacenamiento dentro de Proxmox VE (tanto en implementaciones de servidor único como en despliegues de clúster). Por ahora, los únicos tipos soportados son dir, rbd, nfs, cephfs, lvm, lvmthin, zfspool, btrfs, cifs y pbs. Aquí hay algunos ejemplos.

pve_storages:
  - name: dir1
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /ploup
    disable: no
    maxfiles: 4
  - name: ceph1
    type: rbd
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    username: admin
    pool: rbd
    krbd: yes
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: nfs1
    type: nfs
    content: [ "images", "iso" ]
    server: 192.168.122.2
    export: /data
  - name: lvm1
    type: lvm
    content: [ "images", "rootdir" ]
    vgname: vg1
  - name: lvmthin1
    type: lvmthin
    content: [ "images", "rootdir" ]
    vgname: vg2
    thinpool: data
  - name: cephfs1
    type: cephfs
    content: [ "snippets", "vztmpl", "iso" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: pbs1
    type: pbs
    content: [ "backup" ]
    server: 192.168.122.2
    username: user@pbs
    password: PBSPassword1
    datastore: main
    namespace: Top/something # Opcional
  - name: zfs1
    type: zfspool
    content: [ "images", "rootdir" ]
    pool: rpool/data
    sparse: true
  - name: btrfs1
    type: btrfs
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    path: /mnt/proxmox_storage
    is_mountpoint: true
  - name: cifs1
    server: cifs-host.dominio.tld
    type: cifs
    content: [ "snippets", "vztmpl", "iso" ]
    share: sharename
    subdir: /subdir
    username: user
    password: supersecurepass
    domain: addomain.tld

Consulta https://pve.proxmox.com/pve-docs/api-viewer/index.html para más información.

Actualmente, el tipo zfspool solo puede usarse para los contenidos images y rootdir. Si deseas almacenar los otros tipos de contenido en un volumen ZFS, debes especificarlos con el tipo dir, ruta /<POOL>/<VOLUME> y agregar una entrada en pve_zfs_create_volumes. Este ejemplo añade un almacenamiento iso en un pool ZFS:

pve_zfs_create_volumes:
  - rpool/iso
pve_storages:
  - name: iso
    type: dir
    path: /rpool/iso
    content: [ "iso" ]

Consulta library/proxmox_storage.py enlace para la documentación del módulo.

Configuración de Ceph

Esta sección podría mejorar un poco. Si usas activamente este rol para gestionar tu clúster Ceph de PVE, no dudes en ampliar esta sección y abrir una pull request. Consulta el issue #68.

La gestión de Ceph en PVE con este rol es experimental. Si bien los usuarios han utilizado con éxito este rol para desplegar Ceph en PVE, no está completamente probado en CI (debido a la falta de dispositivos de bloque utilizables para usar como OSD en Travis CI). Por favor, despliega un entorno de prueba con tu configuración primero antes de pasar a producción y reporta cualquier problema que encuentres.

Este rol puede configurar el sistema de almacenamiento Ceph en tus hosts Proxmox. Las siguientes definiciones muestran algunas de las configuraciones que son posibles.

pve_ceph_enabled: true
pve_ceph_network: '172.10.0.0/24'
pve_ceph_cluster_network: '172.10.1.0/24'
pve_ceph_nodes: "ceph_nodes"
pve_ceph_osds:
  # OSD con todo en el mismo dispositivo
  - device: /dev/sdc
  # OSD con block.db/WAL en otro dispositivo
  - device: /dev/sdd
    block.db: /dev/sdb1
  # OSD cifrado con todo en el mismo dispositivo
  - device: /dev/sdc
    encrypted: true
  # OSD cifrado con block.db/WAL en otro dispositivo
  - device: /dev/sdd
    block.db: /dev/sdb1
    encrypted: true
# Reglas Crush para diferentes clases de almacenamiento
# Por defecto, 'type' se establece en host, puedes encontrar tipos válidos en
# (https://docs.ceph.com/en/latest/rados/operations/crush-map/)
# listados bajo 'TYPES AND BUCKETS'
pve_ceph_crush_rules:
  - name: replicated_rule
    type: osd # Este es un ejemplo de cómo puedes sobrescribir una regla preexistente
  - name: ssd
    class: ssd
    type: osd
    min-size: 2
    max-size: 8
  - name: hdd
    class: hdd
    type: host
# 2 pools Ceph para discos de VM que también se definirán como almacenes Proxmox
# Usando diferentes reglas CRUSH
pve_ceph_pools:
  - name: ssd
    pgs: 128
    rule: ssd
    application: rbd
    storage: true
# Este pool Ceph usa valores de tamaño/redundancia personalizados
  - name: hdd
    pgs: 32
    rule: hdd
    application: rbd
    storage: true
    size: 2
    min-size: 1
# Este pool Ceph usa modo de escalado automático personalizado: "off" | "on" | "warn"> (predeterminado = "warn")
  - name: vm-storage
    pgs: 128
    rule: replicated_rule
    application: rbd
    autoscale_mode: "on"
    storage: true
pve_ceph_fs:
# Un sistema de archivos CephFS no definido como almacenamiento de Proxmox
  - name: backup
    pgs: 64
    rule: hdd
    storage: false
    mountpoint: /srv/proxmox/backup

pve_ceph_network por defecto usa el filtro ansible.utils.ipaddr, que requiere que la biblioteca netaddr esté instalada y utilizable por tu controlador Ansible.

pve_ceph_nodes por defecto utiliza pve_group, este parámetro permite especificar en qué nodos instalar Ceph (por ejemplo, si no deseas instalar Ceph en todos tus nodos).

pve_ceph_osds por defecto crea volúmenes ceph sin cifrar. Para usar volúmenes cifrados, el parámetro encrypted debe establecerse por unidad en true.

Passthrough PCIe

Este rol puede configurarse para permitir el paso de dispositivos PCI del host Proxmox a las VMs. Esta funcionalidad no está habilitada por defecto ya que no todas las placas madre y CPU soportan esta característica. Para habilitar el passthrough, la CPU de los dispositivos debe soportar virtualización por hardware (VT-d para sistemas basados en Intel y AMD-V para sistemas basados en AMD). Consulta los manuales de todos los componentes para determinar si esta función es soportada o no. Las convenciones de nombres variarán, pero generalmente se refieren como IOMMU, VT-d, o AMD-V.

Al habilitar esta función, dispositivos dedicados (como una GPU o dispositivos USB) pueden ser pasados a las VMs. Junto con dispositivos dedicados, varios dispositivos integrados como los GPU integrados de Intel o AMD también son capaces de ser pasados a las VMs.

Algunos dispositivos pueden aprovechar el uso mediado. Los dispositivos mediados pueden pasarse a varias VMs para compartir recursos, mientras siguen siendo utilizables por el sistema host. La división de dispositivos no siempre está soportada y debería validarse antes de habilitarse para evitar errores. Consulta el manual del dispositivo que deseas pasar para determinar si el dispositivo es capaz de un uso mediado (En este momento, este rol solo soporta GVT-g; SR-IOV no es actualmente soportado y debe habilitarse manualmente después de completar el rol).

La siguiente es una configuración de ejemplo que habilita el passthrough PCIe:

pve_pcie_passthrough_enabled: true
pve_iommu_passthrough_mode: true
pve_iommu_unsafe_interrupts: false
pve_mediated_devices_enabled: false
pve_pcie_ovmf_enabled: false
pve_pci_device_ids:
  - id: "10de:1381"
  - id: "10de:0fbc"
pve_vfio_blacklist_drivers:
  - name: "radeon"
  - name: "nouveau"
  - name: "nvidia"
pve_pcie_ignore_msrs: false
pve_pcie_report_msrs: true

pve_pcie_passthrough_enabled es requerido para usar cualquier funcionalidad de passthrough PCIe. Sin esto habilitado, se ignorarán todos los demás campos relacionados con PCIe.

pve_iommu_passthrough_mode habilitar el modo de passthrough IOMMU podría aumentar el rendimiento del dispositivo. Al habilitar esta función, se permite que las VMs omitan la traducción DMA al hardware IOMMU que normalmente realizaría el hipervisor.

pve_iommu_unsafe_interrupts debe habilitarse para permitir el passthrough PCI si tu sistema no soporta el reenvío de interrupciones. Puedes comprobar si el dispositivo soporta el reenvío de interrupciones usando dmesg | grep 'remapping'. Si ves una de las siguientes líneas:

• "AMD-Vi: Interrupt remapping enabled"
• "DMAR-IR: Enabled IRQ remapping in x2apic mode" ('x2apic' puede ser diferente en CPUs antiguas, pero debería funcionar)

Entonces el reenvío de interrupciones del sistema está soportado y no necesitas habilitar interrupciones inseguras. Ten en cuenta que al habilitar este valor tu sistema puede volverse inestable.

pve_mediated_devices_enabled habilita el soporte GVT-g para dispositivos integrados, como los GPU de Intel. No todos los dispositivos soportan GVT-g, por lo que se recomienda comprobar con tu dispositivo específico de antemano para asegurarte de que esté permitido.

pve_pcie_ovmf_enabled habilita el passthrough PCI de GPU OVMF. Cuando uses OVMF debes seleccionar 'OVMF' como la opción de BIOS para la VM en lugar de 'SeaBIOS' dentro de Proxmox. Esta configuración intentará excluir dispositivos de la arbitraje VGA si es posible.

pve_pci_device_ids es una lista de IDs de dispositivos y proveedores que se desean pasar a las VMs desde el host. Consulta la sección 'GPU Passthrough' en el WIKI de Proxmox para encontrar tus IDs específicos de dispositivos y proveedores. Al establecer este valor, es requerido especificar un 'id' para cada nuevo elemento en el array.

pve_vfio_blacklist_drivers es una lista de controladores que se excluirán / bloquearán del host. Esto es requerido al pasar un dispositivo PCI para evitar que el host use el dispositivo antes de poder asignarlo a una VM. Al establecer este valor, es requerido especificar un 'name' para cada nuevo elemento en el array.

pve_pcie_ignore_msrs evita que algunas aplicaciones de Windows, como GeForce Experience, Passmark Performance Test y SiSoftware Sandra, bloqueen la VM. Este valor solo es requerido al pasar dispositivos PCI a sistemas basados en Windows.

pve_pcie_report_msrs puede ser usado para habilitar o deshabilitar el registro de advertencias de mensajes msrs. Si ves muchos mensajes de advertencia en tu registro del sistema 'dmesg', este valor puede ser usado para silenciar las advertencias de msrs.

Notas para Desarrolladores

Cuando desarrolles nuevas características o arregles algo en este rol, puedes probar tus cambios utilizando Vagrant (actualmente solo se soporta libvirt). El playbook se encuentra en tests/vagrant (así que asegúrate de modificar las variables de grupo según sea necesario). Asegúrate de probar cualquier cambio en Debian 10 y 11 (actualiza el Vagrantfile localmente para usar debian/buster64) antes de enviar una PR.

También puedes especificar un proxy de caché de apt (por ejemplo, apt-cacher-ng, y debe ejecutarse en el puerto 3142) con la variable de entorno APT_CACHE_HOST para acelerar las descargas de paquetes si tienes uno ejecutándose localmente en tu entorno. El playbook de vagrant detectará si el proxy de caché está disponible y solo lo usará si es accesible desde tu red, así que podrías establecer permanentemente esta variable en tu entorno de desarrollo si prefieres.

Por ejemplo, podrías ejecutar lo siguiente para mostrar una salida más detallada y fácil de leer, usar un proxy de caché y mantener las VMs en ejecución si te encuentras con un error (así puedes solucionarlo y/o ejecutar vagrant provision después de arreglarlo):

APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error

Contribuidores

Musee Ullah (@lae, lae@lae.is) - Desarrollador principal
Fabien Brachere (@Fbrachere) - Soporte de configuración de almacenamiento
Gaudenz Steinlin (@gaundez) - Soporte de Ceph, etc.
Richard Scott (@zenntrix) - Soporte de Ceph, soporte de PVE 7.x, etc.
Thoralf Rickert-Wendt (@trickert76) - Soporte de PVE 6.x, etc.
Engin Dumlu (@roadrunner)
Jonas Meurer (@mejo-)
Ondrej Flidr (@SniperCZE)
niko2 (@niko2)
Christian Aublet (@caublet)
Gille Pietri (@gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@lexxxel) - Soporte de PVE 8.x, etc.
Bruno Travouillon (@btravouillon) - Mejoras de UX
Tobias Negd (@wu3rstle) - Soporte de Ceph
PendaGTP (@PendaGTP) - Soporte de Ceph
John Marion (@jmariondev)
foerkede (@foerkede) - Soporte de almacenamiento ZFS
Guiffo Joel (@futuriste) - Soporte de configuración de pool
Adam Delo (@ol3d) - Soporte de Passthrough PCIe

Lista completa de contribuidores