I updated the detailedQuota wiki, to sharpen that the Quota is managed
from the engine-core perspective.
Your suggestion about the number of snapshots per image is quite
interesting, I think a PM should give an opinion about it.
Although I'm not sure the limitation, should be in the Quota scope,
maybe it is more accurate to set it as a limit in the VM scope. or the
image scope instead.
On 11/17/2011 05:41 PM, Saggi Mizrahi wrote:
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:
>>> Notice that screens of UI mockups should be updated.
>>> Please feel free, to share your comments about it.
>>> Thank you,
>>> Engine-devel mailing list
>> 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
> 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
> 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
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