New VG erases the existing one

[Jonathan-Caruana]

Hi,

We tried to use this simply playbook on our fresh test VM :

- name: linux-system-roles-storage
  hosts: "{{ _target }}"
  roles:
    - linux-system-roles-storage
  vars:
    storage_pools:
      - name: opt
        disks: ["sdb"]
        volumes:
          - name: opt
            size: "2g"
            fs_type: xfs
            mount_point: "/opt"

  post_tasks:
  - name: Create directories /opt/apps and /opt/data
    file:
      path: "{{ item }}"
      state: directory
      mode: '0755'
    loop:
      - /opt2/apps
      - /opt2/data

Before running the playbook, the vgdisplay looks like this :

[root@test ~]# vgdisplay
  --- Volume group ---
  VG Name               cs
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <19.00 GiB
  PE Size               4.00 MiB
  Total PE              4863
  Alloc PE / Size       4862 / 18.99 GiB
  Free  PE / Size       1 / 4.00 MiB
  VG UUID               Ue0Q21-WvLb-HfCT-uNTE-o0dd-gvbW-RFlPLf

and lsblk command show :

[root@test ~]# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   20G  0 disk
├─sda1        8:1    0    1G  0 part /boot
└─sda2        8:2    0   19G  0 part
  ├─cs-root 253:0    0    8G  0 lvm  /
  ├─cs-swap 253:1    0    4G  0 lvm  [SWAP]
  └─cs-var  253:2    0    7G  0 lvm  /var
sdb           8:16   0    2G  0 disk
sr0          11:0    1  374K  0 rom
sr1          11:1    1    2K  0 rom

But after running the playbook it seems the "cs" VG was dropped (and all LV and PV related to /dev/sda) and replaced by "opt" VG :

[root@test ~]# vgdisplay
  --- Volume group ---
  VG Name               opt
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <2.00 GiB
  PE Size               4.00 MiB
  Total PE              511
  Alloc PE / Size       511 / <2.00 GiB
  Free  PE / Size       0 / 0
  VG UUID               lMwTBE-4I96-Ibez-8I2g-bf4u-aRGy-Ti5hic

[root@test ~]# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   20G  0 disk
├─sda1        8:1    0    1G  0 part /boot
└─sda2        8:2    0   19G  0 part
  ├─cs-root 253:0    0    8G  0 lvm  /
  ├─cs-swap 253:1    0    4G  0 lvm  [SWAP]
  └─cs-var  253:2    0    7G  0 lvm  /var
sdb           8:16   0    2G  0 disk
└─opt-opt   253:3    0    2G  0 lvm  /opt
sr0          11:0    1  374K  0 rom
sr1          11:1    1    2K  0 rom

Of course if the VM is restarted it never goes up and running because the system was on the sda disk.

For more testing we have tried to run the playbook again to create another VG called "opt2" with another additionnal disk "sdc"

- name: linux-system-roles-storage
  hosts: "{{ _target }}"
  roles:
    - linux-system-roles-storage
  vars:
    storage_pools:
      - name: opt2
        disks: ["sdc"]
        volumes:
          - name: opt
            size: "2g"
            fs_type: xfs
            mount_point: "/opt2"

  post_tasks:
  - name: Create directories /opt/apps and /opt/data
    file:
      path: "{{ item }}"
      state: directory
      mode: '0755'
    loop:
      - /opt2/apps
      - /opt2/data

This time, the new VG was added without delete the first one.

[root@test ~]# lvdisplay
  --- Logical volume ---
  LV Path                /dev/opt2/opt
  LV Name                opt
  VG Name                opt2
  LV UUID                JFIFWX-0kvr-BO61-yOGJ-3lSD-MLL6-h9qIok
  LV Write Access        read/write
  LV Creation host, time vs-inf-int-jcar-fr-301, 2024-02-08 09:51:49 +0100
  LV Status              available
  # open                 1
  LV Size                2.00 GiB
  Current LE             512
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4

  --- Logical volume ---
  LV Path                /dev/opt/opt
  LV Name                opt
  VG Name                opt
  LV UUID                rG0r0h-Q1bm-Xa3e-jlhV-WdMg-khp6-XcD2cP
  LV Write Access        read/write
  LV Creation host, time vs-inf-int-jcar-fr-301, 2024-02-08 09:47:13 +0100
  LV Status              available
  # open                 1
  LV Size                <2.00 GiB
  Current LE             511
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:3

How can we do to make this playbook functionnal without breaking any existing VolumeGroup created without this role?

Kind regards,

[vojtechtrefny]

This is a bug in blivet (storage library the role uses), the fix is unfortunately not yet available in RHEL/CentOS. The good news is that the existing VG (cs in your case) was not removed, it is just ignored by the system because its PVs are not present in the LVM devices file, you can fix this by running vgimportdevices -a, all VGs on the system should be visible after running this. (And running this command in the playbook at any stage is also a simple workaround for this bug.)

[richm]

@vojtechtrefny is the blivet fix available in the latest composes?

[vojtechtrefny]

Yes, the fix is available in RHEL 9.4 (8 was not affected).