Managing Multiple Virtual Data Centers 3.0

Virtual Data Centers (VDCs) are fully-isolated virtual infrastructure environments where a group of users, under the control of the VDC administrator, can create and manage compute, storage and networking capacity. The VDC administrator can create new users inside the VDC. Both VDC admins and users access the zone through a reverse proxy, so they don't need to know the endpoint of the zone, but rather the address of the oZones module and the VDC where they belong to.

inlinetoc

Adding a new VDC

This guide assumes that the oZones command line interface is correctly installed and configured.

VDCs resources can be managed using the onevdc command. In order to create a VDC, we will need a VDC template, with the necessary information to setup such resource: 

NAME=MyVDC
VDCADMINNAME=vdcadmin
VDCADMINPASS=vdcpass
ZONEID=3
HOSTS=1,2

Once created, the above VDC template will mean the following in the OpenNebula managing the Zone with ID 1:

  • New group called “MyVDC”
  • New user called “vdcadmin”, using “vdcpass” as password
  • A set of ACLs to allow users from group “MyVDC” to deploy in Hosts 4,7,9 and 10, as well as ACLs to allow “vdcadmin” to create new users, and for users of that group to manage resources in the group.

Let's create the VDC:

<xterm> $ onevdc create vdctest.ozo ID: 2 </xterm>

Now it's time to see if it appears in the listing:

<xterm> $ onevdc list 

ID            NAME                                   ZONEID
 2         VDCTest                                        3

</xterm>

If we have access to the Zone 3, we can see that the following has just been created:

Group

<xterm> $ onegroup list 

ID NAME           
 0 oneadmin       
 1 users

101 VDCTest </xterm>

User

<xterm> $ oneuser list 

ID GROUP    NAME                                                      PASSWORD
 0 oneadmin tinova                    4478db59d30855454ece114e8ccfa5563d21c9bd
 1 VDCTest  vdcadmin                  dc3ed3d76febeaafe92c2cbd9facf59877b69f00

</xterm>

ACLs

<xterm> $ oneacl list 

 ID     USER RES_VHNIUTG   RID OPE_CDUMIPpTWY
  0       @1     V-NI-T-     *     C-----p---
  1       @1     -H-----     *     --U-------
  2     @101     V-NI-T-     *     C-----p---
  3       #1     ----U--     *     C---------
  4       #1     ----U--  @101     -D-MI-----
  5     @101     -H-----    #1     --U-------
  6     @101     -H-----    #2     --U-------

</xterm>

VDC Host sharing

By default, the oZones server will check that no hosts are shared between VDCs. This behavior can be overriden by setting the following in the VDC template 

FORCE=yes

or, more intuitively, through the oZones GUI.

Examining a VDC

Once created, a VDC can be asked for details with onevdc show, passing the VDC ID:

<xterm> $ onevdc show 2 VDC VDCTest INFORMATION ID : 2 NAME : VDCTest ZONEID : 3 VDCADMIN : vdcadmin </xterm>

Deleting a VDC

A VDC can be deleting if the VDC ID is known, using onevdc delete

<xterm> $ onevdc delete 2 Resource vdc with id 2 successfully deleted </xterm>

Adding or Removing Hosts to/from VDC

Hosts pertaining to a VDC can be updated, using the CLI and the oZones GUI.

The CLI offers the functionality through the “onevdc” command:

  • addhost <vdcid> <range> : will add hosts in range to the VDC. If a host is being used by other VDC, the request will fail unles the “force” option is used.
  • delhost <vdcid> <range> : will delete hosts in range from the VDC.

In the oZones GUI the VDC can be updated graphically.

Using VDCs

After creating a Zone, and a VDC inside it, users can start to be added to the VDC in order to allow them to use the VDC resources. This can be done through the command line interface or the Sunstone GUI.

Accessing through the Command Line Interface

There are two needed environment variable to access the VDC:

  • ONE_XMLRPC This is an environment variable that tells OpenNebula CLI where to look for the OpenNebula server. It is going to be the address of the reverse proxy, with a reference to the VDC that the user is trying to access. The proxy will redirect the requests to the appropriate Zone. If the VDC has MyVCD as name, the variable would look like 
ONE_XMLRPC=http://ozones.server/MyVDC
  • ONE_AUTH It should point to a file containing valid credentials for the VDC.

For example, let's say we created a VDC with the following template, and a oZones server running at server ozones.server 

NAME=MyVDC
VDCADMINNAME=vdcadmin
VDCADMINPASS=vdcpass
ZONEID=3
HOSTS=1,2

The variables should be:

  • ONE_XMLRPC=http://ozones.server/MyVDC
  • ONE_AUTH=~/.one/one_auth

where ~/.one/one_auth contains: 

vdcadmin:vdcpass

Once this is in place, the VDC admin can start adding new users to the VDC. This works pretty much as a normal “oneadmin” session (although with no ability to change the host pool):

<xterm> $ oneuser create vdcuser1 password </xterm>

Now, the VDC admin or the user can start defining other resources, such as Virtual Networks, Templates, Images, etc.

Accessing through Sunstone

The reverse proxy is set to redirect requests from /sunstone_MyVDC, so just pointing a browser to 

http://ozones.server/sunstone_MyVDC/

should get you to the VDC. Please note the trailing back slash, otherwise the proxy rules won't properly apply.

Now just log in with the VDCAdmin credentials and start creating users for the VDC.

Using the oZones GUI

All the VDC functionality can be accessed using the CLI. The creation of VDCs using the GUI is specially useful, as the Zone hosts can be easily picked from a list: