[Engine-devel] Quota feature description

Sun Nov 27 15:40:13 UTC 2011


----- Original Message -----
> From: "Maor" <mlipchuk at redhat.com>
> To: "Miki Kenneth" <mkenneth at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org, "Saggi Mizrahi" <smizrahi at redhat.com>
> Sent: Sunday, November 27, 2011 4:16:32 PM
> Subject: Re: [Engine-devel] Quota feature description
> 
> On 11/27/2011 02:17 PM, Miki Kenneth wrote:
> > 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.
> sounds good, but it raises a few issues:
> First, if we already thinking of limiting the number of business
> entities, like snapshot, why not also limit the number of other
> entities
> like disks.
Don't see a reason for that.
> 
> because the limitations of snapshot number, actually reflects on all
> the
> snapshot for all the VMs created on the Quota.
> What happened if someone wants to use on his VM, more then the
> snapshot
> configured.
> The administrator will have to change the configuration of the Quota
> for
> all the VMs or reallocate the disk on other Quota that enables it (If
> there is one).
I see that as another of "global" quota. I would not go as far as specifying a number per SD.
> 
> Also I hope we don't give the user too many configuration parameters
> without making the feature to be too complex to use.
> maybe it is a requirement, that we should wait for feedbacks on it,
> see
> if this case is usable enough...
As a role, I'm all for it to make it simple and get FB.
I do think it is a nice idea and a nice to have - can be pushed to > v2.
> 
> > 
> > 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.
> Agreed.
> > 
> > Miki
> > 
> >   
> > ----- Original Message -----
> >> From: "Maor" <mlipchuk at redhat.com>
> >> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> >> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at 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 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.
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
>