Bug 1648917

Description of problem:
After upgrade from 4.1.6 to 4.1.9 and to 4.2.5, when ever I create a new VM from a Template on a DC, where QoS is not enabled, new disks cloned by VM creation from the template, get the wrong QoS ID from default DC.

Disks created by VM creation interface are not able beieng edited, resized or deleted.
Only changing QoS ID in database will repair that issue.

Disks from Template have the correct QoS ID.

After VM creation is complete, adding a new disk to the VM will result with the right ID of the right DC.


Mailing list link:
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/YIJCGKHVJXSTTVVTWQIRJH7KNEXAGBXX/

Version-Release number of selected component (if applicable):
4.2.5.2-1.el7


How reproducible:

Steps to Reproduce:
1. 2 different DCs, default DC with enabled QoS Policy and one without enabled QoS Policy
2. Create new VM from template with cloning disks on DC without QoS enabled. Template is located on DC w/o QoS and template disks have correct QoS ID
3. New disks on new VM have now the QoS ID from default DC, where QoS is enabled instead of having no QoS ID


Actual results:
-> Disks have wrong QoS ID -> No editing, resizing or deleting of these disks is possible


Expected results:
-> Disks should have no QoS policy assigned at all or at least "hidden" default policy of the DC, where QoS is not enabled


Additional info:
Example from engine DB:
select * from image_storage_domain_map where storage_domain_id = '73caedd0-6ef3-46e0-a705-fe268f04f9cc';
->
...
 a50b46ce-e350-40a4-8f00-968529777446 | 73caedd0-6ef3-46e0-a705-fe268f04f9cc | 58ab004a-0315-00d0-02b8-00000000011d | 4a7a0fea-9bc4-4c3a-b3f4-0e8444641ea3
 1cd8f9d9-e2b5-4dec-aa3b-ade2612ed3e7 | 73caedd0-6ef3-46e0-a705-fe268f04f9cc | 58ab004a-009a-00ea-031c-000000000182 | 4a7a0fea-9bc4-4c3a-b3f4-0e8444641ea3
 2f982856-7afa-4f18-a676-fe2cc44b14d6 | 73caedd0-6ef3-46e0-a705-fe268f04f9cc | 58ab004a-009a-00ea-031c-000000000182 | 4a7a0fea-9bc4-4c3a-b3f4-0e8444641ea3
...
->
ll ./6d979004-cb4c-468e-b89a-a292407abafb/
insgesamt 1420
-rw-rw----. 1 vdsm kvm 1073741824 Nov  6 15:46 a50b46ce-e350-40a4-8f00-968529777446
-rw-rw----. 1 vdsm kvm    1048576 Nov  6 15:46 a50b46ce-e350-40a4-8f00-968529777446.lease
-rw-r--r--. 1 vdsm kvm        271 Nov  6 15:46 a50b46ce-e350-40a4-8f00-968529777446.meta

As you see, the disk a50b46ce-e350-40a4-8f00-968529777446 was created some minutes ago, but it has a different default quota ID assigned as the other disks above.
58ab004a-0315-00d0-02b8-00000000011d instead of 58ab004a-009a-00ea-031c-000000000182


select * from quota;
                  id                  |           storage_pool_id            | quota_name |       description       |         _create_date          |         _update_date          | threshold_cluster_percent
age | threshold_storage_percentage | grace_cluster_percentage | grace_storage_percentage | is_default 
--------------------------------------+--------------------------------------+------------+-------------------------+-------------------------------+-------------------------------+--------------------------
----+------------------------------+--------------------------+--------------------------+------------
58ab004a-0315-00d0-02b8-00000000011d | 00000001-0001-0001-0001-000000000089 | Default    | Default unlimited quota | 2017-02-20 14:42:18.967236+00 |                               |                          
 80 |                           80 |                       20 |                       20 | t

58ab004a-009a-00ea-031c-000000000182 | 5507b0a6-9170-4f42-90a7-80d22d4238c6 | Default    | Default unlimited quota | 2017-02-20 14:42:18.967236+00 |                               |                          
 80 |                           80 |                       20 |                       20 | t

As you see here, both quota IDs are default IDs and therefore can't be on the same DC or storage domain.


Workaround:
Enable QoS on all DCs, even when not using it. This will solve wrong QoS ID assigning....