Bug 1710575
Summary: | Incorrect capacity and allocation fields in iscsi pool XML | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Katerina Koukiou <kkoukiou> |
Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
Status: | CLOSED ERRATA | QA Contact: | gaojianan <jgao> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.1 | CC: | jdenemar, meili, mprivozn, rbalakri, xuzhang, yalzhang |
Target Milestone: | rc | ||
Target Release: | 8.1 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-4.5.0-30.el8 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-11-05 20:49:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1709708 |
Description
Katerina Koukiou
2019-05-15 19:41:48 UTC
I think I know what the problem is. When libvirt starts an iscsi pool it then calls virWaitForDevices() which is supposed to call 'udevadm settle' so that udev is done and libvirt can proceed to discovering LUNs and their sized. Well, since in RHEL-8 the build root is as minimal as possible there's no 'udevadm' binary and thus our configure script hasn't found any: From libvirt-4.5.0-24.module+el8.1.0+3205+41ff0a42 build.log: checking for udevadm... no checking for udevsettle... no And therefore our virWaitForDevices() is a NO-OP and therefore we proceed to scanning LUNs before udev even created some nodes. Let me see if I can cook a patch that will resolve this. BTW: This also explains why I was unable to reproduce this under GDB because stepping through lines gives system enough time to settle down. To POST: 3c8d5762a9 m4: Drop needless string checks 523b799d3c m4: Provide default value fore UDEVADM 2944dcb2de lib: Drop UDEVSETTLE 0cabcd98f1 virWaitForDevices: Drop confusing part of comment v5.3.0-93-g3c8d5762a9 Verified at; libvirt-daemon-driver-storage-rbd-4.5.0-30.virtcov.el8.x86_64 libvirt-daemon-driver-qemu-debuginfo-4.5.0-30.virtcov.el8.x86_64 Steps to Reproduce: 1. Create a ramdisk backstore of 50M size, an ISCSI target and a LUN associated with that. targetcli /backstores/ramdisk create test 50M targetcli /iscsi create iqn.2019-09.cockpit.lan targetcli /iscsi/iqn.2019-09.cockpit.lan/tpg1/luns create /backstores/ramdisk/test targetcli /iscsi/iqn.2019-09.cockpit.lan/tpg1/ set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1 On my system the iscsi setup looks like that # targetcli ls o- / ................................................................................................................ [...] o- backstores ..................................................................................................... [...] | o- block ......................................................................................... [Storage Objects: 0] | o- fileio ........................................................................................ [Storage Objects: 0] | o- pscsi ......................................................................................... [Storage Objects: 0] | o- ramdisk ....................................................................................... [Storage Objects: 1] | o- test ....................................................................................... [(50.0MiB) activated] | o- alua .......................................................................................... [ALUA Groups: 1] | o- default_tg_pt_gp .............................................................. [ALUA state: Active/optimized] o- iscsi ................................................................................................... [Targets: 1] | o- iqn.2019-09.cockpit.lan .................................................................................. [TPGs: 1] | o- tpg1 ......................................................................................... [gen-acls, no-auth] | o- acls ................................................................................................. [ACLs: 1] | | o- iqn.1994-05.com.redhat:8dd547fc8758 ......................................................... [Mapped LUNs: 1] | | o- mapped_lun0 ....................................................................... [lun0 ramdisk/test (rw)] | o- luns ................................................................................................. [LUNs: 1] | | o- lun0 ....................................................................... [ramdisk/test (default_tg_pt_gp)] | o- portals ........................................................................................... [Portals: 1] | o- 0.0.0.0:3260 ............................................................................................ [OK] o- loopback ................................................................................................ [Targets: 0] 2. Create a libvirt iscsi storage pool on the same machine with the following XML # virsh pool-dumpxml my_iscsi_pool <pool type='iscsi'> <name>my_iscsi_pool</name> <source> <host name='127.0.0.1' port='3260'/> <device path='iqn.2019-09.cockpit.lan'/> </source> <target> <path>/dev/disk/by-path</path> </target> </pool> 3. Confirm that the capacity is 50M # virsh pool-dumpxml my_iscsi_pool <pool type='iscsi'> <name>my_iscsi_pool</name> <uuid>b585990a-42d3-4db2-9e8c-59655bfb7efa</uuid> <capacity unit='bytes'>52428800</capacity> <allocation unit='bytes'>52428800</allocation> <available unit='bytes'>0</available> <source> <host name='127.0.0.1' port='3260'/> <device path='iqn.2019-09.cockpit.lan'/> </source> <target> <path>/dev/disk/by-path</path> </target> </pool> Worked as expected Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:3345 |