Ovirt 4.2 has been humming away quite nicely for me in the last few months, and now I am hitting an issue when try to touch any api call that has to do with a specific disk. This disk resides on a hyperconverged DC, and none of the other disks seem to be affected. Here is the error thrown. 2018-02-08 10:13:20,005-05 ERROR [org.ovirt.engine.core.bll.storage.disk.RemoveDiskCommand] (default task-22) [7b48d1ec-53a7-497a-af8e-938f30a321cf] Error during ValidateFailure.: org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: Quota 6156b8dd-50c9-4e8f-b1f3-4a6449b02c7b does not match storage pool 5a497956-0380-021e-0025-00000000035e Any ideas what can be done to fix this? _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

The error message means that the data center (storage pool) where the quota is defined is different from the data center where the disk is. It seems like a bug, as it should not be possible to assign a quota to a disk from a different data center. To fix it, try setting the quota of the disk to any quota from the same data center. ​Regards, Andrej​ On 8 February 2018 at 16:37, Martin Sivak <msivak(a)redhat.com&gt; wrote: > Andrej, this might be related to the recent fixes of yours in that > area. Can you take a look please? > > Best regards > > Martin Sivak > > On Thu, Feb 8, 2018 at 4:18 PM, Donny Davis <donny(a)fortnebula.com&gt; wrote: > > Ovirt 4.2 has been humming away quite nicely for me in the last few > months, > > and now I am hitting an issue when try to touch any api call that has > to do > > with a specific disk. This disk resides on a hyperconverged DC, and > none of > > the other disks seem to be affected. Here is the error thrown. > > > > 2018-02-08 10:13:20,005-05 ERROR > > [org.ovirt.engine.core.bll.storage.disk.RemoveDiskCommand] (default > task-22) > > [7b48d1ec-53a7-497a-af8e-938f30a321cf] Error during ValidateFailure.: > > org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: Quota > > 6156b8dd-50c9-4e8f-b1f3-4a6449b02c7b does not match storage pool > > 5a497956-0380-021e-0025-00000000035e > > > > > > > > Any ideas what can be done to fix this? > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > >

Do the operations work in the UI? If not, then the DB has to be changed manually: $ psql engine UPDATE image_storage_domain_map sd_map SET quota_id = NULL FROM images WHERE sd_map.image_id = images.image_guid AND images.image_group_id = 'ID_OF_THE_DISK'; On 8 February 2018 at 17:06, Donny Davis <donny(a)fortnebula.com&gt; wrote: > Any operation on the disk throws this error, to include changing the > quota. > > On Thu, Feb 8, 2018 at 11:03 AM, Andrej Krejcir <akrejcir(a)redhat.com&gt; > wrote: > >> The error message means that the data center (storage pool) where the >> quota is defined is different from the data center where the disk is. >> >> It seems like a bug, as it should not be possible to assign a quota to a >> disk from a different data center. >> >> To fix it, try setting the quota of the disk to any quota from the same >> data center. >> >> ​Regards, >> Andrej​ >> >> >> On 8 February 2018 at 16:37, Martin Sivak <msivak(a)redhat.com&gt; wrote: >> >>> Andrej, this might be related to the recent fixes of yours in that >>> area. Can you take a look please? >>> >>> Best regards >>> >>> Martin Sivak >>> >>> On Thu, Feb 8, 2018 at 4:18 PM, Donny Davis <donny(a)fortnebula.com&gt; >>> wrote: >>> > Ovirt 4.2 has been humming away quite nicely for me in the last few >>> months, >>> > and now I am hitting an issue when try to touch any api call that has >>> to do >>> > with a specific disk. This disk resides on a hyperconverged DC, and >>> none of >>> > the other disks seem to be affected. Here is the error thrown. >>> > >>> > 2018-02-08 10:13:20,005-05 ERROR >>> > [org.ovirt.engine.core.bll.storage.disk.RemoveDiskCommand] (default >>> task-22) >>> > [7b48d1ec-53a7-497a-af8e-938f30a321cf] Error during ValidateFailure.: >>> > org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: >>> Quota >>> > 6156b8dd-50c9-4e8f-b1f3-4a6449b02c7b does not match storage pool >>> > 5a497956-0380-021e-0025-00000000035e >>> > >>> > >>> > >>> > Any ideas what can be done to fix this? >>> > >>> > _______________________________________________ >>> > Users mailing list >>> > Users(a)ovirt.org >>> > http://lists.ovirt.org/mailman/listinfo/users >>> > >>> >> >> >

Or, it should be enough to disable the quota in the data center, then change it for the disk and reenable it again. On 8 February 2018 at 17:42, Andrej Krejcir <akrejcir(a)redhat.com&gt; wrote: > Do the operations work in the UI? > If not, then the DB has to be changed manually: > > $ psql engine > > UPDATE image_storage_domain_map sd_map > SET quota_id = NULL > FROM images > WHERE sd_map.image_id = images.image_guid > AND images.image_group_id = 'ID_OF_THE_DISK'; > > > On 8 February 2018 at 17:06, Donny Davis <donny(a)fortnebula.com&gt; wrote: > >> Any operation on the disk throws this error, to include changing the >> quota. >> >> On Thu, Feb 8, 2018 at 11:03 AM, Andrej Krejcir <akrejcir(a)redhat.com&gt; >> wrote: >> >>> The error message means that the data center (storage pool) where the >>> quota is defined is different from the data center where the disk is. >>> >>> It seems like a bug, as it should not be possible to assign a quota to >>> a disk from a different data center. >>> >>> To fix it, try setting the quota of the disk to any quota from the same >>> data center. >>> >>> ​Regards, >>> Andrej​ >>> >>> >>> On 8 February 2018 at 16:37, Martin Sivak <msivak(a)redhat.com&gt; wrote: >>> >>>> Andrej, this might be related to the recent fixes of yours in that >>>> area. Can you take a look please? >>>> >>>> Best regards >>>> >>>> Martin Sivak >>>> >>>> On Thu, Feb 8, 2018 at 4:18 PM, Donny Davis <donny(a)fortnebula.com&gt; >>>> wrote: >>>> > Ovirt 4.2 has been humming away quite nicely for me in the last few >>>> months, >>>> > and now I am hitting an issue when try to touch any api call that >>>> has to do >>>> > with a specific disk. This disk resides on a hyperconverged DC, and >>>> none of >>>> > the other disks seem to be affected. Here is the error thrown. >>>> > >>>> > 2018-02-08 10:13:20,005-05 ERROR >>>> > [org.ovirt.engine.core.bll.storage.disk.RemoveDiskCommand] (default >>>> task-22) >>>> > [7b48d1ec-53a7-497a-af8e-938f30a321cf] Error during >>>> ValidateFailure.: >>>> > org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: >>>> Quota >>>> > 6156b8dd-50c9-4e8f-b1f3-4a6449b02c7b does not match storage pool >>>> > 5a497956-0380-021e-0025-00000000035e >>>> > >>>> > >>>> > >>>> > Any ideas what can be done to fix this? >>>> > >>>> > _______________________________________________ >>>> > Users mailing list >>>> > Users(a)ovirt.org >>>> > http://lists.ovirt.org/mailman/listinfo/users >>>> > >>>> >>> >>> >> >

So now when I create a new disk on the same domain with quota disabled, I get - Cannot edit Virtual Disk. Quota is not valid. This is a new machine, created after the above issue was solved On Thu, Feb 8, 2018 at 11:56 AM, Donny Davis <donny(a)fortnebula.com&gt; wrote: > Disabling the quota for that DC did the trick. The funny part is it was > never enabled. I put it in audit mode, tried a delete, got the error... and > then disabled it. > > Worked, I am a happy camper... Thanks guys. > > On Thu, Feb 8, 2018 at 11:51 AM, Andrej Krejcir <akrejcir(a)redhat.com&gt; > wrote: > >> Or, it should be enough to disable the quota in the data center, then >> change it for the disk and reenable it again. >> >> On 8 February 2018 at 17:42, Andrej Krejcir <akrejcir(a)redhat.com&gt; wrote: >> >>> Do the operations work in the UI? >>> If not, then the DB has to be changed manually: >>> >>> $ psql engine >>> >>> UPDATE image_storage_domain_map sd_map >>> SET quota_id = NULL >>> FROM images >>> WHERE sd_map.image_id = images.image_guid >>> AND images.image_group_id = 'ID_OF_THE_DISK'; >>> >>> >>> On 8 February 2018 at 17:06, Donny Davis <donny(a)fortnebula.com&gt; wrote: >>> >>>> Any operation on the disk throws this error, to include changing the >>>> quota. >>>> >>>> On Thu, Feb 8, 2018 at 11:03 AM, Andrej Krejcir <akrejcir(a)redhat.com&gt; >>>> wrote: >>>> >>>>> The error message means that the data center (storage pool) where the >>>>> quota is defined is different from the data center where the disk is. >>>>> >>>>> It seems like a bug, as it should not be possible to assign a quota >>>>> to a disk from a different data center. >>>>> >>>>> To fix it, try setting the quota of the disk to any quota from the >>>>> same data center. >>>>> >>>>> ​Regards, >>>>> Andrej​ >>>>> >>>>> >>>>> On 8 February 2018 at 16:37, Martin Sivak <msivak(a)redhat.com&gt; wrote: >>>>> >>>>>> Andrej, this might be related to the recent fixes of yours in that >>>>>> area. Can you take a look please? >>>>>> >>>>>> Best regards >>>>>> >>>>>> Martin Sivak >>>>>> >>>>>> On Thu, Feb 8, 2018 at 4:18 PM, Donny Davis <donny(a)fortnebula.com&gt; >>>>>> wrote: >>>>>> > Ovirt 4.2 has been humming away quite nicely for me in the last >>>>>> few months, >>>>>> > and now I am hitting an issue when try to touch any api call that >>>>>> has to do >>>>>> > with a specific disk. This disk resides on a hyperconverged DC, >>>>>> and none of >>>>>> > the other disks seem to be affected. Here is the error thrown. >>>>>> > >>>>>> > 2018-02-08 10:13:20,005-05 ERROR >>>>>> > [org.ovirt.engine.core.bll.storage.disk.RemoveDiskCommand] >>>>>> (default task-22) >>>>>> > [7b48d1ec-53a7-497a-af8e-938f30a321cf] Error during >>>>>> ValidateFailure.: >>>>>> > org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: >>>>>> Quota >>>>>> > 6156b8dd-50c9-4e8f-b1f3-4a6449b02c7b does not match storage pool >>>>>> > 5a497956-0380-021e-0025-00000000035e >>>>>> > >>>>>> > >>>>>> > >>>>>> > Any ideas what can be done to fix this? >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Users mailing list >>>>>> > Users(a)ovirt.org >>>>>> > http://lists.ovirt.org/mailman/listinfo/users >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> >

Error while executing action: Cannot edit Quota. Quota is not valid. On Fri, Feb 9, 2018 at 5:33 AM, Andrej Krejcir <akrejcir(a)redhat.com&gt; wrote: > The error can mean that a quota does not exist for the DC, or was saved > in an invalid state. > > Try these steps in the UI: > - Set the quota mode to Audit on the DC > - Check the DC details page, quota tab, if there is a quota defined > - If not, create one > - If it is, try editing it and save it. The UI will save a valid quota. > > - Set the quota mode back to Disabled. > > On 9 February 2018 at 00:00, Donny Davis <donny(a)fortnebula.com&gt; wrote: > >> So now when I create a new disk on the same domain with quota disabled, >> I get >> >> - Cannot edit Virtual Disk. Quota is not valid. >> >> >> This is a new machine, created after the above issue was solved >> >> On Thu, Feb 8, 2018 at 11:56 AM, Donny Davis <donny(a)fortnebula.com&gt; >> wrote: >> >>> Disabling the quota for that DC did the trick. The funny part is it was >>> never enabled. I put it in audit mode, tried a delete, got the error... and >>> then disabled it. >>> >>> Worked, I am a happy camper... Thanks guys. >>> >>> On Thu, Feb 8, 2018 at 11:51 AM, Andrej Krejcir <akrejcir(a)redhat.com&gt; >>> wrote: >>> >>>> Or, it should be enough to disable the quota in the data center, then >>>> change it for the disk and reenable it again. >>>> >>>> On 8 February 2018 at 17:42, Andrej Krejcir <akrejcir(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Do the operations work in the UI? >>>>> If not, then the DB has to be changed manually: >>>>> >>>>> $ psql engine >>>>> >>>>> UPDATE image_storage_domain_map sd_map >>>>> SET quota_id = NULL >>>>> FROM images >>>>> WHERE sd_map.image_id = images.image_guid >>>>> AND images.image_group_id = 'ID_OF_THE_DISK'; >>>>> >>>>> >>>>> On 8 February 2018 at 17:06, Donny Davis <donny(a)fortnebula.com&gt; >>>>> wrote: >>>>> >>>>>> Any operation on the disk throws this error, to include changing the >>>>>> quota. >>>>>> >>>>>> On Thu, Feb 8, 2018 at 11:03 AM, Andrej Krejcir <akrejcir(a)redhat.com >>>>>> > wrote: >>>>>> >>>>>>> The error message means that the data center (storage pool) where >>>>>>> the quota is defined is different from the data center where the disk is. >>>>>>> >>>>>>> It seems like a bug, as it should not be possible to assign a quota >>>>>>> to a disk from a different data center. >>>>>>> >>>>>>> To fix it, try setting the quota of the disk to any quota from the >>>>>>> same data center. >>>>>>> >>>>>>> ​Regards, >>>>>>> Andrej​ >>>>>>> >>>>>>> >>>>>>> On 8 February 2018 at 16:37, Martin Sivak <msivak(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Andrej, this might be related to the recent fixes of yours in that >>>>>>>> area. Can you take a look please? >>>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> Martin Sivak >>>>>>>> >>>>>>>> On Thu, Feb 8, 2018 at 4:18 PM, Donny Davis <donny(a)fortnebula.com&gt; >>>>>>>> wrote: >>>>>>>> > Ovirt 4.2 has been humming away quite nicely for me in the last >>>>>>>> few months, >>>>>>>> > and now I am hitting an issue when try to touch any api call >>>>>>>> that has to do >>>>>>>> > with a specific disk. This disk resides on a hyperconverged DC, >>>>>>>> and none of >>>>>>>> > the other disks seem to be affected. Here is the error thrown. >>>>>>>> > >>>>>>>> > 2018-02-08 10:13:20,005-05 ERROR >>>>>>>> > [org.ovirt.engine.core.bll.storage.disk.RemoveDiskCommand] >>>>>>>> (default task-22) >>>>>>>> > [7b48d1ec-53a7-497a-af8e-938f30a321cf] Error during >>>>>>>> ValidateFailure.: >>>>>>>> > org.ovirt.engine.core.bll.quota.InvalidQuotaParametersException: >>>>>>>> Quota >>>>>>>> > 6156b8dd-50c9-4e8f-b1f3-4a6449b02c7b does not match storage pool >>>>>>>> > 5a497956-0380-021e-0025-00000000035e >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > Any ideas what can be done to fix this? >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > Users mailing list >>>>>>>> > Users(a)ovirt.org >>>>>>>> > http://lists.ovirt.org/mailman/listinfo/users >>>>>>>> > >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >