KVM: Cannot find any matching source devices for logical volume group vg2

Posted on Posted in Hardware, Operating systems Tagged with , ,

I installed Centos 7 on a brand new machine about a half a year ago, and set up KVM with two data pools – one just a regular directory for old raw images, the second being an LVM volume group. Later, I added one additional physical disk to the machine, for local backups, which turned out to be an important detail later.

Nowadays I wanted to start a new virtual machine but to my surprise, the data pool based on LVM volume group ‘vg2’ wasn’t active:

# virsh pool-list
Name State Autostart 
-------------------------------------------
backups active yes 
vg2 inactive yes

The LVM itself seemed to be working just fine, as well as the one virtual machine which was already residing in a logical volume in this particular data pool. But the data pool would not get activated, no matter if I tried from virsh:

unsupported configuration: cannot find any matching source devices for logical volume group 'vg2'

or from virt-manager:

Error starting pool 'vg2': unsupported configuration: cannot find any
matching source devices for logical volume group 'vg2'

Eventually, it turned out that when I had added the physical disk for backups into the machine back then, this new disk got /dev/sda assigned while the original old disk got /dev/sdb as the device name. LVM was able to cope with the change, but libvirt remembered the original value:

# virsh pool-dumpxml vg2
<pool type='logical'>
 <name>vg2</name>
 <uuid></uuid>
 <capacity unit='bytes'>1351803207680</capacity>
 <allocation unit='bytes'>461373440000</allocation>
 <available unit='bytes'>890429767680</available>
 <source>
 <device path='/dev/sda7'/>
 <name>vg2</name>
 <format type='lvm2'/>
 </source>
 <target>
 <path>/dev/vg2</path>
 </target>
</pool>

Luckily for me, I was not the first one to run into this issue, so it was an easy fix:

 <device path='/dev/sdb7'/>

After changing the device path to the correct device name, data pool was able to start again. In the referenced bug ticket, it was stated that removing the device path altogether works just as well and might actually be a better option because device path is only needed when storage pool is being defined for the first time.