1:33 p.m.
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> 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> 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>
> 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> 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> 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>
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>
>>>>>> 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
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>