When adding a Direct LUN via the API, there are two flavors that can be used: 1. With a HOST element. In this case, the host is used for sanity checks (e.g., that the LUN is visible) and to retrieve basic information about the LUN (e.g., size) 2. Without a HOST element. In this case, the operation is a database-only operation, and the storage is never accessed. While this is the intended behavior, it is not intuitive, and the documentation in DisksService#Add should be improved to explain this. An example of how this behavior is non intuitive can be seen in Bug #1404389: +++ This bug was initially created as a clone of Bug #1404389 +++ Description of problem: When adding a 50 GB direct lun to the system via REST API, it shows it's size is < 1 GB. The POST body to /api/disks is: <disk> <alias>direct_lun_test</alias> <lun_storage> <logical_units> <logical_unit id="LUN_ID"> <address>ISCSI_SERVER_IP</address> <port>3260</port> <target>LUN_TARGET</target> </logical_unit> </logical_units> <type>iscsi</type> </lun_storage> </disk> Version-Release number of selected component (if applicable): 4.1.0-0.2.master.20161212071212.git8a015dd.el7.centos How reproducible: Add direct Steps to Reproduce: 1. Send POST request to /api/disks with body: <disk> <alias>direct_lun_test</alias> <lun_storage> <logical_units> <logical_unit id="LUN_ID"> <address>ISCSI_SERVER_IP</address> <port>3260</port> <target>LUN_TARGET</target> </logical_unit> </logical_units> <type>iscsi</type> </lun_storage> </disk> 2. Check the disk's size 3. Actual results: Expected results: Additional info: --- Additional comment from Allon Mureinik on 2016-12-14 00:52:11 IST --- Without a host parameter, this just adds a LUN to the database. It should be refreshed when you try to use it. Can you please try with the host element and check if it gets the size registered? --- Additional comment from Raz Tamir on 2016-12-14 01:39:54 IST --- Allon, When adding the host it does show the correct LUN size. When adding it without the host attribute and attach it to VM, the size isn't refreshed and the VM see it's real size (# lsblk) --- Additional comment from Allon Mureinik on 2016-12-15 15:56:53 IST --- OK, I think there are two issues here: (In reply to Raz Tamir from comment #2) > Allon, > When adding the host it does show the correct LUN size. Good news. As I noted in comment 1, when a <host> element is not provided, this is just a DB operation, and no details from the LUN itself are saved to the DB. This is the intended behavior, although I agree this is not necessarily intuitive, and should be documented better. Juan - I guess that DisksService#Add is the right place to document it? > When adding it without the host attribute and attach it to VM, the size > isn't refreshed and the VM see it's real size (# lsblk) After going over the code again, this indeed is not the behavior. We need some way to refresh the LUNs details, which, AFAIK, we don't have. I think we should open a new bug (RFE?) on this, and prioritize it with PM. --- Additional comment from Idan Shaby on 2016-12-15 16:05:33 IST --- This seems to be like a dup of bug 1275649 which I solved more than a year ago. Regarding a scenario where you add a direct lun without a host - Allon I think we talked about it a while ago and I raised the idea that we can call GetDeviceList with a random host in the vm's dc when we attach the direct lun to that vm. If we agree on the idea, this should indeed be a new RFE, IMHO. --- Additional comment from Juan Hernández on 2016-12-15 17:02:51 IST --- (In reply to Allon Mureinik from comment #3) > Juan - I guess that DisksService#Add is the right place to document it? Yes, that is the right place. --- Additional comment from Allon Mureinik on 2016-12-18 11:43:28 IST --- (In reply to Idan Shaby from comment #4) > This seems to be like a dup of bug 1275649 which I solved more than a year > ago. Seems so, yes, but let's keep this BZ for future work described in comment 3. > > Regarding a scenario where you add a direct lun without a host - Allon I > think we talked about it a while ago and I raised the idea that we can call > GetDeviceList with a random host in the vm's dc when we attach the direct > lun to that vm. > > If we agree on the idea, this should indeed be a new RFE, IMHO. Not sure if attaching is the right event to trigger this (need PM input here). But as this was always the behavior, and I don't see any critical flow blocked by NOT having this new capability, I agree we should treat this as an RFE. Raz/Yaniv - if you disagree, please weigh in here.
If you are already into this, I'd appreciate if you can also give an example of creating one against multiple IPs - do you have to use multiple logical_unit objects with different ISCSI_SERVER_IP , etc.
rhevm-4.1.0.3-0.1.el7.noarch The explanation why the disk size is reported wrongly is not documented in the response body, I this it should be. Add direct LUN request: <disk> <alias>direct_lun_test</alias> <lun_storage> <logical_units> <logical_unit id="3514f0c5a516008d7"> <address>10.35.146.129</address> <address>10.35.146.163</address> <address>10.35.146.193</address> <address>10.35.146.225</address> <port>3260</port> <target>iqn.2008-05.com.xtremio:xio00153500071-514f0c50023f6c00</target> </logical_unit> </logical_units> <type>iscsi</type> </lun_storage> </disk> =============================================================== Add direct LUN response: <disk href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f" id="7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f"> <actions> <link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/export" rel="export"/> <link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/move" rel="move"/> <link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/sparsify" rel="sparsify"/> <link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/copy" rel="copy"/> </actions> <name>direct_lun_test</name> <link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/permissions" rel="permissions"/> <link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/statistics" rel="statistics"/> <alias>direct_lun_test</alias> <lun_storage id="3514f0c5a516008d7"> <logical_units> <logical_unit id="3514f0c5a516008d7"> <disk_id>7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f</disk_id> <paths>0</paths> <size>0</size> </logical_unit> </logical_units> </lun_storage> <propagate_errors>false</propagate_errors> <shareable>false</shareable> <storage_type>lun</storage_type> <wipe_after_delete>false</wipe_after_delete> </disk>
model doesn't include the fix for the bug. Please verify with CI it is in the latest build.
This bug was accidently moved to ON_QA, and this build indeed does not include the fix. It is, however, merged to the correct branch, so the next build should include it. Pushing out to be verified when the build is available.
The model now includes the right information regarding adding direct LUN: Adding a new direct LUN disk: When adding a new floating direct LUN via the API, there are two flavors that can be used: With a host element - in this case, the host is used for sanity checks (e.g., that the LUN is visible) and to retrieve basic information about the LUN (e.g., size and serial). Without a host element - in this case, the operation is a database-only operation, and the storage is never accessed. ============ Used: rhevm-4.1.1.2-0.1.el7.noarch ovirt-engine-restapi-4.1.1.2-0.1.el7.noarch