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 <fsch...@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-le...@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/YIJCGKHVJXSTTVVTWQIRJH7KNEXAGBXX/
>
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/OIVEQXGKH6TWMNE5QYEFF3BLPBKRGPSF/
