ansible role proxmox
v1.9.0
Installe et configure un environnement virtuel ProxMox 6.x / 7.x / 8.x sur les serveurs Debian.
Ce rôle vous permet de déployer et de gérer les installations de PVE à un nœud et les clusters PVE (3+ nœuds) sur Debian Buster (10) et Bullseye (11) et Bookworm (12). Vous pouvez configurer ce qui suit avec l'aide de ce rôle:
datacenter.cfgpve-no-subscription ou pve-enterprise )Avec le clustering activé, ce rôle fait (ou vous permet de faire) ce qui suit:
Pour le support ou si vous souhaitez contribuer à ce rôle mais que vous souhaitez des conseils, n'hésitez pas à rejoindre ce serveur Discord: https://discord.gg/cjqr6fg. Veuillez noter qu'il s'agit d'une invitation temporaire, vous devrez donc attendre @Lae pour vous attribuer un rôle, sinon Discord vous supprimera du serveur lorsque vous vous déconnectez.
L'objectif principal de ce rôle est de configurer et de gérer un cluster Proxmox VE (voir Exemple PlayBook), mais ce rôle peut être utilisé pour installer rapidement les serveurs proxmox de nœud unique.
Je suppose que vous avez déjà installé Ansible. Vous devrez utiliser une machine externe sur celle sur laquelle vous installez Proxmox (principalement en raison du redémarrage au milieu de l'installation, bien que je puisse gérer cela quelque peu différemment pour ce cas d'utilisation plus tard).
Copiez le playbook suivant dans un fichier comme 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
Installez ce rôle et un rôle pour la configuration du NTP:
ansible-galaxy install lae.proxmox geerlingguy.ntp
Vous pouvez maintenant effectuer l'installation:
ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER
Si votre SSH_USER a un mot de passe sudo, passez l'indicateur -K à la commande ci-dessus. Si vous vous authentifiez également à l'hôte via le mot de passe au lieu de PuBkey Auth, passez l'indicateur -k (assurez-vous que sshpass est également installé). Vous pouvez définir ces variables avant d'exécuter la commande ou simplement les remplacer. Notez que la virgule est importante, car une liste est attendue (sinon elle tentera de rechercher un fichier contenant une liste d'hôtes).
Une fois terminé, vous devriez pouvoir accéder à votre instance Proxmox VE sur https://$SSH_HOST_FQDN:8006 .
Créez un nouveau répertoire Playbook. Nous appelons lab-cluster de notre. Notre livre de jeu finira par ressembler à ceci, mais le vôtre n'a pas à suivre toutes les étapes:
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
La première chose que vous pouvez noter est que nous avons un tas de fichiers .key et .pem . Ce sont des clés privées et des certificats SSL que ce rôle utilisera pour configurer l'interface Web pour Proxmox sur tous les nœuds. Ce ne sont pas nécessaires, cependant, si vous souhaitez continuer à utiliser les certificats signés par l'AC que ProxMox configure en interne. Vous pouvez généralement utiliser un coffre-fort ANSIBLE pour crypter les clés privées, par exemple:
ansible-vault encrypt files/pve01/*.key
Cela vous obligerait alors à passer le mot de passe du coffre-fort lors de l'exécution du livre de jeu.
Spécions d'abord nos hôtes de cluster. Notre fichier inventory peut ressembler à ceci:
[pve01]
lab-node01.local
lab-node02.local
lab-node03.local
Vous pourriez avoir plusieurs clusters, c'est donc une bonne idée d'avoir un groupe pour chaque cluster. Maintenant, spécifions nos exigences de rôle dans roles/requirements.yml :
---
- src: geerlingguy.ntp
- src: lae.proxmox
Nous avons besoin d'un rôle NTP pour configurer le NTP, nous utilisons donc le rôle de Jeff Geerling pour le faire. Vous n'en auriez pas besoin si vous avez déjà configuré NTP ou si vous avez une méthode différente pour configurer NTP.
Maintenant, spécifions certaines variables de groupe. Tout d'abord, créons group_vars/all pour définir les variables liées au NTP:
---
ntp_manage_config: true
ntp_servers:
- lab-ntp01.local iburst
- lab-ntp02.local iburst
Bien sûr, remplacez ces serveurs NTP par ceux que vous préférez.
Maintenant pour la chair de votre livre de jeu, les variables de groupe de pve01 . Créez un fichier group_vars/pve01 , ajoutez ce qui suit et modifiez en conséquence pour votre environnement.
---
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 est défini sur le nom de groupe de notre cluster, pve01 - il sera utilisé dans le but de s'assurer que tous les hôtes de ce groupe peuvent se connecter les uns aux autres et sont regroupés. Notez que le nom du cluster PVE sera également défini sur ce nom de groupe, sauf indication contraire par pve_cluster_clustername . Laisser cette non définie sera par défaut à proxmox .
pve_watchdog permet ici la prise en charge de Watchdog IPMI et configure le gestionnaire HA de PVE pour l'utiliser. Utilisez None ou laissez cette non-définie pour utiliser le chien de garde du logiciel ProxMox par défaut. S'il est défini sur autre chose, la valeur devrait être un module de noyau de chien de garde.
pve_ssl_private_key et pve_ssl_certificate Point aux certificats SSL pour PVECLUsUR. Ici, une recherche de fichiers est utilisée pour lire le contenu d'un fichier dans le playbook, par exemple files/pve01/lab-node01.key . Vous pouvez éventuellement utiliser des variables hôtes au lieu de fichiers, si vous préférez.
pve_cluster_enabled permet au rôle d'effectuer toutes les tâches de gestion des cluster. Cela inclut la création d'un cluster s'il n'existe pas ou l'ajout de nœuds au cluster existant. Il existe des vérifications pour vous assurer que vous ne mélangez pas les nœuds qui sont déjà en clusters existants avec différents noms.
pve_groups , pve_users et pve_acls autorisent certains utilisateurs locaux de l'UNIX (ils doivent déjà exister) pour accéder à PVE et leur donne le rôle administrateur dans le cadre du groupe ops . Lisez la section de gestion des utilisateurs et ACL pour plus d'informations.
pve_storages permet de créer différents types de stockage et de les configurer. Le backend doit être pris en charge par Proxmox. Lisez la section de gestion du stockage pour plus d'informations.
pve_metric_servers vous permet de configurer un serveur métrique pour le cluster PVE. Ceci est utile si vous souhaitez utiliser InfluxDB, Graphite ou autre (avec Telegraf).
pve_ssh_port vous permet de modifier le port SSH. Si votre SSH écoute sur un port autre que le 22 par défaut, veuillez définir cette variable. Si un nouveau nœud rejoint le cluster, le cluster PVE doit communiquer une fois via SSH.
pve_manage_ssh (par défaut True) vous permet de désactiver toutes les modifications que ce module apporterait à votre configuration de serveur SSH. Ceci est utile si vous utilisez un autre rôle pour gérer votre serveur SSH. Notez que le réglage sur FALSE n'est pas officiellement pris en charge, vous êtes seul pour reproduire les modifications normalement apportées dans ssh_cluster_config.yml et pve_add_node.yml .
interfaces_template est défini sur le chemin d'un modèle que nous utiliserons pour configurer le réseau sur ces machines Debian. Ceci n'est nécessaire que si vous souhaitez gérer le réseautage d'ANSIBLE plutôt que manuellement ou via chaque hôte de PVE. Vous devriez probablement être familier avec ANSIBLE avant de le faire, car votre méthode peut impliquer la définition des variables hôtes pour les adresses IP pour chaque hôte, etc.
Éloignons ce modèle d'interface. N'hésitez pas à ignorer ce fichier (et à le laisser non défini dans group_vars/pve01 ) autrement. En voici un que j'utilise:
# {{ 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
Vous ne connaissez peut-être pas la recherche dig , mais en gros, nous faisons une recherche A Record pour chaque machine (par exemple Lab-node01.local) pour la première interface (et la configurer comme un pont que nous utiliserons pour les interfaces VM ), puis une autre recherche légèrement modifiée pour le réseau "clustering" que nous pourrions utiliser pour Ceph ("lab-node01-Clusternet.local"). Bien sûr, le vôtre peut être complètement différent, surtout si vous utilisez des liaisons, trois réseaux différents pour le trafic de gestion / corosync, de stockage et de machine virtuelle, etc.
Enfin, écrivons notre livre de jeu. site.yml ressemblera à ceci:
---
- 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
Fondamentalement, nous exécutons le rôle NTP sur tous les hôtes (vous voudrez peut-être ajouter des machines non proxmox), configurer la mise en réseau sur pve01 avec notre réseau de cluster et la disposition de pont séparés, redémarrez pour que ces modifications prennent effet, puis exécutent ce rôle Proxmox contre les hôtes pour configurer un cluster.
À ce stade, notre livre de jeu est prêt et nous pouvons exécuter le livre de jeu.
Assurez-vous que les rôles et les dépendances sont installés:
ansible-galaxy install -r roles/requirements.yml --force
pip install jmespath dnspython
jmespath est requis pour certaines des tâches impliquant le clustering. dnspython n'est requis que si vous utilisez une recherche dig , ce que vous ne serez probablement pas si vous avez sauté la configuration de la mise en réseau. Nous passons --force à ansible-galaxy ici afin que les rôles soient mis à jour vers leurs dernières versions si elles sont déjà installées.
Maintenant, exécutez le livre de jeu:
ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'
Le -e '{"pve_reboot_on_kernel_update": true}' devrait principalement être exécuté la première fois que vous effectuez la configuration du cluster Proxmox, car il redémarrera le serveur pour démarrer dans un noyau PVE. Les analyses ultérieures devraient laisser cela, car vous souhaitez redémarrer séquentiellement les serveurs après l'exécution du cluster.
Pour spécifier un utilisateur particulier, utilisez -u root (remplacement de root ), et si vous devez fournir des mots de passe, utilisez -k pour le mot de passe SSH et / ou -K pour le mot de passe sudo. Par exemple:
ansible-playbook -i inventory site.yml -K -u admin1
Cela demandera un mot de passe sudo, puis connectez-vous à l'utilisateur admin1 (en utilisant la clé publique Auth - Add -k pour PW) et exécutez le playbook.
C'est ça! Vous devriez maintenant avoir un cluster ProxMox entièrement déployé. Vous voudrez peut-être créer du stockage Ceph par la suite (voir Ceph pour plus d'informations) et d'autres tâches éventuellement, mais la partie difficile est principalement complète.
Cela configurera les hôtes du groupe pve01 en tant que cluster, ainsi que redémarrer les machines si le noyau avait été mis à jour. (Uniquement recommandé pour définir ce drapeau pendant l'installation - les redémarrages pendant le fonctionnement doivent se produire en série pendant une période de maintenance.) Il permettra également le chien de garde 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
À propos des valeurs par défaut: certaines des valeurs par défaut sont sélectionnées au moment de l'exécution et peuvent donc différer de l'exemple répertorié ici.
[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)
Pour activer le regroupement avec ce rôle, configurez les variables suivantes de manière appropriée:
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)
Les variables suivantes sont utilisées pour fournir des informations de réseautage à Corosync. Ceux-ci sont appelés ring0_addr / ring1_addr ou link0_addr / link1_addr, selon la version PVE. Ils doivent être des adresses IPv4 ou IPv6. Vous pouvez également configurer la priorité de ces interfaces pour faire allusion à Corosync quelle interface doit gérer le trafic de cluster (les nombres plus bas indiquent une priorité plus élevée). Pour plus d'informations, reportez-vous au chapitre Cluster Manager dans la documentation 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
Vous pouvez définir des options dans le fichier de configuration Datacenter.CFG:
pve_datacenter_cfg:
keyboard: en-us
Vous pouvez également configurer les groupes de gestionnaires HA:
pve_cluster_ha_groups: [] # List of HA groups to create in PVE.
Cet exemple crée un groupe "lab_node01" pour les ressources attribuées à l'hôte Lab-node01:
pve_cluster_ha_groups:
- name: lab_node01
comment: "My HA group"
nodes: "lab-node01"
nofailback: 0
restricted: 0
Toutes les options de configuration prises en charge dans le fichier datacenter.cfg sont documentées dans la section Datacenter.cfg manuelle proxmox.
Pour que le rechargement en direct des interfaces réseau fonctionne via l'interface utilisateur Web PVE, vous devez installer le package ifupdown2 . Notez que cela supprimera ifupdown . Vous pouvez spécifier cela à l'aide de la variable de rôle pve_extra_packages .
Vous pouvez définir des royaumes / domaines en tant que sources d'authentification dans le fichier de configuration domains.cfg . Si ce fichier n'est pas présent, seuls les royaumes Linux PAM et Proxmox VE authentication server sont disponibles. Les types pris en charge sont pam , pve , ad et ldap . Il est possible de synchroniser automatiquement les utilisateurs et les groupes pour les royaumes basés sur LDAP (LDAP et Microsoft Active Directory) avec sync: true . Un royaume doit avoir la propriété default: 1 pour le marquer comme par défaut:
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
Ce rôle n'installe pas NTP, vous devez donc configurer NTP vous-même, par exemple avec le rôle geerlingguy.ntp comme indiqué dans l'exemple playbook.
Lorsque le clustering est activé, ce rôle utilise le filtre json_query , ce qui nécessite que la bibliothèque jmespath soit installée sur votre hôte de contrôle. Vous pouvez soit pip install jmespath ou l'installer via le gestionnaire de packages de votre distribution, par exemple apt-get install python-jmespath .
Vous pouvez utiliser ce rôle pour gérer les utilisateurs et les groupes dans Proxmox VE (à la fois dans les déploiements de serveurs uniques et les déploiements de cluster). Voici quelques exemples.
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
Reportez-vous à library/proxmox_user.py Link et lien library/proxmox_group.py pour la documentation du module.
Pour gérer les rôles et les ACL, un module similaire est utilisé, mais la principale différence est que la plupart des paramètres n'acceptent que des listes (sous réserve de changement):
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
Reportez-vous à la liaison library/proxmox_role.py et lien library/proxmox_acl.py pour la documentation du module.
Vous pouvez utiliser ce rôle pour gérer le stockage dans Proxmox VE (à la fois dans les déploiements de serveurs uniques et les déploiements de cluster). Pour l'instant, les seuls types pris en charge sont dir , rbd , nfs , cephfs , lvm , lvmthin , zfspool , btrfs , cifs et pbs . Voici quelques exemples.
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
Reportez-vous à https://pve.proxmox.com/pve-docs/api-viewer/index.html pour plus d'informations.
Actuellement, le type zfspool ne peut être utilisé que pour images et les contenus rootdir . Si vous souhaitez stocker les autres types de contenu sur un volume ZFS, vous devez les spécifier avec Type dir , Path /<POOL>/<VOLUME> et ajouter une entrée dans pve_zfs_create_volumes . Cet exemple ajoute un stockage iso sur un pool ZFS:
pve_zfs_create_volumes:
- rpool/iso
pve_storages:
- name: iso
type: dir
path: /rpool/iso
content: [ "iso" ]
Reportez-vous à la liaison library/proxmox_storage.py pour la documentation du module.
Cette section pourrait utiliser un peu plus d'amour. Si vous utilisez activement ce rôle pour gérer votre cluster PVE CEPH, n'hésitez pas à chasser cette section plus approfondie et à ouvrir une demande de traction! Voir le numéro # 68.
PVE CEPH La gestion avec ce rôle est expérimental. Bien que les utilisateurs aient utilisé avec succès ce rôle pour déployer PVE CEPH, il n'est pas entièrement testé dans CI (en raison d'un manque de dispositifs de blocs utilisables à utiliser comme OSD dans Travis CI). Veuillez déployer un environnement de test avec votre configuration d'abord avant ProD et signaler tout problème si vous en rencontrez.
Ce rôle peut configurer le système de stockage CEPH sur vos hôtes ProxMox. Les définitions suivantes montrent certaines des configurations possibles.
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 Utilise par défaut le filtre ansible.utils.ipaddr , qui nécessite que la bibliothèque netaddr soit installée et utilisable par votre contrôleur anible.
pve_ceph_nodes Utilise par défaut pve_group , ce paramètre permet de spécifier quels nœuds installent ceph (par exemple si vous ne souhaitez pas installer Ceph sur tous vos nœuds).
pve_ceph_osds par défaut crée des volumes CEPH non cryptés. Pour utiliser des volumes cryptés, le paramètre encrypted doit être défini par lecteur sur true .
Ce rôle peut être configuré pour permettre à PCI le périphérique de passer de l'hôte Proxmox en machines virtuelles. Cette fonctionnalité n'est pas activée par défaut, car toutes les cartes mères et les CPU ne prennent pas en charge cette fonctionnalité. Pour activer le passhrough, le processeur des appareils doit prendre en charge la virtualisation matérielle (VT-D pour les systèmes basés sur Intel et AMD-V pour les systèmes basés sur AMD). Reportez-vous aux manuels de tous les composants pour déterminer si cette fonction est prise en charge ou non. Les conventions de dénomination varieront, mais est généralement appelée iommu, VT-D ou AMD-V.
En activant cette fonctionnalité, des appareils dédiés (tels qu'un GPU ou des appareils USB) peuvent être transmis à la machine virtuelle. Parallèlement aux appareils dédiés, divers appareils intégrés tels que les GPU intégrés d'AMD ou AMD peuvent également être transmis à des machines virtuelles.
Certains appareils sont en mesure de profiter de l'utilisation médiée. Les appareils médiés peuvent être transmis à plusieurs machines virtuelles pour partager des ressources, tout en restant utilisables par le système hôte. La division des dispositifs n'est pas toujours prise en charge et doit être validée avant d'être activée pour éviter les erreurs. Reportez-vous au manuel de l'appareil que vous souhaitez passer pour déterminer si l'appareil est capable d'une utilisation médiée (actuellement ce rôle ne prend en charge que GVT-G; SR-IOV n'est pas actuellement pris en charge et doit être activé manuellement après l'achèvement du rôle).
Ce qui suit est un exemple de configuration qui permet à PCIe pasthrough:
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 est nécessaire pour utiliser n'importe quelle fonctionnalité PCIe pashrough. Sans cela, tous les autres champs liés à PCIe ne seront pas utilisés.
pve_iommu_passthrough_mode Activation du mode IOMMU PASSTHROUGH pourrait augmenter les performances de l'appareil. En activant cette fonctionnalité, il permet aux machines virtuelles de contourner la traduction DMA par défaut qui serait normalement effectuée par l'hyper-visor. Au lieu de cela, VMS passe DMA demande directement au matériel Iommu.
pve_iommu_unsafe_interrupts doit être activé pour permettre PCI passthrough si votre système ne prend pas en charge le remappage d'interruption. Vous pouvez découvrir si l'appareil prend en charge les remappage d'interruption à l'aide de dmesg | grep 'remapping' . Si vous voyez l'une des lignes suivantes:
Ensuite, le remappage d'interruption du système est pris en charge et vous n'avez pas besoin d'activer les interruptions dangereuses. Sachez qu'en permettant à cette valeur, votre système peut devenir instable.
pve_mediated_devices_enabled permet la prise en charge GVT-G pour les périphériques intégrés tels que les IGPU Intel. Tous les appareils ne prennent pas en charge GVT-G, il est donc recommandé de vérifier au préalable votre appareil spécifique pour vous assurer qu'il est autorisé.
pve_pcie_ovmf_enabled Active GPU OVMF PCI passthrough. Lorsque vous utilisez OVMF, vous devez sélectionner «OVMF» comme option BIOS pour la machine virtuelle au lieu de «Seabios» dans Proxmox. Ce paramètre essaiera de retirer les appareils à partir de VGA Arbitration si possible.
pve_pci_device_ids est une liste d'ID de périphérique et de fournisseur qui devrait être transmis par les machines virtuelles de l'hôte. Consultez la section «GPU Passthrough» sur le Wiki Proxmox pour trouver votre appareil et votre identifiant de fournisseur spécifique. Lors de la définition de cette valeur, il est nécessaire de spécifier un «ID» pour chaque nouvel élément du tableau.
pve_vfio_blacklist_drivers est une liste de pilotes à exclure / liste noire de l'hôte. Ceci est nécessaire lors du passage d'un périphérique PCI pour empêcher l'hôte d'utiliser le périphérique avant de pouvoir être attribué à une machine virtuelle. Lors de la définition de cette valeur, il est nécessaire de spécifier un «nom» pour chaque nouvel élément du tableau.
pve_pcie_ignore_msrs Empêche certaines applications Windows comme GeForce Experience, Passmark Performance Test et Sisoftware Sandra de bloquer la machine virtuelle. Cette valeur n'est requise que lors du passage des périphériques PCI aux systèmes basés sur Windows.
pve_pcie_report_msrs peut être utilisé pour activer ou désactiver les messages de journalisation des avertissements MSRS. Si vous voyez beaucoup de messages d'avertissement dans votre journal système «DMESG», cette valeur peut être utilisée pour faire taire les avertissements MSRS.
Vous pouvez configurer des serveurs métriques dans Proxmox VE à l'aide de la variable de rôle pve_metric_servers . Vous trouverez ci-dessous un exemple de configuration pour différents types de serveurs métriques:
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 : (obligatoire) Identifiant unique pour le serveur métrique.port : (facultatif) Port du serveur métrique. La valeur par défaut est 8089 .server : (requis) Nom DNS ou adresse IP du serveur métrique.type : (facultatif) Type de serveur métrique. Valeurs possibles: influxdb , graphite . La valeur par défaut est influxdb .protocol : Protocole (facultatif) utilisé pour envoyer des mesures. Valeurs possibles: udp , tcp , http , https . La valeur par défaut est udp .disable : (facultatif) Désactiver le serveur métrique. La valeur par défaut est false .organization : (facultatif) Nom de l'organisation. Disponible uniquement pour InfluxDB avec l'API HTTP V2.bucket : (facultatif) Nom du seau pour affluxdb. Utile uniquement avec l'API HTTP V2 ou compatible.token : (facultatif) InfluxDB Access Token. Requis uniquement lors de l'utilisation de l'API HTTP V2.path : (facultatif) chemin racine de graphite. Disponible uniquement pour le graphite.api_path_prefix : (Facultatif) PRAIL API PRÉFIX INSÉRÉ ENTRE <host>:<port>/ et /api2/ . Utile si le service InfluxDB se déroule derrière un proxy inversé. Disponible uniquement pour InfluxDB avec l'API HTTP V2.timeout : (facultatif) Timeout en secondes. Disponible uniquement pour InfluxDB avec l'API HTTP V2 ou la prise TCP Graphite.max_body_size : (facultatif) taille maximale du corps en octets. Disponible uniquement pour InfluxDB avec l'API HTTP V2. La valeur par défaut est 25000000 .mtu : (facultatif) MTU pour la transmission métrique UDP.verify_certificate : (facultatif) Vérifier le certificat SSL. Disponible uniquement pour affluxDB avec HTTPS. Proxmox 8.2 introduit Linux 6.8, qui peut entraîner des problèmes dans certains déploiements. Pour contourner cela, vous pouvez épingler la version du noyau utilisée à 6.5 en ajoutant la variable de rôle suivante:
pve_default_kernel_version : 1.0.1 Cela crée une broche sur le package proxmox-default-kernel , qui est la méthode suggérée par PVE. Il peut être supprimé par la suite en dénouant cette variable de rôle.
Ajoutez cette section à votre ansible.cfg .
[ssh_connection]
ssh_args = -o ServerAliveInterval=20Problème de référence
Lors du développement de nouvelles fonctionnalités ou de la fixation de quelque chose dans ce rôle, vous pouvez tester vos modifications en utilisant Vagrant (seule LibVirt est prise en charge actuellement). Le Playbook peut être trouvé dans tests/vagrant (alors assurez-vous de modifier les variables de groupe selon les besoins). Assurez-vous de tester toutes les modifications sur toutes les versions prises en charge de Debian (mettez à jour le VagrantFile localement pour utiliser debian/bookworm64 , debian/bullseye64 ou debian/buster64 ) avant de soumettre un PR.
Vous pouvez également spécifier un proxy de mise en cache apt (par exemple apt-cacher-ng , et il doit s'exécuter sur le port 3142) avec la variable d'environnement APT_CACHE_HOST pour accélérer les téléchargements de packages si vous en avez un fonctionnant localement dans votre environnement. Le Playbook Vagrant détectera si le proxy de mise en cache est disponible ou non et l'utilisera uniquement s'il est accessible à partir de votre réseau, vous pouvez donc simplement définir cette variable dans votre environnement de développement si vous préférez.
Par exemple, vous pouvez exécuter ce qui suit pour afficher la sortie verbeux / plus facile à lire, utiliser un proxy de mise en cache et maintenir les machines virtuelles en cours d'exécution si vous rencontrez une erreur (afin que vous puissiez le dépanner et / ou exécuter vagrant provision après la fixation):
APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error
Musée Ullah (@lae, [email protected]) - Développeur principal
Fabien Brachere (@fbrachere) - Support de configuration de stockage
Gaudenz Steinlin (@gaundez) - Support Ceph, etc.
Richard Scott (@ZennTrix) - Support Ceph, support PVE 7.X, etc.
Thoralf Rickert-Wendt (@ Trickert76) - Support PVE 6.x, etc.
Engin Dumlu (@Roadrunner)
Jonas Meurer (@ mejo-)
Ondrej flidr (@sniperpze)
niko2 (@ niko2)
Christian Aublit (@caublet)
Gille Pietri (@Gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@lexxxel) - PVE 8.x Support, etc.
Bruno Travouillon (@btravouillon) - Améliorations UX
Tobias Negd (@ wu3rstle) - Support Ceph
PendAgTP (@PendAgTP) - Support Ceph
John Marion (@jmariondev)
Foerkede (@foerkede) - Support de stockage ZFS
Guiffo Joel (@futuriste) - Prise en charge de la configuration du pool
Adam Delo (@ OL3D) - PCIe Passthrough Support Antoine Thys (@Thystips) - Support des serveurs métriques
Liste complète des contributeurs
