Created attachment 1420757 [details] engine.log and vdsm.log Description of problem: When registering a VM that has some disks on unattached storage domains, errors are generated to the engine.log showing the missing storage domains names as 'null'. Version-Release number of selected component: rhvm-4.2.2.6-0.1.el7.noarch vdsm-4.20.23-1.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. create a VM with disks on 6 storage domains: 2 NFS, 2 iscsi, 2 gluster (one on each storage domain) 2. detach all storage domains 3. attach only part of them (one of each type) 4. register the VM Actual results: Error in engine.log, for each disk that wasn't registered, showing null as the storage domain name: 2018-04-11 23:06:15,347+03 ERROR [org.ovirt.engine.core.bll.validator.ImportValidator] (default task-23) [5b8e49a8-98bc-448a-861d-ae815b56bd9a] Storage Domain 'null' with id 'dd0bf7a0-9a84-4290-9568-6e0c3538f886', could not be found for disk alias 'test_vm_disk_nfs_4' with image id 'df183cf5-2661-4d11-a3bf-a324e8fea78c' 2018-04-11 23:06:15,347+03 ERROR [org.ovirt.engine.core.bll.validator.ImportValidator] (default task-23) [5b8e49a8-98bc-448a-861d-ae815b56bd9a] Storage Domain 'null' with id '70bffef2-09ef-4001-b842-f858c255852b', could not be found for disk alias 'test_vm_disk_iscsi_4' with image id 'dff4dc75-56e2-4368-8473-89ac0e556d10' 2018-04-11 23:06:15,349+03 ERROR [org.ovirt.engine.core.bll.validator.ImportValidator] (default task-23) [5b8e49a8-98bc-448a-861d-ae815b56bd9a] Storage Domain 'null' with id '6f11866f-dcf4-4aeb-86d3-889f06a2794b', could not be found for disk alias 'test_vm_disk_gluster_4' with image id '68580eaa-3cd6-4706-8c75-6101cd573d5c' Expected results: 1. The storage domain name to be displayed. 2. Maybe these messages could be logged as WARN instead of ERROR. Additional info: Found in verification of bug 1547907
The error message is when storage domain does not exists in the Data Center. The same can also be when the storage domain does not exists in the setup at all. Therefore we can not know the name of the storage domain.
Will changing the name to 'unknown' will be better? Like so: "Storage Domain 'unknown' with id 'dd0bf7a0-9a84-4290-9568-6e0c3538f886', could not be found for disk alias...."
(In reply to Maor from comment #2) > Will changing the name to 'unknown' will be better? > Like so: > "Storage Domain 'unknown' with id 'dd0bf7a0-9a84-4290-9568-6e0c3538f886', > could not be found for disk alias...." I think it's best to display the actual name of the storage domain.
(In reply to Natalie Gavrielov from comment #3) > (In reply to Maor from comment #2) > > Will changing the name to 'unknown' will be better? > > Like so: > > "Storage Domain 'unknown' with id 'dd0bf7a0-9a84-4290-9568-6e0c3538f886', > > could not be found for disk alias...." > > I think it's best to display the actual name of the storage domain. I mean, to find a way to do so
Maor, I think it is better to display 'unknown' than 'null', but it would still look like a bug. The optimal solution is to display the name.
(In reply to Natalie Gavrielov from comment #5) > Maor, > > I think it is better to display 'unknown' than 'null', but it would still > look like a bug. > The optimal solution is to display the name. The solution should be comprehensive for all use cases including a use case when the storage domains does not exists in the setup. For this use case there is no way to know the storage domains' names.
(In reply to Maor from comment #6) > (In reply to Natalie Gavrielov from comment #5) > > Maor, > > > > I think it is better to display 'unknown' than 'null', but it would still > > look like a bug. > > The optimal solution is to display the name. > > The solution should be comprehensive for all use cases including a use case > when the storage domains does not exists in the setup. > For this use case there is no way to know the storage domains' names. Let's go with the 'unknown' for now, it will be better than null
Verified. ovirt-engine-4.2.4.2-0.1.el7_3.noarch
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.4 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.