[Engine-devel] Quota feature description

[Saggi Mizrahi]

On Thu 17 Nov 2011 03:29:48 PM IST, Maor wrote:
> Hi Saggi, thanks for the comments, please see my comments in line
>
> On 11/17/2011 02:36 PM, Saggi Mizrahi wrote:
>> On Wed 16 Nov 2011 02:48:40 PM IST, Maor wrote:
>>> Hello all,
>>>
>>> The Quota feature description is published under the following links:
>>>     http://www.ovirt.org/wiki/Features/DetailedQuota
>>>     http://www.ovirt.org/wiki/Features/Quota
>>> Notice that screens of UI mockups should be updated.
>>>
>>> Please feel free, to share your comments about it.
>>>
>>> Thank you,
>>> Maor
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> I can't see how the host is supposed to enforce and handle it. Pause the
>> VM? Crash it? raise ENOMEM\ENOSPC in the guest?
> The enforcement and handling, should be from the engine scope and not
> from the Host perspective.
> Actually the Host, should not be aware of Quota at all.
>> Also what about cases of KSM\QCow2, disk\memory overcommit.
> on QCOW issue, the active disk should consume the full potential space
> from the Quota, since we are not sure how much space will be in use,
> slthough the snapshot disk, will be updated to consume only its real
> size from the Quota.
>
> you can check the Enforcement section :
> "When dealing with QCOW disks (which is not pre-allocated, like
> templates or stateless VM) the Quota should consume the total maximum
> size of the disk, since it is the potential size that can be used."
>
> for overcommit issue, please see CRUD section in the WIKI:
> "...However, users will not be able to exceed the Quota limitations
> again after the resources are released."
>
>> Disk Templates.
>> Storage for hibernation disk.
>> Temporary and shared disks.
> same logic as above (Enforcement section)
>> Shared disks between VMs owned by different users.
> Please see Dependencies / Related Features and Projects:
> "When handling plug/unplug disks or attach/detach disks, the entity will
> still consume resources from its configured original Quota it was
> created on. "
>
> Which means the disk should consume from the same Quota all the time
> (not dependent on the users that use it).
>> Backup snapshots (should they count in the quota? They are transient)
> When ever a volume is created whether it is snapshot, backup snapshot,
> stateless disk, or any QCOW implementation, the enforcement should the
> the same as described above (see Enforcement section)
>>
>> I also don't see how vcpu limiting is any good? I don't even know what
>> it means. What happens in migration between hosts with different amount
>> of physical CPUs?
> The "atomic" section that Quota is handling in the run time scope is
> cluster.
> Actually for the user migration will be transparent since it is consumed
> from the same Quota, the only validation the VM should encounter will be
> the same as before in the Host perspective.
>
>> I also don't think CPU limiting is even a thing to be managed by a
>> quota. There is no reason not to use 100% of the CPU if you are the only
>> VM active. CPU scheduling should use a priority model and not a quota IMHO.
> Again, the Quota should be managed from the engine level, and should not
> be reflected in the Host implementation.
> Try to look at it, as an abstract management mechanism for taking notes
> and managing resource consumes for the Administrator.
>
> A priority model is an interesting thought.
> Now it can be supported, by using different grace percentage from one
> Quota to another, or maybe create different Quota for Different type of
> users.

So I understand there is a pure disconnect between host lever quotas 
and policies and this quota feature.
Speaking with Livnat and Maor I see this is a good use case for an 
ovirt user to allow simple quotas to clients.

It just feels like a feature that should be implemented as part of a 
grater policy structure validating user actions and not as a strict 
quota.


I think snapshots and images should have different quotas where images 
are capped by size and snapshots are capped by number.

Think of it from a hosting provider perspective. I want each client to 
get a maximum of 30GB of storage.
I can limit them to 30GB. And let them calculated that if they made a 
16GB worth of VM they can never snapshot it. On the other hand I can 
chose to limit them to 10GB and allow up to 2 snapshots to each 
clients. This way I know each client will take up to 30 GB and there 
will be no complaints when the user created a VM and now he can't 
snapshot it. Snapshotting can also be capped on the image level instead 
of the user level (3 snapshots per image). I tend to go towards the 
latter because it'll keep multiple disk VM snapshots from failing due 
to depleted quota.

This will also make complaints about the pessimistic storage estimation 
invalid.