Description of problem: After upgrading DC and cluster from 3.6 or 4.0 to 4.1, the storage domain is upgraded automatically and the Discard Data option is available. But when trying to edit the storage domain to support the discard data, an error is shown saying it is not supported because the underlying storage is not supporting Discard, even though when creating new storage domain V4 in the same cluster from the same storage server, it can be configured with the discard option with no errors. Version-Release number of selected component (if applicable): ovirt-engine-4.1.0.3-0.1.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Create new DC and cluster and configure 3.6 or 4.0 version compatibility. 2. Create new storage domain and make sure the Discard option is not even available 3. Edit the cluster and change the compatibility version to 4.1, repeat for DC. 4. After the storage domain was updated to V4 version, edit the storage domain and check the Discard Data option. Actual results: Following error is shown: Error while executing action: Cannot edit Storage. Discard after delete is not supported by the underlying storage of storage-ge8-iscsi2. Expected results: Storage domain is updated. Additional info: engine.log 2017-02-05 15:04:00,784+02 WARN [org.ovirt.engine.core.bll.storage.domain.UpdateStorageDomainCommand] (default task-16) [22cd071d-d809-4a91-92e5-d5d3d2cd8860] Validation of action 'UpdateStorageDomain' failed for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__UPDATE,ACTION_TYPE_FAILED_DISCARD_AFTER_DELETE_NOT_SUPPORTED_BY_UNDERLYING_STORAGE,$storageDomainName storage-ge8-iscsi2
Created attachment 1247817 [details] engine.log
Thanks for the detailed description, Lilach! This is indeed a bug, although if I am not mistaken it is not the classic use case. The classic flow of upgrading a dc is: 1. Move the host to maintenance. 2. Update the host. 3. Change the cluster's version. 4. Change the dc's version. 5. Activate host. When the host is not moved to maintenance and then activated, the luns are not updated in the db with the new discard related information from vdsm, and thus the user gets the error message. Of course that this bug should be fixed, but I wanted to explain the cause for it before I specify the workaround. Well, the best thing that you can do is move the host to maintenance and then activate it. This will update all the luns in the dc. If that isn't possible, you can also move the storage domain to maintenance and then activate it, but note that this will only update that specific storage domain's luns and not the others ones.
The only effect is that some of the storage domains will not be updated with the discard ability and you will not be able to use discard with them, there is a workaround for that and it's a new feature thus not a regression, definitely not urgent and most likely not a blocker
-------------------------------------- Tested with the following code: ---------------------------------------- rhevm-4.1.1.3-0.1.el7.noarch vdsm-4.19.7-1.el7ev.x86_64 Tested with the following scenario: Steps to Reproduce: 1. Create new DC and cluster and configure 3.6 or 4.0 version compatibility. 2. Create new storage domain and make sure the Discard option is not even available 3. Edit the cluster and change the compatibility version to 4.1, repeat for DC. 4. After the storage domain was updated to V4 version, edit the storage domain and check the Discard Data option. Actual results: Storage domain is updated. Expected results: Moving to VERIFIED!