[ovirt-users] Cannot Remove Disk

[Andrej Krejcir]

The last workaround I can think of, is to set the quota mode to Audit,
create a new quota and use this new quota for the new disk

Please, can you open a bug and include steps how to get to this state?

Thanks

On 9 February 2018 at 13:28, Donny Davis <donny at fortnebula.com> wrote:

> Error while executing action: Cannot edit Quota. Quota is not valid.
>
> On Fri, Feb 9, 2018 at 5:33 AM, Andrej Krejcir <akrejcir at redhat.com>
> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at ovirt.org
>>>>>>>>> > http://lists.ovirt.org/mailman/listinfo/users
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180209/ec4abc0e/attachment.html>