New disks cloned from template get wrong quota-id, when quota is disabled on DC
Hi, we have recently upgraded our ovirt environment from 4.1.6 to 4.1.9 and then to 4.2.5. I don't know exactly when this issue was happened the first time, because on the affected DCs, we haven't created new VMs for some time ago. To our setup: We have several DCs configured and only the former default one has quota enabled. We have separate templates for each DC and they haven't been cloned or anything else from a template in default DC When I now create a VM on DC from a template (disks are cloned), where quota is not enabled, the new disks are getting quotas assigned, which are not available in that DC! The template disks all have the correct quota ID assigned! 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. As soon I enable quota on that DC, new disks created by VM creation via template, will get the correct quota ID. The problem with wrong IDs is, that you can't edit the disks anymore! I can repeat that error every time and I can give all the information you need to debug this. Pleas inform me, what data do you need... Best Regards Florian
Hi Florian, This is definitely a bug. Can you please open a new ticket in Bugzilla? https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine Set 'oVirt team' to 'SLA'. We don't need any more info for now, the info in the email is sufficient. If it is not possible to edit the disks, the only workaround is to modify the DB directly: UPDATE image_storage_domain_map SET quota_id = quota.id FROM storage_domains JOIN quota ON storage_domains.storage_pool_id = quota.storage_pool_id WHERE storage_domains.id = image_storage_domain_map.storage_domain_id AND quota.is_default = true AND image_storage_domain_map.image_id = '{ID_OF_THE_IMAGE}'; Best Regards, Andrej On Tue, 6 Nov 2018 at 17:16, Florian Schmid <fschmid@ubimet.com> wrote:
Hi,
we have recently upgraded our ovirt environment from 4.1.6 to 4.1.9 and then to 4.2.5. I don't know exactly when this issue was happened the first time, because on the affected DCs, we haven't created new VMs for some time ago.
To our setup: We have several DCs configured and only the former default one has quota enabled. We have separate templates for each DC and they haven't been cloned or anything else from a template in default DC
When I now create a VM on DC from a template (disks are cloned), where quota is not enabled, the new disks are getting quotas assigned, which are not available in that DC! The template disks all have the correct quota ID assigned!
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.
As soon I enable quota on that DC, new disks created by VM creation via template, will get the correct quota ID.
The problem with wrong IDs is, that you can't edit the disks anymore!
I can repeat that error every time and I can give all the information you need to debug this. Pleas inform me, what data do you need...
Best Regards Florian _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YIJCGKHVJXSTTV...
Hi Andrej, thank you very much! I have reported this Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1648917 LG Florian Von: "Andrej Krejcir" <akrejcir@redhat.com> An: "Florian Schmid" <fschmid@ubimet.com> CC: "users" <users@ovirt.org> Gesendet: Donnerstag, 8. November 2018 15:44:14 Betreff: Re: [ovirt-users] New disks cloned from template get wrong quota-id, when quota is disabled on DC Hi Florian , This is definitely a bug. Can you please open a new ticket in Bugzilla? [ https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine | https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine ] Set 'oVirt team' to 'SLA'. We don't need any more info for now, the info in the email is sufficient. If it is not possible to edit the disks, the only workaround is to modify the DB directly: UPDATE image_storage_domain_map SET quota_id = [ http://quota.id/ | quota.id ] FROM storage_domains JOIN quota ON storage_domains.storage_pool_id = quota.storage_pool_id WHERE [ http://storage_domains.id/ | storage_domains.id ] = image_storage_domain_map.storage_domain_id AND quota.is_default = true AND image_storage_domain_map.image_id = '{ID_OF_THE_IMAGE}'; Best Regards, Andrej On Tue, 6 Nov 2018 at 17:16, Florian Schmid < [ mailto:fschmid@ubimet.com | fschmid@ubimet.com ] > wrote: Hi, we have recently upgraded our ovirt environment from 4.1.6 to 4.1.9 and then to 4.2.5. I don't know exactly when this issue was happened the first time, because on the affected DCs, we haven't created new VMs for some time ago. To our setup: We have several DCs configured and only the former default one has quota enabled. We have separate templates for each DC and they haven't been cloned or anything else from a template in default DC When I now create a VM on DC from a template (disks are cloned), where quota is not enabled, the new disks are getting quotas assigned, which are not available in that DC! The template disks all have the correct quota ID assigned! 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. As soon I enable quota on that DC, new disks created by VM creation via template, will get the correct quota ID. The problem with wrong IDs is, that you can't edit the disks anymore! I can repeat that error every time and I can give all the information you need to debug this. Pleas inform me, what data do you need... Best Regards Florian _______________________________________________ Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ] To unsubscribe send an email to [ mailto:users-leave@ovirt.org | users-leave@ovirt.org ] Privacy Statement: [ https://www.ovirt.org/site/privacy-policy/ | https://www.ovirt.org/site/privacy-policy/ ] oVirt Code of Conduct: [ https://www.ovirt.org/community/about/community-guidelines/ | https://www.ovirt.org/community/about/community-guidelines/ ] List Archives: [ https://lists.ovirt.org/archives/list/users@ovirt.org/message/YIJCGKHVJXSTTV... | https://lists.ovirt.org/archives/list/users@ovirt.org/message/YIJCGKHVJXSTTV... ]
participants (2)
-
Andrej Krejcir -
Florian Schmid