ansible role proxmox
v1.9.0
Instala y configura Proxmox Virtual Environment 6.x/7.x/8.x en los servidores Debian.
Este rol le permite implementar y administrar instalaciones PVE de un solo nodo y grupos PVE (más de 3 nodos) en Debian Buster (10) y Bullseye (11) y Bookworm (12). Puede configurar lo siguiente con la ayuda de este rol:
datacenter.cfgpve-no-subscription o pve-enterprise )Con la agrupación habilitada, este rol hace (o le permite hacer) lo siguiente:
Para el soporte o si desea contribuir a este rol, pero desea orientación, no dude en unirse a este servidor de discordias: https://discord.gg/cjqr6fg. Tenga en cuenta que esta es una invitación temporal, por lo que deberá esperar a que @Lae le asigne un rol; de lo contrario, Discord lo eliminará del servidor cuando cierre sesión.
El objetivo principal para este rol es configurar y administrar un clúster Proxmox VE (ver el libro de jugadas de ejemplo), sin embargo, este papel se puede usar para instalar rápidamente los servidores ProxMox de nodo único.
Supongo que ya tiene Ansible instalado. Deberá usar una máquina externa a la que está instalando proxmox (principalmente debido al reinicio en el medio de la instalación, aunque puedo manejar esto de manera algo diferente para este caso de uso más adelante).
Copie el siguiente libro de jugadas en un archivo como 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
Instale este rol y un rol para configurar NTP:
ansible-galaxy install lae.proxmox geerlingguy.ntp
Ahora puede realizar la instalación:
ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER
Si su SSH_USER tiene una contraseña de sudo, pase el indicador -K al comando anterior. Si también se autentica en el host a través de la contraseña en lugar de la autenticación de PubKey, pase el indicador -k (asegúrese de tener sshpass instalado también). Puede configurar esas variables antes de ejecutar el comando o simplemente reemplazarlas. Tenga 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ía poder acceder a su instancia proxmox VE en https://$SSH_HOST_FQDN:8006 .
Crea un nuevo directorio de libros de jugadas. Llamamos a nuestro lab-cluster . Nuestro libro de jugadas 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
6 directories, 12 files
Lo primero que puede notar es que tenemos un montón de archivos .key y .pem . Estas son claves privadas y certificados SSL que este rol usará para configurar la interfaz web para Proxmox en todos los nodos. Sin embargo, estos no son necesarios si desea seguir utilizando los certificados firmados por la CA que proxmox se establece internamente. Por lo general, puede usar Ansible Vault para cifrar las claves privadas, por ejemplo:
ansible-vault encrypt files/pve01/*.key
Esto requeriría que pase la contraseña de bóveda al ejecutar el libro de jugadas.
Primero especifiquemos nuestros hosts de clúster. Nuestro archivo inventory puede verse así:
[pve01]
lab-node01.local
lab-node02.local
lab-node03.local
Podrías tener múltiples grupos, por lo que es una buena idea tener un grupo para cada clúster. Ahora, especifiquemos nuestros requisitos de rol en roles/requirements.yml :
---
- src: geerlingguy.ntp
- src: lae.proxmox
Necesitamos un rol de NTP para configurar NTP, por lo que estamos utilizando el papel de Jeff Geerling para hacerlo. No lo necesitaría si ya tiene NTP configurado o tiene un método diferente para configurar NTP.
Ahora, especifiquemos algunas variables de grupo. En primer lugar, creemos group_vars/all para configurar variables relacionadas con NTP:
---
ntp_manage_config: true
ntp_servers:
- lab-ntp01.local iburst
- lab-ntp02.local iburst
Por supuesto, reemplace esos servidores NTP con los que prefiere.
Ahora para la carne de tu libro de jugadas, las variables grupales de pve01 . Cree un archivo group_vars/pve01 , agregue lo siguiente y modifique en consecuencia para su 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: Operations Team
pve_users:
- name: admin1@pam
email: [email protected]
firstname: Admin
lastname: User 1
groups: [ "ops" ]
- name: admin2@pam
email: [email protected]
firstname: Admin
lastname: User 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 de grupo de nuestro clúster, pve01 : se utilizará para garantizar que todos los hosts dentro de ese grupo puedan conectarse entre sí y se agrupen. Tenga en cuenta que el nombre del clúster PVE también se establecerá en este nombre de grupo, a menos que se especifique lo contrario pve_cluster_clustername . Dejar esto indefinido predeterminado a proxmox .
pve_watchdog aquí habilita el soporte de IPMI WatchDog y configura el Administrador de HA de PVE para usarlo. Use None o deje esto indefinido para usar el Software PROXMOX PROXMOX predeterminado. Si se establece en algo más, se espera que el valor sea un módulo de kernel de vigilancia.
pve_ssl_private_key Y pve_ssl_certificate PUNTO a los certificados SSL para PVECLUSTER. Aquí, se usa una búsqueda de archivo para leer el contenido de un archivo en el libro de jugadas, por ejemplo, files/pve01/lab-node01.key . Posiblemente podría usar variables de host en lugar de archivos, si lo prefiere.
pve_cluster_enabled permite que el papel realice todas las tareas de administración de clúster. Esto incluye crear un clúster si no existe, o agregar nodos al clúster existente. Hay cheques para asegurarse de que no esté mezclando nodos que ya estén en grupos existentes con diferentes nombres.
pve_groups , pve_users y pve_acls autoriza a algunos usuarios locales de UNIX (ya deben existir) para acceder a PVE y les da el papel de administrador como parte del grupo ops . Lea la sección de gestión del usuario y ACL para obtener más información.
pve_storages permite crear diferentes tipos de almacenamiento y configurarlos. El backend debe ser compatible con Proxmox. Lea la sección de gestión de almacenamiento para obtener más información.
pve_metric_servers le permite configurar un servidor métrico para el clúster PVE. Esto es útil si desea usar InfluxDB, Grafito u otro (con Telegraf).
pve_ssh_port le permite cambiar el puerto SSH. Si su SSH está escuchando en un puerto que no sea el 22 predeterminado, configure esta variable. Si un nuevo nodo está uniendo el clúster, el clúster PVE necesita comunicarse una vez a través de SSH.
pve_manage_ssh (verdadero verdadero) le permite deshabilitar cualquier cambio que este módulo realizaría en la configuración de su servidor SSH. Esto es útil si usa otro rol para administrar su servidor SSH. Tenga en cuenta que configurar esto en falso no es compatible oficialmente, está solo para replicar los cambios que normalmente se realizan en ssh_cluster_config.yml y pve_add_node.yml .
interfaces_template se establece en la ruta de una plantilla que usaremos para configurar la red en estas máquinas Debian. Esto solo es necesario si desea administrar redes de Ansible en lugar de manualmente o a través de cada host en PVE. Probablemente debería estar familiarizado con Ansible antes de hacer esto, ya que su método puede implicar establecer variables de host para las direcciones IP para cada host, etc.
Sacemos esa plantilla de interfaz fuera del camino. Siéntase libre de omitir este archivo (y dejarlo indefinido en group_vars/pve01 ) de lo contrario. Aquí hay uno que uso:
# {{ 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é familiarizado con la búsqueda dig , pero básicamente aquí estamos haciendo una búsqueda de registro para cada máquina (por ejemplo, Lab-nodo01.local) para la primera interfaz (y la configuración como un puente que usaremos para las interfaces de VM ), y luego otra búsqueda ligeramente modificada para la red de "agrupación" que podríamos usar para CEPH ("Lab-nodo01-Clusternet.local"). Por supuesto, el suyo puede verse completamente diferente, especialmente si está utilizando la unión, tres redes diferentes para administración/corosync, almacenamiento y tráfico de VM, etc.
Finalmente, escribamos nuestro libro de jugadas. site.yml se verá así:
---
- hosts: all
become: True
roles:
- geerlingguy.ntp
# Leave this out if you're not modifying networking through Ansible
- hosts: pve01
become: True
serial: 1
tasks:
- name: Install bridge-utils
apt:
name: bridge-utils
- name: Configure /etc/network/interfaces
template:
src: "{{ interfaces_template }}"
dest: /etc/network/interfaces
register: _configure_interfaces
- block:
- name: Reboot for networking changes
shell: "sleep 5 && shutdown -r now 'Networking changes found, rebooting'"
async: 1
poll: 0
- name: Wait for server to come back online
wait_for_connection:
delay: 15
when: _configure_interfaces is changed
- hosts: pve01
become: True
roles:
- lae.proxmox
Básicamente, ejecutamos el papel NTP en todos los hosts (es posible que desee agregar algunas máquinas no proxmox), configurar las redes en pve01 con nuestra red de clúster y diseño de puente separados, reiniciar para que esos cambios entren en efecto, y ejecute este papel proxmox contra los hosts para configurar un clúster.
En este punto, nuestro libro de jugadas está listo y podemos ejecutar el libro de jugadas.
Asegúrese de que se instalen roles y dependencias:
ansible-galaxy install -r roles/requirements.yml --force
pip install jmespath dnspython
Se requiere jmespath para algunas de las tareas que involucran la agrupación. dnspython solo es necesario si está utilizando una búsqueda dig , lo que probablemente no será si se omite configurar redes. Pasamos --force a ansible-galaxy aquí para que los roles se actualicen a sus últimas versiones si ya ya se instalan.
Ahora ejecuta el libro de jugadas:
ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'
El -e '{"pve_reboot_on_kernel_update": true}' debe ejecutarse principalmente la primera vez que realice la configuración del clúster Proxmox, ya que reiniciará el servidor para iniciar en un kernel PVE. Las ejecuciones posteriores deben dejar esto fuera, ya que desea reiniciar secuencialmente los servidores después de que el clúster se esté ejecutando.
Para especificar un usuario en particular, use -u root (reemplazo root ), y si necesita proporcionar contraseñas, use -k para contraseña ssh y/o -K para la contraseña de sudo. Por ejemplo:
ansible-playbook -i inventory site.yml -K -u admin1
Esto solicitará una contraseña de sudo, luego iniciará sesión en el usuario admin1 (usando la clave pública Auth - Agregar -k para PW) y ejecutar el libro de jugadas.
¡Eso es todo! Ahora debería tener un clúster ProxMox completamente implementado. Es posible que desee crear almacenamiento CEPH después (consulte CEPH para obtener más información) y otras tareas posiblemente, pero la parte difícil es principalmente completa.
Esto configurará hosts en el grupo pve01 como un clúster, así como reiniciará las máquinas si el núcleo se ha actualizado. (Solo se recomienda establecer este indicador durante la instalación: los reiniciados durante la operación deben ocurrir en serie durante un período de mantenimiento). También habilitará el perro guardián 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
Sobre los valores predeterminados: algunos de los valores predeterminados se seleccionan en el tiempo de ejecución y, por lo tanto, pueden diferir del ejemplo enumerado aquí.
[variable]: [default] #[description/purpose]
pve_group: proxmox # host group that contains the Proxmox hosts to be clustered together
pve_repository_line: "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" # apt-repository configuration - change to enterprise if needed (although TODO further configuration may be needed)
pve_remove_subscription_warning: true # patches the subscription warning messages in proxmox if you are using the community edition
pve_extra_packages: [] # Any extra packages you may want to install, e.g. ngrep
pve_run_system_upgrades: false # Let role perform system upgrades
pve_run_proxmox_upgrades: true # Let role perform Proxmox VE upgrades
pve_check_for_kernel_update: true # Runs a script on the host to check kernel versions
pve_reboot_on_kernel_update: false # If set to true, will automatically reboot the machine on kernel updates
pve_reboot_on_kernel_update_delay: 60 # Number of seconds to wait before and after a reboot process to proceed with next task in cluster mode
pve_remove_old_kernels: true # Currently removes kernel from main Debian repository
# pve_default_kernel_version: # version to pin proxmox-default-kernel to (see https://pve.proxmox.com/wiki/Roadmap#Kernel_6.8)
pve_pcie_passthrough_enabled: false # Set this to true to enable PCIe passthrough.
pve_iommu_passthrough_mode: false # Set this to true to allow VMs to bypass the DMA translation. This might increase performance for IOMMU passthrough.
pve_iommu_unsafe_interrupts: false # Set this to true if your system doesn't support interrupt remapping.
pve_mediated_devices_enabled: false # Set this to true if your device supports gtv-g and you wish to enable split functionality.
pve_pcie_ovmf_enabled: false # Set this to true to enable GPU OVMF PCI passthrough.
pve_pci_device_ids: [] # List of pci device ID's (see https://pve.proxmox.com/wiki/Pci_passthrough#GPU_Passthrough).
pve_vfio_blacklist_drivers: [] # List of device drivers to blacklist from the Proxmox host (see https://pve.proxmox.com/wiki/PCI(e)_Passthrough).
pve_pcie_ignore_msrs: false # Set this to true if passing through to Windows machine to prevent VM crashing.
pve_pcie_report_msrs: true # Set this to false to prevent dmesg system from logging msrs crash reports.
pve_watchdog: none # Set this to "ipmi" if you want to configure a hardware watchdog. Proxmox uses a software watchdog (nmi_watchdog) by default.
pve_watchdog_ipmi_action: power_cycle # Can be one of "reset", "power_cycle", and "power_off".
pve_watchdog_ipmi_timeout: 10 # Number of seconds the watchdog should wait
pve_zfs_enabled: no # Specifies whether or not to install and configure ZFS packages
# pve_zfs_options: "" # modprobe parameters to pass to zfs module on boot/modprobe
# pve_zfs_zed_email: "" # Should be set to an email to receive ZFS notifications
pve_zfs_create_volumes: [] # List of ZFS Volumes to create (to use as PVE Storages). See section on Storage Management.
pve_ceph_enabled: false # Specifies wheter or not to install and configure Ceph packages. See below for an example configuration.
pve_ceph_repository_line: "deb http://download.proxmox.com/debian/ceph-pacific bookworm main" # apt-repository configuration. Will be automatically set for 6.x and 7.x (Further information: https://pve.proxmox.com/wiki/Package_Repositories)
pve_ceph_network: "{{ (ansible_default_ipv4.network +'/'+ ansible_default_ipv4.netmask) | ansible.utils.ipaddr('net') }}" # Ceph public network
# pve_ceph_cluster_network: "" # Optional, if the ceph cluster network is different from the public network (see https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_install_wizard)
pve_ceph_nodes: "{{ pve_group }}" # Host group containing all Ceph nodes
pve_ceph_mon_group: "{{ pve_group }}" # Host group containing all Ceph monitor hosts
pve_ceph_mgr_group: "{{ pve_ceph_mon_group }}" # Host group containing all Ceph manager hosts
pve_ceph_mds_group: "{{ pve_group }}" # Host group containing all Ceph metadata server hosts
pve_ceph_osds: [] # List of OSD disks
pve_ceph_pools: [] # List of pools to create
pve_ceph_fs: [] # List of CephFS filesystems to create
pve_ceph_crush_rules: [] # List of CRUSH rules to create
# pve_ssl_private_key: "" # Should be set to the contents of the private key to use for HTTPS
# pve_ssl_certificate: "" # Should be set to the contents of the certificate to use for HTTPS
pve_roles: [] # Added more roles with specific privileges. See section on User Management.
pve_groups: [] # List of group definitions to manage in PVE. See section on User Management.
pve_users: [] # List of user definitions to manage in PVE. See section on User Management.
pve_storages: [] # List of storages to manage in PVE. See section on Storage Management.
pve_metric_servers: [] # List of metric servers to configure in PVE.
pve_datacenter_cfg: {} # Dictionary to configure the PVE datacenter.cfg config file.
pve_domains_cfg: [] # List of realms to use as authentication sources in the PVE domains.cfg config file.
pve_no_log: false # Set this to true in production to prevent leaking of storage credentials in run logs. (may be used in other tasks in the future)
Para habilitar la agrupación con este rol, configure las siguientes variables adecuadamente:
pve_cluster_enabled: no # Set this to yes to configure hosts to be clustered together
pve_cluster_clustername: "{{ pve_group }}" # Should be set to the name of the PVE cluster
pve_manage_hosts_enabled : yes # Set this to no to NOT configure hosts file (case of using vpn and hosts file is already configured)
Las siguientes variables se utilizan para proporcionar información de red a Corosync. Estos se conocen como ring0_addr/ring1_addr o link0_addr/link1_addr, dependiendo de la versión PVE. Deben ser direcciones IPv4 o IPv6. También puede configurar la prioridad de estas interfaces para insinuar a Corosync, qué interfaz debe manejar el tráfico de clúster (números más bajos indican una prioridad más alta). Para obtener más información, consulte el Capítulo del Administrador de clúster en la documentación PVE.
# pve_cluster_addr0: "{{ defaults to the default interface ipv4 or ipv6 if detected }}"
# pve_cluster_addr1: "another interface's IP address or hostname"
# pve_cluster_addr0_priority: 255
# pve_cluster_addr1_priority: 0
Puede establecer opciones en el archivo de configuración Datacenter.cfg:
pve_datacenter_cfg:
keyboard: en-us
También puede configurar grupos de HA Manager:
pve_cluster_ha_groups: [] # List of HA groups to create in PVE.
Este ejemplo crea un grupo "LAB_NODE01" para los recursos asignados al host de Node01 LAB:
pve_cluster_ha_groups:
- name: lab_node01
comment: "My HA group"
nodes: "lab-node01"
nofailback: 0
restricted: 0
Todas las opciones de configuración admitidas en el archivo datacenter.cfg se documentan en la sección del manual proxmox datacenter.cfg.
Para que la recarga en vivo de las interfaces de red funcione a través de la interfaz de usuario web PVE, debe instalar el paquete ifupdown2 . Tenga en cuenta que esto eliminará ifupdown . Puede especificar esto utilizando la variable de rol pve_extra_packages .
Puede 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 del servidor de autenticación Linux PAM y Proxmox VE authentication server . Los tipos compatibles son pam , pve , ad y ldap . Es posible sincronizar automáticamente a los usuarios y grupos para reinos basados en LDAP (LDAP y Microsoft Active Directory) con sync: true . Un reino debe tener la propiedad default: 1 para marcarlo como el valor predeterminado:
pve_domains_cfg:
- name: pam
type: pam
attributes:
comment: Linux PAM standard authentication
- name: pve
type: pve
attributes:
comment: Proxmox VE authentication server
- name: ad
type: ad
attributes:
comment: Active Directory authentication
domain: yourdomain.com
server1: dc01.yourdomain.com
default: 1
secure: 1
server2: dc02.yourdomain.com
- name: ldap
type: ldap
sync: true
attributes:
comment: LDAP authentication
base_dn: CN=Users,dc=yourdomain,dc=com
bind_dn: "uid=svc-reader,CN=Users,dc=yourdomain,dc=com"
bind_password: "{{ secret_ldap_svc_reader_password }}"
server1: ldap1.yourdomain.com
user_attr: uid
secure: 1
server2: ldap2.yourdomain.com
Este rol no instala NTP, por lo que debe configurar NTP usted mismo, por ejemplo, con el papel geerlingguy.ntp como se muestra en el libro de jugadas de ejemplo.
Cuando se habilita la agrupación, este rol utiliza el filtro json_query , que requiere que la biblioteca jmespath se instale en su host de control. Puede pip install jmespath o instalarlo a través del Administrador de paquetes de su distribución, por ejemplo, apt-get install python-jmespath .
Puede usar este rol para administrar usuarios y grupos dentro de Proxmox VE (tanto en implementaciones de servidores individuales como en implementaciones de clúster). Aquí hay algunos ejemplos.
pve_groups:
- name: Admins
comment: Administrators of this PVE cluster
- 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: "Temporary user set to expire on 2018年 1月 1日 月曜日 00:00:00 PST"
email: [email protected]
firstname: Test
lastname: User
Consulte library/proxmox_user.py Link y library/proxmox_group.py Link para la documentación del módulo.
Para la gestión de roles y ACL, se emplea un módulo similar, pero la principal diferencia es que la mayoría de los parámetros solo aceptan listas (sujetas 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
Consulte library/proxmox_role.py Link y library/proxmox_acl.py Link para la documentación del módulo.
Puede usar este rol para administrar el almacenamiento dentro de ProxMox VE (tanto en implementaciones de servidores individuales como en implementaciones de clúster). Por ahora, los únicos tipos compatibles 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 # Optional
- 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.domain.tld
type: cifs
content: [ "snippets", "vztmpl", "iso" ]
share: sharename
subdir: /subdir
username: user
password: supersecurepass
domain: addomain.tld
Consulte https://pve.proxmox.com/pve-docs/api-viewer/index.html para obtener más información.
Actualmente, el tipo zfspool solo se puede usar para images y contenidos rootdir . Si desea almacenar los otros tipos de contenido en un volumen ZFS, debe especificarlos con Tipo dir , Ruta /<POOL>/<VOLUME> y agregar una entrada en pve_zfs_create_volumes . Este ejemplo agrega un almacenamiento iso en un grupo ZFS:
pve_zfs_create_volumes:
- rpool/iso
pve_storages:
- name: iso
type: dir
path: /rpool/iso
content: [ "iso" ]
Consulte la library/proxmox_storage.py para la documentación del módulo.
Esta sección podría usar un poco más de amor. Si está utilizando activamente este rol para administrar su clúster PVE Ceph, ¡no dude en desarrollar esta sección más a fondo y abrir una solicitud de extracción! Ver número #68.
El manejo de PVE Ceph con este papel es experimental. Si bien los usuarios han utilizado con éxito este rol para implementar PVE CEPH, no se prueba completamente en CI (debido a la falta de dispositivos de bloque utilizables para usar como OSD en Travis CI). Implemente primero un entorno de prueba con su configuración antes de Prod, e informe cualquier problema si se encuentra con alguno.
Este rol puede configurar el sistema de almacenamiento CEPH en sus hosts Proxmox. Las siguientes definiciones muestran algunas de las configuraciones 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 with everything on the same device
- device: /dev/sdc
# OSD with block.db/WAL on another device
- device: /dev/sdd
block.db: /dev/sdb1
# encrypted OSD with everything on the same device
- device: /dev/sdc
encrypted: true
# encrypted OSD with block.db/WAL on another device
- device: /dev/sdd
block.db: /dev/sdb1
encrypted: true
# Crush rules for different storage classes
# By default 'type' is set to host, you can find valid types at
# (https://docs.ceph.com/en/latest/rados/operations/crush-map/)
# listed under 'TYPES AND BUCKETS'
pve_ceph_crush_rules:
- name: replicated_rule
type: osd # This is an example of how you can override a pre-existing rule
- name: ssd
class: ssd
type: osd
min-size: 2
max-size: 8
- name: hdd
class: hdd
type: host
# 2 Ceph pools for VM disks which will also be defined as Proxmox storages
# Using different CRUSH rules
pve_ceph_pools:
- name: ssd
pgs: 128
rule: ssd
application: rbd
storage: true
# This Ceph pool uses custom size/replication values
- name: hdd
pgs: 32
rule: hdd
application: rbd
storage: true
size: 2
min-size: 1
# This Ceph pool uses custom autoscale mode : "off" | "on" | "warn"> (default = "warn")
- name: vm-storage
pgs: 128
rule: replicated_rule
application: rbd
autoscale_mode: "on"
storage: true
pve_ceph_fs:
# A CephFS filesystem not defined as a Proxmox storage
- name: backup
pgs: 64
rule: hdd
storage: false
mountpoint: /srv/proxmox/backup
pve_ceph_network de forma predeterminada utiliza el filtro ansible.utils.ipaddr , que requiere que la biblioteca netaddr sea instalada y utilizable por su controlador Ansible.
pve_ceph_nodes De forma predeterminada usa pve_group , este parámetro permite especificar en qué nodos instalan CEPH (por ejemplo, si no desea instalar CEPH en todos sus nodos).
pve_ceph_osds por defecto crea volúmenes de CEPH no cifrados. Para usar volúmenes cifrados, el parámetro encrypted debe establecerse por unidad a true .
Este rol se puede configurar para permitir el paso del dispositivo PCI desde el host Proxmox a las máquinas virtuales. Esta función no está habilitada de forma predeterminada ya que no todas las placas base y CPU admiten esta función. Para habilitar Passthrough, la CPU de dispositivos debe admitir la virtualización de hardware (VT-D para sistemas basados en Intel y AMD-V para sistemas basados en AMD). Consulte los manuales de todos los componentes para determinar si esta característica es compatible o no. Las convenciones de nombres de voluntad varían, pero generalmente se conoce como iommu, vt-d o amd-v.
Al habilitar esta función, los dispositivos dedicados (como una GPU o dispositivos USB) pueden pasar a las máquinas virtuales. Junto con dispositivos dedicados, varios dispositivos integrados como las GPU integradas de Intel o AMD también pueden pasar a VMS.
Algunos dispositivos pueden aprovechar el uso mediado. Los dispositivos mediados pueden pasar a múltiples máquinas virtuales para compartir recursos, sin dejar de ser utilizables por el sistema de host. La división de dispositivos no siempre es compatible y debe validarse antes de ser habilitado para evitar errores. Consulte el manual del dispositivo que desea pasar para determinar si el dispositivo es capaz del uso mediado (actualmente este rol solo admite GVT-G; SR-IOV actualmente no es compatible y debe habilitarse manualmente después de la finalización de roles).
La siguiente es una configuración de ejemplo que habilita el paso de 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 necesario para usar cualquier funcionalidad PCIE PASSTHROUR. Sin esto habilitado, todos los demás campos relacionados con PCIe no se utilizarán.
pve_iommu_passthrough_mode habilitando el modo de paso de Iommu podría aumentar el rendimiento del dispositivo. Al habilitar esta función, permite a las máquinas virtuales omitir la traducción predeterminada de DMA que normalmente sería realizada por el hiper-visor. En su lugar, las máquinas virtuales pasan las solicitudes de DMA directamente al hardware IOMMU.
pve_iommu_unsafe_interrupts debe habilitarse para permitir el paso de PCI si su sistema no admite la reasignación de interrupción. Puede encontrar verificar si el dispositivo admite la reasignación de interrupción utilizando dmesg | grep 'remapping' . Si ve una de las siguientes líneas:
Luego, la reasignación de interrupción del sistema es compatible y no necesita habilitar interrupciones inseguras. Tenga en cuenta que al habilitar este valor su sistema puede volverse inestable.
pve_mediated_devices_enabled habilita el soporte GVT-G para dispositivos integrados como Intel IGPU. No todos los dispositivos admiten GVT-G, por lo que se recomienda verificar con su dispositivo específico de antemano para asegurarse de que esté permitido.
pve_pcie_ovmf_enabled habilita GPU OVMF PCI PASSTROUGH. Cuando use OVMF, debe seleccionar 'OVMF' como la opción BIOS para la VM en lugar de 'Seabios' dentro de Proxmox. Esta configuración intentará optar por los dispositivos del arbitraje VGA si es posible.
pve_pci_device_ids es una lista de ID de dispositivo y proveedor que se desea pasar a las máquinas virtuales del host. Consulte la sección 'Passthrough de GPU' en el wiki proxmox para encontrar su dispositivo específico e ID de proveedor. Al establecer este valor, se requiere especificar una 'ID' para cada nuevo elemento en la matriz.
pve_vfio_blacklist_drivers es una lista de controladores que se excluirán/lista negra del host. Esto se requiere al pasar a través de un dispositivo PCI para evitar que el host use el dispositivo antes de que pueda asignarse a una VM. Al establecer este valor, se requiere especificar un 'nombre' para cada nuevo elemento en la matriz.
pve_pcie_ignore_msrs evita que algunas aplicaciones de Windows como GeForce Experience, Passmark Performance Test y Sisoftware Sandra se bloqueen la VM. Este valor solo se requiere al pasar dispositivos PCI a sistemas basados en Windows.
pve_pcie_report_msrs se puede usar para habilitar o deshabilitar los mensajes de registro de las advertencias de MSRS. Si ve muchos mensajes de advertencia en el registro de su sistema 'DMESG', este valor se puede usar para silenciar las advertencias de MSRS.
Puede configurar los servidores métricos en Proxmox VE utilizando la variable de rol pve_metric_servers . A continuación se muestra una configuración de ejemplo para diferentes tipos de servidores métricos:
pve_metric_servers :
- id : influxdb1
port : 8086
server : influxdb.example.com
type : influxdb
protocol : http
organization : myorg
bucket : mybucket
token : mytoken
timeout : 30
max_body_size : 25000000
verify_certificate : true
- id : graphite1
port : 2003
server : graphite.example.com
type : graphite
protocol : tcp
path : mygraphitepath
mtu : 1500id : (requerido) Identificador único para el servidor métrico.port : (opcional) puerto del servidor métrico. El valor predeterminado es 8089 .server : (requerido) Nombre DNS o dirección IP del servidor métrico.type : (opcional) Tipo de servidor métrico. Valores posibles: influxdb , graphite . El valor predeterminado es influxdb .protocol : Protocolo (opcional) utilizado para enviar métricas. Valores posibles: udp , tcp , http , https . El valor predeterminado es udp .disable : (opcional) Deshabilite el servidor métrico. El valor predeterminado es false .organization : (opcional) Nombre de la organización. Disponible solo para InfluxDB con la API HTTP V2.bucket : (opcional) Nombre del cubo para InfluxDB. Útil solo con la API HTTP V2 o compatible.token : (opcional) InfluxDB Access Token. Requerido solo cuando se usa la API HTTP V2.path : (opcional) Ruta de la raíz de grafito. Disponible solo para grafito.api_path_prefix : (Opcional) Prefijo de ruta API Insertado entre <host>:<port>/ y /api2/ . Útil si el servicio InfluxDB se ejecuta detrás de un proxy inverso. Disponible solo para InfluxDB con la API HTTP V2.timeout : (opcional) Tiempo de espera en segundos. Disponible solo para InfluxDB con la API HTTP V2 o el socket de grafito TCP.max_body_size : (opcional) Tamaño máximo del cuerpo en bytes. Disponible solo para InfluxDB con la API HTTP V2. El valor predeterminado es 25000000 .mtu : (opcional) MTU para la transmisión métrica UDP.verify_certificate : (opcional) Verifique el certificado SSL. Disponible solo para InfluxDB con HTTPS. Proxmox 8.2 presenta Linux 6.8, lo que puede causar problemas en algunas implementaciones. Para trabajar alrededor de esto, puede fijar la versión del núcleo utilizada a 6.5 agregando la siguiente variable de rol:
pve_default_kernel_version : 1.0.1 Esto crea un PIN en el paquete proxmox-default-kernel , que es el método sugerido por PVE. Posteriormente se puede eliminar sin resolver esta variable de rol.
Agregue esta sección a su ansible.cfg .
[ssh_connection]
ssh_args = -o ServerAliveInterval=20Problema de referencia
Al desarrollar nuevas funciones o arreglar algo en este rol, puede probar sus cambios usando Vagrant (solo LibVirt es compatible actualmente). El libro de jugadas se puede encontrar en tests/vagrant (así que asegúrese de modificar las variables de grupo según sea necesario). Asegúrese de probar cualquier cambio en todas las versiones compatibles de Debian (actualizar el Vagrantfile localmente para usar debian/bookworm64 , debian/bullseye64 o debian/buster64 ) antes de enviar un PR.
También puede especificar un proxy de almacenamiento en caché 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 tiene una que se ejecuta localmente en su entorno. El libro de jugadas vagabundo detectará si el proxy de almacenamiento en caché está disponible y solo lo usará si es accesible desde su red, por lo que podría establecer esta variable permanentemente en su entorno de desarrollo si lo prefiere.
Por ejemplo, puede ejecutar lo siguiente para mostrar la salida detallada/más fácil de leer, usar un proxy de almacenamiento en caché y mantener las máquinas virtuales en funcionamiento si se encuentra con un error (para que pueda solucionarlo y/o ejecutar vagrant provision después de la solucionamiento)::
APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error
Musee Ullah (@Lae, [email protected]) - 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 PVE 7.x, etc.
Thoralf Rickert -Wendt (@Trickert76) - PVE 6.x Soporte, 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 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 del grupo
Adam DeLo (@OL3D) - Soporte PCIE PASSTROUGH Antoine Thys (@Thystips) - Soporte de servidores métricos
Lista completa de contribuyentes
