View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017351 | CentOS-8 | libvirt | public | 2020-05-10 15:21 | 2020-05-10 15:21 |
| Reporter | KALIBR-10 | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 8.1.1911 | ||||
| Summary | 0017351: libvirtd starts before lvm activation | ||||
| Description | Hi everyone! The datastore is connected to the server using the iSCSI protocol + multipath + lvm. Two pools have been added through virsh and everyone has the startup option. Once the system is restarted, one pool is not available because libvirtd is loaded before it is initialized by the system. /var/log/messages (Pay attention to the time!) May 10 14:33:37 mlxvm01 libvirtd[5665]: 2020-05-10 11:33:37.481+0000: 5821: error : virStorageBackendLogicalMatchPoolSource:662 : unsupported configuration: cannot find logical volume group name 'dcomp_vol2' May 10 14:33:37 mlxvm01 libvirtd[5665]: 2020-05-10 11:33:37.481+0000: 5821: error : storageDriverAutostartCallback:189 : internal error: Failed to autostart storage pool 'DCOMP-VOL2': unsupported configuration: cannot find logical volume group name 'dcomp_vol2' A Secunda later May 10 14:33:38 mlxvm01 lvm[6546]: pvscan[6546] PV /dev/mapper/dcomp_vol2 online, VG dcomp_vol2 is complete. May 10 14:33:38 mlxvm01 lvm[6546]: pvscan[6546] VG dcomp_vol2 run autoactivation. The solution is to restart libvirtd after booting the system, or to run libvirtd by timer, which is not convenient. I think it would be better to run libvirtd after activating all physical and logical volumes. Sorry about the mistakes, I 'm writing through a translator. I thank for attention) | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-05-10 15:21 | KALIBR-10 | New Issue |
