LVM, filesystem e montagem persistente | RHCE in Ansible: automação e operação

Separar as camadas

Um batch de reconciliação aproxima-se do limite de espaço. A equipa de storage aumentou a capacidade apresentada à VM, mas df continua igual. O diagnóstico deve localizar a camada ainda não expandida: dispositivo, PV, VG, LV ou filesystem. Espaço disponível no VG não é espaço livre no filesystem. Também não é necessário alterar todas as camadas em todas as mudanças; uma reserva já existente no VG pode bastar. Regista dispositivo e UUID, filesystem, montagem, ocupação e capacidade livre antes de decidir. Um nome como /dev/sdb pode mudar entre máquinas ou arranques e não constitui autorização para formatar um disco.

Um alvo repetível

O exercício usa um LV XFS de laboratório já existente e montado em /srv/dr-batch. O nome é labvg/batch e o alvo é pelo menos 6 GiB. Antes de executar, confirma numa VM RHEL 10 descartável que o VG tem capacidade suficiente e que o volume não contém dados a conservar. O playbook compara o UUID fornecido com o observado e rejeita outro tipo de filesystem ou montagem. size: 6g exprime um alvo absoluto; size: +2g exprime um incremento que pode voltar a crescer em cada repetição. shrink: false impede reduzir um LV que já seja maior, pelo que o contrato é um limite inferior, não tamanho exatamente igual a 6 GiB.

Crescimento e recuperação

resizefs pede o crescimento do filesystem juntamente com o LV nos tipos suportados. Mesmo assim, confirma ambos os resultados: uma falha pode deixar o LV maior sem completar o filesystem. Não confundas esta condição parcial com perda automática de dados, nem a declares resolvida pelo tamanho do LV. Para XFS, não planeies uma redução como reversão simples do crescimento; a documentação RHEL não suporta essa redução. Se o requisito passar a ser um volume menor, prepara migração ou restauro para um destino apropriado e valida a aplicação. Um snapshot não substitui por si um plano de recuperação testado e pode depender da mesma capacidade limitada.

Persistência e aceitação

state: mounted configura a entrada persistente e a montagem atual. present trata a configuração persistente sem garantir a montagem atual; ephemeral serve uma montagem temporária sem escrever fstab. Usa o estado que corresponde ao contrato. Para aceitar o exercício, compara lvs, findmnt e df, verifica escrita e leitura de dados sintéticos e repete o playbook. Depois reinicia a VM de laboratório de forma controlada e volta a observar o mesmo UUID no mesmo ponto de montagem. A existência de uma linha em fstab não prova que o dispositivo estará disponível no arranque nem que a aplicação consegue atravessar os diretórios.

Estado do exercício

Este exemplo foi verificado quanto a sintaxe e resolução dos módulos, não executado sobre LVM real. Instala as collections indicadas em requirements.yml e fornece inventário rhel_lab, lab_confirmed=true e expected_uuid apenas depois de preparar a VM descartável. O exemplo começa num LV existente; não provisiona discos, PVs, VG ou filesystem inicial. Esses pré-requisitos e as observações posteriores fazem parte do trabalho prático a realizar.

# Exercise for a disposable RHEL 10 VM with an existing XFS lab LV.
# Syntax checked only; no LVM, mount or reboot execution is claimed.
- name: Grow an identified lab filesystem without allowing shrink
  hosts: rhel_lab
  become: true
  gather_facts: true
  vars:
    lab_vg: labvg
    lab_lv: batch
    lab_path: /srv/dr-batch
  pre_tasks:
    - name: Require an explicit disposable lab and expected UUID
      ansible.builtin.assert:
        that:
          - lab_confirmed | default(false) | bool
          - ansible_distribution == 'RedHat'
          - ansible_distribution_major_version == '10'
          - expected_uuid | default('') | length > 0
    - name: Read identity of the existing filesystem
      ansible.builtin.command:
        argv: [blkid, -s, UUID, -o, value, "/dev/{{ lab_vg }}/{{ lab_lv }}"]
      register: observed_uuid
      changed_when: false
    - name: Read existing filesystem type
      ansible.builtin.command:
        argv: [blkid, -s, TYPE, -o, value, "/dev/{{ lab_vg }}/{{ lab_lv }}"]
      register: observed_type
      changed_when: false
    - name: Reject unexpected volume identity or type before resizing
      ansible.builtin.assert:
        that:
          - observed_uuid.stdout | trim == expected_uuid
          - observed_type.stdout | trim == 'xfs'
    - name: Confirm that XFS is already mounted at the intended lab path
      ansible.builtin.command:
        argv: [findmnt, --noheadings, --source, "UUID={{ expected_uuid }}", --output, TARGET]
      register: current_mount
      changed_when: false
    - name: Reject unexpected mount identity before growth
      ansible.builtin.assert:
        that:
          - current_mount.stdout | trim == lab_path
  tasks:
    - name: Grow to at least six GiB without shrinking a larger LV
      community.general.lvol:
        vg: "{{ lab_vg }}"
        lv: "{{ lab_lv }}"
        size: 6g
        shrink: false
        resizefs: true
        state: present
    - name: Keep the identified filesystem mounted and configured
      ansible.posix.mount:
        path: "{{ lab_path }}"
        src: "UUID={{ expected_uuid }}"
        fstype: xfs
        opts: defaults
        state: mounted

NA PRÁTICA

LV passa de 4 para 6 GiB, mas df ainda mostra 4: falta confirmar e tratar a camada do filesystem.

Armadilhas comuns

Incremento repetido; redução XFS tratada como rollback; fstab como prova de reboot; identidade presumida pelo nome do disco.

Tópicos relacionados: SELinux: mapeamento e estado efetivo · Serviços, firewall e validação externa

Leva esta ideia contigo

Confirma identidade e mede capacidade, filesystem, montagem e utilização separadamente.

Criar conta

Referência: Logical volume module · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned