Welcome to docs.opsview.com


A tenancy is a grouping of roles and contacts together, so end users can make changes to roles and contacts without knowing any information about other tenants.

A tenancy consists of a primary role which defines the maximum list of access permissions allowed for all contacts in the tenancy. The primary role also defines the list of objects that the contacts can see.

The basic rules are:

  • The primary role in a tenancy defines the maximum permissions available to all the tenants. This is the tenancy
  • Each tenant role can define a subset of permissions based on the primary role
  • Each tenant cannot see objects outside of their tenancy
  • The primary role cannot be edited by anyone in the tenancy
  • Non tenant users can see all objects as usual based on their access

You need to have CONFIGURETENANCIES to view the tenancy pages. Contacts with this access will be able to list all roles and all objects.

To setup a tenancy, you have to:

  • Create the host group in the hierarchy that the tenant will use. We recommend that you create a 2nd host group within this top level host group which is where hosts will be placed
  • Create a role to be the primary role. Set the maximum permissions available to all users in the tenancy with the configuration host group to be the one created above. There are some accesses that are not allowed - see below for the list
  • Create the tenancy with the primary role set to the newly created role
  • Create contacts for this primary role

Note: If a tenancy is deleted, all the related roles and all the related contacts will be deleted automatically.

Note: As tenancies take effect immediately, the UI will not show amber rows after changes.

List view

This will list all the tenancies configured in Opsview, with the primary role and other roles.

If you select Reorder, you can reorder the tenancies. This affects the order of tenancies listed on this page and on the roles list page.

Edit view


The name of the tenancy.


Free text to describe the tenancy.

Primary role

This defines the role which will have the maximum permissions allowed for all contacts in the tenancy.

The roles listed will not already be part of a tenancy and will not contain roles that have invalid access (as these reveal information about all hosts in the system). The invalid list of accesses are:


The primary role cannot be changed after the initial creation, although an administrator can edit the permissions for that role. Opsview will automatically ensure that all other roles in that tenancy will not have more permissions than the primary role.

Different Functionality For Tenancy Users


You can only list roles associated with your tenancy.

You cannot edit the primary role for a tenancy.


You can only list contacts associated with your tenancy.

The list of roles you can set for the contact is limited to the roles in your tenancy.


This is disabled for tenant usres as information about hosts outside of the tenancy maybe visible.

Best Practice


It is best to have one slave per tenant, otherwise there will be data on the slave that could be retrieved form the command line about other tenants.

Host Groups

We recommend you have separate trees in the host group hierarchy for each tenant.


Due to a limitation in MRTG's access control, if there are multiple tenants on a slave, then they can guess the URL for other hosts that are on that slave.


Note: While a tenant user is restricted to their list of objects, the system needs to have unique names so checks for uniqueness are across tenancies.

Note: An Opsview reload will affect all tenancies at once.