🚨 OpenStack Error Guide: 'Volume group not found' Cinder LVM backend failure

Exact Error Message

2026-06-27 18:02:14.771 13 ERROR cinder.volume.drivers.lvm
[req-9a2c1d4e-7b33-4e10-bb21-8a2c1d4e55f0 - - - - -] Volume group cinder-volumes not found.
2026-06-27 18:02:14.771 13 ERROR cinder.volume.manager Error encountered during initialization
of driver: LVMVolumeDriver
2026-06-27 18:02:14.771 13 ERROR cinder.volume.manager
cinder.exception.VolumeGroupNotFound: Unable to find Volume Group: cinder-volumes

From a host shell you will see the same thing:

# vgs cinder-volumes
  Volume group "cinder-volumes" not found
  Cannot process volume group cinder-volumes

What the Error Means

Cinder’s LVM driver stores each volume as a logical volume (LV) carved out of a single LVM volume group (VG), by default named cinder-volumes. On startup and on every create/extend, the driver runs vgs/lvs against that VG. VolumeGroupNotFound means the host running cinder-volume cannot see the configured VG at all — so the driver fails to initialize and the backend is marked down. New volume creates then fail with No valid backend because the LVM backend never came up.

The VG can be invisible for several reasons: it was never created, its underlying physical volume (PV) disappeared (a loop device not re-attached after reboot, a missing disk, an unactivated VG), the name in cinder.conf does not match the real VG, or LVM filters are hiding the device. Because the data lives on the PV, a missing VG is usually recoverable once the underlying storage is brought back and the VG re-activated — the volumes are not necessarily lost.

Common Causes

• VG was never created on this host (fresh node or misprovisioned backend).
• Loopback-backed PV not re-attached after reboot — common in lab/PoC setups using a file-backed loop device.
• Underlying disk/LUN missing or renamed — the PV’s device disappeared, so the VG is incomplete.
• VG not activated after boot — the VG exists but is inactive (vgchange -ay never ran).
• Name mismatch — volume_group in cinder.conf differs from the actual VG name.
• LVM device filter hiding the PV — lvm.conf filter/global_filter excludes the device.
• cinder-volume running on the wrong node — the VG lives on a different host than the one initializing the driver.

How to Reproduce the Error

In a lab, deactivate or remove the VG under a running cinder-volume:

1. Confirm the backend is healthy and vgs cinder-volumes shows the VG.
2. Deactivate it: simulate a post-reboot state where the VG is not active.
3. Restart cinder-volume.

The driver’s startup vgs finds nothing active, and initialization fails with Volume group cinder-volumes not found. A name typo in cinder.conf’s volume_group reproduces the mismatch variant immediately on restart.

Diagnostic Commands

Read-only. Determine whether the VG exists, is active, and matches the config.

# Does the VG exist and is it active? (host or inside the Kolla container)
# Traditional packages
vgs
vgs cinder-volumes
pvs
lvs cinder-volumes

# Kolla-Ansible (LVM tooling runs in the cinder_volume container)
docker exec cinder_volume vgs
docker exec cinder_volume pvs

  VG             #PV #LV #SN Attr   VSize    VFree
  cinder-volumes   1  12   0 wz--n- <200.00g  64.00g

Check what Cinder is configured to use and read the driver error:

# Configured VG name and driver
# Kolla-Ansible
docker exec cinder_volume grep -E 'volume_group|volume_driver' /etc/cinder/cinder.conf
docker logs cinder_volume 2>&1 | grep -i "VolumeGroupNotFound\|not found" | tail
# Traditional
grep -E 'volume_group|volume_driver' /etc/cinder/cinder.conf
journalctl -u openstack-cinder-volume | grep -i "VolumeGroupNotFound\|not found" | tail

Confirm the backend state from the API:

openstack volume service list --service cinder-volume

| cinder-volume | ctrl1@lvm | nova | enabled | down | 2026-06-27T18:02:14.000000 |

Step-by-Step Resolution

1. Check whether the VG exists at all. Run vgs. If cinder-volumes is absent, the VG is either missing, on the wrong host, or its PV is gone.

2. If the VG exists but is inactive, activate it:

   # Traditional
   vgchange -ay cinder-volumes
   # Kolla-Ansible
   docker exec cinder_volume vgchange -ay cinder-volumes

3. If the PV is missing, restore the underlying device. For loopback-backed labs, re-attach the backing file to a loop device and re-scan, then re-run vgs. For a real disk/LUN, confirm the device is present and re-scan with pvscan so the VG becomes complete.

4. Fix a name mismatch. Compare volume_group in cinder.conf with the actual VG name from vgs. If they differ, correct the config to match the real VG, then restart the service.

5. Check LVM filters if pvs does not show the expected device. An over-broad filter/global_filter in lvm.conf can hide the PV; adjust it to include the device, then pvscan.

6. Restart cinder-volume and confirm the backend comes up:

   docker restart cinder_volume            # Kolla-Ansible
   systemctl restart openstack-cinder-volume   # Traditional
   openstack volume service list --service cinder-volume

   The service should report up and new volume creates should succeed.

Prevention and Best Practices

• Ensure the VG activates automatically at boot (auto-activation enabled, no manual vgchange needed) so a reboot never strands the backend.
• Avoid loopback-file PVs in anything but throwaway labs — they routinely fail to re-attach after a reboot and produce exactly this error.
• Pin the device path for the PV (by-id / by-path) so a renamed disk does not orphan the VG.
• Keep lvm.conf filters as narrow as needed and document them, so a future device addition is not silently excluded.
• Monitor openstack volume service list and alert when the LVM backend reports down — that is the earliest sign the VG went missing, before users hit failed creates.

Related Errors

• No valid backend was found / No weighed backends available — the scheduler-side symptom once the LVM backend is down. Covered standalone in our /categories/openstack/ Cinder guides.
• Volume <id> stuck in creating — a create that hangs because the backend is degraded rather than cleanly failing.
• Failed to activate logical volume — the VG is present but an individual LV cannot activate (thin-pool or metadata issue).
• Insufficient free space on volume group — the VG exists and is active but is full; a capacity error, not a missing-VG error.

Frequently Asked Questions

Are my volumes lost when the VG is not found? Usually not. The data lives on the physical volume. If the PV is intact and you re-activate or restore the VG, the logical volumes (and your Cinder volumes) come back. Only a destroyed PV loses data.

Why does this happen after a reboot? Either the VG was not set to auto-activate, or its PV was a loop device or hot-plugged disk that did not re-attach on boot. The VG is then absent or inactive until manually restored.

How do I know if it is a name mismatch versus a truly missing VG? Run vgs with no arguments. If a VG exists under a different name, the config is wrong. If no VG appears at all, the VG or its PV is genuinely missing.

Where do I run the LVM commands in Kolla-Ansible? Inside the cinder_volume container via docker exec cinder_volume vgs/pvs/lvs, since that container owns the LVM tooling and config for the backend.

Will activating the VG fix the backend immediately? Activating the VG removes the cause, but cinder-volume may need a restart to re-initialize the driver. After the restart, openstack volume service list should show the backend up.