Skip to content

XEN_CRM_configuration

Jump to bottom
Carolina Fernández edited this page Sep 18, 2015 · 1 revision

Home > Configuration > C RM

Disclaimer: The following configuration manual assumes that installation of the whole software has been done according to the installation manual.

Configuration options

The configuration file is located at vt_manager/src/python/vt_manager/mySettings.py.

General parameters

FLAG Values Comments
ISLAND_NAME String Island/testbed name. Shown on the upper right corner of the Web frontend
VTAM_IP String C RM (VT AM) host domain name/IP
VTAM_PORT String WebUI and XMLRPC TCP port (default:8445)
XMLRPC_USER String XMLRPC interface username
XMLRPC_PASS String XMLRPC interface username's password

###Root (Island Manager) account information

FLAG Values Comments
ROOT_USERNAME String C RM (VT AM)'s root username (Note: this does not create a superuser account in Django. You will be requested to do that in the last step of the installation)
ROOT_PASSWORD String C RM (VT AM)'s root password
ROOT_EMAIL String C RM (VT AM)'s root email

###Database parameters

FLAG Values Comments
DATABASE_USER String MySQL username
DATABASE_PASSWORD String MySQL password
DATABASE_HOST String MySQL host (e.g. 127.0.0.1)
DATABASE_NAME String C RM (VT AM) database name.

Configure Agent on virtualized servers

The configuration of the Agent is performed during the installation. The only important parameter to take into account is the XMLRPC_PASSWORD, which is set during installation, and will be required when adding Servers to the Virtualization Aggregate Manager, in next section.

C RM (VT AM) GUI procedures

Add Ethernet/IP Ranges to the C RM (Virtualization Aggregate Manager)

Servers currently in order to create VMs MUST have one available range (pool) of MAC addresses and IPs. This, in a common configuration, means that at least one global IP and MAC range is needed to be defined. Take a look at next section for details.

Global vs. non-global ranges

By default servers use ranges tagged as global without having to do any kind of configuration to the server (subscription). In other words, if they are not subscribed to any range in particular, they will use all the global ranges to obtain MACs and IPs, in a random order.

However, if the servers subscribe to one or more ranges, regardless of its nature (whether if they are global or not), VMs will be created from addresses contained only in the pool of subscribed ranges (in a random manner).

The global flag, accordingly, should be disabled by those ranges that are particular to one server, and that do not apply to the rest of the servers (for instance a local testing server out of the addressing of the testbed). In general, servers should use global ranges for simplicty and since they do not need this mechanism.

Remember that subscription to MAC ranges does not imply nor has any effect to IPv4 subscription to ranges (they are completely independent).

Take this into account while defining the ranges and configure the servers.

Creating the ranges...

From the UI Dashboard click on Network Settings IPv4 ranges and Create range to define a new IPv4 range. The parameters of the IPv4 Range will be used to configure the VMs networking, this is, they will use the Mask, GW and DNSs of the range which provides the IP.

Create as many ranges as needed. For IPv4 ranges

  • Range name: Name to identify the range.
  • Global range: Global/Not Global flag.
  • Range start Ip: Beggining of the range.
  • Range end Ip: End of the range.
  • Network mask: Network mask to apply over the IPs.
  • Gw: IP address of the default gateway for the VMs.
  • Dns1: In OFELIA installations it is important that the first DNS is the internal federeation DNS (e.g. for OFELIA it is 10.216.24.2).
  • Dns2

For Ethernet Ranges, the only parameters are:

  • Range name
  • Global range
  • Start Mac Address: In OFELIA installations MACs have to be in the range 02:0Y:XX:XX:XX:XX, where Y is the island identifier. To be agreed for FELIX.
  • End Mac Address

When necessary, you can add Exceptions to this ranges.

After they have been set -and in the case you need specially addressing schema for a specific server- you can edit the server to subscribe it to specific ranges.

Add servers in the C RM (Virtualization Aggregate Manager)

Create a server from the Add a server link in the Dashboard or in the Administrate Servers page.

  • UUID: Automatically generated.
  • Enabled: Uncheck if you want to add the server but not make it available for use.
  • Name: Server name
  • OS Type: Server's OS type
  • OS Distribution: Server's OS type
  • OS Version: Server's OS version
  • Virtualization Technology: hypervisor running in the server
  • URL of the Server Agent: URL where the Agent daemon in the Server is listening. It should be https://DOMAIN_NAME:PORT/, default PORT is 9229.

SFA and GENI procedures

Setting the URN for your island

In order to advertise the resources of your island in an appropriate manner, you should change the HRN setting in the file vt_manager/src/python/vt_manager/communication/geni/v3/settings/vtam.py as follows:

HRN = ocf.<your_organization_name_in_lowercase> # Example: ocf.i2cat

Finally, restart Apache. If you have RO deployed in your island and at least run once, you should delete the CRM resources inside RO's database. In a console, write the following:

mongo
> use felix_ro
> db.resource.com.node.drop()
> db.resource.com.link.drop()
> exit

After that, and assuming that SDNRM resources are deleted as well, you may restart the RO.

Allowing requests to the SFA and GENIv3 interfaces

The last step for configuration relates to the management of the clients that are allowed to communicate against the GENIv3 API of your resource managers (RMs). Both C RM and SDN RM require to authorise the certificate of the clearinghouse that issues the credentials of the client you want to allow. Such certificate can be found in ~/.gcf/ch-cert.pem in case you are using the GENI Control Framework and Clearinghouse.

Note1: in the first stages of deployment, every FELIX island will use the same certificates (and respective keys) for ClearingHouse and user Alice. Request such certificates and place them in ~/.gcf/ch-cert.pem (~/.gcf/ch-key.pem), ~/.gcf/trusted_roots/ch-cert.pem, ~/.gcf/trusted_roots/CATedCACerts.pem and ~/.gcf/alice-cert.pem (~/.gcf/alice-key.pem), respectively. If using RMs that request to have a copy of the client or peer certificate to be trusted, place the Clearinghouse certificate under their respective folders (see below for C RM).

Enabling a specific peer is achieved in two steps:

  1. Add the certificate of the client's clearinghouse in the RM

  • Add it as a new .gid file (you pick the name) to the trusted_roots folder:

    cp -p ~/.gcf/ch-cert.pem <path_to_ocf>/vt_manager/src/python/vt_manager/communication/geni/v3/trusted_roots/felix-<organisation>.gid

  • Note: ensure that this file is unique, i.e. not previously saved under other name or coincident

  1. Append the certificate of the client's clearinghouse in the Apache SSL
  • Append it to the end of the /etc/apache2/ssl.crt/ca_clients.crt file
  • Restart Apache
Clone this wiki locally