[Bug 1801918] Re: storage pool with persistent device names fails
Christian Ehrhardt
1801918 at bugs.launchpad.net
Tue Nov 6 13:37:41 UTC 2018
Error on starting the device:
error : virStorageBackendLogicalMatchPoolSource:692 : unsupported configuration: cannot find any matching source devices for logical volume group 'testpool1'
That error from the log matches the error in the UI of virsh.
The reason is that even thou it was defined by-path the lvm toolchain
has stored it as /dev/vdd and /dev/vdc
$ sudo /sbin/pvs --noheadings -o pv_name,vg_name
/dev/vdc testpool1
/dev/vdd testpool2
That is exactly the command it uses to build a list of existing VGs and then it looks for.
It finds the pool and then will check for the sources that are registered.
666 /* If the pool has defined source device(s), then let's make sure
667 * they match as well; otherwise, matching can only occur on the
668 * pool's name.
669 */
670 if (!def->source.ndevice) {
671 ret = true;
672 goto cleanup;
673 }
674
675 /* Let's make sure the pool's device(s) match what the pvs output has
676 * for volume group devices.
677 */
678 for (i = 0; i < def->source.ndevice; i++) {
679 for (j = 0; j < thisSource->ndevice; j++) {
680 if (STREQ(def->source.devices[i].path,
681 thisSource->devices[j].path))
682 matchcount++;
683 }
684 }
685
686 /* If we didn't find any matches, then this pool has listed (a) source
687 * device path(s) that don't/doesn't match what was created for the pool
688 */
689 if (matchcount == 0) {
Since this will not match as above output has stored it as /dev/vdd it
cann't find it and will hit the issue described here.
Commands from the pool-build run:
/sbin/pvcreate /dev/disk/by-path/virtio-pci-0000:00:07.0
/sbin/vgcreate testpool1 /dev/disk/by-path/virtio-pci-0000:00:07.0
I cleared the vg/lv/pv configuration from my disks and did the same without any libvirt in play.
ubuntu at cosmic-storage-pools:~$ sudo /sbin/pvcreate /dev/disk/by-path/virtio-pci-0000:00:07.0
Physical volume "/dev/disk/by-path/virtio-pci-0000:00:07.0" successfully created.
ubuntu at cosmic-storage-pools:~$ sudo /sbin/vgcreate testpool1 /dev/disk/by-path/virtio-pci-0000:00:07.0
Volume group "testpool1" successfully created
ubuntu at cosmic-storage-pools:~$ sudo vgdisplay
--- Volume group ---
VG Name testpool1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 28.00 MiB
PE Size 4.00 MiB
Total PE 7
Alloc PE / Size 0 / 0
Free PE / Size 7 / 28.00 MiB
VG UUID 0P3X39-nzR0-OtOP-3sts-W3oz-N5z6-tezzgA
ubuntu at cosmic-storage-pools:~$ sudo pvdisplay
--- Physical volume ---
PV Name /dev/vdc
VG Name testpool1
PV Size 30.00 MiB / not usable 2.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 7
Free PE 7
Allocated PE 0
PV UUID UstNOO-rYvf-9RDP-2Kfz-laI9-cMTr-5VSr16
ubuntu at cosmic-storage-pools:~$ sudo /sbin/pvs --noheadings -o pv_name,vg_name
/dev/vdc testpool1
As you can see already lvm tools do the remapping from by-path and store the current raw device path - there is not much libvirt can do about it.
We have to consider if it is an lvm2 issue thou - I'll re-tag the bug
here.
@Jan - could you add a link to the upstream Mailing list discussion you
referred please?
** Also affects: lvm2 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: libvirt (Ubuntu)
Status: Confirmed => Invalid
** Description changed:
+ lvm2 tools do not store by-path values in their config.
+ That can drive scripts/tools (like the libvirt case here) mad.
+ Simplified example:
+
+ $ sudo /sbin/pvcreate /dev/disk/by-path/virtio-pci-0000:00:07.0
+ $ sudo /sbin/pvs --noheadings -o pv_name,vg_name
+ /dev/vdc
+
+ It is NOT using /dev/disk/by-path/virtio-pci-0000:00:07.0 as instructed,
+ but instead did the mapping to /dev/vdd and keeps that from now on.
+
+ I know that "inside" lvm all that is done via metadata and it won't matter.
+ But tools around it get confused.
+ Not sure yet if it is a real issue, or just "works as designed".
+
+
+ --- started as libvirt issue - keeping old desc below ---
+
I am trying to create a logical volume storage pool with persistent
device names for the block devices, because I can't/don't want to ensure
that /dev/sd* names are persistent through reboots.
virsh # pool-define-as web2067 logical - -
/dev/disk/by-path/pci-0000:18:00.0-scsi-0:2:2:0 web2067 /dev/web2067
virsh # pool-build web2067
These two steps work as expected and the pv and the vg get created, but
when I try to start the pool I get the following error:
virsh # pool-start web2067
error: Failed to start pool web2067
error: unsupported configuration: cannot find any matching source
devices for logical volume group 'web2067'
If I do the same steps just with /dev/sdX instead of
/dev/disk/by-path/..., the pool gets created correctly.
- According to the libvirt mailing list /dev and /dev/disk/by-path are
+ According to the libvirt mailing list /dev and /dev/disk/by-path are
supposed to work the same way.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1801918
Title:
storage pool with persistent device names fails
Status in libvirt package in Ubuntu:
Invalid
Status in lvm2 package in Ubuntu:
New
Bug description:
lvm2 tools do not store by-path values in their config.
That can drive scripts/tools (like the libvirt case here) mad.
Simplified example:
$ sudo /sbin/pvcreate /dev/disk/by-path/virtio-pci-0000:00:07.0
$ sudo /sbin/pvs --noheadings -o pv_name,vg_name
/dev/vdc
It is NOT using /dev/disk/by-path/virtio-pci-0000:00:07.0 as
instructed, but instead did the mapping to /dev/vdd and keeps that
from now on.
I know that "inside" lvm all that is done via metadata and it won't matter.
But tools around it get confused.
Not sure yet if it is a real issue, or just "works as designed".
--- started as libvirt issue - keeping old desc below ---
I am trying to create a logical volume storage pool with persistent
device names for the block devices, because I can't/don't want to ensure
that /dev/sd* names are persistent through reboots.
virsh # pool-define-as web2067 logical - -
/dev/disk/by-path/pci-0000:18:00.0-scsi-0:2:2:0 web2067 /dev/web2067
virsh # pool-build web2067
These two steps work as expected and the pv and the vg get created, but
when I try to start the pool I get the following error:
virsh # pool-start web2067
error: Failed to start pool web2067
error: unsupported configuration: cannot find any matching source
devices for logical volume group 'web2067'
If I do the same steps just with /dev/sdX instead of
/dev/disk/by-path/..., the pool gets created correctly.
According to the libvirt mailing list /dev and /dev/disk/by-path are
supposed to work the same way.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1801918/+subscriptions
More information about the foundations-bugs
mailing list