[Engine-devel] Quota feature description

Sun Nov 27 12:17:29 UTC 2011

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 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
> 