Created attachment 1231294 [details] engine and vdsm logs 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:
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?
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)
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.
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.
(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.
(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.
Verified on ovirt-engine- 4.2.0-0.0.master.20170725202023.git561151b.el7.centos Added new direct lun with: <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> The disk was added and its size is < 1 GB. Executed POST to /api/disks/<DISK_ID>/refreshlun <action> <host> <name>host_mixed_1</name> </host> </action> LUN refreshed and its actual size is now displayed
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.