Exclusión de MER

This guide will show you how to set the usage quotas for users and groups.

6.6.1 Overview

The quota system tracks user and group usage of system resources, and allows the system administrator to set limits on the usage of these resources. Quota limits can be set for:

• users, to individually limit the usage made by a given user.

• groups, to limit the overall usage made by all the users in a given group. This can be of special interest for the OpenNebula Zones and Virtual Data Center (VDC) components.

6.6.2 Which Resource can be limited?

The quota system allows you to track and limit usage on:

• Datastores, to control the amount of storage capacity allocated to each user/group for each datastore. • Compute, to limit the overall memory, cpu or VM instances.

• Network, to limit the number of IPs a user/group can get from a given network. This is specially interesting for networks with public IPs, which usually are a limited resource.

• Images, you can limit the how many VM instances from a given user/group are using a given image. You can take advantage of this quota when the image contains consumable resources (e.g. software licenses).

6.6.3 Defining User/Group Quotas

Usage quotas are set in a traditional template syntax (either plain text or XML). The following table explains the attributes needed to set each quota:

Datastore Quotas. Attribute name: DATASTORE

DATASTORE Attribute

Description ID SIZE

IMAGE

ID of the Datastore to set the quota for Maximum size in MB that can be used in the datastore Maximum number of images that can be created in the datastore

Compute Quotas. Attribute name: VM

VM Attribute Description VMS MEMORY

CPU

VOLATILE_SIZE

Maximum number of VMs that can be created Maximum memory in MB that can be requested by user/group VMs Maximum CPU capacity that can be requested by user/group VMs Maximum volatile disks size (in MB) that can be requested by user/group VMs

Network Quotas. Attribute name: NETWORK

NETWORK Attribute Description

ID LEASES ID of the Network to set the quota for Maximum IPs that can be leased from the Network

Image Quotas. Attribute name: IMAGE

IMAGE Attribute Description

ID RVMS ID of the Image to set the quota for Maximum VMs that can used this image at the same time For each quota, there are two special limits:

OpenNebula 4.4 Administration Guide,

• -1 means that the default quota will be used

Warning: Each quota has an usage counter associated named <QUOTA_NAME>_USED. For example MEMORY_USEDmeans the total memory used by user/group VMs, and its associated quota is MEMORY.

The following template shows a quota example for a user in plain text. It limits the overall usage in Datastore 0 to 20Gb (for an unlimited number of images); the number of VMs that can be created to 4 with a maximum memory to 2G and 5 CPUs; the number of leases from network 1 to 4; and image 1 can only be used by 3 VMs at the same time:

DATASTORE=[ ID="1", IMAGES="0", SIZE="20480" ] VM=[ CPU="5", MEMORY="2048", VMS="4", VOLATILE_SIZE="-1" ] NETWORK=[ ID="1", LEASES="4" ] IMAGE=[ ID="1", RVMS="3" ] IMAGE=[ ID="2", RVMS="0" ]

Warning: Note that whenever a network, image, datastore or VM is used the corresponding quota counters are created for the user with an unlimited value. This allows to track the usage of each user/group even when quotas are not used.

6.6.4 Setting User/Group Quotas

User/group quotas can be easily set up either trough the command line interface or sunstone. Note that you need MANAGEpermissions to set a quota of user, and ADMIN permissions to set the quota of a group. In this way, by default, only oneadmin can set quotas for a group, but if you define a group manager (as in a VDC) she can set specific usage quotas for the users on her group (so distributing resources as required). You can always change this behaviour setting the appropriate ACL rules.

To set the quota for a user, e.g. userA, just type:

$ oneuser quota userA

This will open an editor session to edit a quota template (with some tips about the syntax).

Warning: Usage metrics are included for information purposes (e.g. CPU_USED, MEMORY_USED, LEASES_USED...) you cannot modify them

Warning: You can add as many resource quotas as needed even if they have not been automatically initialized. Similarly, you can set the quotas for group A with:

$ onegroup quota groupA

There is a batchquota command that allows you to set the same quotas for several users or groups:

$ oneuser batchquota userA,userB,35

$ onegroup batchquota 100..104

OpenNebula 4.4 Administration Guide,

6.6.5 Setting Default Quotas

There are two default quota limit templates, one for users and another for groups. This template applies to all users/groups, unless they have an individual limit set.

Use the oneuser/onegroup defaultquota command.

$ oneuser defaultquota

6.6.6 Checking User/Group Quotas

Quota limits and usage for each user/group is included as part of its standard information, so it can be easily check with the usual commands. Check the following examples:

$ oneuser show uA USER 2 INFORMATION ID : 2 NAME : uA GROUP : gA PASSWORD : a9993e364706816aba3e25717850c26c9cd0d89d AUTH_DRIVER : core ENABLED : Yes USER TEMPLATE

RESOURCE USAGE & QUOTAS

DATASTORE ID IMAGES (used) IMAGES (limit) SIZE (used) SIZE (limit)

1 1 0 1024 0

VMS MEMORY (used) MEMORY (limit) CPU (used) CPU (limit)

0 1024 0 1 0

NETWORK ID LEASES (used) LEASES (limit)

1 1 0

IMAGE ID RVMS (used) RVMS (limit)

1 0 0

2 0 0

And for the group:

$ onegroup show gA GROUP 100 INFORMATION ID : 100 NAME : gA USERS ID 2 3

RESOURCE USAGE & QUOTAS

DATASTORE ID IMAGES (used) IMAGES (limit) SIZE (used) SIZE (limit)

1 2 0 2048 0

VMS MEMORY (used) MEMORY (limit) CPU (used) CPU (limit)

0 2048 0 2 0

NETWORK ID LEASES (used) LEASES (limit)

1 1 0

2 1 0

IMAGE ID RVMS (used) RVMS (limit)

1 0 0

2 0 0

5 1 0

6 1 0

CHAPTER

SEVEN

AUTHENTICATION

7.1 External Auth Overview

OpenNebula comes by default with an internal user/password authentication system, see theUsers & Groups Subsys- tem guidefor more information. You can enable an external Authentication driver.

7.1.1 Authentication

In the figure to the right of this text you can see three authentication configurations you can customize in OpenNebula.

a) CLI Authentication

You can choose from the following authentication drivers to access OpenNebula from the command line: • Built-in User/Password

• SSH Authentication

• X509 Authentication

• LDAP Authentication

b) Sunstone Authentication

By default, users with the “core” authentication driver (user/password) can login in Sunstone. You can enable users with the “x authentication driver to login using an external SSL proxy (e.g. Apache).

Proceed to the Sunstone documentation to configure the x509 access: • Sunstone Authentication Methods

c) Servers Authentication

OpenNebula ships with three servers: Sunstone, EC2 and OCCI. When a user interacts with one of them, the server authenticates the request and then forwards the requested operation to the OpenNebula daemon.

The forwarded requests are encrypted by default using a Symmetric Key mechanism. The following guide shows how to strengthen the security of these requests using x509 certificates. This is specially relevant if you are running your server in a machine other than the frontend.

• Cloud Servers Authentication