[one-users] VDC

[Carlos Martín Sánchez]

Hi,

Please find my comments inline

On Thu, Oct 4, 2012 at 10:28 PM, Gandalf Corvotempesta <
gandalf.corvotempesta at gmail.com> wrote:

> Let's assume a single OpenNebula installation with 5 nodes managed.
> In a dedicated VM (outside Opennebula) i'll install oZones.
>

Since you are only going to manage one OpenNebula zone, you can install the
oZones server in the same front-end machine. But of course a dedicated
machine is completely fine.


> With this VM i'll be able to manage the original opennebula installation.
> If I create a VDC, can the vdc admin user instantiate virtual machines
> from ozone resources by reading public images from the datastore?
>

The permissions in opennebula are very fine-grained and flexible.

You have two mechanisms: permissions for each resource [1] and ACL Rules
[2].
The permissions are easier to manage (users can also manage them) and
understand, as they are very similar to the unix file-system permissions.
The ACL Rules have to be set by oneadmin, and allow more advanced resource
usage control.

A "public image" can be shared with permissions, giving USE privileges to
OTHER users. This can be done with the command 'oneimage chmod <id> 604'

If you need to make it available only to a set of specific users or groups,
you can use ACL Rules similar to this one:
oneacl create "#<user_id> @<group_id_for_images>/IMAGE USE"

What happens if I create multiple VDCs from the same oZone, managed by
> multipele vdc admins? For example, if VDCAdmin1 creates VM snapshot,
> that snapshot, will also be available to VDCAdmin2?
>

No. By default, resources (Images in this case) are created with
permissions 600 (only the owner can USE & MANAGE it). The owner can decide
to share it with his group (640 or 660), but the permissions to OTHER users
can only be set if you allow it. See ENABLE_OTHER_PERMISSIONS in oned.conf
[3]


> I would like to create multiple VDC, with multiple VDC admins but non
> related with each other. Also, these VDC admin should not be able to
> customize our image templates or network definitions. Is this
> possibile?
>

By default VDCs are isolated from each other.
The shared Image and VNets can't be edited unless the user has MANAGE
rights, see the Authorization Requests Reference section in the API
reference (oneimage/onevnet update) [4]. So you only need to make sure you
give USE rights to your VDC users.

Regards

[1] http://opennebula.org/documentation:rel3.6:chmod
[2] http://opennebula.org/documentation:rel3.6:manage_acl
[3]
http://opennebula.org/documentation:rel3.6:oned_conf#auth_manager_configuration
[4] http://opennebula.org/documentation:rel3.6:api

--
Carlos Martín, MSc
Project Engineer
OpenNebula - The Open-source Solution for Data Center Virtualization
www.OpenNebula.org | cmartin at opennebula.org |
@OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>



On Thu, Oct 4, 2012 at 10:28 PM, Gandalf Corvotempesta <
gandalf.corvotempesta at gmail.com> wrote:

> Let's assume a single OpenNebula installation with 5 nodes managed.
> In a dedicated VM (outside Opennebula) i'll install oZones.
>
> With this VM i'll be able to manage the original opennebula installation.
> If I create a VDC, can the vdc admin user instantiate virtual machines
> from ozone resources by reading public images from the datastore? What
> happens if I create multiple VDCs from the same oZone, managed by
> multipele vdc admins? For example, if VDCAdmin1 creates VM snapshot,
> that snapshot, will also be available to VDCAdmin2?
>
> I would like to create multiple VDC, with multiple VDC admins but non
> related with each other. Also, these VDC admin should not be able to
> customize our image templates or network definitions. Is this
> possibile?
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20121010/5100aa41/attachment-0002.htm>