When creating an HCP tenant, you specify:
•A name for the tenant. This name determines the URL for the tenant.
When naming tenants, keep in mind that each tenant name must be unique within an HCP system. For example, you cannot create a tenant named finance for each of two different customers. You could, however, create a tenant named cust1-finance for Customer 1 and another tenant named cust2-finance for Customer 2.
Also, keep in mind that you cannot replicate a tenant to another HCP system that already has a different tenant with the same name.
You can change the tenant name at any time after you create the tenant, except while the CIFS or NFS protocol is enabled for any namespaces owned by the tenant. However, keep in mind that when you change the tenant name, you are also changing the URLs for the tenant and its namespaces.
![]() |
Tip: Be sure to notify the tenant contact when you change the name of a tenant. |
•Optionally, a description of the tenant. For example, you can use a description to specify the name of the organization for which you’re creating the tenant.
You can change this description at any time after you create the tenant.
•In an HCP system that uses virtual networking, a management network for the tenant. Clients use this network to access the Tenant Management Console and HCP management API for the tenant. Clients use the domain name associated with this network when sending access requests to the management interfaces (Tenant Management Console and HCP management API) for the tenant.
You need to ensure that requests for access to the Tenant Management Console and HCP management API for the tenant are routable from the clients to the HCP system over the management network that you specify.
If the tenant is configured to allow system-level users to manage it, those users can access its Tenant Management Console directly from the System Management Console even if the tenant management network is not [hcp_system].
You can select a different management network for a tenant at any time. However, when you change the management network, you also change:
oThe IP addresses used to route access requests from clients to the management interfaces (Tenant Management Console and HCP management interface) for the tenant
o The management network domain name included in the tenant URL
![]() |
Tip: Be sure to notify the tenant contact when you select a different management network for a tenant. |
For information on networks and routability, see About virtual networking with HCP.
•In an HCP system that uses virtual networking, a data access network for the tenant. Clients use this network to access the contents of namespaces that the tenant owns. Clients use the domain name associated with this network when sending namespace data access requests to the tenant.
You need to ensure that requests for access to the contents of the namespaces that the tenant owns are routable from the clients to the HCP system over the data access network that you specify.
HCP Data Migrator (HCP-DM) and the Hitachi Data Discovery Suite (HDDS) search facility do not support the use of IPv6 networks for communication with HCP. To enable clients to use HCP-DM to access the contents of namespaces that the tenant owns or to use the HDDS search facility to search and index those namespaces, you need to specify a data access network that has IPv4 addresses assigned to it.
You can select a different data access network for a tenant at any time. However, when you change the data access network, you also change:
oThe IP addresses used to route namespace data access requests from clients to the tenant
oThe domain name included in the URLs for the namespaces that the tenant owns
Changing the IP addresses and domain name used to access the namespaces that a tenant owns causes all CIFS and NFS mounts of those namespaces to be disconnected from HCP.
![]() |
Tip: Be sure to notify the tenant contact when you select a different data access network for a tenant. |
•A hard quota for the tenant. This is the total amount of storage available to the tenant. The tenant allocates this storage to the namespaces it owns by setting a hard quota for each namespace.
You can allocate more total space to your tenants than is actually available for storing objects. HCP warns you when the space used by all tenants is approaching the system storage capacity.
You can change this quota at any time after you create the tenant. However, you cannot specify a quota that is less than the total amount of storage that the tenant has already allocated to its namespaces.
![]() |
Note: HCP checks the amount of data stored in a namespace against the namespace hard quota hourly. If large amounts of data are added rapidly to a namespace, the namespace can store substantially more data than its hard quota allows. Each namespace managed by a tenant can exceed its hard quota in this way. As a result, the total amount of storage used by all namespaces owned by a tenant can exceed the hard quota for that tenant. |
•A soft quota for the tenant. This is the percentage point at which HCP should notify tenant administrators that the storage available to the tenant is running low on free space.
You can change this quota any time after you create the tenant.
•A namespace quota for the tenant. This is the number of namespaces that HCP reserves for the tenant out of the total number of namespaces that the system can have (10,000).
You cannot overallocate namespaces. That is, the maximum number of namespaces that you can allocate to tenants is 10,000, or 9,999 if the system includes the default namespace.
You can create tenants that do not have quotas. The total number of namespaces that these tenants can own is equal to the number of unallocated namespaces in the HCP system. If you allocate a total of 10,000 namespaces to other tenants, the tenants that do not have quotas cannot create any namespaces.
You can change the namespace quota for a tenant at any time after you create the tenant, as long as the new quota is not less than the number of namespaces that the tenant currently owns.
•The authentication methods allowed for the tenant. At least one of these authentication methods must be enabled:
oLocal — The tenant supports internal authentication by HCP. To be authenticated, a user must have a locally authenticated HCP user account.
oRADIUS — The tenant supports remote authentication by RADIUS. To be authenticated, a user must have a RADIUS-authenticated HCP user account.
A tenant that supports RADIUS authentication must also support local authentication, Active Directory authentication, or both.
oActive Directory — The tenant supports remote authentication by AD. To be authenticated, a user must have an AD user account.
![]() |
Tip: To help ensure that AD authentication is available for those tenants that need to support it, enable AD only for those tenants. |
![]() |
Note: For RADIUS or Active Directory authentication to work for the tenant for: •Access to the Tenant Management Console and HCP management API, the tenant management network must be [hcp_system] •Access to the content of namespaces owned by the tenant, the tenant data access network must be [hcp_system] For information on networks, see About virtual networking with HCP. |
You can change the allowed authentication methods at any time after you create the tenant. However, you cannot disable local authentication if the only tenant-level account with the security role is a locally authenticated HCP user account. Similarly, you cannot disable AD authentication if the only tenant-level account with the security role is a group account.
If you disable AD authentication for a tenant after the tenant has created group accounts, those accounts continue to exist but are not visible to the tenant. If you subsequently reenable AD authentication for the tenant, the group accounts become visible again.
For information on these authentication methods, see User authentication.
•An initial security account for the tenant. This can be a locally authenticated HCP user account or an HCP group account, depending on which authentication methods are allowed for the tenant:
oFor a locally authenticated user account, you specify the account username and password. When HCP creates the tenant, it also creates a tenant-level user account with the specified username and password. This account has only the security role and no data access permissions.
oFor an HCP group account, you select an AD group. When HCP creates the tenant, it also creates a tenant-level group account that corresponds to that AD group. This group account has only the security role and no data access permissions.
For the initial security account to be a group account, Active Directory must be selected as an authentication method for the tenant, HCP must be configured to support AD, and HCP must be able to communicate with AD. For information on this, see Configuring Active Directory or Windows workgroup support.
After creating the tenant, you cannot modify the initial security account configuration from the System Management Console. However, tenant administrators can modify the initial security account configuration in the Tenant Management Console.
For information on user and group accounts, see About user and group accounts.
•Optionally, contact information for the tenant. For example, you can specify contact information for the primary person responsible for administering the tenant.
You can change this information at any time after you create the tenant. Tenant-level administrators can also change this information from the Tenant Management Console.
•Optionally, tags for the tenant. A tag is an arbitrary text string associated with an HCP tenant. You can associate up to ten tags with any given tenant, and you can use the same tags for multiple tenants.
You can use tags to group tenants and filter tenant lists. For example, if you’ve created multiple tenants for a company named ABC Corporation, you could associate the tag ABC with each of those tenants. Then you could filter a list of tenants to display only the tenants with that tag.
Tags exist only as long as they are associated with at least one tenant. If you remove a tag from the last tenant with which it’s associated, the tag no longer exists.
You can change the tags associated with the tenant at any time after you create the tenant.
•Whether the tenant can be replicated. This option is available only if the HCP system supports replication.
After creating the tenant, you can change this setting from not allowing replication to allowing replication. However, you cannot do the reverse.
For information on replication, see Replicating Tenants and Namespaces.
•Whether tenant administrators are allowed to select the retention mode for the namespaces that the tenant owns. If this is not allowed, tenant administrators can create namespaces only in enterprise mode.
After creating the tenant, you can change this setting from not allowing tenant administrators to select the retention mode to allowing it. However, you cannot do the reverse.
For retention mode descriptions, see Regulatory compliance.
•Whether tenant administrators are allowed to enable search for the namespaces that the tenant owns.
After creating the tenant, you can change this setting from not allowing tenant administrators to enable search for the namespaces that the tenant to allowing it. However, you cannot do the reverse.
For information on search, see Search administration.
•Whether tenant administrators are allowed to associate service plans with the namespaces that the tenant owns. If tenant administrators are not allowed to associate service plans with the namespaces that the tenant owns, you need to specify a service plan for the tenant. This specification is not visible in the Tenant Management Console.
After creating the tenant, you can change this setting from not allowing tenant administrators to associate service plans with the namespaces that the tenant owns to allowing it. However, you cannot do the reverse.
For information on service plans, see Working with service plans.
•Whether tenant administrators are allowed to enable versioning for the namespaces that the tenant owns.
After creating the tenant, you can change this setting from not allowing tenant administrators to enable versioning for the namespaces that the tenant owns to allowing it. However, you cannot do the reverse.
For information on versioning, see Managing a Tenant and Its Namespaces and Using a Namespace.
© 2016 Hitachi Data Systems Corporation. All rights reserved.