ansible role proxmox
v1.9.0
Instala e configura o ambiente virtual Proxmox 6.x/7.x/8.x nos servidores Debian.
Essa função permite implantar e gerenciar instalações de PVE de nó único e clusters PVE (mais de 3 nós) no Debian Buster (10) e Bullseye (11) e Bookworm (12). Você pode configurar o seguinte com a assistência desta função:
datacenter.cfgpve-no-subscription ou pve-enterprise )Com o cluster ativado, essa função faz (ou permite fazer) o seguinte:
Para suporte ou se você quiser contribuir para essa função, mas deseja orientação, sinta -se à vontade para ingressar neste servidor Discord: https://discord.gg/cjqr6fg. Observe que este é um convite temporário; portanto, você precisará aguardar o @LAE para atribuir uma função a você, caso contrário, a discórdia o removerá do servidor ao fazer o logout.
O objetivo principal dessa função é configurar e gerenciar um cluster Proxmox VE (consulte o manual de exemplo), no entanto, essa função pode ser usada para instalar rapidamente servidores Proxmox Node Single Node.
Estou assumindo que você já tem o Ansible instalado. Você precisará usar uma máquina externa para a instalação do Proxmox (principalmente por causa da reinicialização no meio da instalação, embora eu possa lidar com isso de maneira um pouco diferente para este caso de uso posteriormente).
Copie o seguinte manual para um arquivo 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 esta função e uma função para configurar o NTP:
ansible-galaxy install lae.proxmox geerlingguy.ntp
Agora você pode executar a instalação:
ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER
Se o seu SSH_USER tiver uma senha sudo, passe o sinalizador -K para o comando acima. Se você também se autenticar para o host via senha em vez de pubKey Auth, passe o sinalizador -k (verifique se também instalou sshpass ). Você pode definir essas variáveis antes de executar o comando ou apenas substituí -las. Observe que a vírgula é importante, pois é esperado uma lista (caso contrário, tentará procurar um arquivo que contenha uma lista de hosts).
Uma vez concluído, você poderá acessar sua instância Proxmox VE em https://$SSH_HOST_FQDN:8006 .
Crie um novo diretório de playbook. Chamamos o nosso lab-cluster . Nosso manual acabará sendo assim, mas o seu não precisa seguir todas as etapas:
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
A primeira coisa que você pode observar é que temos um monte de arquivos .key e .pem . São teclas privadas e certificados SSL que essa função usará para configurar a interface da Web para Proxmox em todos os nós. Isso não é necessário, no entanto, se você deseja continuar usando os certificados assinados pela CA que o Proxmox configura internamente. Você normalmente pode usar o Ansible Vault para criptografar as chaves privadas, por exemplo:
ansible-vault encrypt files/pve01/*.key
Isso exigiria que você passe a senha do cofre ao executar o manual.
Vamos primeiro especificar nossos hosts de cluster. Nosso arquivo inventory pode ser assim:
[pve01]
lab-node01.local
lab-node02.local
lab-node03.local
Você pode ter vários clusters, por isso é uma boa ideia ter um grupo para cada cluster. Agora, vamos especificar nossos requisitos de função em roles/requirements.yml :
---
- src: geerlingguy.ntp
- src: lae.proxmox
Precisamos de uma função do NTP para configurar o NTP, por isso estamos usando o papel de Jeff Geerling para fazê -lo. Você não precisaria se já tiver o NTP configurado ou tiver um método diferente para configurar o NTP.
Agora, vamos especificar algumas variáveis de grupo. Primeiro, vamos criar group_vars/all para definir variáveis relacionadas ao NTP:
---
ntp_manage_config: true
ntp_servers:
- lab-ntp01.local iburst
- lab-ntp02.local iburst
Obviamente, substitua os servidores NTP por aqueles que você prefere.
Agora, para a carne do seu manual, as variáveis de grupo do pve01 . Crie um arquivo group_vars/pve01 , adicione o seguinte e modifique de acordo com o seu ambiente.
---
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 é definido como o nome do grupo do nosso cluster, pve01 - ele será usado para fins de garantir que todos os hosts desse grupo possam se conectar e se agruparem. Observe que o nome do cluster PVE também será definido como esse nome do grupo, a menos que especificado de outra forma por pve_cluster_clustername . Deixar isso indefinido será o padrão do proxmox .
pve_watchdog aqui permite que o IPMI Watchdog Support e configure o gerenciador de HA da PVE para usá -lo. Use None ou deixe isso indefinido para usar o cão de guarda padrão do Software Proxmox. Se definido como qualquer outra coisa, espera -se que o valor seja um módulo de kernel de vigilância.
pve_ssl_private_key e pve_ssl_certificate Ponto para os certificados SSL para Pvecluster. Aqui, uma pesquisa de arquivo é usada para ler o conteúdo de um arquivo no manual, por exemplo, files/pve01/lab-node01.key . Você pode usar variáveis de host em vez de arquivos, se preferir.
pve_cluster_enabled permite que a função execute todas as tarefas de gerenciamento de cluster. Isso inclui a criação de um cluster, se não existir ou adicionar nós ao cluster existente. Existem cheques para garantir que você não esteja misturando nós que já estão em clusters existentes com nomes diferentes.
pve_groups , pve_users e pve_acls autoriza alguns usuários do UNIX local (eles já devem existir) a acessar o PVE e oferece a eles a função de administrador como parte do grupo ops . Leia a seção de gerenciamento de usuário e ACL para obter mais informações.
pve_storages permite criar diferentes tipos de armazenamento e configurá -los. O back -end precisa ser suportado pelo Proxmox. Leia a seção de gerenciamento de armazenamento para obter mais informações.
pve_metric_servers permite configurar um servidor métrico para o cluster PVE. Isso é útil se você deseja usar o InfluxDB, grafite ou outro (com Telegraf).
pve_ssh_port permite alterar a porta SSH. Se o seu SSH estiver ouvindo em uma porta que não seja o padrão 22, defina esta variável. Se um novo nó estiver ingressando no cluster, o cluster PVE precisará se comunicar uma vez via SSH.
pve_manage_ssh (padrão true) permite desativar quaisquer alterações que esse módulo faria na sua configuração do SSH Server. Isso é útil se você usar outra função para gerenciar seu servidor SSH. Observe que definir isso como false não é oficialmente suportado, você está sozinho para replicar as alterações normalmente feitas em ssh_cluster_config.yml e pve_add_node.yml .
interfaces_template está definido para o caminho de um modelo que usaremos para configurar a rede nessas máquinas Debian. Isso só é necessário se você deseja gerenciar a rede da Ansible, e não manualmente ou através de cada host no PVE. Você provavelmente deve estar familiarizado com o Ansible antes de fazer isso, pois seu método pode envolver a definição de variáveis do host para os endereços IP para cada host, etc.
Vamos tirar esse modelo de interface do caminho. Sinta -se à vontade para pular este arquivo (e deixá -lo indefinido em group_vars/pve01 ) caso contrário. Aqui está um que eu 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
Você pode não estar familiarizado com a pesquisa dig , mas basicamente aqui estamos fazendo uma pesquisa de registro para cada máquina (por exemplo, node01.local) para a primeira interface (e configurando-a como uma ponte usaremos para interfaces de VM ), e depois outra pesquisa ligeiramente modificada para a rede "Clustering" que podemos usar para CEPH ("Lab-node01-cllusternet.local"). Obviamente, o seu pode parecer completamente diferente, especialmente se você estiver usando a ligação, três redes diferentes para gerenciamento/corosync, armazenamento e tráfego de VM etc.
Finalmente, vamos escrever nosso manual. site.yml vai parecer algo assim:
---
- 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
Basicamente, executamos a função NTP em todos os hosts (você pode querer adicionar algumas máquinas não proxmox), configurar redes no pve01 com nossa rede de cluster e layout de ponte separada, reiniciar para fazer essas mudanças entrar em vigor e, em seguida, executar esse papel proxmox contra os hosts para configurar um cluster.
Neste ponto, nosso manual está pronto e podemos executar o manual.
Certifique -se de que funções e dependências sejam instaladas:
ansible-galaxy install -r roles/requirements.yml --force
pip install jmespath dnspython
jmespath é necessário para algumas das tarefas que envolvem cluster. dnspython só é necessário se você estiver usando uma pesquisa dig , que provavelmente não será se pular a configuração da rede. Passamos --force para ansible-galaxy aqui para que as funções sejam atualizadas para suas versões mais recentes, se já instaladas.
Agora execute o manual:
ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'
O -e '{"pve_reboot_on_kernel_update": true}' deve ser executado principalmente na primeira vez que você fizer a configuração do cluster Proxmox, pois reiniciará o servidor para inicializar em um kernel pve. As execuções subsequentes devem deixar isso de fora, pois você deseja reiniciar seqüencialmente os servidores após a execução do cluster.
Para especificar um usuário específico, use -u root (substituindo root ) e, se você precisar fornecer senhas, use -k para senha ssh e/ou -K para senha do sudo. Por exemplo:
ansible-playbook -i inventory site.yml -K -u admin1
Isso solicitará uma senha do sudo e depois login no usuário admin1 (usando a chave pública Auth - Add -k para PW) e executará o manual.
É isso! Agora você deve ter um cluster Proxmox totalmente implantado. Você pode criar o armazenamento de ceph depois (consulte o CEPH para obter mais informações) e outras tarefas possivelmente, mas a parte mais difícil está principalmente completa.
Isso configurará hosts no grupo pve01 como um cluster, bem como reiniciar as máquinas se o kernel foi atualizado. (Recomendado apenas para definir esse sinalizador durante a instalação - as reinicializações durante a operação devem ocorrer em série durante um período de manutenção.) Ele também permitirá que o cão de guarda 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 os valores padrão: alguns dos valores padrão são selecionados no tempo de execução e podem diferir do exemplo listado aqui.
[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 ativar o cluster com essa função, configure as seguintes variáveis apropriadamente:
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)
As seguintes variáveis são usadas para fornecer informações de rede ao Corosync. Estes são conhecidos como ring0_addr/ring1_addr ou link0_addr/link1_addr, dependendo da versão pve. Eles devem ser endereços IPv4 ou IPv6. Você também pode configurar a prioridade dessas interfaces para sugerir o Corosync Qual interface deve lidar com o tráfego do cluster (números mais baixos indicam maior prioridade). Para obter mais informações, consulte o capítulo do Cluster Manager na documentação do 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
Você pode definir opções no arquivo de configuração datacenter.cfg:
pve_datacenter_cfg:
keyboard: en-us
Você também pode configurar grupos de gerente de HA:
pve_cluster_ha_groups: [] # List of HA groups to create in PVE.
Este exemplo cria um grupo "lab_node01" para obter recursos atribuídos ao host de nó de laboratório:
pve_cluster_ha_groups:
- name: lab_node01
comment: "My HA group"
nodes: "lab-node01"
nofailback: 0
restricted: 0
Todas as opções de configuração suportadas no arquivo datacenter.cfg estão documentadas na seção proxmox manual datacenter.cfg.
Para que a recarga ao vivo das interfaces de rede funcione através da interface do usuário da Web PVE, você precisa instalar o pacote ifupdown2 . Observe que isso removerá ifupdown . Você pode especificar isso usando a variável pve_extra_packages .
Você pode definir os reinos / domínios como fontes de autenticação no arquivo de configuração domains.cfg . Se este arquivo não estiver presente, apenas os reinos do servidor de autenticação Linux PAM e Proxmox VE authentication server estão disponíveis. Os tipos suportados são pam , pve , ad e ldap . É possível sincronizar automaticamente usuários e grupos para reinos baseados em LDAP (LDAP & Microsoft Active Directory) com sync: true . Um reino deve ter a propriedade default: 1 para marcá -lo como o padrão:
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
Essa função não instala o NTP; portanto, você deve configurar o NTP, por exemplo, com a função geerlingguy.ntp como mostrado no manual de exemplo.
Quando o cluster é ativado, essa função faz uso do filtro json_query , que exige que a biblioteca jmespath seja instalada no seu host de controle. Você pode pip install jmespath ou instalá-lo através do gerenciador de pacotes da sua distribuição, por exemplo apt-get install python-jmespath .
Você pode usar essa função para gerenciar usuários e grupos no Proxmox VE (tanto em implantações de servidor único quanto no cluster implantações). Aqui estão alguns exemplos.
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 o link library/proxmox_user.py e library/proxmox_group.py para documentação do módulo.
Para gerenciar funções e ACLs, um módulo semelhante é empregado, mas a principal diferença é que a maioria dos parâmetros aceita apenas listas (sujeitas a alterações):
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 o link library/proxmox_role.py e library/proxmox_acl.py para documentação do módulo.
Você pode usar essa função para gerenciar o armazenamento no Proxmox VE (tanto em implantações de servidor único quanto no cluster implantações). Por enquanto, os únicos tipos suportados são dir , rbd , nfs , cephfs , lvm , lvmthin , zfspool , btrfs , cifs e pbs . Aqui estão alguns exemplos.
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 obter mais informações.
Atualmente, o tipo zfspool pode ser usado apenas para images e conteúdos rootdir . Se você deseja armazenar os outros tipos de conteúdo em um volume ZFS, precisará especificá -los com DIRIR dir , PATH /<POOL>/<VOLUME> e adicione uma entrada em pve_zfs_create_volumes . Este exemplo adiciona um armazenamento iso em um pool ZFS:
pve_zfs_create_volumes:
- rpool/iso
pve_storages:
- name: iso
type: dir
path: /rpool/iso
content: [ "iso" ]
Consulte o link library/proxmox_storage.py para documentação do módulo.
Esta seção pode usar um pouco mais de amor. Se você estiver usando ativamente essa função para gerenciar seu cluster PVE CEPH, sinta -se à vontade para desenvolver esta seção mais completa e abrir uma solicitação de tração! Veja a edição #68.
O gerenciamento do PVE CEPH com esse papel é experimental. Embora os usuários tenham usado com sucesso essa função para implantar o PVE CEPH, ela não está totalmente testada no IC (devido à falta de dispositivos de bloco utilizáveis para usar como OSDs no Travis CI). Implante um ambiente de teste com sua configuração primeiro antes do Prod e relate quaisquer problemas se você se deparar com algum.
Essa função pode configurar o sistema de armazenamento CEPH em seus hosts Proxmox. As definições a seguir mostram algumas das configurações possíveis.
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 Por padrão, usa o filtro ansible.utils.ipaddr , que exige que a biblioteca netaddr seja instalada e utilizável pelo seu controlador Ansible.
pve_ceph_nodes Por padrão, usa pve_group , este parâmetro permite especificar em quais nós instalam o CEPH (por exemplo, se você não deseja instalar o CEPH em todos os seus nós).
pve_ceph_osds Por padrão, cria volumes de ceph não criptografados. Para usar volumes criptografados, o parâmetro encrypted deve ser definido por unidade para true .
Essa função pode ser configurada para permitir a passagem do dispositivo PCI do host Proxmox para as VMs. Esse recurso não está ativado por padrão, pois nem todas as placas -mãe e CPUs suportam esse recurso. Para ativar a passagem, a CPU de dispositivos deve suportar virtualização de hardware (VT-D para sistemas baseados em Intel e AMD-V para sistemas baseados em AMD). Consulte os manuais de todos os componentes para determinar se esse recurso é suportado ou não. As convenções de nomeação de vontade variam, mas geralmente são referidas como iommu, vt-d ou amd-v.
Ao ativar esse recurso, dispositivos dedicados (como uma GPU ou dispositivos USB) podem ser transmitidos para as VMs. Juntamente com dispositivos dedicados, vários dispositivos integrados, como a Intel ou a AMD Integrated GPUs, também podem ser transmitidos para as VMs.
Alguns dispositivos são capazes de tirar proveito do uso mediado. Os dispositivos mediados podem ser transmitidos para várias VMs para compartilhar recursos, enquanto ainda permanecem utilizáveis pelo sistema host. A divisão de dispositivos nem sempre é suportada e deve ser validada antes de ser ativada para evitar erros. Consulte o manual do dispositivo pelo qual você deseja passar para determinar se o dispositivo é capaz de uso mediado (atualmente essa função suporta apenas GVT-G; SR-IOV não é suportada no momento e deve ser ativada manualmente após a conclusão do papel).
A seguir, é apresentado um exemplo de configuração que permite a passagem do 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 é necessário para usar qualquer funcionalidade PCIE Passthrough. Sem isso ativado, todos os outros campos relacionados ao PCIE não serão utilizados.
pve_iommu_passthrough_mode ativando o modo de passagem iommu pode aumentar o desempenho do dispositivo. Ao ativar esse recurso, ele permite que as VMs ignorem a tradução padrão do DMA, que normalmente seria executada pelo hiper-visor. Em vez disso, o VMS passa o DMA solicita diretamente para o hardware iommu.
pve_iommu_unsafe_interrupts é necessário para ser ativado para permitir a passagem do PCI se o seu sistema não suportar o remapeamento interrompido. Você pode descobrir se o dispositivo suporta o remapeamento de interrupção usando dmesg | grep 'remapping' . Se você vir uma das seguintes linhas:
Em seguida, o remapeamento de interrupção do sistema é suportado e você não precisa ativar interrupções inseguras. Esteja ciente de que, ao ativar esse valor, seu sistema pode se tornar instável.
pve_mediated_devices_enabled Ativa o suporte GVT-G para dispositivos integrados, como a Intel IGPU. Nem todos os dispositivos suportam o GVT-G, por isso é recomendável verificar com seu dispositivo específico com antecedência para garantir que ele seja permitido.
pve_pcie_ovmf_enabled Ativa o GPU ovmf PCI Passthrough. Ao usar o OVMF, você deve selecionar 'OVMF' como a opção BIOS para a VM em vez de 'Seabios' no Proxmox. Essa configuração tentará optar por desativar dispositivos da arbitragem VGA, se possível.
pve_pci_device_ids é uma lista de IDs de dispositivo e fornecedor que desejam ser transmitidos para as VMs do host. Consulte a seção 'GPU Passthrough' no Wiki Proxmox para encontrar seu dispositivo específico e IDs do fornecedor. Ao definir esse valor, é necessário especificar um 'ID' para cada novo elemento na matriz.
pve_vfio_blacklist_drivers é uma lista de drivers a serem excluídos/na lista negra do host. Isso é necessário ao passar por um dispositivo PCI para impedir que o host use o dispositivo antes que ele possa ser atribuído a uma VM. Ao definir esse valor, é necessário especificar um 'nome' para cada novo elemento na matriz.
pve_pcie_ignore_msrs impede alguns aplicativos do Windows, como o GeForce Experience, o Passmark Performance Test e o Sisoftware Sandra de travar a VM. Esse valor é necessário apenas ao passar os dispositivos PCI para sistemas baseados no Windows.
pve_pcie_report_msrs pode ser usado para ativar ou desativar mensagens de registro de avisos do MSRS. Se você vir muitas mensagens de alerta no registro do sistema 'DMESG', esse valor pode ser usado para silenciar os avisos do MSRS.
Você pode configurar servidores métricos no Proxmox VE usando a variável de função pve_metric_servers . Abaixo está um exemplo de configuração 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 : (exigido) Identificador exclusivo para o servidor métrico.port : (opcional) porta do servidor métrico. O padrão é 8089 .server : (requerido) Nome do DNS ou endereço IP do servidor métrico.type : (opcional) Tipo de servidor métrico. Valores possíveis: influxdb , graphite . O padrão é influxdb .protocol : protocolo (opcional) usado para enviar métricas. Valores possíveis: udp , tcp , http , https . O padrão é udp .disable : (opcional) Desative o servidor métrico. O padrão é false .organization : (opcional) Nome da organização. Disponível apenas para influxo com a API HTTP V2.bucket : (opcional) Nome do balde para influxDB. Útil apenas com a API HTTP V2 ou compatível.token : (opcional) InfluxDB Token de acesso. Necessário somente ao usar a API HTTP V2.path : (opcional) Caminho da raiz de grafite. Disponível apenas para grafite.api_path_prefix : (Opcional) Prefixo prefixo inserido entre <host>:<port>/ e /api2/ . Útil se o serviço InfluxDB estiver sendo executado atrás de um proxy reverso. Disponível apenas para influxo com a API HTTP V2.timeout : (opcional) Tempo limite em segundos. Disponível apenas para influxDB com a API HTTP V2 ou o soquete TCP de grafite.max_body_size : (opcional) tamanho corporal máximo em bytes. Disponível apenas para influxo com a API HTTP V2. O padrão é 25000000 .mtu : (opcional) MTU para transmissão métrica UDP.verify_certificate : (Opcional) Verifique o certificado SSL. Disponível apenas para influxDB com https. O Proxmox 8.2 apresenta o Linux 6.8, o que pode causar problemas em algumas implantações. Para contornar isso, você pode fixar a versão do kernel usada para 6.5 adicionando a seguinte variável de função:
pve_default_kernel_version : 1.0.1 Isso cria um pino no pacote proxmox-default-kernel , que é o método sugerido pelo PVE. Posteriormente, pode ser removido por desativar essa variável de função.
Adicione esta seção ao seu ansible.cfg .
[ssh_connection]
ssh_args = -o ServerAliveInterval=20Questão de referência
Ao desenvolver novos recursos ou corrigir algo nessa função, você pode testar suas alterações usando o VAGrant (apenas o LibVirt é suportado atualmente). O manual pode ser encontrado em tests/vagrant (portanto, modifique as variáveis de grupo conforme necessário). Certifique -se de testar quaisquer alterações em todas as versões suportadas do Debian (atualize o VagrantFile localmente para usar o debian/bookworm64 , debian/bullseye64 ou debian/buster64 ) antes de enviar um PR.
Você também pode especificar um proxy de cache adequado (por exemplo, apt-cacher-ng , e ele deve ser executado na porta 3142) com a variável de ambiente APT_CACHE_HOST para acelerar o downloads do pacote, se você tiver um em execução localmente em seu ambiente. O manual Vagrant detectará se o proxy de cache está ou não disponível e o usará apenas se estiver acessível a partir da sua rede, para que você possa definir permanentemente essa variável em seu ambiente de desenvolvimento, se preferir.
Por exemplo, você pode executar o seguinte para mostrar a saída detalhada/mais fácil de ler, usar um proxy de cache e manter as VMs em execução se você tiver um erro (para que você possa solucioná -lo e/ou executar vagrant provision após a fixação):
APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error
Musee Ullah (@lae, [email protected]) - Desenvolvedor principal
FABIEN BRACHERE (@FBRACHERE) - Suporte de configuração de armazenamento
Gaudenz Steinlin (@gaundez) - Suporte de ceph, etc
Richard Scott (@Zenntrix) - Suporte de Ceph, suporte PVE 7.x, etc.
Thoralf Rickert -wendt (@trickert76) - suporte PVE 6.x, etc
Engin Dumlu (@RoadRunner)
Jonas Meurer (@mejo-)
Ondrej Flidr (@snipercze)
niko2 (@niko2)
Christian Aublet (@cauflet)
Gille Pietri (@Gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@Lexxxel) - Suporte PVE 8.x, etc.
Bruno Travouillon (@btravouillon) - Melhorias de UX
Tobias negd (@wu3rstle) - suporte de ceph
Pendagtp (@Pendagtp) - Suporte de CEPH
John Marion (@JMarionDev)
Foerkede (@foerkede) - Suporte de armazenamento ZFS
Guiffo Joel (@futuriste) - Suporte de configuração do pool
Adam Delo (@OL3D) - Suporte a Pcie Passthrough Antoine Thys (@thystips) - Suporte aos servidores métricos
Lista completa de colaboradores
