Re: [Engine-devel] Quota feature description

I think that capping the number of snapshots is a very intutive idea, and it might be easier for cloud provider use case. However, I don't think we can omit the total space option, but having a cap on the number of snapshots in addition, sounds fine.

On another note, looking at some other storage vendors I can say that in most cases the following parameters apply: - Hard Limit - when exceeding it the action is denied. - Soft limit - when exceeding it the User get a warning. (optional) - Grace - on the Hard limit, that in some cases is restricted by time as well So I do think for completeness we should define/design on these parameters.

Miki ----- Original Message ----- > From: "Maor" <mlipchuk(a)redhat.com&gt; > To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt; > Cc: "Oved Ourfalli" <ovedo(a)redhat.com&gt;, engine-devel(a)ovirt.org > Sent: Thursday, November 17, 2011 8:16:22 PM > Subject: Re: [Engine-devel] Quota feature description > > 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: >>>>> 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(a)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. > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >