Delegated License Service User Guide

NVIDIA Delegated License Service User Guide

Documentation for system administrators that explains how to install, configure, and manage the Delegated License Service.

The NVIDIA License System is used to provide software licenses to licensed NVIDIA software products. The licenses that the NVIDIA License System provides are obtained from the NVIDIA Licensing Portal.

1.1. Introduction to NVIDIA Software Licensing

To activate licensed functionalities, a licensed client must obtain a software license when it is booted. NVIDIA License System provides role-based access control (RBAC) for DLS instances, enabling organizations to create multiple application users with different privilege levels. These application users are separate from OS-level users (dls_admin, rsu_admin) and are used solely for DLS Web UI and API access. Administrators can create local users or integrate with enterprise LDAP/Active Directory systems for centralized authentication. For more information, see User Accounts on a DLS Virtual Appliance.

NVIDIA License System supports the types of licensing for licensed clients:

• Networked-licensing: A client with a network connection obtains a license by leasing it from a NVIDIA License System service instance. The service instance serves the license to the client over the network from a pool of floating licenses obtained from the NVIDIA Licensing Portal. The license is returned to the service instance when the licensed client no longer requires the license.
• Node locked-licensing: A client system without a network connection or on an air-gapped network can obtain a node-locked NVIDIA vGPU software license from a file installed locally on the client system.
  Note:

  Support for node-locked licensing was introduced in NVIDIA vGPU software 15.0. It is not supported in earlier NVIDIA vGPU software releases.

1.1.1. Pre-Requisites for using vGPU 18 or Later

1. Upgrade to DLS 3.4 or Later
   • To avoid licensing failures with vGPU 18.0 and later releases, upgrade your license server to a minimum version of DLS 3.4 before upgrading vGPU to version 18.0 or later.
   • Refer to the Migrating a DLS Instance section of the DLS 3.4 documentation for upgrade instructions.
2. Update the License Server File (DLS only)
   • After upgrading your DLS instance to version 3.4 or later:
     • Download a fresh license server file from the NVIDIA Licensing Portal
     • Install the license server file on your newly upgraded DLS appliance.
   • Refer to the Installing a License Server on a DLS Instance section of the NLS 3.4 documentation for instructions.

NLS Security Policy Enhancement

• For NLS release 3.4 and later, the license server files bound to DLS SI will have a validity of three years.
• The three-year validity will begin from the time the file is downloaded from the NLP portal.
• The NVIDIA Licensing Portal will display the validity period in the details section for license servers bound to DLS SI after its download.
  • The validity period for the pre-existing license servers which are already downloaded will not be displayed unless it is downloaded again.

1.2. About License Server Instances (CLS/DLS)

A license server instance is required to serve licenses to licensed clients.

NVIDIA License System supports the following types of license server instances:

• Cloud License Service (CLS) instance. A CLS instance is hosted on the NVIDIA Licensing Portal.
• Delegated License Service (DLS) instance. A DLS instance is hosted on-premises at a location that is accessible from your private network, such as inside your data center.

For example, you can deploy license server instances in distinct physical locations by deploying a DLS instance in each of your data centers. You can also use a mixture of CLS and DLS instances to serve your licenses to licensed clients.

1.2.1. About Cloud License Service (CLS) Instances

A Cloud License Service (CLS) instance is hosted on the NVIDIA Licensing Portal.

Because a CLS instance is hosted on the NVIDIA Licensing Portal, you do not need to download licenses from the NVIDIA Licensing Portal and upload them to the instance.

Hosting a CLS instance on a cloud service provides robustness and dynamic scalability for the CLS instance. Because a CLS instance is maintained by NVIDIA and the cloud service provider, feature and maintenance updates are generally transparent to users.

1.2.2. About Delegated License Service (DLS) Instances

A Delegated License Service (DLS) instance is hosted on-premises at a location that is accessible from your private network, such as inside your data center.

Because a DLS instance is fully disconnected from the NVIDIA Licensing Portal, you must download licenses from the NVIDIA Licensing Portal and upload them to the instance manually.

1.3. High Availability for NVIDIA License System DLS Instances

To provide licensed clients with continued access to licenses if a DLS instance fails, you can configure DLS instances for high availability.

For resilience within a single Kubernetes service instance (multiple application copies and a highly available database), see Deploying Multi-Replica DLS Instance on Kubernetes Platforms. For an HA cluster of separate DLS instances, see Configuring an HA Cluster of DLS Instances

High availability requires at least two DLS instances in a failover configuration:

• A primary DLS instance, which is actively serving licenses to licensed clients
• One or more secondary DLS instances, which act as a backup for the primary DLS instance

Configuring multiple DLS instances in a failover configuration increases availability because simultaneous failure of multiple instances is rare. The primary and secondary DLS instances work together to ensure that licenses in the enterprise remain continually available to licensed clients.

If the primary DLS instance fails, failover occurs. One of the secondary DLS instances becomes the primary instance and begins to serve licenses. In a cluster of more than two instances, the secondary instance that has the longest uptime becomes the primary instance. The DLS instance that failed becomes a secondary instance when it is returned to service. The next time that failover occurs, the primary DLS instance becomes a secondary DLS instance again.

During normal operation, the primary DLS instance continually updates the secondary DLS instances with information about the licenses that are being served to clients.

For more information about configuring DLS instances for high availability, see Configuring an HA Cluster of DLS Instances.

To enable transparent client failover, you can configure Virtual IP Management for your HA cluster. Virtual IP Management automatically migrates a floating IP address between cluster nodes during failover events, eliminating the need for client reconfiguration. For more information, see Configuring Virtual IP Management for High Availability.

1.4. Heartbeat Checks for DLS Failover

In a High Availability (HA) cluster, the Heartbeat service, running on every node, monitors the health of DLS appliances and triggers a failover when an unhealthy node is detected based on one of the following criteria. In the event of a failover, one of the secondary nodes assumes the role of the primary node to serve the requests, and the previous primary node takes on the role of the secondary node.

Failover Criteria

• Service health check using health end point of service:
  • This check verifies whether all services are running in a healthy state and are responsive.
  • Every service has a health endpoint. The Heartbeat service will monitor the endpoint to check if the service is responsive.
• Database connection check:
  • The database connection check verifies whether the database is responsive.
  • As part of this check, a lightweight query will be executed.
  • If the database is not responsive, it will result in a client request failure.
• Resource exhaustion check:
  • This check verifies whether any resources (CPU, RAM, and disk) have exceeded the predefined thresholds.
  • Exhaustion of resources impacts system stability, so this is a proactive action for a failover.
• Application failure:
  • Application failure check verifies whether client requests are serviced successfully.
  • If the percentage of failures over a predefined time interval crosses the predefined threshold, a failover gets triggered.
  • This is distinct from the service health check, which verifies if the service is responsive.
  • This check monitors failures in servicing requests. Only authentication and lease operations are monitored for application failure.
• Secondary node monitoring of primary node health:
  • This check verifies if the primary node is running and if the lease service is responsive.
  • As part of the lease response check, a read query (get lease count) is executed by the lease monitoring service.

In summary, a failover occurs when any of the following conditions is detected:

• Services are not responsive.
• The database is not responsive.
• Resources are exhausted.
• Failures are observed for authentication and lease operations.
• A secondary node observes that the primary node is down.

1.4.1. Recovery Actions for DLS Failover

You can perform the following actions for recovering a DLS virtual appliance from a failover.

• Resource exhaustion:

  Take appropriate actions based on the respective resources:

  • For CPU or RAM exhaustion: Increase the assigned vCPU or RAM, or check the maximum supported load for a single DLS instance and reduce the load.

    For the performance numbers, see Sizing Guidelines for a DLS Appliance.

  • For disk space exhaustion: Increase the available disk space or free up more disk space.

    For the disk space cleanup script, see Expanding the Disk Space on a DLS Virtual Appliance.

  • Application restart might help free up RAM and CPU resources.
• Database connection failure:
  • Restart the application to bring the appliance to a healthy state if the database is recoverable.
  • Check for resource limits, such as memory, CPU, and disk space, to ensure they are not exhausted in unlikely scenarios where failover check of resource exhaustion does not detect in advance.
  • Follow the instructions described in Restarting the DLS Virtual Appliance to restart.
  • To verify if the database has been restored, you can do either of the following checks:

    • Check whether the user interface is performing correctly.

    • Check database connection by using the health endpoint after 10 minutes.

      Copy

      Copied!

                  
      
                  
      curl -k --location "https://<Node_IP>/service_instance_manager/v1/health?op=db"
              

      The expected response code is displayed as follows:

      Copy

      Copied!

                  
      
                  
      {"isServiceHealthy":true}
              

• Service health check failure:

  • Restart the application to bring the appliance to a healthy state by following the instructions described in Restarting the DLS Virtual Appliance.

• Application failure:

  • Restart the application to bring the appliance to a healthy state by following the instructions described in Restarting the DLS Virtual Appliance.

• Power failure:

  • Ensure that power is restored.

If none of the preceding actions can recover the appliance successfully, contact NVIDIA Enterprise Support.

1.4.2. Restarting the DLS Virtual Appliance

To restart a DLS virtual appliance, choose an appropriate action based on your appliance.

VM-Based DLS Appliances

There are two methods to initiate the restart:

• Method 1: Reboot the VM.
• Method 2: Log in using the rsu_admin user, and then execute the systemctl command to restart applicationStartup.
  Copy

  Copied!

              
  
              
  sudo systemctl restart applicationStartup
          

Container-Based DLS Appliances

• Docker containers:

  Run the following command to restart.

  Copy

  Copied!

              
  
              
  $ docker-compose -f /path/to/docker-compose.yml restart
          

To simplify the installation and administration of the DLS, the DLS is distributed as a software image to be installed or deployed on a supported platform. The DLS is a secure, hardened environment in which access to the application software is strictly controlled.

The following types of DLS software image are available:

• A virtual appliance image to be installed in a VM on a supported hypervisor
• A containerized software image for deployment on a supported container orchestration platform
• An installable package for installation on a supported OS running in a virtualized server environment on your choice of hypervisor or on a bare-metal server

Each DLS software image is configured with a single standard user account for accessing the DLS appliance and an account with sudo user privileges for installing updates to the DLS appliance software. Modifications to these accounts are strictly controlled. You cannot add other user accounts to the software image. However, you can use a lightweight directory access protocol (LDAP) directory instead of the configured accounts for managing user access to a DLS appliance. DLS Virtual Appliance supports user account management at two levels: OS-level user accounts (dls_admin, rsu_admin) exist on the underlying operating system and are used for appliance management, while application-level user accounts (introduced in DLS 3.6.0) are created via DLS Web UI or API for accessing DLS management interfaces. Application users exist only in the DLS application database and support role-based access control (RBAC) with three pre-defined roles: DLS_ADMIN, DLS_OPERATOR, and DLS_USER.

In each VM-based virtual appliance image, the DLS application software is containerized to allow limited access to the OS so that non-root users can install security compliance and scanning tools in the VM. However, a container orchestration platform cannot control or restrict access to the OS on which the platform is running.

In the package for installation on a supported OS, the DLS application software is containerized to ensure that all software dependencies are met and to isolate the DLS application software from the underlying OS.

As far as possible, the DLS appliances based on all types of software image are functionally equivalent. Therefore, whether to use a container-based DLS appliance, a VM-based DLS appliance, or a DLS appliance from a package for installation on a supported OS depends on the requirements of your IT infrastructure or the policies of your IT department.

For additional guidelines, refer to the following resources from the vendors of platforms that support NVIDIA License System:

• Citrix: Containers or Virtual Machines? It Doesn’t Have to Be One or the Other.
• Microsoft: Containers vs. virtual machines
• Red Hat: Containers vs VMs
• VMware: Why use containers vs. VMs?

2.1. Platform Requirements for a DLS Virtual Appliance or Containerized DLS Software Image

Before proceeding, ensure that you have a platform suitable for hosting a DLS virtual appliance or containerized DLS software image.

• The hosting platform must be a physical host running a supported hypervisor or container orchestration platform.
• The minimum resource requirements for the VM in which the DLS virtual appliance or DLS container will run is as follows:
  • Number of vCPUs: 4
  • RAM: 8 Gbytes
  • Disk Size: 15 Gbytes

  For additional guidelines, refer to Sizing Guidelines for a DLS Appliance.

• The platform must have a fixed (unchanging) IP address. The IP address may be assigned dynamically by DHCP or statically configured, but must be constant.
• The platform’s date and time must be set accurately. NTP is recommended.

2.2. Host Name Resolution Requirements for a DLS Virtual Appliance

The platform that hosts a DLS virtual appliance must be identified by its IP address or its fully qualified domain name. It can also be identified by its CNAME. If you want to identify the platform by its fully qualified domain name, ensure that the required DNS entries are set before installing the DLS virtual appliance. If you want to identify the platform by its default host name, you must set a DNS entry that maps the default host name to the fully qualified domain name.

The process for setting these DNS entries is separate from the process for installing the DLS virtual appliance. Use the standard interfaces of the name resolution service that you are using to set the required DNS entries.

Determining Whether the Forward Pointer and Reverse Pointer DNS Entries Are Correct

For each mapping between a domain name and an IP address, ensure that you set both the forward pointer and reverse pointer DNS entries. A DLS virtual appliance requires the reverse pointer entry to determine the domain name of the DLS virtual appliance when creating a client configuration token.

To determine whether the forward pointer and reverse pointer DNS entries have been set correctly, type the following commands in a shell on any UNIX or Linux host on the same network as the DLS virtual appliance:

• For the forward pointer entry, type:

  Copy

  Copied!

              
  
              
  $ host domain-name
          

  domain-name

  The domain name for which you want to determine whether the forward pointer DNS entry is correct.

  If the DNS entry has been set correctly, the command displays the IP address that is mapped to the domain name.

• For the reverse pointer entry, type:

  Copy

  Copied!

              
  
              
  $ host ip-address
          

  ip-address

  The IP address for which you want to determine whether the reverse pointer DNS entry is correct.

  If the DNS entry has been set correctly, the command displays the domain name that is mapped to the IP address.

How a DLS Instance Determines Whether a Fully Qualified Domain Name Is Set

How a DLS instance determines whether a fully qualified domain name is set depends on the type of DLS instance.

• VM-based DLS virtual appliance: When the VM that hosts a DLS instance starts, the DLS instance checks whether a fully qualified domain name is mapped to the IP address of the VM. If a name is mapped to the IP address of the VM, the DLS instance retrieves the name to display in the user interface of the NVIDIA Licensing application on the appliance.

• Containerized DLS Software Image: The fully qualified domain name is set through an environment variable. When the container within which the DLS software image is deployed is started, the DLS instance checks whether this environment variable is set.

  Note:

  Licensed clients outside the container must be able to resolve the fully qualified domain name. The environment variable must not specify a name that can be resolved only by the container orchestrator.

  • If this environment variable is set, the DLS instance retrieves the name to display in the user interface of the NVIDIA Licensing application on the appliance.
  • If this environment variable is not set, a user cannot connect to the container in which the DLS software image is deployed through a fully qualified domain name, even if a fully qualified domain name is mapped to an IP address in the DNS server.

  For more information, refer to Setting Properties for a Containerized DLS Software Image.

How the Host Name of the VM or Container that Hosts a DLS Instance Is Set

How the host name of the VM or container that hosts a DLS instance is set depends on the type of DLS instance.

• VM-based DLS virtual appliance: The host name is preset in the virtual appliance image.
  • The host name of a standalone DLS virtual appliance is preset to nls-si-0.
  • The host names of the DLS virtual appliances in an HA cluster are preset to nls-si-0 and nls-si-1.

  The host name can be changed as explained in Changing the Host Name of a VM-Based DLS Virtual Appliance.

• Containerized DLS Software Image: The host name is set through an environment variable. If this environment variable is not set, the container orchestration platform sets the host name to the container ID. For more information, refer to Setting Properties for a Containerized DLS Software Image.
• CNAME Identification: The platform that hosts a DLS virtual appliance can also be identified by its CNAME.

2.3. Communications Ports Requirements

To enable communication between a licensed client and a CLS or DLS instance, specific ports must be open in your firewall or proxy server. If you are using an HA cluster of DLS instances with a firewall or proxy server between the DLS instances, additional ports must be open in your firewall or proxy server.

Communications Ports Between a Licensed Client and a CLS Instance

To enable communication between a licensed client and a CLS instance, the following ports must be open in your firewall or proxy server:

Communications Ports Between a Licensed Client and a DLS Instance

To enable communication between a licensed client and a DLS instance, the following ports must be open in your firewall or proxy server:

Communications Ports Between DLS Instances in an HA Cluster

If you are using an HA cluster of DLS instances with a firewall or proxy server between the DLS instances, the following ports must also be open in the firewall or proxy server:

✔ Port is used.

- Port is not used.

The following ports that were required to be open in earlier releases are no longer used:

• 22
• 1883
• 5672
• 8883
• 15672
• 25671
• 25672
• 61613
• 61614

Communications Ports in the Container Orchestrator

The following ports must be available in the container orchestrator to allow the DLS appliance container to bind to them:

2.4. Sizing Guidelines for a DLS Appliance

Use the measured performance numbers to determine the optimum configuration for your container-based or VM-based DLS appliances based on the expected number and frequency of requests from licensed clients.

2.4.1. Throughput for a DLS Appliance

Throughput measures the number of clients that a VM-based or container-based DLS appliance can process in 1 second.

2.4.2. Scalability for a DLS Appliance

Scalability measures the maximum number of licensed clients that a VM-based or container-based DLS appliance can serve in a specific interval. A DLS appliance serves a licensed client by performing a licensing operation for the client, namely the borrowing, return, or renewal of a license. Registration of a licensed client is not considered a licensing operation because it occurs only once for any client.

These measurements capture the maximum number of licensed clients that DLS appliances with varying numbers of vCPUs and amounts of RAM can serve when licenses are borrowed for 12 hours. The maximum number of clients is directly proportional to the length of time for which licenses are borrowed. If the length of time increases, the maximum number of clients also increases.

To calculate the maximum number of clients from the length of time for which licenses are borrowed, use the following formula:

max-clients=clients-per-second⨯60⨯(renewal-interval-percentage/100)⨯borrow-time-in-hours⨯60

max-clients

The maximum number of licensed clients that a DLS appliance can serve.

clients-per-second

The number of clients per second that the DLS appliance can serve as measured by scalability runs for each configuration. Use the number of clients per second in the table for the appropriate configuration.

renewal-interval-percentage

The percentage of the length of time for which a license is borrowed to which the renewal interval is set.

When these measurements were taken, the renewal interval was set to 15% of the length of time in hours for which licenses were borrowed.

borrow-time-in-hours

The length of time in hours for which licenses are borrowed.

When these measurements were taken, licenses were borrowed for 12 hours.

This formula prevents the accumulation of requests on a DLS instance, ensuring smooth operation.

2.4.3. Burst Load Performance for a DLS Appliance

Burst load performance measures the time that a VM-based or container-based DLS appliance requires to process the requests received from a large number of clients in a short interval of time. Burst load performance does not measure concurrency or throughput.

2.4.4.  Default Resource Configuration for a DLS Multi-Replica Deployment

A DLS multi-replica deployment consists of DLS appliance pods and DLS database pods, each of which is deployed with a default CPU limit and a default memory limit. All the performance numbers in the sections that follow were measured with these default limits in place.

2.4.5.  Scalability for a DLS Multi-Replica Deployment

Scalability measures the maximum number of licensed clients that a DLS multi-replica deployment can serve in a specific interval. A DLS multi-replica deployment serves a licensed client by performing a licensing operation for the client, namely the borrowing, return, or renewal of a license. Registration of a licensed client is not considered a licensing operation because it occurs only once for any client.

These measurements capture the maximum number of licensed clients that DLS multi-replica deployments with varying numbers of appliance pods and database pods can serve when licenses are borrowed for 12 hours. The maximum number of clients is directly proportional to the length of time for which licenses are borrowed. If the length of time increases, the maximum number of clients also increases.

To calculate the maximum number of clients from the length of time for which licenses are borrowed, use the following formula:

max-clients = clients-per-second ⨯ 60 ⨯ (renewal-interval-percentage / 100) ⨯ borrow-time-in-hours ⨯ 60

max-clientsThe maximum number of licensed clients that a DLS multi-replica deployment can serve.

clients-per-secondThe number of clients per second that the DLS multi-replica deployment can serve as measured by scalability runs for each topology. Use the number of clients per second in the table for the appropriate topology.

renewal-interval-percentageThe percentage of the length of time for which a license is borrowed to which the renewal interval is set.

When these measurements were taken, the renewal interval was set to 15% of the length of time in hours for which licenses were borrowed.

borrow-time-in-hoursThe length of time in hours for which licenses are borrowed.

When these measurements were taken, licenses were borrowed for 12 hours.

This formula prevents the accumulation of requests on a DLS multi-replica deployment, ensuring smooth operation.

2.4.6. Burst Load Performance for a DLS Multi-Replica Deployment

Burst load performance measures the ability of a DLS multi-replica deployment to process the requests received from a large number of clients in a short interval of time. Burst load performance does not measure concurrency or throughput.

For a burst of 10,000 licensed clients, the following table gives the recommended interval over which the clients should be started for each supported topology. If the clients are started over a shorter interval than the recommended interval, licensing operations might not complete within the interval and average response times increase.

2.5. Installing a VM-Based DLS Virtual Appliance

To simplify the installation process, a VM-based DLS virtual appliance is supplied as a virtual appliance image to be installed on a supported hypervisor.

After verifying the requirements in Platform Requirements for a DLS Virtual Appliance or Containerized DLS Software Image and reviewing the guidelines in Sizing Guidelines for a DLS Appliance, install and configure the DLS virtual appliance by following this sequence of instructions:

1. Installing the DLS Virtual Appliance Image on a Supported Hypervisor
2. If necessary: Setting the IP Address of a DLS Virtual Appliance from the Hypervisor
3. Registering the DLS Administrator User
4. Optional: Creating or Expanding an HA Cluster of DLS Instances
5. Optional: Setting the Static IP Address of a DLS Virtual Appliance

2.5.1. Installing the DLS Virtual Appliance Image on a Supported Hypervisor

DLS virtual appliance images are available for several hypervisors. You use standard interfaces of the hypervisor to install the DLS virtual appliance on your chosen hypervisor.

The DLS virtual appliance image for each supported hypervisor except Red Hat Enterprise Linux KVM specifies the minimum configuration for the VM as listed in Platform Requirements for a DLS Virtual Appliance or Containerized DLS Software Image. You are not required to specify the VM configuration when you install the DLS virtual appliance for these hypervisors. After installing the DLS virtual appliance, you can use standard interfaces of the hypervisor to change the configuration of the VM if necessary.

2.5.1.1. Installing the DLS Virtual Appliance on Citrix Hypervisor

The DLS image for Citrix Hypervisor is distributed as a ZIP archive that contains an XVA file, which is a format that is specific to Xen-based hypervisors.

Use the Citrix XenCenter Import wizard to perform this task on the Citrix Hypervisor host on which you want to run the DLS virtual appliance.

For additional information, see Import VMs From XVA on the Citrix product documentation website.

1. Download the ZIP archive that contains the XVA file that contains the DLS virtual appliance image to the hypervisor host.
2. Extract the contents of the ZIP archive that you downloaded.
3. In Citrix XenCenter, from the File menu, choose Import.
4. Browse for and select the downloaded XVA file, and click Next.
5. Select the server on which the imported VM will be placed and click Next.
6. Select the storage repository where the virtual disks for the newly imported VM will be stored and click Import.
7. Select the default virtual network interfaces in the template for the virtual appliance and click Next.
8. Review the settings for importing the virtual machine and click Finish to create the virtual machine.
9. Start the VM that you created.

Allow approximately 15 minutes after the VM is started for the installation of the DLS virtual appliance to complete and for the DLS virtual appliance to start. What to do after the DLS virtual appliance starts depends on whether the VM has been assigned an IP address automatically, for example, by a DHCP server:

• If the VM has been assigned an IP address, what to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

  • If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
  • If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

• Otherwise, set the IP address of the DLS virtual appliance from the hypervisor as explained in Setting the IP Address of a DLS Virtual Appliance from the Hypervisor.

2.5.1.2. Installing the DLS Virtual Appliance on Microsoft Windows Server with Hyper-V

The DLS image for Microsoft Windows Server with Hyper-V is distributed as a ZIP archive.

Use Hyper-V Manager to perform this task on the Microsoft Windows Server with Hyper-V host on which you want to run the DLS virtual appliance.

For additional information, see Import a Virtual Machine on the Microsoft documentation website.

1. Download the ZIP archive that contains the DLS virtual appliance image to the hypervisor host.
2. Extract the contents of the ZIP archive that you downloaded.
3. From the Hyper-V ManagerActions menu, choose Import Virtual Machine.
4. Browse for and select the folder to which you extracted the DLS virtual appliance image and click Next.
5. When prompted to choose the type of import, select the Copy the virtual machine (create a new unique ID) option and click Next.
6. Browse for and select the folders in which you want to store virtual machine (VM) files and click Next.

   

7. Browse for and select the folder for storing the virtual disk.
   Note:

   If you are creating two VMs for a cluster of DLS instances, ensure that you choose a unique folder for each VM to prevent errors from Hyper-V Manager.

8. Review the settings for importing the VM and click Finish to create the VM.
9. After the VM has been created, specify the virtual switch that the VM should use.
   1. From the Actions menu under the name of the imported VM, choose Settings.
   2. Under Hardware in the left navigation bar of the Settings window, select Network Adapter, select the virtual switch from the Virtual switch drop-down list, and click Apply.
10. Start the imported VM.
    1. From the Actions menu under the name of the imported VM, choose Connect.
    2. In the Virtual Machine Connection window that opens, click Start.

A command window opens when the installation of the imported VM is started. Use this window to log in to the DLS virtual appliance only if you need to set the IP address of the DLS virtual appliance from the hypervisor.

Allow approximately 15 minutes after the VM is started for the installation of the DLS virtual appliance to complete and for the DLS virtual appliance to start. What to do after the DLS virtual appliance starts depends on whether the VM has been assigned an IP address automatically, for example, by a DHCP server:

• If the VM has been assigned an IP address, what to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

  • If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
  • If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

• Otherwise, set the IP address of the DLS virtual appliance from the hypervisor as explained in Setting the IP Address of a DLS Virtual Appliance from the Hypervisor.

After the VM has started, you can get its IP address from the Networking tab for the VM in Hyper-V Manager.

2.5.1.3. Installing the DLS Virtual Appliance on Red Hat Enterprise Linux KVM

The DLS image for Red Hat Enterprise Linux KVM is distributed as a ZIP archive that contains a QEMU copy-on-write (QCOW2) image file. After preparing the QCOW2 file, install the image by using Virtual Machine Manager to create a VM from the QCOW2 file.

Perform this task from the hypervisor host.

1. Download the ZIP archive that contains the QCOW2 image file to the hypervisor host.
2. Extract the contents of the ZIP archive that you downloaded.
3. Copy the QCOW2 image file to the /var/lib/libvirt/images directory on the hypervisor host.
4. Start Virtual Machine Manager.
5. Add a connection to the hypervisor host.
   1. In the Virtual Machine Manager window, from the File menu, choose Add Connection.
   2. In the Add Connection window that opens, set the options in the following table and click Connect.

      Option	Setting
      Hypervisor	From the drop-down list, select QEMU/KVM.
      Connect to remote host over SSH	Select this option.
      User Name	In this text-entry field, type root.
      Hostname	In this text-entry field, type the IP address or the fully qualified host name of the Red Hat Enterprise Linux KVM host.

   The connection is added to the Virtual Machine Manager window.

6. Context click the connection that you added in the previous step and choose New. The Create a new virtual machine wizard starts.
7. In the first New VM window, select the Import existing disk image option and click Forward.
8. In the second New VM window, import the downloaded QCOW2 image file and choose the operating system to install.
   1. Click Browse.
   2. In the Choose Storage Volume window that opens, select the downloaded QCOW2 image file and click Choose Volume.
   3. Back in the second New VM window, type Ubuntu 22.04 in the search box and from the list of operating systems that opens, select Ubuntu 22.04 (ubuntu).
   4. Click Forward.
9. In the third New VM window, set Memory to 8192 MiB and CPUs to 4, and click Forward.
10. In the final New VM window, specify the VM name and the network that the VM will use.
    1. In the Name text-entry field, type your choice of name for the VM that you are creating.
    2. Select the Customize configuration before install option.
    3. From the Network Selection drop-down list, select the network that the VM will use.
    4. Click Finish.
11. In the window for reviewing a new VM, modify the VM as follows.
    1. Remove USB Redirector 1, USB Redirector 2, and Channel spice. For each item to remove, context-click the item in the left navigation bar and from the menu that pops up, choose Remove Hardware.
    2. Change Video QXL to VGA. In the left navigation bar, select Video QXL and from the Model drop-down list, select VGA.
    3. In the the Overview tab update the Firmware to UEFI.
12. Click Apply to save your changes to the configuration and click Begin Installation.
13. After the VM is created, start the VM and log in to the VM to get the IP address of the VM. You must log in to the VM to get its IP address because the IP address is not shown in the Virtual Machine Manager console.
    1. Click the play button to start the VM on the hypervisor host.
    2. Use the command window that opens when the VM starts to log in to the DLS virtual appliance as the dls_admin user with the preset password welcome.
    3. Get the address of the VM.
       Copy

       Copied!

                   
       
                   
       $ ip addr
               

Allow approximately 15 minutes after the VM is started for the installation of the DLS virtual appliance to complete and for the DLS virtual appliance to start. What to do after the DLS virtual appliance starts depends on whether the VM has been assigned an IP address automatically, for example, by a DHCP server:

• If the VM has been assigned an IP address, what to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

  • If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
  • If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

• Otherwise, set the IP address of the DLS virtual appliance from the hypervisor as explained in Setting the IP Address of a DLS Virtual Appliance from the Hypervisor.

2.5.1.4. Installing the DLS Virtual Appliance on Red Hat Virtualization

The DLS image for Red Hat Virtualization is distributed as a ZIP archive that contains a QEMU copy-on-write (QCOW2) image file. After preparing the QCOW2 file, install the image by using Virtual Machine Manager to create a VM from the QCOW2 file.

Perform this task from the hypervisor host.

1. Download the ZIP archive that contains the QCOW2 image file to the hypervisor host.
2. Extract the contents of the ZIP archive that you downloaded.
3. Copy the QCOW2 image file to the /var/lib/libvirt/images directory on the hypervisor host.
4. Start Virtual Machine Manager.
5. Add a connection to the hypervisor host.
   1. In the Virtual Machine Manager window, from the File menu, choose Add Connection.
   2. In the Add Connection window that opens, set the options in the following table and click Connect.

      Option	Setting
      Hypervisor	From the drop-down list, select QEMU/KVM.
      Connect to remote host over SSH	Select this option.
      User Name	In this text-entry field, type root.
      Hostname	In this text-entry field, type the IP address or the fully qualified host name of the Red Hat Enterprise Linux KVM host.

   The connection is added to the Virtual Machine Manager window.

6. Context click the connection that you added in the previous step and choose New. The Create a new virtual machine wizard starts.
7. In the first New VM window, select the Import existing disk image option and click Forward.
8. In the second New VM window, import the downloaded QCOW2 image file and choose the operating system to install.
   1. Click Browse.
   2. In the Choose Storage Volume window that opens, select the downloaded QCOW2 image file and click Choose Volume.
   3. Back in the second New VM window, type Ubuntu 22.04 in the search box and from the list of operating systems that opens, select Ubuntu 22.04 (ubuntu).
   4. Click Forward.
9. In the third New VM window, set Memory to 8192 MiB and CPUs to 4, and click Forward.
10. In the final New VM window, specify the VM name and the network that the VM will use.
    1. In the Name text-entry field, type your choice of name for the VM that you are creating.
    2. Select the Customize configuration before install option.
    3. From the Network Selection drop-down list, select the network that the VM will use.
    4. Click Finish.
11. In the window for reviewing a new VM, modify the VM as follows.
    1. Remove USB Redirector 1, USB Redirector 2, and Channel spice. For each item to remove, context-click the item in the left navigation bar and from the menu that pops up, choose Remove Hardware.
    2. Change Video QXL to VGA. In the left navigation bar, select Video QXL and from the Model drop-down list, select VGA.
    3. In the the Overview tab update the Firmware to UEFI.
12. Click Apply to save your changes to the configuration and click Begin Installation.
13. After the VM is created, start the VM and log in to the VM to get the IP address of the VM. You must log in to the VM to get its IP address because the IP address is not shown in the Virtual Machine Manager console.
    1. Click the play button to start the VM on the hypervisor host.
    2. Use the command window that opens when the VM starts to log in to the DLS virtual appliance as the dls_admin user with the preset password welcome.
    3. Get the address of the VM.
       Copy

       Copied!

                   
       
                   
       $ ip addr
               

Allow approximately 15 minutes after the VM is started for the installation of the DLS virtual appliance to complete and for the DLS virtual appliance to start. What to do after the DLS virtual appliance starts depends on whether the VM has been assigned an IP address automatically, for example, by a DHCP server:

• If the VM has been assigned an IP address, what to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

  • If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
  • If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

• Otherwise, set the IP address of the DLS virtual appliance from the hypervisor as explained in Setting the IP Address of a DLS Virtual Appliance from the Hypervisor.

2.5.1.5. Installing the DLS Virtual Appliance on Ubuntu Hypervisor

The DLS image for Ubuntu Hypervisor is distributed as a ZIP archive that contains a QEMU copy-on-write (QCOW2) image file. After preparing the QCOW2 file, install the image by using Virtual Machine Manager to create a VM from the QCOW2 file.

Perform this task from the hypervisor host.

1. Download the ZIP archive that contains the QCOW2 image file to the hypervisor host.
2. Extract the contents of the ZIP archive that you downloaded.
3. Copy the QCOW2 image file to the /var/lib/libvirt/images directory on the hypervisor host.
4. Start Virtual Machine Manager.
5. Add a connection to the hypervisor host.
   1. In the Virtual Machine Manager window, from the File menu, choose Add Connection.
   2. In the Add Connection window that opens, set the options in the following table and click Connect.

      Option	Setting
      Hypervisor	From the drop-down list, select QEMU/KVM.
      Connect to remote host over SSH	Select this option.
      User Name	In this text-entry field, type root.
      Hostname	In this text-entry field, type the IP address or the fully qualified host name of the Red Hat Enterprise Linux KVM host.

   The connection is added to the Virtual Machine Manager window.

6. Context click the connection that you added in the previous step and choose New. The Create a new virtual machine wizard starts.
7. In the first New VM window, select the Import existing disk image option and click Forward.
8. In the second New VM window, import the downloaded QCOW2 image file and choose the operating system to install.
   1. Click Browse.
   2. In the Choose Storage Volume window that opens, select the downloaded QCOW2 image file and click Choose Volume.
   3. Back in the second New VM window, type Ubuntu 22.04 in the search box and from the list of operating systems that opens, select Ubuntu 22.04 (ubuntu).
   4. Click Forward.
9. In the third New VM window, set Memory to 8192 MiB and CPUs to 4, and click Forward.
10. In the final New VM window, specify the VM name and the network that the VM will use.
    1. In the Name text-entry field, type your choice of name for the VM that you are creating.
    2. Select the Customize configuration before install option.
    3. From the Network Selection drop-down list, select the network that the VM will use.
    4. Click Finish.
11. In the window for reviewing a new VM, modify the VM as follows.
    1. Remove USB Redirector 1, USB Redirector 2, and Channel spice. For each item to remove, context-click the item in the left navigation bar and from the menu that pops up, choose Remove Hardware.
    2. Change Video QXL to VGA. In the left navigation bar, select Video QXL and from the Model drop-down list, select VGA.
    3. In the the Overview tab update the Firmware to UEFI.
12. Click Apply to save your changes to the configuration and click Begin Installation.
13. After the VM is created, start the VM and log in to the VM to get the IP address of the VM. You must log in to the VM to get its IP address because the IP address is not shown in the Virtual Machine Manager console.
    1. Click the play button to start the VM on the hypervisor host.
    2. Use the command window that opens when the VM starts to log in to the DLS virtual appliance as the dls_admin user with the preset password welcome.
    3. Get the address of the VM.
       Copy

       Copied!

                   
       
                   
       $ ip addr
               

Allow approximately 15 minutes after the VM is started for the installation of the DLS virtual appliance to complete and for the DLS virtual appliance to start. What to do after the DLS virtual appliance starts depends on whether the VM has been assigned an IP address automatically, for example, by a DHCP server:

• If the VM has been assigned an IP address, what to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

  • If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
  • If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

• Otherwise, set the IP address of the DLS virtual appliance from the hypervisor as explained in Setting the IP Address of a DLS Virtual Appliance from the Hypervisor.

2.5.1.6. Installing the DLS Virtual Appliance on VMware vSphere

The DLS image for VMware vSphere is distributed as a ZIP archive that contains an Open Virtual Appliance (OVA) file.

Use the VMware vSphere Client to perform this task on the ESXi server on which you want to run the DLS virtual appliance.

For additional information, see the following topics on the VMware Docs site:

• Log in to vCenter Server by Using the vSphere Web Client
• Deploy an OVF or OVA Template

1. Download the ZIP archive that contains the OVA file that contains the DLS image for VMware vSphere.
2. Extract the contents of the ZIP archive that you downloaded.
3. Log in to vCenter Server by using the VMware vSphere Client.
4. From the VMware vSphere Client Actions menu, choose Deploy OVF Template.
5. Select the Local file option, browse for and select the downloaded OVA file, and click Next.
6. Enter the your choice of virtual machine name, select a location for the virtual machine, and click Next.
7. Select a compute resource where the virtual machine will be created and click Next.
8. Review the details of the template that you are deploying and click Next.
9. Select the storage for the virtual appliance configuration and disk files and click Next.
10. Leave the destination network as-is, set the IP allocation option to Static - Manual, and click Next.
11. Set the virtual network and IP allocation properties for the VM and click Next.
    1. In the ipaddress text-entry field, type the IP address that you want to assign to the VM.
       Note:

       To change this address after completing the installation, you must follow the instructions in Changing the IP Address of a VMware VM Set During DLS Appliance Installation. If you use any other method to change this address, it reverts to its original setting when the VM is restarted.

    2. In the netmask text-entry field, type the subnet mask of the VM's network in classless inter-domain routing (CIDR) format without the leading slash character (/). To get a subnet mask in CIDR format from its decimal equivalent, refer to the table on page 2 of IETF RFC 1878: Variable Length Subnet Table For IPv4. For example, the subnet mask in CIDR format of the decimal equivalent 255.255.255.0 is 24.
    3. In the gateway text-entry field, type the IP address of the VM's default gateway.
       Note:

       If you leave the gateway field empty, the DLS virtual appliance uses DHCP settings.

    4. Optional: In the dns_server_one text-entry field, type the IP address of the first DNS server to be used for name resolution.
    5. Optional: In the dns_server_two text-entry field, type the IP address of the second DNS server to be used for name resolution.
12. Review all the details of the virtual machine that you are creating and click Finish.
13. Start the VM that you created.
    Note:

    If subnet conflicts occur, contact your network administrator for an appropriate subnet address and then follow these steps.

    1. Modify the back-tier property of the networks element in the /etc/dls/config/docker-compose.yml file using the rsu_admin user.
    2. Restart the VM for the change to take effect.

Allow approximately 15 minutes after the VM is started for the installation of the DLS virtual appliance to complete and for the DLS virtual appliance to start. What to do after the DLS virtual appliance starts depends on whether the VM has been assigned an IP address automatically, for example, by a DHCP server:

• If the VM has been assigned an IP address, what to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

  • If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
  • If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

• Otherwise, set the IP address of the DLS virtual appliance from the hypervisor as explained in Setting the IP Address of a DLS Virtual Appliance from the Hypervisor.

2.5.2. Setting the IP Address of a DLS Virtual Appliance from the Hypervisor

If the VM that hosts a DLS virtual appliance has not been assigned an IP address automatically, you must set the IP address from the hypervisor. Each DLS virtual appliance provides a shell script specifically for this purpose and is configured with a user account for running the script.

1. Use the hypervisor management console of the appliance to log in as the user dls_admin to the VM that hosts the DLS virtual appliance. If the dls_admin user has not been registered, you can still log in to the VM as the dls_admin user with the default password welcome.
2. Run the /etc/adminscripts/set-static-ip-cli.sh script.
   Copy

   Copied!

               
   
               
   $ /etc/adminscripts/set-static-ip-cli.sh
           

3. When prompted, enter the details of the IP address. The script presents any default values that are already set for the virtual appliance's network.
   1. Enter the number that denotes the IP version that the virtual appliance's network uses.
      • For an IPv4 network, type 4.
      • For an IPv6 network, type 6.
   2. Enter the IP address that you want to assign to the DLS virtual appliance.
   3. Enter the IP address of the DLS virtual appliance's default gateway.
      Note:

      If you omit the default gateway address, the DLS virtual appliance uses DHCP settings.

   4. Enter the IP address of the first DNS server to be used for name resolution.
   5. Enter the IP address of the second DNS server to be used for name resolution.
   6. Enter the subnet mask of the DLS virtual appliance's network in classless inter-domain routing (CIDR) format without the leading slash character (/). To get a subnet mask in CIDR format from its decimal equivalent, refer to the table on page 2 of IETF RFC 1878: Variable Length Subnet Table For IPv4. For example, the subnet mask in CIDR format of the decimal equivalent 255.255.255.0 is 24.

After the IP address has been set, log files containing progress message from the script are available in the /tmp/static-ip-cli-logs directory.

What to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

• If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
• If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

2.5.3. Changing the IP Address of a VMware VM Set During DLS Appliance Installation

The IP address of a VMware VM that hosts a DLS appliance can be set when the appliance is installed from an OVF template. If the IP address was set this way, you can change it only by editing vApps options within VM that hosts the DLS appliance. If you use any other method to change this address, it reverts to its original setting when the VM is restarted.

1. Log in to vCenter Server by using the VMware vSphere Web Client. For detailed instructions, refer to Log in to vCenter Server by Using the vSphere Web Client.
2. From the vCenter Server inventory, navigate to the VM that hosts the DLS appliance.
3. Shut down the VM to which you navigated in the previous step.
4. On the Configure tab, expand Settings, select vApp options, and click Edit.
5. In the list of vApp options, select Networkproperties.IPaddress and click Set Value.
6. Enter the IP address that you want to assign to the VM that hosts the DLS appliance.
7. Save your changes and start the VM.

2.6. Deploying a Containerized DLS Software Image

For deployments on a supported container orchestration platform, the DLS is supplied as a containerized software image.

After verifying the requirements in Platform Requirements for a DLS Virtual Appliance or Containerized DLS Software Image, deploy a containerized DLS software image by following this sequence of instructions:

1. Setting Properties for a Containerized DLS Software Image
2. Deploying the Containerized DLS Software Image on a Supported Platform
3. Registering the DLS Administrator User
4. Optional:  Creating or Expanding an HA Cluster of DLS Instances

2.6.1. Contents of the Containerized DLS Software Image Download

The containerized DLS software image is distributed as the ZIP archive nls-4.0.0-bios.zip.

This ZIP archive contains the following artifacts:

dls_appliance_4.0.0.tar.gz

The DLS application container.

dls_pgsql_4.0.0.tar.gz

The PostgreSQL database container.

The DLS application container and the PostgreSQL database container share a common volume for exchanging information between them. If both containers are deployed on a multinode cluster, they must be run on the same worker node.

2.6.2. Setting Properties for a Containerized DLS Software Image

To enable communications with the container within which the DLS appliance is running, you must set properties such as host names, IP addresses, and port numbers. Set these properties before deploying the containerized DLS software image on a supported platform.

Set the properties for a containerized DLS software image by editing the appropriate deployment file for your container orchestration platform.

2.6.2.1. Setting Environment Variables to Specify String Properties

You can set environment variables to specify string properties for all supported container orchestration platforms.

Set environment variables to specify string properties by editing the appropriate section of the deployment file for your container platform.

The environment variables for specifying string properties are as follows:

Required: DLS_DB_HOST

The IP address of the database container.

Ensure that the IP address of the database container is a private IP address on the same subnet as the DLS appliance container. The database container must not be accessible over any public subnet.

Required: DLS_PUBLIC_IP

The IP address of the container orchestration platform. To access the NVIDIA Licensing application, the user connects to the container in which the DLS software image is deployed through this address.

Optional: DLS_PRIVATE_HOSTNAME

The host name of the container in which the DLS software image is deployed.

If this environment variable is not set, the container orchestration platform sets the host name to the container ID.

Optional: FQDN

The fully qualified domain name that is mapped to the IP address that is specified by the DLS_PUBLIC_IP environment variable.

Ensure that this name can be resolved by licensed clients. Do not specify a name that can be resolved only by the container orchestrator.

If this environment variable is not set, a user cannot connect to the container in which the DLS software image is deployed through a fully qualified domain name.

2.6.2.2. Specifying Integer Values as Environment Variables

You can specify integer values such as port numbers for Docker, Podman, Red Hat OpenShift Container Platform, and VMware Tanzu Application Platform as environment variables.

To specify integer values by setting environment variables, edit the appropriate section of the deployment file for your container platform.

The following environment variables apply to Docker, Red Hat OpenShift Container Platform, and VMware Tanzu Application Platform:

Optional: CPU_CORE_LIMIT

The maximum number of CPU cores that can be assigned to the DLS appliance container pod.

Default: 4

Optional: DLS_HA_MAX_NODES_ENV

The maximum number of instances in a cluster to which this instance is to be added.

Allowed values: 2-9

Default: 2

Optional: DLS_HTTP_PORT

The port on which the container in which the DLS software image is deployed listens for HTTP requests.

Default: 80

Optional: DLS_HTTPS_PORT

The port on which the container in which the DLS software image is deployed listens for HTTPS requests.

Default: 443

Optional: DLS_RABBITMQ_SSL_PORT

The Secure Sockets Layer (SSL) port through which the nodes in and HA cluster of DLS instances communicate with each other.

Default: 5671

The following environment variables apply only to Red Hat OpenShift Container Platform and VMware Tanzu Application Platform:

Optional: DLS_EXPOSED_HTTP_PORT

The port on which the container orchestrator listens for and forwards the request to the port that is specified by the DLS_HTTP_PORT environment variable.

Not applicable to Docker or Podman.

Default: 30000

Optional: DLS_EXPOSED_HTTPS_PORT

The port on which the container orchestrator listens for and forwards the request to the port that is specified by the DLS_HTTP_PORTS environment variable.

Not applicable to Docker or Podman.

Default: 30001

Optional: DLS_VA_SERVICE_PORT

The port in the container orchestrator to which the DLS appliance container binds.

Not applicable to Docker or Podman.

Default: 8085

2.6.2.3. Specifying Integer Values as Actual Values

Kubernetes does not accept strings for integer values. Therefore, you cannot specify integer values for Kubernetes as environment variables. Instead, you must specify integer values for Kubernetes as actual values.

To specify integer values as actual values, replace the references to environment variables with actual values in the ports: section of the nls-si-0-deployment.yaml and nls-si-0-service.yaml deployment files.

• In nls-si-0-deployment.yaml, the references to environment variables in the ports: section are as follows:
  Copy

  Copied!

              
  
              
  ports:
     - containerPort: ${DLS_HTTP_PORT:-80}
       hostPort: ${DLS_EXPOSED_HTTP_PORT:-80}
     - containerPort: ${DLS_HTTPS_PORT:-443}
       hostPort: ${DLS_EXPOSED_HTTPS_PORT:-443}
     - containerPort: ${DLS_RABBITMQ_SSL_PORT:-5671}
       hostPort: ${DLS_RABBITMQ_SSL_PORT:-5671}
     - containerPort: 8085
       hostPort: ${DLS_VA_SERVICE_PORT:-8085}
          

• In nls-si-0-service.yaml, the references to environment variables in the ports: section are as follows:
  Copy

  Copied!

              
  
              
  ports:
      - name: "DLS_HTTP_CONTAINER"
        port: ${DLS_HTTP_PORT:-80}
        targetPort: ${DLS_HTTP_PORT:-80}
        nodePort: ${DLS_EXPOSED_HTTP_PORT:-30000}
      - name: "DLS_HTTPS_CONTAINER"
        port: ${DLS_HTTPS_PORT:-443}
        targetPort: ${DLS_HTTPS_PORT:-443}
        nodePort: ${DLS_EXPOSED_HTTPS_PORT:-30001}
      - name: "DLS_RABBITMQ_SSL_PORT"
        port: ${DLS_RABBITMQ_SSL_PORT:-5671}
        targetPort: ${DLS_RABBITMQ_SSL_PORT:-5671}
        nodePort: ${DLS_RABBITMQ_SSL_PORT:-5671}
      - name: "DLS_VA_SERVICE_PORT"
        port: 8085
        targetPort: 8085
        nodePort: ${DLS_VA_SERVICE_PORT:-8085}
          

The values with which to replace these references to environment variables are as follows:

Both files: ${DLS_HTTP_PORT:-80}

The port on which the container in which the DLS software image is deployed listens for HTTP requests.

nls-si-0-deployment.yaml: ${DLS_EXPOSED_HTTP_PORT:-80}

nls-si-0-service.yaml: ${DLS_EXPOSED_HTTP_PORT:-30000}

The port on which the container orchestrator listens for and forwards the request to the port that is specified by the DLS_HTTP_PORT environment variable.

Both files: ${DLS_HTTPS_PORT:-443}

The port on which the container in which the DLS software image is deployed listens for HTTPS requests.

nls-si-0-deployment.yaml: ${DLS_EXPOSED_HTTPS_PORT:-443}

nls-si-0-service.yaml: ${DLS_EXPOSED_HTTPS_PORT:-30001}

The port on which the container orchestrator listens for and forwards the request to the port that is specified by the DLS_HTTP_PORTS environment variable.

Both files: ${DLS_RABBITMQ_SSL_PORT:-5671}

The Secure Sockets Layer (SSL) port through which the nodes in and HA cluster of DLS instances communicate with each other.

Both files: ${DLS_VA_SERVICE_PORT:-8085}

The port in the container orchestrator to which the DLS appliance container binds.

This example shows the ports: sections in the nls-si-0-deployment.yaml and nls-si-0-service.yaml deployment files in which the references to environment variables are replaced with actual values.

• In nls-si-0-deployment.yaml, the ports: section is as follows:
  Copy

  Copied!

              
  
              
  ports:
     - containerPort: 80
       hostPort: 80
     - containerPort: 443
       hostPort: 443
     - containerPort: 5671
       hostPort: 5671
     - containerPort: 8085
       hostPort: 8085
          

• In nls-si-0-service.yaml, the ports: section is as follows:
  Copy

  Copied!

              
  
              
  ports:
      - name: "DLS_HTTP_CONTAINER"
        port: 80
        targetPort: 80
        nodePort: 30000
      - name: "DLS_HTTPS_CONTAINER"
        port: 443
        targetPort: 443
        nodePort: 30001
      - name: "DLS_RABBITMQ_SSL_PORT"
        port: 5671
        targetPort: 5671
        nodePort: 30002
      - name: "DLS_VA_SERVICE_PORT"
        port: 8085
        targetPort: 8085
        nodePort: 30003
          

2.6.3. Deploying the Containerized DLS Software Image on a Supported Platform

The containerized DLS software image is distributed with default deployment files for several container orchestration platforms. You use standard interfaces of the container orchestration platform to deploy the containerized DLS software image on your chosen platform.

The default deployment file for each supported container orchestration platform specifies the resource reservations for the container that are listed in Platform Requirements for a DLS Virtual Appliance or Containerized DLS Software Image. You are not required to specify the resource reservations for the container when you deploy the containerized DLS software image.

Follow the instructions for the container orchestration platform that you are using.

2.6.3.1. Deploying the Containerized DLS Software Image on Docker

Ensure that the required environment variables have been set as explained in Setting Properties for a Containerized DLS Software Image.

1. Import the DLS appliance artifact and the PostgreSQL database artifact.
   1. Import the DLS appliance artifact.
      Copy

      Copied!

                  
      
                  
      docker load --input dls_appliance_4.0.0.tar.gz
              

   2. Import the PostgreSQL database artifact.
      Copy

      Copied!

                  
      
                  
      $ docker load --input dls_pgsql_4.0.0.tar.gz
              

2. Change to the directory that contains the docker-compose.yml file.
3. Start the DLS appliance and PostgreSQL database containers.
   Copy

   Copied!

               
   
               
   $ docker-compose up
           

What to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

• If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
• If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

2.6.3.2. Deploying the Containerized DLS Software Image on Kubernetes Platforms

Perform this task if you are using Kubernetes, Red Hat OpenShift Container Platform, or VMware Tanzu Application Platform. This procedure installs a single-replica DLS deployment (Active - Passive) using the legacy YAML files. To provide high availability with this method, deploy separate DLS instances and configure them as an HA cluster.

Ensure that the following prerequisites are met:

• The required environment variables have been set as explained in Setting Properties for a Containerized DLS Software Image.
• A private repository for the DLS appliance artifact and the PostgreSQL database artifact has been created.
• If a registry secret is required for pulling the artifacts from the private repository, the registry secret has been created.

  In the deployment files for the DLS appliance artifact and the PostgreSQL database artifact, the name of the registry secret is preset to registry-secret. If you create a secret with this name, you don't need to edit the deployment files to reference the secret.

  For the Active-Active deployment model, see Deploying Multi-Replica DLS Instance on Kubernetes Platforms. In that model, the DLS operator manages multiple application replicas that share a PostgreSQL database cluster.

1. Import the DLS appliance artifact and the PostgreSQL database artifact into your private repository.
2. Edit the deployment files for the DLS appliance artifact and the PostgreSQL database artifact to pull these artifacts from the private repository into which they were imported. In each file, replace the string <POPULATE THIS WITH PRIVATE REPOSITORY> with the name of the private repository.
   1. For the DLS appliance artifact, edit the following line in the file nls-si-0-deployment.yaml:
      Copy

      Copied!

                  
      
                  
      image: <POPULATE THIS WITH PRIVATE REPOSITORY>:appliance
              

   2. For the PostgreSQL database artifact, edit the following line in the file postgres-nls-si-0-deployment.yaml:
      Copy

      Copied!

                  
      
                  
      image: <POPULATE THIS WITH PRIVATE REPOSITORY>:pgsql
              

3. If a registry secret is required for pulling the artifacts from the private repository, edit the deployment files for the DLS appliance artifact and the PostgreSQL database artifact to reference the secret. In each file, replace the string registry-secret with the name of your registry secret.
   1. For the DLS appliance artifact, edit the file nls-si-0-deployment.yaml.
   2. For the PostgreSQL database artifact, edit the file postgres-nls-si-0-deployment.yaml.
4. Start the PostgreSQL database container pod with the supplied deployment file postgres-nls-si-0-deployment.yaml.
   Copy

   Copied!

               
   
               
   $ kubectl create -f directory/postgres-nls-si-0-deployment.yaml
           

   directory

   The full path to the directory that contains the file postgres-nls-si-0-deployment.yaml.

5. Get the IP address of the PostgreSQL database container pod.
   Copy

   Copied!

               
   
               
   $ kubectl get pods -o wide
           

6. Set the DLS_DB_HOST environment variable in the file nls-si-0-deployment.yaml to the IP address that you got in the previous step.
   Note:

   To enable the DLS appliance container pod to create and modify files on the volumes mapped to it, ensure that the required file access permissions are set on these volumes.

7. Start the DLS appliance container pod with the supplied deployment file nls-si-0-deployment.yaml.
   Copy

   Copied!

               
   
               
   $ kubectl create -f directory/nls-si-0-deployment.yaml
           

   directory

   The full path to the directory that contains the file nls-si-0-deployment.yaml.

What to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

• If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
• If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

2.6.3.2.1. Deploying Multi-Replica DLS Instance on Kubernetes Platforms

Ensure that the following requirements are met before you deploy a multi-replica DLS instance on Kubernetes, Red Hat OpenShift Container Platform, or VMware Tanzu Application Platform. Multi-replica DLS uses an Active-Active deployment model.

• Platform Requirements for a DLS Virtual Appliance or Containerized DLS Software Image in the NVIDIA License System User Guide.
• Host Name Resolution Requirements for a DLS Virtual Appliance in the NVIDIA License System User Guide
• Communications Ports Requirements in the NVIDIA License System User Guide
• The NVIDIA License System Release Notes for your release (supported platforms and known issues)

2.6.3.2.1.1. About Multi-Replica DLS Deployment

Perform this reading task before you deploy a multi-replica DLS instance on Kubernetes, Red Hat OpenShift Container Platform, or VMware Tanzu.

What is multi-replica deployment?

In a multi-replica deployment, NVIDIA License System runs several copies of the DLS application for one DLS service instance.

Licensed clients (for example, vGPU clients) still connect to one address. They do not need to know how many copies of DLS are running behind that address.

By default, a multi-replica deployment runs:

• Three DLS application copies
• Three database copies (for database high availability)

Your organization can change these numbers during installation if your platform team advises a different size.

Why use multi-replica?

A multi-replica deployment is intended for production Kubernetes environments when you need:

• Continued licensing service if one application copy fails
• Continued database service if one database copy fails
• Version upgrades that replace application copies one at a time, so licensing can stay available during the upgrade

How this differs from other DLS options

Roles and responsibilities

Many organizations have one person perform all these roles. The split below helps when teams are separate.

What the software installs for you

You install DLS by using Helm charts from the NLS software download artifact. After installation:

• Automation software (an operator) creates and maintains the application copies, the database, and the required storage and network objects.
• You do not need to start the database by hand before the application, as you do in the older single-pod Kubernetes YAML procedure.
• You manage the deployment mainly through Helm settings and the DLS Web UI after the system reports that it is ready.

.

2.6.3.2.1.2. Before You Begin

Ensure that the following requirements are met before you deploy a multi-replica DLS instance on Kubernetes, Red Hat OpenShift Container Platform, or VMware Tanzu.

Also review:

• Platform Requirements for a DLS Virtual Appliance or Containerized DLS Software Image in the NVIDIA License System User Guide
• Host Name Resolution Requirements for a DLS Virtual Appliance in the NVIDIA License System User Guide
• Communications Ports Requirements in the NVIDIA License System User Guide

Sizing Guidelines

Scale a DLS multi-replica deployment by adjusting the quantity of appliance and database pods rather than the vCPU and RAM assigned to a single instance. Avoid using sizing data from Throughput for a DLS Appliance, Scalability for a DLS Appliance, or Burst Load Performance for a DLS Appliance for multi-replica topologies.

Find pod-level resource limits and measured capacity for supported multi-replica configurations in these subsections:

• Default Resource Configuration for a DLS Multi-Replica Deployment
• Scalability for a DLS Multi-Replica Deployment
• Burst Load Performance for a DLS Multi-Replica Deployment

located under Sizing Guidelines for a DLS Appliance.

During a version upgrade, the system may run one extra application copy for a short time while it replaces copies one by one. Allow a small amount of spare CPU, memory, and database connection capacity for that window.

Storage requirements

DLS needs two kinds of persistent storage. Your platform administrator must provide the correct storage classes (named storage templates in the cluster).

Important

• Do not use the same NFS / RWX class for database data. Database storage must use a block (RWO) class.
• If your cluster has no RWX storage class, multi-replica deployment is not supported with the default settings. Add NFS or another shared file storage option before you continue.

Platform example values for Tanzu and OpenShift are described in kubernetes/helm-charts/README.md in the NLS download package.

Network, DNS, and client access

Licensed clients reach DLS through a single published address that you configure during install.

Ports that licensed clients need

These ports match the User Guide communications requirements for a licensed client and a DLS instance.

Session stickiness

Your load balancer should keep a given client on the same healthy application copy when possible (sticky sessions / session persistence) or preserve the client source IP so that Kubernetes can do the same.

Licensing usually still works without stickiness, but sticky sessions reduce edge cases when several application copies are active.

OpenShift note

On OpenShift, you typically publish HTTPS through a Route to the DLS service on port 443, and you still need a path for HTTP lease return on port 80 (or the port you configure for lease shutdown). Set the client-facing address to the host name that clients will use.

Container images

Load these images from the NLS ARTIFACT package into a registry that your cluster can pull from:

The Helm charts in the package are already matched to these image versions. You normally only need to point the charts at your registry path.

If the registry is private, create the image pull secret as described in the Helm README for your release.

Information to collect before install

Ask your platform team for:

1. Registry path for DLS images (for example harbor.example.com/dls)
2. RWX storage class name for configurations
3. RWO storage class name for the database
4. Client-facing VIP or IP address
5. Optional DNS host name for that address
6. Whether the platform is vanilla Kubernetes, OpenShift, or Tanzu (so you can use the matching values file)

What to do next

• Refer to the Sizing Guidelines for a DLS Appliance for the application and db pods and deployment topology
• Deploy the multi-replica instance as explained in Deploying a Multi-Replica DLS Instance on Kubernetes Platforms.
• If your platform team requires dedicated nodes or tainted node pools, also review Controlling Where DLS Pods Run before you finalize Helm values.

2.6.3.2.1.3. Controlling Where DLS Pods Run

Perform this task if your platform team wants DLS application copies, database copies, or setup jobs to run only on selected worker nodes (for example a dedicated node pool), including nodes that use taints.

If you do not set these options, DLS keeps the default placement behavior shipped with the release. Existing deployments that omit these settings continue to work as before.

Exact Helm value names for your release are in kubernetes/helm-charts/README.md and in the dls-appliance-instance / dls-platform values files in the NLS download package.

What you can control

• Workload	Helm / configuration block	What it affects
  DLS application copies	applianceScheduling	Application pods, and appliance-related setup jobs
  Database copies	postgresScheduling	PostgreSQL pods, and database-related setup or upgrade jobs
  Connection poolers (optional)	poolerScheduling	PgBouncer pooler pods, when poolers are enabled

For each block you can set, when needed:

Default behavior (no scheduling settings)

When applianceScheduling, postgresScheduling, and poolerScheduling are empty or omitted:

• Application copies use the built-in preferred spread across nodes and zones (soft rules; the scheduler may still place more than one copy on the same node if the cluster is small).
• Database copies use the database automation defaults (preferred spread across nodes).
• An application disruption budget is created only when application autoscaling (enableHPA) is enabled — the same behavior as earlier multi-replica releases.

This is the safe path for most installs and for upgrades of clusters that already run multi-replica DLS.

Before you begin (platform preparation)

Ask your platform administrator to:

1. Identify or create the worker nodes that should run DLS application and/or database workloads.
2. Label those nodes (example labels below).
3. Optionally taint those nodes so other workloads do not schedule there.
4. Confirm that enough nodes exist if you plan to use Required anti-affinity (you need at least as many eligible nodes as copies).

Example labels and taints (adjust names to your site standard):

            

            
# Application nodes
kubectl label node <app-node> dls.nvidia.com/workload=appliance
kubectl taint nodes <app-node> dls.nvidia.com/dedicated=appliance:NoSchedule

# Database nodes
kubectl label node <db-node> dls.nvidia.com/workload=database
kubectl taint nodes <db-node> dls.nvidia.com/dedicated=database:NoSchedule
        

On OpenShift, use oc instead of kubectl when that is your site practice.

Configuring placement in Helm values

Add the scheduling blocks under your instance settings (for the platform chart, under instance.spec).

Example: dedicated application and database node pools

            

            
# Fragment for my-dls-values.yaml (dls-platform: under instance.spec)
# or for the dls-appliance-instance chart: under spec

applianceScheduling:
  nodeSelector:
    dls.nvidia.com/workload: appliance
  tolerations:
    - key: dls.nvidia.com/dedicated
      operator: Equal
      value: appliance
      effect: NoSchedule
  podAntiAffinity: Required

postgresScheduling:
  nodeSelector:
    dls.nvidia.com/workload: database
  tolerations:
    - key: dls.nvidia.com/dedicated
      operator: Equal
      value: database
      effect: NoSchedule
  podAntiAffinity: Required

# Optional — only if you enabled poolers (poolerInstances > 0)
poolerScheduling:
  nodeSelector:
    dls.nvidia.com/workload: database
  tolerations:
    - key: dls.nvidia.com/dedicated
      operator: Equal
      value: database
      effect: NoSchedule
        

Optional: application disruption budget without autoscaling

By default, the application disruption budget follows autoscaling (enableHPA). To keep a disruption budget when autoscaling is off:

            

            
enableHPA: false
applianceScheduling:
  pdb:
    enabled: true
    minAvailable: "2"   # keep at least two application copies during voluntary drains
        

Optional: pooler disruption budget

Pooler disruption budgets are off unless you enable them:

            

            
poolerInstances: 3
poolerScheduling:
  pdb:
    enabled: true
    minAvailable: "1"
        

Applying the settings

New install

Include the scheduling blocks in the values file you pass to helm install, as described in Deploying a Multi-Replica DLS Instance on Kubernetes Platforms.

Existing deployment

1. Add or update the scheduling blocks in your values file.
2. Run helm upgrade with the same chart and values you use for normal upgrades (see Upgrading a Multi-Replica DLS Deployment and the Helm README).
3. Wait until the DLS instance returns to Ready.
4. Confirm that pods land on the intended nodes:
   Copy

   Copied!

               
   
               
   kubectl get pods -n dls-system -o wide
           

Choosing Preferred vs Required anti-affinity

Relationship to multi-node storage spread

multiNodeSpread controls storage for RabbitMQ (shared PVC versus local emptyDir). It does not pin pods to specific nodes.

To pin pods to nodes, use the scheduling blocks in this topic. You may use both: for example multiNodeSpread: true together with applianceScheduling on a dedicated application pool.

What to do next

• After install or upgrade, verify pods with Verifying the Multi-Replica Deployment.
• If pods stay Pending after you set scheduling, see Troubleshooting Multi-Replica DLS Deployments.

2.6.3.2.1.4. Installing the multi-replica deployment

Perform this task to install a multi-replica DLS instance on Kubernetes, Red Hat OpenShift, or VMware Tanzu.

Before installing, import the release images into a repository that the cluster can access. Obtain a client-facing virtual IP or LoadBalancer IP address, a storage class that supports ReadWriteMany (RWX) for the shared configuration, log, and RabbitMQ volumes, and a block-storage class that supports ReadWriteOnce (RWO) for the PostgreSQL volumes.

Replace each placeholder below with the value for your environment. <DLS-image-repository> is the complete image repository path, including the DLS image name, for example registry.example.com/licensing/dls, without an image tag. <client-facing-IP-address> is the numeric IP address that clients use to reach DLS. <RWX-storage-class> and <RWO-database-storage-class> are storage class names available in your cluster.

Run only the example for your platform. Start in the root directory of the extracted deployment package, which contains the kubernetes directory.

For Kubernetes without the OpenShift or Tanzu platform overrides, run:

            

            
cd kubernetes/helm-charts

helm install dls ./dls-platform \
  --namespace default \
  --set-string global.image.repository='<DLS-image-repository>' \
  --set-string instance.spec.publicIP='<client-facing-IP-address>' \
  --set-string instance.spec.storageClass='<RWX-storage-class>' \
  --set-string instance.spec.dbStorageClass='<RWO-database-storage-class>'
        

For Red Hat OpenShift, run:

            

            
cd kubernetes/helm-charts

helm install dls ./dls-platform \
  --namespace default \
  -f dls-platform/values-openshift.yaml \
  --set-string global.image.repository='<DLS-image-repository>' \
  --set-string instance.spec.publicIP='<client-facing-IP-address>' \
  --set-string instance.spec.storageClass='<RWX-storage-class>' \
  --set-string instance.spec.dbStorageClass='<RWO-database-storage-class>'
        

For VMware Tanzu, run:

            

            
cd kubernetes/helm-charts

helm install dls ./dls-platform \
  --namespace default \
  -f dls-platform/values-tanzu.yaml \
  --set-string global.image.repository='<DLS-image-repository>' \
  --set-string instance.spec.publicIP='<client-facing-IP-address>' \
  --set-string instance.spec.storageClass='<RWX-storage-class>' \
  --set-string instance.spec.dbStorageClass='<RWO-database-storage-class>'
        

The OpenShift and Tanzu values files keep multiNodeSpread set to false and use shared RWX volumes. The OpenShift values file also enables the OpenShift-specific operator and database settings. Specify the RWO database storage class explicitly; do not use the shared RWX class for the database volumes.

To configure a DNS name at installation time, append --set-string instance.spec.fqdn='<DLS-fully-qualified-domain-name>' to the same helm install command for your platform before running it.

Configure DNS so that the fully qualified domain name resolves to the client-facing IP address.

Watch the DLS instance status. On Kubernetes or VMware Tanzu, run:

kubectl get dlsappliance dls-main -n default -w

On Red Hat OpenShift, run:

oc get dlsappliance dls-main -n default -w

Wait until PHASE shows Ready, then press Ctrl+C to stop watching. If PHASE shows Failed, see Troubleshooting Multi-Replica DLS Deployments.

Confirm that the application, database, and operator pods are ready. On Kubernetes or VMware Tanzu, run:

kubectl get pods -n dls-system

kubectl get pods -n cnpg-system

kubectl get pods -n dls-appliance-operator

On Red Hat OpenShift, run:

oc get pods -n dls-system

oc get pods -n cnpg-system

oc get pods -n dls-appliance-operator

Application, database, and operator pods should show Running with all containers ready. One-time setup jobs may show Completed. Ready indicates that the platform deployment is ready; administrator registration and license allocation installation are still required

2.6.3.2.1.5. Verifying the Multi-Replica Deployment

Perform these checks after a new multi-replica install or after an upgrade return to Ready.

Health checklist

• Check	What to do	Expected result
  Instance phase	kubectl get dlsappliance dls-main -n default (or oc on OpenShift)	PHASE is Ready (use your CR namespace if not default)
  Application copies	kubectl get pods -n dls-system	DLS application pods are Running (use your workload namespace if not dls-system)
  Database	Inspect database pods / cluster status in dls-system	Database pods are healthy / Ready
  Controllers (optional)	kubectl get pods -n cnpg-system and -n dls-appliance-operator	CNPG and appliance operator pods are Running (use custom namespaces if you changed them)
  Storage	kubectl get pvc -n dls-system	Claims are Bound
  Node placement (optional)	kubectl get pods -n dls-system -o wide	If you configured dedicated nodes, application and database pods run on the expected nodes
  Web UI	Open https://<publicIP>/	Login or registration page loads
  Test license	Lease a license from a test client	Success

What Ready does not guarantee

1. Register the DLS administrator user (new installs).
2. Install the license server file from the NVIDIA Licensing Portal.
3. Configure users, roles, and any LDAP or SSO settings your organization requires.
4. Confirm that licensed clients can reach the published address on ports 443 and, for Windows shutdown return, 80.

Quick connectivity checks

From a machine on the client network:

1. Confirm HTTPS reaches DLS:
   Copy

   Copied!

               
   
               
   curl -k https://<publicIP>/
           

2. Confirm DNS, if you use a host name:
   Copy

   Copied!

               
   
               
   nslookup <fqdn>
           

3. Confirm that the host name resolves to the same address you set as publicIP.

If these checks fail, see Troubleshooting Multi-Replica DLS Deployments.

What to do next

• Day-to-day administration follows the same User Guide topics as other DLS deployments (users, licenses, alerts, and so on).
• For version upgrades, see Upgrading a Multi-Replica DLS Deployment.
• For optional dedicated-node placement, see Controlling Where DLS Pods Run.

2.6.3.2.1.6. Accessing the DLS Web UI

1. From a browser that can reach the client-facing address, open: https://<publicIP>/ If you configured a DNS name, you may also use: https://<fqdn>/
2. Register the DLS administrator user as explained in Registering the DLS Administrator User in the NVIDIA License System User Guide.
3. Install the license server file from the NVIDIA Licensing Portal and complete the remaining configuration steps as you would for any other DLS instance.

What to do next

• Verify health using Verifying the Multi-Replica Deployment
• To pin workloads to dedicated or tainted nodes (optional), see Controlling Where DLS Pods Run
• For later version upgrades, see Upgrading a Multi-Replica DLS Deployment
• If the phase stays Failed or the Web UI does not load, see Troubleshooting Multi-Replica DLS Deployments

2.6.3.2.1.7. Upgrading a Multi-Replica DLS Deployment

Perform this task to move an existing multi-replica DLS deployment to a newer NLS release on Kubernetes, Red Hat OpenShift Container Platform, or VMware Tanzu.

Before you upgrade

1. Read the NVIDIA License System Release Notes for the target version.
2. Load the new container images into your registry:
   • dls:operator_<newVersion>
   • dls:appliance_<newVersion>
   • dls:pgsql_<newVersion>\
3. Use the Helm charts from the new NLS ARTIFACT.
4. Confirm that you still have your previous values (registry, publicIP, storage classes, replica count, and any optional scheduling / node-placement settings).
5. Choose an upgrade strategy:

   Strategy	When to use
   Rolling (recommended)	Routine upgrades that stay on the same PostgreSQL major version
   File-based upgrade	PostgreSQL major version change, or when Rolling is not suitable

Rolling upgrade requirements

• At least two DLS application copies (replicas ≥ 2), or autoscaling with a minimum of two copies.
• Same PostgreSQL major version as the target images.

If these requirements are not met, the upgrade may fail. Fix the configuration before you continue.

What happens during a Rolling upgrade

Understanding the order helps when you monitor progress:

1. Credentials — New database credentials are prepared so both the old and new application versions can connect during the transition.
2. Database first — Database copies move to the new database image, one at a time.
3. Application second — DLS application copies upgrade one at a time. Licensing can stay available while other copies continue to serve clients.
4. Cleanup — When every application copy is on the new version, the system finishes the upgrade and removes temporary credential material.

During the roll, you may briefly have one extra application copy. This is expected.

Two-phase upgrade procedure

Exact flags for your release are in the Helm README. The flow is always:

Phase 1 — Upgrade the application and database (controllers stay on the old image)

1. From the new kubernetes/helm-charts directory, run a Helm upgrade that:
   • Applies the new charts / appliance version
   • Keeps the operator and database-controller images on the currently running (old) tag
2. Wait until the instance phase returns to Ready on the new appliance version:
   Copy

   Copied!

               
   
               
   kubectl get dlsappliance dls-main -n default -w
           

Phase 2 — Upgrade the automation controllers last

1. After Phase 1 is Ready, run a second Helm upgrade that moves the operator and database-controller images to the new tag.
2. Confirm that pods in the operator and database-controller namespaces are running on the new image.
3. Re-run the Verifying the Multi-Replica Deployment.

Monitoring an upgrade

            

            
kubectl get dlsappliance dls-main -n default -w
kubectl describe dlsappliance dls-main -n default
        

You may see phases such as UpgradingRolling while work is in progress. When finished, the phase returns to Ready.

If the phase becomes Failed, or stays in an upgrading state for an unusually long time, see Troubleshooting Multi-Replica DLS Deployments.

Upgrade checklist

1. Read release notes for the target version.
2. Load new images into the registry.
3. Use Helm charts from the new version artifact.
4. Run Phase 1 (application and database; controllers pinned to the old image).
5. Wait for PHASE = Ready on the new version.
6. Run Phase 2 (upgrade controller images).
7. Verify Web UI access and a test license lease.

What to do next

Continue normal DLS administration using the NVIDIA License System User Guide. No separate multi-replica steps are required for day-to-day license and user management after a successful upgrade.

2.6.4. Deploying the Containerized DLS Software Image on Podman

Ensure that the required environment variables have been set as explained in Setting Properties for a Containerized DLS Software Image.

1. Import the DLS appliance artifact and the PostgreSQL database artifact.
   1. Import the DLS appliance artifact.
      Copy

      Copied!

                  
      
                  
      $ podman load --input dls_appliance_4.0.0.tar.gz
              

   2. Import the PostgreSQL database artifact.
      Copy

      Copied!

                  
      
                  
      $ podman load --input dls_pgsql_4.0.0.tar.gz
              

2. Change to the podman directory.
3. Optional: Edit the postgres-nls-si-0-deployment/compose.yml file to customize the subnets with which you want to create the postgres-nls-si-0-deployment_back-tier network. By default, the postgres-nls-si-0-deployment_back-tier network is created with the following subnets:
   • IPv4: 172.16.238.0/28
   • IPv6: 2001:3984:3989::/64
4. Create the postgres-nls-si-0-deployment_back-tier network, configurations volume mapping, and postgres-data volume mapping, and deploy the PostgreSQL database container.
   Copy

   Copied!

               
   
               
   $ podman-compose -f postgres-nls-si-0-deployment/compose.yml up -d
           

   For information about the configurations and postgres-datavolume mappings, refer to Volume Mappings for a Containerized DLS Software Image.

5. Confirm that the postgres-nls-si-0-deployment_back-tier network, configurations volume mapping, and postgres-data volume mapping were created and that the PostgreSQL database container was deployed.
   1. Confirm that the postgres-nls-si-0-deployment_back-tier network has been created.
      Copy

      Copied!

                  
      
                  
      # podman network ls
      NETWORK ID    NAME                                    DRIVER
      2f259bab93aa  podman                                  bridge
      272c45824a80  postgres-nls-si-0-deployment_back-tier  bridge
              

   2. Confirm that the properties of the postgres-nls-si-0-deployment_back-tier network, for example, its subnets, are correct.
      Copy

      Copied!

                  
      
                  
      # podman network inspect postgres-nls-si-0-deployment_back-tier
      [
          {
              "name": "postgres-nls-si-e-deployment_back-tier”,
              "id": "272cu5824a80fd8117261f28e820f920999fudes6a03ua78lesecf1015a76201",
              "driver": "bridge",
              "network_interface": "cni-podmanl",
              "created": "2023-03-08T07:42:03.88777482",
              "subnets": [
                  {
                      "subnet": "172.16.238.0/28",
                      "gateway": "172.16.238.1"
                  },
                  {
                      "subnet": "2001:3984:3989::/64",
                      "gateway": "2001:3984:3989::1"
                  }
              ],
              "ipv6_enabled": true,
              "internal": false,
              "dns_enabled": true,
              "labels": {
                  "com.docker.compose.project": "postgres-nls-si-0-deployment",
                  "io.podman.compose.project": "postgres-nls-si-0-deployment"
              },
              "ipam_options": {
                  "driver": "host-local"
              }
          }
      ]
              

   3. Confirm that the configurations volume mapping and postgres-data volume mapping were created.
      Copy

      Copied!

                  
      
                  
      # podman volume ls
      DRIVER       VOLUME NAME
      local        configurations
      local        postgres-data
              

   4. Confirm that the PostgreSQL database container was deployed.
      Copy

      Copied!

                  
      
                  
      # podman container ls
              

6. Get the IP address of the PostgreSQL database container pod.
   Copy

   Copied!

               
   
               
   $ podman inspect postgres-nls-si-0-deployment_postgres-nls-si-0_1
           

7. Set the DLS_DB_HOST environment variable in the file nls-si-0-deployment/compose.yml to the IP address that you got in the previous step.
8. Create the logs volume mapping and rabbitmq_data volume mapping, and deploy the DLS appliance container.
   Copy

   Copied!

               
   
               
   $ podman-compose  -f nls-si-0-deployment/compose.yml up -d
           

   For information about the logs and rabbitmq_data volume mappings, refer to Volume Mappings for a Containerized DLS Software Image.

9. Confirm that the logs volume mapping and rabbitmq_data volume mapping were created and that the DLS appliance container was deployed.
   1. Confirm that the logs volume mapping and rabbitmq_data volume mapping were created.
      Copy

      Copied!

                  
      
                  
      # podman volume ls
      DRIVER       VOLUME NAME
      ...
      local        logs
      ...
      local        rabbitmq_data
              

   2. Confirm that the DLS appliance container was deployed.
      Copy

      Copied!

                  
      
                  
      # podman container ls
              

What to do next depends on whether you are performing a new installation or are upgrading an existing DLS instance:

• If you are performing a new installation, register the DLS administrator user on the appliance as explained in Registering the DLS Administrator User.
• If you are upgrading an existing DLS instance, migrate the existing DLS instance as explained in Migrating a DLS Instance.

2.6.5. Volume Mappings for a Containerized DLS Software Image

When a containerized DLS software image is deployed, several volume mappings are created for maintaining the state of the NVIDIA Licensing application in the DLS appliance.

The mapping of the volumes to the container filesystem can be found in the respective deployment files depending on the Orchestrator platform that the containerized appliance is being deployed on.

The volume mappings that are created are as follows:

configurations

Contains the state of the DLS appliance container to enable its dynamic properties to be retrieved if the container fails.

logs

Contains log files created by the NVIDIA Licensing application in the DLS appliance.

postgres-data

Contains NVIDIA Licensing application data created by the PostgreSQL database. Because this volume contains information about available and checked out licenses, ensure that access to this volume is limited.

rabbitmq_data

Contains information about the real-time replication of data between nodes in an HA cluster of DLS instances.

2.6.6. Troubleshooting Issues with Deploying the Containerized DLS Software Image

2.6.6.1. Containerized DLS Appliance Fails to Start on Kubernetes Platforms

When this issue occurs, the service enters a crash loop, container creating, pending sequence before the container enters an error state.

This issue might affect Kubernetes, Red Hat OpenShift Container Platform, or VMware Tanzu Application Platform. It does not affect Docker.

1. Ensure that the file access permissions on the volumes allow write access by the database container and the DLS appliance container, for example 707 (rwx---rwx).
2. If the containerized DLS software image is deployed on a multinode cluster, ensure that the database container and the DLS appliance container are running on the same worker node.
3. If the Kubernetes cluster does not dynamically provision persistent volumes when creating persistent volume claims, ensure that the persistent volumes are created manually with file access permissions that allow the database container and the DLS appliance container to write to them.
4. Ensure that the versions of the database container and the DLS appliance container are identical.

2.6.6.2. Volume Mode Access for DLS Appliance Resources on Kubernetes Platforms Is Incorrect

The DLS application container and the PostgreSQL database container share a common volume for exchanging information between them. If the volume mode access is incorrect, start-up of only the first container pod to be started is successful. The remaining container pod fails to start because the volume is already mounted on the first container pod to be started.

This issue might affect Kubernetes, Red Hat OpenShift Container Platform, or VMware Tanzu Application Platform. It does not affect Docker.

1. If both containers are deployed on a multinode cluster, ensure that the DLS application container and the PostgreSQL database container run on the same worker node.
2. Ensure that the PostgreSQL database container pod is started before the DLS appliance container pod. For more information, refer to Deploying the Containerized DLS Software Image on Kubernetes Platforms.

2.6.6.3. Data Validation Errors Prevent the DLS Appliance Container Pod from Starting on Kubernetes

This issue occurs if port numbers are specified as references to environment variables in the deployment files. Because Kubernetes does not accept string values for port numbers, you cannot specify port numbers for Kubernetes by setting environment variables.

This issue might affect Kubernetes. It does not affect other supported container orchestration platforms.

When this issue occurs, the following error messages are displayed:

            

            
error: error validating ".": error validating data:[
ValidationError(Deployment.spec.template.spec.containers[0].ports[0].containerPort): 
invalid type for io.k8s.api.core.v1.ContainerPort.containerPort: got "string", expected "integer", 
ValidationError(Deployment.spec.template.spec.containers[0].ports[0].hostPort):
invalid type for io.k8s.api.core.v1.ContainerPort.hostPort: got "string", expected "integer",
ValidationError(Deployment.spec.template.spec.containers[0].ports[1].containerPort): 
invalid type for io.k8s.api.core.v1.ContainerPort.containerPort: got "string", expected "integer",
ValidationError(Deployment.spec.template.spec.containers[0].ports[1].hostPort): 
invalid type for io.k8s.api.core.v1.ContainerPort.hostPort: got "string", expected "integer",
ValidationError(Deployment.spec.template.spec.containers[0].ports[2].containerPort): 
invalid type for io.k8s.api.core.v1.ContainerPort.containerPort: got "string", expected "integer", 
ValidationError(Deployment.spec.template.spec.containers[0].ports[2].hostPort): 
invalid type for io.k8s.api.core.v1.ContainerPort.hostPort: got "string", expected "integer", 
ValidationError(Deployment.spec.template.spec.containers[0].ports[3].hostPort): 
invalid type for io.k8s.api.core.v1.ContainerPort.hostPort: got "string", expected "integer"];
        

1. Edit the deployment files to specify port numbers as integer values instead of references to environment variables. For instructions, refer to Specifying Integer Values as Actual Values.
2. Start the DLS appliance container pod with the supplied deployment file nls-si-0-deployment.yaml.
   Copy

   Copied!

               
   
               
   $ kubectl create -f directory/nls-si-0-deployment.yaml
           

   directory

   The full path to the directory that contains the file nls-si-0-deployment.yaml.

2.6.6.4. The Management Interface of the NVIDIA Licensing Application Fails to Load

When this issue occurs, the containerized DLS appliance starts correctly but the management interface of the NVIDIA Licensing application is not loaded into the browser.

1. Ensure that the DLS_DB_HOST environment variable set to the IP address of the database container.
2. Ensure that the environment variables for port mappings set in the deployment files are correct and that the ports are open on the Kubernetes node.
3. Ensure that the port specified by the DLS_EXPOSED_HTTPS_PORT environment variable is open in the firewall on the node that is hosting the DLS appliance container.
4. If the Kubernetes cluster does not dynamically provision persistent volumes when creating persistent volume claims, ensure that the persistent volumes are created manually with file access permissions that allow the database container and the DLS appliance container to write to them.
5. Ensure that the versions of the database container and the DLS appliance container are identical.

2.6.6.5. HA Configuration or Online Upgrade Fails

High availability (HA) configuration or online upgrade between two containerized DLS appliances fails if port mappings or volume configurations are incorrect.

1. Ensure that the same ports are exposed and mapped internally for both containers. The following environment variables must be the same for both containers.
   • DLS_EXPOSED_HTTP_PORT
   • DLS_EXPOSED_HTTPS_PORT
2. Ensure that the DLS_RABBITMQ_SSL_PORT environment variable is set to 5671 for both containers
3. Ensure that ports 5671, 8081 and 8084 are open on the containers within which the containerized DLS appliances are deployed.
4. Ensure that Ports 8080 through 8085 are open on each worker node.
5. Ensure that the sizes of the volumes rabbitmq-data, postgres-data, logs and configurations are equal to or exceed the minimum recommended storage space.

   Volume	Minimum Recommended Storage Space
   rabbitmq-data	2 GiB
   postgres-data	10 GiB
   logs	500 MiB
   configurations	1 GiB

6. Ensure that the file access permissions on the folders inside the rabbitmq-data volume allow write access by the containers.

2.6.6.6. Windows Client Cannot Return Licenses Because the Return Endpoint Is Unavailable

A licensed Windows client returns a license by sending an HTTP request to the DLS instance on port 80. If the container orchestrator within which a containerized DLS appliance is deployed cannot receive requests on this port, the client cannot return a license.

How to resolve this issue depends on whether you can control the port on which the container orchestrator listens for HTTP requests.

• If you can control the port on which the container orchestrator listens for HTTP requests from licensed clients, ensure that the DLS_EXPOSED_HTTP_PORT environment variable is set to 80.
• Otherwise, use a load balancer to do path based routing of all license return requests to the URL https://dls-ip-address:dls-exposed-https-port/leasing/v1/lessor/shutdown

  dls-ip-address

  The IP address that is specified in the DLS_PUBLIC_IP environment variable.

  dls-exposed-https-port

  The port number that is specified in the DLS_EXPOSED_HTTPS_PORT environment variable.

  For more information about these environment variables, refer to Setting Properties for a Containerized DLS Software Image.

2.6.6.7. Client Cannot Obtain License if Client Configuration Token Specifies the Domain Name

A configuration error for a containerized DLS instance can prevent a licensed client from obtaining a license if the client configuration token specifies a fully qualified domain name. However, this error does not prevent a client from obtaining a license if the client configuration token specifies an IP address.

1. Set the FQDN environment variable to the fully qualified domain name that is mapped to the IP address of the container in which the DLS software image is deployed.

   Ensure that this name can be resolved by licensed clients. Do not specify a name that can be resolved only by the container orchestrator.

2. Restart the container in which the DLS appliance is deployed.

2.6.6.8. Node Health Information Is Missing from the Home Page

Insufficient storage for a containerized DLS instance can prevent node health information from being displayed on the Service Instance page of the management interface of the NVIDIA Licensing application.

1. Force reload the Home page in the browser.
2. If the node health information is still missing after the page is reloaded, check the amount of storage space available in the volumes created for the DLS appliance container. For more information about these volumes, refer toVolume Mappings for a Containerized DLS Software Image.
3. If any volumes are full, resize the volumes and restart the container in which the DLS appliance is deployed.

2.6.6.9. The podman-compose Command Fails with Missing Networks Error

In some deployments, the podman-compose up command might fail with the error RuntimeError: missing networks: back-tier.

This failure is caused by a known issue with Podman Compose 1.0.3 and earlier versions.
Ensure that you are using one of the supported versions of Podman Compose listed in NVIDIA Delegated License Service Release Notes. If necessary, install the latest version of Podman from GitHub.

            

            
# pip3 install https://github.com/containers/podman-compose/archive/devel.tar.gz
        

2.6.6.10. Re-deploying a Containerized DLS Software Image on Red Hat OpenShift Container Platform Fails

Re-deploying a containerized DLS software image on Red Hat OpenShift Container Platform might fail because permission issues prevent a new PostgreSQL database container from being deployed. This issue can cause an in-place upgrade to fail because an in-place upgrade requires the containerized DLS software image to be re-deployed.

When this issue occurs, the following error messages are displayed:

            

            
chown: /etc/dls/config/ldap3-2.9.1.dist-info: Permission denied 
chown: /etc/dls/config/ldap3: Permission denied 
chown: /etc/dls/config/chardet-4.0.0.dist-info: Permission denied 
chown: /etc/dls/config/chardet: Permission denied 
chown: /etc/dls/config/certifi-2022.12.7.dist-info: Permission denied 
chown: /etc/dls/config/certifi: Permission denied
        

1. Change to the directory where the configuration volume is mounted.
2. Change to the /etc/dls/config/ directory.
   Copy

   Copied!

               
   
               
   $ cd /etc/dls/config/
           

3. Forcibly remove the directories for which permission is denied and their contents.
   Copy

   Copied!

               
   
               
   $ \rm -rf ldap3-2.9.1.dist-info ldap3 \
   chardet-4.0.0.dist-info chardet \
   certifi-2022.12.7.dist-info certifi
           

4. Try again to deploy the containerized DLS software image on Red Hat OpenShift Container Platform. For detailed instructions, refer to Deploying the Containerized DLS Software Image on Kubernetes Platforms.

2.6.6.11. Containerized DLS Appliance fails to start on Openshift Platform

Containerized DLS Appliance fails to start on Openshift Platform with "Error: The directory named as part of the path /var/log/supervisor/supervisord.log does not exist".

1. Navigate to the logs volume and create folders supervisor and nginx .
2. Ensure that the file access permissions on the log volumes allow write access by the DLS appliance container, for example:
   Copy

   Copied!

               
   
               
   $ 707 (rwx---rwx)
           

2.6.6.12. Multi-replica deployment does not reach Ready status

When this issue occurs

After helm install or helm upgrade, the DLS instance phase stays in a starting or upgrading state for a long time, or changes to Failed.

Causes

Common causes include:

• Missing or incorrect storage classes
• Images that the cluster cannot pull
• Replica count too low for a Rolling upgrade
• Attempt to install an older version than the one already deployed
• Temporary wait for database automation to become ready on a cold start

Resolution

1. Run:
   Copy

   Copied!

               
   
               
   kubectl describe dlsappliance dls-main -n default
           

2. Read the status message and events carefully.
3. If the message mentions storage, see the storage topics below.
4. If the message mentions image pull errors, confirm that the images exist in your registry and that any pull secret is configured.
5. If the message mentions replicas or Rolling upgrade requirements, set at least two application copies (or an autoscaler minimum of two), then retry.
6. If the message indicates a version downgrade, install only a version that is the same as or newer than the version already running.
7. On a brand-new cluster, wait several more minutes for database automation to finish starting, then re-check the phase.

2.6.6.13. Configurations storage remains Pending

When this issue occurs

The “configurations” persistent volume claim stays Pending, and application copies cannot start.

Causes

The cluster has no suitable ReadWriteMany (RWX) storage class, or the storage class name in your Helm values is wrong.

Resolution

1. Ask your platform administrator to list available storage classes.
2. Identify an RWX / file-based class (for example NFS or file CSI).
3. Set instance.spec.storageClass to that class name.
4. Re-apply the Helm values and wait for the claim to become Bound.

2.6.6.14. Database storage remains Pending

When this issue occurs

Database volume claims stay Pending, or database pods cannot start.

Causes

The database storage class is missing, misspelled, or points to NFS / RWX storage instead of block ReadWriteOnce (RWO) storage.

Resolution

1. Set instance.spec.dbStorageClass to a block (RWO) storage class.
2. Do not reuse the “configuration” NFS / RWX class for database data.
3. Re-apply Helm values and confirm that database claims become Bound.

2.6.6.15. Image pull errors prevent pods from starting

When this issue occurs

Pods show ImagePullBackOff, ErrImagePull, or similar errors.

Causes

The cluster cannot download one or more of these images from your registry:

• dls:operator_<version>
• dls:appliance_<version>
• dls:pgsql_<version>

Resolution

1. Confirm that the images were loaded into the registry path used in global.image.repository.
2. Confirm that the image tags match the charts in your NLS artifact
3. If the registry is private, create and reference the image pull secret as described in the Helm README.
4. Delete failing pods after fixing registry access so they are recreated, or re-run the Helm install/upgrade.

2.6.6.16. Management interface fails to load while pods are running

When this issue occurs

Pods are running, but the NVIDIA Licensing application management interface does not load in the browser.

Resolution

1. Confirm HTTPS connectivity to the published address (see the previous topic).
2. Confirm that ports on the load balancer match the service ports for HTTPS and, if needed, HTTP lease return.
3. Confirm that configurations and database volumes are Bound and writable.
4. Confirm that the appliance and database image versions match the release you installed.
5. Review operator logs and pod logs in the dls-system namespace for application start errors.

2.6.6.17. Web UI is unreachable after a successful install

When this issue occurs

The instance phase is Ready, but a browser cannot load https://<publicIP>/orhttps://<fqdn>/.

Causes

The client-facing address, DNS, firewall, load balancer, or OpenShift Route does not match the running service.

Resolution

1. Confirm that instance.spec.publicIP is the address clients actually use.
2. If you use a host name, confirm that fqdn is set and that DNS resolves to the same address.
3. From a client network, test:
   Copy

   Copied!

               
   
               
   curl -k https://<publicIP>/
           

4. Confirm that firewall rules allow 443 (and 80 for Windows license return) to that address.
5. Confirm that your load balancer or OpenShift Route forwards to the DLS service on the correct ports.
6. Confirm reverse DNS if client configuration tokens depend on matching host names, as described in the User Guide host name resolution section.

2.6.6.18. Rolling upgrade is stuck or fails

When this issue occurs

During an upgrade, the phase stays in an upgrading state for a long time, or changes to Failed.

Causes

• Fewer than two application copies while using Rolling
• PostgreSQL major version change attempted with Rolling
• Controllers upgraded before the application and database finished migrating
• Image pull or storage problems during the roll

Resolution

1. Read the status message:
   Copy

   Copied!

               
   
               
   kubectl describe dlsappliance dls-main -n default
           

2. Ensure replicas is at least 2 (or autoscaling minimum is at least 2).
3. For a PostgreSQL major version change, use the File-based upgrade strategy as documented in the Helm README for your release—not Rolling.
4. Confirm that you followed the two-phase upgrade: application and database first, automation controllers last.
5. Check that database pods and application pods in dls-system are progressing (some may be terminating or starting during a healthy roll).
6. Do not attempt a downgrade. Move only forward to a supported newer version.

2.6.6.19. Licensed clients cannot obtain licenses

When this issue occurs

The Web UI may work for administrators, but licensed clients fail to acquire licenses.

Resolution

1. Confirm that the license server file is installed on the DLS instance.
2. Confirm that clients use the correct client configuration token and the published address.
3. Confirm that clients can reach port 443 on that address.
4. Confirm DNS if the token embeds a host name.
5. Prefer load-balancer sticky sessions (or source-IP preservation) so a client stays on one healthy application copy when possible.
6. Test from a machine on the same network as the failing clients.

2.6.6.20. Windows clients cannot return licenses at shutdown

When this issue occurs

Windows VMs cannot return licenses when they shut down.

Cause

Windows clients return licenses over HTTP on port 80. The published endpoint is missing, blocked, or mapped to the wrong port.

Resolution

1. Ensure your load balancer, NodePort, or Route path forwards port 80 (or the lease-shutdown port you configured) to the DLS service.
2. Ensure firewalls allow that port from client networks.
3. If port 80 cannot be used in your environment, set the lease-shutdown port in Helm values and update the load balancer to match, as described in the Helm README.

This issue is the multi-replica form of the User Guide topic Windows Client Cannot Return Licenses Because the Return Endpoint Is Unavailable.

2.6.6.21. OpenShift security policy denies pods

When this issue occurs

On Red Hat OpenShift Container Platform, pods fail to start with security-context or SCC (Security Context Constraint) errors.

Resolution

1. Follow the OpenShift section of kubernetes/helm-charts/README.md for your release.
2. Ensure the recommended SCC / permissions for the DLS charts are applied.
3. Retry the install or upgrade after the platform policy is corrected.

2.6.6.22. Temporary webhook errors at first install

When this issue occurs

Immediately after a cold install, you briefly see errors about the database webhook or controller not being ready.

Cause

Database automation is still starting. The install charts wait for this in normal conditions, but a slow cluster can surface short-lived errors.

Resolution

1. Wait a few minutes.
2. Re-check pods in cnpg-system and dls-appliance-operator.
3. Re-check the DLS instance phase.
4. Escalate only if the errors continue after the controllers are running and several minutes have passed.

2.6.6.23. Application or database pods stay Pending after you set node placement

When this issue occurs

After you configure applianceScheduling, postgresScheduling, or poolerScheduling (for example dedicated node labels or taints), one or more pods in dls-system remain Pending, and the DLS instance may not become Ready. Setup or upgrade jobs may also stay Pending.

Cause

Common causes include:

• Node labels in Helm values do not match the labels on any worker node
• Nodes are tainted, but the matching tolerations are missing or incorrect
• podAntiAffinity is set to Required, and there are fewer eligible nodes than application or database copies
• Dedicated pools do not have enough CPU or memory for the requested copies

Resolution

1. List pods and why they are waiting:
   Copy

   Copied!

               
   
               
   kubectl get pods -n dls-system -o wide
   kubectl describe pod <pending-pod-name> -n dls-system
           

   Look for events such as FailedScheduling, untolerated taint, or insufficient nodes for anti-affinity.

2. Confirm node labels and taints with your platform team:
   Copy

   Copied!

               
   
               
   kubectl get nodes --show-labels
   kubectl describe node <node-name>
           

3. Ensure every tainted dedicated node has a matching toleration in the corresponding scheduling block. A label alone is not enough on a tainted node.
4. If you used podAntiAffinity: Required, either add enough matching nodes or change the mode to Preferred.
5. For correct examples and defaults, see Controlling Where DLS Pods Run.

Related documentation

2.6.6.24. When to escalate

When you contact NVIDIA support for a multi-replica issue, include:

• NLS / DLS version
• Platform (Kubernetes, OpenShift, or Tanzu) and version
• Output of kubectl describe dlsappliance dls-main -n default (or oc)
• Recent operator logs
• Your Helm values with secrets removed

2.6.6.25. Related documentation

2.7. Installing the DLS Software Image on Red Hat Enterprise Linux OS

For installation on a supported operating system, the Delegated License Server (DLS) component of the NVIDIA License System is supplied as an installable package. The package includes the containerization software and container images that are required to run the NVIDIA Licensing application on the operating system. The operating system can be running in a virtualized server environment on your choice of hypervisor or on a bare-metal server.

Ensure that the server on which you are installing the DLS software image has at least 15 GB of free disk space.

The DLS software image ZIP archive for the Red Hat Enterprise Linux OS contains the following artifacts:

• Docker container orchestrator RPM packages
• Appliance container images
  • Database container image
  • Application container image
• Installation script with the helper scripts
• README file
• VERSION file

1. Extract the contents of the ZIP archive to a local folder.
2. Update the file access permissions of the installApplicance.sh file to allow execute permission.
   Copy

   Copied!

               
   
               
   $ chmod +x installAppliance.sh
           

3. Run the installApplicance.sh installation script.
4. When the installation is complete, confirm that messages on the console indicate that the NVIDIA Licensing application has started.

2.8. Configuring User Accounts on a DLS Virtual Appliance

Each DLS software image is configured with a single standard user account for accessing the DLS appliance and an account with sudo user privileges for installing updates to the DLS appliance software. Modifications to these accounts are strictly controlled. You cannot add other user accounts to the software image. However, you can use a lightweight directory access protocol (LDAP) directory instead of the configured accounts for managing user access to a DLS appliance. DLS Virtual Appliance supports user account management at two levels: OS-level user accounts (dls_admin, rsu_admin) exist on the underlying operating system and are used for appliance management, while application-level user accounts (introduced in DLS 3.6.0) are created via DLS Web UI or API for accessing DLS management interfaces. Application users exist only in the DLS application database and support role-based access control (RBAC) with three pre-defined roles: DLS_ADMIN, DLS_OPERATOR, and DLS_USER.

2.8.1. Registering the DLS Administrator User

Each DLS virtual appliance is configured with a user account specifically for administering the DLS. This account provides access through a web-based management interface to the NVIDIA Licensing application on the appliance. Before administering a DLS virtual appliance, you must register this user to be able to access this management interface.

If you intend to configure a cluster of DLS instances, you need perform this task only for the DLS instance from which you will configure the cluster. The registration of the DLS administrator user is propagated from this instance to the other instance when you configure the cluster.

1. Open a web browser and connect to the URL https://dls-vm-ip-address.

   dls-vm-ip-address

   The IP address or, if defined, the fully qualified domain name or the CNAME of the VM on which the DLS virtual appliance is installed.

   You can get the IP address from the management console of your hypervisor.

2. On the Set Up page that opens, click NEW INSTALLATION.
3. On the Register User page that opens, provide the credentials for the DLS administrator user.
   Note:

   If the DLS administrator user has already been registered, the login page opens instead of the Register User page.

   1. Optional: If you want to change the user name from the preset name dls_admin, replace the text in the Username field with your choice of user name.
   2. Provide a password for the DLS administrator user and confirm the password.

      The password is case sensitive and must contain 15 to 64 characters, including at least one uppercase letter, one lowercase letter, one digit, and one special character. It must not contain whitespace or the username, and it must pass the appliance's password-strength validation.

4. On the Register User page that opens, provide the credenttials for the DLS administrator user.
   Note:

   If the DLS administrator user has already been registered, the login page opens instead of the Register User page.

   1. Optional: If you want to change the user name from the preset name dls_admin, replace the text in the Username field with your choice of user name.
   2. Provide a password for the DLS administrator user and confirm the password. The password must be at least eight characters long and is case sensitive.
   Note:

   You can change the DLS administrator user name and password at any time after the DLS administrator user is registered. For instructions, refer to Changing the DLS Administrator User Name and Password.

If you want to use the virtual appliance for a single DLS instance, what to do next depends on whether you intend to use a static IP address for the virtual appliance that is hosting the DLS instance.

• If you want to use the virtual appliance in an HA cluster of DLS instances, configure the cluster as explained in Configuring an HA Cluster of DLS Instances.

• If you want to use a static IP address for the virtual appliance that is hosting the DLS instance, set the address as explained in Setting the Static IP Address of a DLS Virtual Appliance.

• Otherwise, configure the DLS instance as explained in Configuring a Service Instance.

If you need to reset the DLS administrator user's password, follow the Forgot Password? link on the login page and, when prompted, type the local reset secret, provide a new password for this user, and confirm the new password.

2.8.2. Retrieving the DLS Administrator User's Reset Secret

If you need to reset the DLS administrator user's password but do not have the local reset secret, you can download a reset secret from the NVIDIA Licensing Portal.

1. If you are not already logged in, log in to the NVIDIA Enterprise Application Hub and click NVIDIA LICENSING PORTAL to go to the NVIDIA Licensing Portal.
2. Click License Allocations.
3. Locate the DLS allocation you are resetting the password for, open it, click More DLS actions, and then select Download reset secret token.

2.8.3. Changing the DLS Administrator Password

The administrator account created during appliance registration is a protected account. Its username cannot be changed after registration. You can change its password while signed in to that account, even when additional local users exist. You do not need to delete those users first. .

1. Open a web browser and connect to the URL https://dls-vm-ip-address.

   dls-vm-ip-address

   The IP address or, if defined, the fully qualified domain name or the CNAME of the VM on which the DLS virtual appliance is installed.

   You can get the IP address from the management console of your hypervisor.

2. Sign in to the DLS Web UI with the protected administrator account.
3. Select your username at the top right to open User Profile.
4. Select Security, then Password.
5. Enter the current password in Current password. Enter the new password in New password and enter it again in Confirm new password. The new password must meet the requirements shown in the form.
6. Select Change Password.
7. Choose the protected administrator username during registration. It cannot be changed after registration. You can subsequently change the password as described in Changing the DLS Administrator Password.
   1. Select the signed-in username at the top right to open User Profile.
   2. In User Profile, choose Security; the tab is highlighted.
   3. Use the current, new, and confirmation password fields, then Change Password. The protected username restriction and password requirements are shown.

2.8.4. Creating the DLS sudo User Account

The predefined DLS sudo user account rsu_admin has the elevated privileges required to install updates to the DLS appliance software that NVIDIA releases periodically. To comply with the terms of the GPL/LGPL v3 license under which the GPL/LGPL v3 licensed Open Source Software (OSS) libraries within the DLS virtual appliance are released, this account also has the elevated privileges required to update and upgrade these libraries.

Perform this task for each DLS virtual appliance for which you want to create the DLS sudo user account. If the DLS virtual appliance is hosting a node in an HA cluster, the creation of the user is not automatically propagated to the other node in the cluster.

1. From the hypervisor, log in as the user dls_admin to the VM that hosts the DLS virtual appliance.
2. Run the /etc/adminscripts/enable_sudo.sh script.
   Copy

   Copied!

               
   
               
   $ /etc/adminscripts/enable_sudo.sh
           

3. When prompted, provide a password for the rsu_admin user.

The sudo user with elevated privileges rsu_admin is created.

2.8.5. Understanding Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is an access control method in which permissions to perform operations are assigned to roles, and users are assigned to roles. In DLS, RBAC provides:

• Separation of duties between administrators, operators, and viewers
• Least privilege principle by granting only the permissions needed for each role
• Simplified administration by managing permissions at the role level instead of per-user
• Audit compliance through clear role definitions and assignment tracking

2.8.5.1. DLS Roles and Permissions

DLS provides three pre-defined roles with distinct permission levels.

2.8.5.2. Role Capabilities and Use Cases

DLS_ADMIN (Administrator)

Purpose: Complete system administration with full control over all DLS operations.

Key Capabilities:

• User Management: Create, modify, and delete local user accounts
• Role Management: Assign and modify user role assignments
• LDAP Configuration: Configure LDAP/Active Directory integration and group mappings
• System Configuration: Modify all system settings including SSL/TLS, email alerts, and general settings
• Node Management: Configure high availability, IP addresses, and node operations
• License Management: Full CRUD (create, read, update, delete) operations on license pools and servers
• Maintenance Operations: Perform system upgrades, database backups, snapshots, and migrations
• Security Configuration: Manage SSL certificates, TLS cipher settings, and API keys
• Audit and Compliance: Export, archive, and manage audit event logs

Typical Job Roles:

• DLS System Administrators
• IT Infrastructure Administrators
• Security Administrators
• DevOps Engineers (with administrative responsibilities)

Access Level: Full read and write access to all resources and configurations.

DLS_OPERATOR (Operator)

Purpose: Operational access for day-to-day license management without ability to modify security settings, users, or system infrastructure.

Key Capabilities:

• License Operations: Create, update, and delete license pools and servers
• Service Instance Management: Modify service instance configurations
• Settings Configuration: Configure general settings, email alerts (excludes SSL, TLS, LDAP)
• Client Configuration: Generate client configuration tokens
• Lease Operations: View all leases and perform bulk release operations: Configure high availability, IP addresses, and node operations
• Monitoring: View metrics, events, and system status
• API Key Management: Import and export API keys

Restrictions (Cannot perform):

• User or role management
• LDAP configuration changes
• Node management or HA configuration
• SSL/TLS certificate or cipher configuration
• System upgrades or maintenance operations
• Individual lease creation, modification, or deletion
• Event export, import, or archiving

Typical Job Roles:

• License Administrators
• Operations Team Members
• Technical Support Staff
• Application Administrators

Access Level: Read access to all resources; write access to license pools, service instances, and operational settings only.

DLS_USER (User/Viewer)

Purpose: Read-only access for viewing license information, system status, and generating reports.

Key Capabilities:

• View Operations: View all license pools, servers, leases, and configurations
• Reporting: Generate reports on license usage and system status
• Monitoring: View system metrics, events, and alerts: Configure general settings, email alerts (excludes SSL, TLS, LDAP)
• Information Access: Access all user, role, and system information in read-only mode

Restrictions (Cannot perform):

• Any create, update, or delete operations
• Configuration changes
• User or role management
• License pool or server modifications
• System administration tasks

Typical Job Roles:

• End Users viewing their license allocations
• Business Stakeholders monitoring license usage
• Technical Support Staff
• Reporting Analysts

Access Level: Read-only access to all resources; no write or configuration capabilities.

Permission Hierarchy and Precedence

When a user has multiple role assignments (ONLY possible with LDAP multi-group membership), DLS applies the role with the highest privilege:

            

            
Priority 1 (Highest): DLS_ADMIN (privilege_level = 1)
	↓
Priority 2 (Medium):  DLS_OPERATOR (privilege_level = 2)
	↓
Priority 3 (Lowest):  DLS_USER (privilege_level = 3)
        

If an LDAP user belongs to both “License_Admins” (mapped to DLS_ADMIN) and “License_Users” (mapped to DLS_USER), the user will be assigned the DLS_ADMIN role (highest privilege).

2.8.6. Managing Local Users

Local users are application-level user accounts created and managed directly within the DLS instance. Local users authenticate using credentials stored in the DLS database (separate from LDAP/Active Directory).

To manage local accounts, sign in as an administrator and select Operations > Users. The Users page displays each account's username, account type, and role. Accounts marked Protected can be viewed but cannot be edited or deleted from this page.

Prerequisites

To manage local users, you must::

• Have the DLS_ADMIN role assigned to your account
• Be logged into the DLS Web UI

2.8.6.1. Creating Local Users (DLS Web UI)

Procedure

1. Open Operations > Users and select Create User.
2. In the Create User panel, enter a unique Username and a Password that meets the requirements shown in the form.
3. Select Admin, Operator, or User from the Role list.
4. Select Create User. Confirm that the new account appears on the Users page with the intended role.

Post-Creation Steps

• Securely communicate the credentials to the user
• Instruct the user to change their password on first login (recommended)

2.8.6.2. Assigning Roles to Users

During User Creation

• Select the appropriate role from the “Role” dropdown during user creation
• The role assignment is automatically created when the user is saved

Modifying an Existing User’s Role:

1. Open Operations > Users.
2. Open the action menu for a Standard account and select Edit.
3. In the Edit User panel, select the required Role. Leave New Password empty if you are only changing the role.
4. Select Save Changes.

2.8.6.3. Modifying User Accounts

Procedure:

1. Open Operations > Users, open the Standard account's action menu, and select Edit.
2. Change Role or enter a New Password as required. Leave New Password empty to keep the current password. The username cannot be edited in this panel.
3. Select Save Changes.

To change your own password, select your signed-in username at the top right, then select

• User Profile > Security > Password
  • Enter the current password, the new password. and its confirmation.
  • Select Change Password.
• Change Username: Navigate to User Profile > Change Username
  • Requires current password verification
  • New username must be unique

2.8.6.4. Deleting User Accounts

Prerequisites:

• Must have DLS_ADMIN role
• Cannot delete the system application user (first application user created during setup)
• Cannot delete your own user account (must be deleted by another administrator)

Procedure:

1. Open Operations > Users and locate the Standard account to delete.
2. Verify that you have selected the correct account, then open its action menu and select Delete.
3. Confirm that the success notification appears and the account is removed from the Users list.
4. In the confirmation dialog, review the warning:
   • User account will be permanently deleted
   • All role assignments will be removed
   • Action cannot be undone
5. Click Confirm to proceed with deletion
6. A success message confirms the deletion
7. The user is removed from the user list

Impact of User Deletion:

• User can no longer log in to DLS
• Active sessions for the deleted user are invalidated
• Audit logs retain records of the user’s past actions
• Role assignments are automatically removed (cascade delete)

2.8.6.5. Password Management

2.8.6.5.1. Password Policy Requirements

Also see : About SCIM Password Rotation on a DLS Virtual Appliance.

Password Policy Requirements:

All passwords (local users and API-generated) must comply with DLS password policy:

Length Requirements:

• Minimum: 15 characters
• Maximum: 64 characters

Complexity Requirements (must contain at least one of each):

• Uppercase letter (A-Z)
• Lowercase letter (a-z)
• Digit (0-9)
• Special character: !@#$%^&*()_+-=[]{}|;:,.<>?

Security Requirements: (must contain at least one of each):

• Must not contain whitespace characters
• Must not contain the username
• Must not contain repetitive patterns (e.g., “aaa”, “111”)
• Must not match any of the last 5 passwords (password history)
• Must differ by at least 8 characters from the previous password

Example Valid Passwords: (must contain at least one of each):

• MySecureP@ssw0rd2024!
• ComplexLicense#Admin99
• Str0ng!DLS$Access2024

Example Invalid Passwords:

• short (too short, less than 15 characters)
• NoSpecialCharacter123 (missing special character)
• all lowercase password! (missing uppercase letter)
• john.doe@Example123! (contains username “john.doe”)

2.8.6.5.2. Changing User Passwords (Web UI)

Also see : About SCIM Password Rotation on a DLS Virtual Appliance.

Self-Service Password Change

1. Sign in to the DLS Web UI and select your username at the top right to open User Profile.
2. Select Security, then Password.
3. . Enter:
   • Current Password
   • New Password:
   • Confirm new password
4. Select Change Password
5. Success message confirms the password change
6. You are logged out automatically (in some implementations)
7. Log back in with the new password

Administrator Password Reset

An administrator can set a new password for a Standard local account through the Edit User panel. The administrator supplies the password; DLS does not generate or display a temporary password in this workflow. Protected accounts cannot be reset from the Users page.

1. Open Operations > Users
2. Open the target Standard account's action menu and select Edit.
3. Enter the required password in New Password and select Save Changes.
4. Communicate the new password securely to the user and ask the user to change it after signing in.

2.8.6.5.3. Configuring SCIM 2.0 Password Rotation

This section discusses SCIM password rotation. See this topics:

• About SCIM Password Rotation on a DLS Virtual Appliance
• Before You Configure SCIM Password Rotation
• Enabling SCIM on DLS
• Integrating with an Enterprise Password Vault
• Verifying SCIM Password Rotation
• Troubleshooting SCIM Password Rotation

2.8.6.5.3.1. About SCIM Password Rotation on a DLS Virtual Appliance

Read this before you enable SCIM 2.0 password rotation for local DLS users.

What is SCIM on DLS?

SCIM (System for Cross-domain Identity Management) is an open standard that identity and password-management products use to talk to applications in a consistent way.

On DLS, SCIM is used so an Enterprise Password Vault (EPV) — for example CyberArk Privileged Access Manager or Privilege Cloud — can look up an existing local DLS user and set a new password on a schedule.

Licensed clients (for example vGPU clients) continue to obtain licenses as they do today. SCIM does not change how licensed clients check out licenses.

What DLS does and does not do

DLS does:

• Allow the vault to find an existing local user by username.
• Accept a new password from the vault and apply it after password-policy checks.
• Update the local DLS account (and the related system account password when applicable).
• Keep an audit trail of vault-driven password changes.
• Omit the password from SCIM responses (the vault already has the new secret).

DLS does not:

• Create, rename, disable, or delete users through SCIM in this release.
• Rotate passwords for LDAP / Active Directory users (rotate those in the directory, not via DLS SCIM).
• Provide SCIM on Cloud License Service (CLS).
• Replace the vault — DLS only accepts the password the vault generates.

How password rotation works

1. An administrator creates the local DLS user in the DLS Web UI (or existing multi-user API), if the account does not already exist.
2. The administrator enables SCIM on DLS and stores a bearer token in the vault.
3. The vault onboards the DLS account and, on schedule, generates a new password.
4. The vault asks DLS for the user, then sends the new password to DLS.
5. DLS validates the password against DLS policy and saves it.
6. Operators later sign in to DLS with the password currently stored in the vault.

How SCIM relates to other password methods

How SCIM relates to LDAP

Also see:

• Configuring LDAP Authentication
• Configuring Single Sign-On (SSO) Authentication

SCIM password rotation targets local DLS users. Directory users authenticate elsewhere; their passwords are not managed by DLS SCIM.

What to do next

1. Review Before You Configure SCIM Password Rotation.
2. Continue with Enabling SCIM on DLS.
3. Continue with Integrating with an Enterprise Password Vault.
4. Continue with Verifying SCIM Password Rotation.

2.8.6.5.3.2. Before You Configure SCIM Password Rotation

Ensure that the following requirements are met before you enable SCIM 2.0 password rotation on a DLS virtual appliance.

Who should perform these tasks?

• A DLS administrator who can manage local users and authentication settings.
• A PAM / vault administrator who can onboard a target application and rotation policy.
• Optionally, a network or platform administrator for HTTPS connectivity from the vault to DLS.

General requirements

1. You are using a DLS Virtual Appliance (or containerized DLS software image). SCIM password rotation is not supported on Cloud License Service (CLS).
2. The local DLS user accounts that the vault will manage already exist (created in the DLS Web UI or existing multi-user API). SCIM does not create users in this release.
3. Those accounts are local DLS users — not LDAP-only directory users.
4. The vault can reach the DLS management address over HTTPS (TLS 1.2 or later).
5. You have DLS Administrator rights and, for API enablement, an Enterprise-scoped API key if your process uses the REST API.
6. Vault password-generation rules will be aligned with the DLS password policy (see below).

Password policy alignment

DLS rejects passwords that do not meet appliance policy. Align the vault’s password generator with DLS requirements documented under Password Management in the User Guide, including typical rules such as:

• Length within the DLS-allowed range.
• Uppercase, lowercase, digit, and special character requirements.
• No username substring.
• Sufficient difference from the previous password.
• Not reusing recent passwords from DLS password history.

Information to collect

Security planning

1. Store the SCIM bearer token only in the vault (or equivalent secret store).
2. Plan operational rotation or replacement of the bearer token on a schedule (for example every 90–365 days) or after suspected compromise.
3. Limit which local accounts are onboarded in the vault to those that truly need privileged rotation.
4. Ensure audit logging is retained for both DLS and the vault so rotations can be correlated.

What to do next

• Create any missing local users in the DLS Web UI.
• Continue with Enabling SCIM on DLS.

2.8.6.5.3.3. Enabling SCIM on DLS

Perform this task to turn on SCIM 2.0 on a DLS virtual appliance and create a bearer token for your Enterprise Password Vault.

Before you begin, complete Before You Configure SCIM Password Rotation and About SCIM Password Rotation on a DLS Virtual Appliance.

Overview of the setup

1. Confirm the target local users already exist on DLS.
2. Enable SCIM on the appliance.
3. Create a SCIM bearer token and store it in the vault.
4. Do not onboard LDAP-only users for DLS SCIM rotation.

Confirm local users exist

1. Sign in to the DLS Web UI as an Administrator.
2. Open user management and confirm each account the vault will rotate.
3. If an account is missing, create it as a local user and assign the correct DLS role.
4. Do not onboard LDAP-only users for DLS SCIM rotation.

Enable SCIM

Using an Enterprise API key with permission to configure authentication, enable SCIM on the appliance.

Example:

            

            
PUT https://{DLS_FQDN}/auth/v1/scim/config
x-api-key: {enterprise_api_key}
Content-Type: application/json
 
{
  "enabled": true
}
        

Replace {DLS_FQDN} with the host name administrators use for the appliance.

Create a bearer token

Create a SCIM bearer token and copy it immediately into your vault secret store.

Example:

            

            
POST https://{DLS_FQDN}/auth/v1/scim/token
x-api-key: {enterprise_api_key}
        

Treat the token like a password:

1. Do not commit it to source control or share it in chat.
2. Store it only in the vault configuration for the DLS target application.
3. Replace it if it may have been exposed.

Note the SCIM base URL

Your vault needs:

What to do next

Configure the vault target application. See Integrating with an Enterprise Password Vault.

2.8.6.5.3.4. Integrating with an Enterprise Password Vault

Perform this task to configure an Enterprise Password Vault (EPV) or PAM platform so it rotates passwords for existing local DLS users using SCIM 2.0.

Before you begin, complete Enabling SCIM on DLS.

Overview of the setup

1. Create a privileged account entry in the vault for each DLS local user.
2. Point the account at DLS as a SCIM 2.0 target application.
3. Align vault password complexity with DLS password policy.
4. Run a manual rotation, then enable the schedule.

Exact screens differ by vault product. The guidance below maps common CyberArk / PAM concepts to DLS values.

DLS values for the vault connector

Replace {DLS_FQDN} with the fully qualified domain name of your DLS appliance. Use HTTPS.

Onboard each DLS local account in the vault

For every local account to rotate:

1. Create a privileged account record whose username matches the DLS local username exactly.
2. Select a platform / target type suitable for SCIM 2.0 custom application (wording varies by product).
3. Enter the SCIM base URL and bearer token from DLS.
4. Do not mark LDAP directory users for this DLS SCIM target — rotate those accounts in Active Directory instead.

Align password generation with DLS policy

1. In the vault password policy / platform policy:
2. Match length and character-class rules to DLS Password Management requirements.
3. Allow the vault to regenerate and retry when DLS rejects a candidate password.
4. Avoid generating passwords that embed the username.

If DLS rejects a password, rotation fails until the vault produces a compliant value.

Understand what the vault calls on DLS

1. A typical successful rotation looks like this:
   1. Find the user — the vault looks up the account by userName
   2. Set the password — the vault sends the new password to DLS.
   3. Confirm — DLS returns the user record without including the password.
   4. Store — the vault keeps the new secret as the current password for that account.

Administrators do not need to paste passwords into DLS during vault rotation.

Dual-account or rotational groups (if your vault uses them)

1. Some vaults rotate paired active/inactive accounts. On DLS:
   1. Each local user is a separate SCIM user.
   2. DLS does not implement vault-specific rotational-group logic.
   3. The vault decides which account is active; onboard each DLS username separately.

System user vs other local users

Next Steps

Verify lookup and rotation before relying on the schedule. See Verifying SCIM Password Rotation.

2.8.6.5.3.5. Verifying SCIM Password Rotation

Perform this task after SCIM is enabled and the Enterprise Password Vault is configured for DLS.

Before you verify

• SCIM is enabled on the DLS appliance.
• The bearer token is configured in the vault (or available for a controlled test).
• The target local username exists on DLS.
• You can sign in to the DLS Web UI to confirm the new password afterward.

Discover SCIM capabilities (optional)

Confirm that DLS advertises patch support by requesting the service provider configuration from the SCIM base URL with the bearer token.

Look up the user

Ask the vault (or a controlled test client) to find the user by exact userName.

Success criteria:

• DLS returns the user record.
• The response includes an id the vault can use for the password update.
• The password field is not returned.

Run a manual rotation

• Trigger a manual password rotation in the vault for the onboarded DLS account.
• Confirm the vault reports success.
• Sign out of the DLS Web UI (if signed in).
• Sign in with the local username and the new password from the vault.
• Confirm that the previous password no longer works.

Confirm audit visibility

• Check DLS audit / event logs for a SCIM password-set event (wording may vary by release).
• Correlate the timestamp with the vault rotation log.
• Confirm passwords are not written in clear text to DLS logs.

Enable the schedule

After a successful manual rotation:

• Enable the vault’s scheduled rotation policy for the account.
• Document the break-glass process for retrieving the current password from the vault if interactive login is needed during an incident.
• Document bearer-token replacement procedures for your operations team.

What to do next

If verification fails, see Troubleshooting SCIM password rotation.

2.8.6.5.3.6. Troubleshooting SCIM Password Rotation

Use these topics when Enterprise Password Vault rotation against DLS does not work as expected.

Also see Password Management and Troubleshooting Authentication and Authorization Issues for authentication troubleshooting topics in the published User Guide.

2.8.7. Configuring LDAP Authentication

You can use a lightweight directory access protocol (LDAP) directory instead of the configured accounts for managing user access to a DLS appliance. When integrated with an LDAP server, the DLS appliance uses Windows Challenge/Response, formerly NT (New Technology) LAN Manager, (NTLM) for authenticating users. LDAP here is for the DLS Web UI, not licensed-client checkout.

The dls_diagnostics and dls_system users have been replaced with the default user, which is the dls_admin user. For the initial installation of DLS and prior to registration on the UI, the default password for the dls_admin user is welcome

. Once registration on the portal is done, the same password and username can be used to login to the VM Appliance from the hypervisor console.

• Since a new user role is used in DLS 3.X, the password for dls_admin must be reset in order to login to the CLI of the DLS Appliance following a migration from DLS 2.X and older.

• The dls_admin user has the same capabilities as that of dls_system and dls_diagnostics. In other words, all are able to configure appliance network properties, enable the sudo user, configure disk expansion, view log files, configuration files, etc.

• The rsu_admin user role would be used for an in-place upgrade, applying security patches, and the execution of NVIDIA-provided scripts. This is true unless it is used for OS-based package updates; in that case, there is no concern for DLS support.

If you want to enable secure LDAP (LDAPS), ensure that the following prerequisites are met:

• You have obtained the required certificate file in the correct format.

  For a TLS certificate, the authentication certificate is the Root CA certificate in Base-64 encoded X.509 (.cer) format.

• The certificate file has the correct name.

LDAP (Lightweight Directory Access Protocol) integration enables DLS to authenticate users against enterprise directory services such as:

• Microsoft Active Directory

Benefits of LDAP Integration:

• Centralized user authentication
• Automatic role assignment based on group membership
• Simplified user lifecycle management
• Compliance with enterprise security policies

Configuring LDAP Settings

LDAP authentication can be configured through either the DLS Web UI or programmatically via RESTful API. Both methods provide the same configuration capabilities.

2.8.7.1. Configuring LDAP via DLS Web UI

LDAP authentication can be configured through either the DLS Web UI or programmatically via RESTful API. Both methods provide the same configuration capabilities. Access LDAP Configuration

1. Sign in to the DLS Web UI as an administrator.
2. Select Operations > Settings > Security. In the on-page navigation, select Authentication.
3. Select Add identity provider, then select LDAP.
4. Enter a Display name, then enter the LDAP connection and directory-search settings supplied by your directory administrator.

Configure LDAP Connection

1. LDAP Server: Enter hostname or IP address of your LDAP server
2. Port: Enter LDAP port (389 for LDAP, 636 for LDAPS)
3. Use Secure Connection (LDAPS): Enable for encrypted communication
4. Authentication Type: Select NTLM or SASL
5. Domain: Enter domain name (required for NTLM/Active Directory)

Configure Search Settings

1. Root DN: Enter root distinguished name (e.g., “dc=example,dc=com”)
2. Search Base: Enter base DN for user searches (e.g., “CN=Users,DC=example,DC=com”)
3. Search Filter: Enter the LDAP query.
4. Username Attribute: Enter attribute name.
5. Follow Referrals: Enable if your LDAP server uses referrals

Upload CA Certificate (for LDAPS)

• If using secure connection, upload your LDAP server’s root CA certificate in PEM format

Configure Group-to-Role Mappings (Optional)::

1. To check the connection, select Test LDAP connection. Enter the LDAP username and password in the test dialog, select Test LDAP connection, and review the result.
2. Under Enable for sign-in, leave Enable this provider when saving off while you finish configuring the provider, or turn it on to enable the provider as part of this save.
3. Select Add identity provider.
4. Enable this provider when saving is off by default. A provider saved with this option off remains disabled. If enabling it changes the active protocol, review the warning and the list of providers that will remain enabled before saving.
5. In the Identity providers table, open the LDAP provider's action menu and select Map groups to roles:
6. To restrict LDAP access by group membership, turn on Enable group based access. Enter the full LDAP group DN in the field for each required DLS role. At least one group mapping is required when this option is on.
7. Select Save mapping.

   With no user or group role mappings configured, authenticated LDAP users receive Administrator access. When mappings are configured, a user who matches no mapping is denied. Turning off Enable group based access removes the group mappings; any separately configured user mappings still apply.

8. To enable a saved provider for the current sign-in protocol, open its action menu, select Enable, and confirm with Enable. To disable it, select Disable and confirm with Disable.
9. To switch protocols, select Change sign-in method. Select the required protocol, choose the providers to enable, and review the effect on the other protocols. Select Switch to LDAP, Switch to SAML, or Switch to OIDC, as appropriate.

   Only one of LDAP, SAML, or OIDC can have enabled providers at a time. Providers that you leave unchecked remain disabled. Local password sign-in remains available for emergency access through the current Web UI.

Security

1. Select Operations > Settings > Security > Authentication.
2. Select Add identity provider, then select SAML.
3. Enter a Display name and configure the identity provider using a metadata URL, metadata content, or manual details.
4. Leave Enable this provider when saving off and select Add identity provider. Complete the identity-provider registration and role mappings before enabling the saved provider.
5. In the Identity providers table, open the provider's action menu and select Map groups to roles. Enter the groups attribute or claim and the required group-to-role mappings, then select Save mapping.
6. To enable a saved provider for the current sign-in protocol, open its action menu, select Enable, and confirm with Enable. To disable it, select Disable and confirm with Disable.
7. To switch protocols, select Change sign-in method. Select the required protocol, choose the providers to enable, and review the effect on the other protocols. Select Switch to LDAP, Switch to SAML, or Switch to OIDC, as appropriate.
8. In the Identity providers table, open the provider's action menu and select Map groups to roles. Enter the groups attribute or claim and the required group-to-role mappings, then select Save mapping.
9. To enable a saved provider for the current sign-in protocol, open its action menu, select Enable, and confirm with Enable. To disable it, select Disable and confirm with Disable.
10. To switch protocols, select Change sign-in method. Select the required protocol, choose the providers to enable, and review the effect on the other protocols. Select Switch to LDAP, Switch to SAML, or Switch to OIDC, as appropriate.

    Only one of LDAP, SAML, or OIDC can have enabled providers at a time. Providers that you leave unchecked remain disabled. Local password sign-in remains available for emergency access through the current Web UI.

2.8.7.2. Mapping LDAP Groups to DLS Roles

Overview:

Group-to-role mapping enables automatic role assignment based on LDAP group membership. When a user authenticates via LDAP, DLS:

1. Retrieves the user’s LDAP group memberships
2. Checks if any groups are mapped to DLS roles
3. Assigns the appropriate role based on mapping configuration

Configuration

Add the ldap_group_role_mapping object to your LDAP configuration request:

            

            
{
  "ldap_group_role_mapping": {
	"CN=LicenseAdmins,OU=Groups,DC=example,DC=com": "DLS_ADMIN",
	"CN=LicenseOperators,OU=Groups,DC=example,DC=com": "DLS_OPERATOR",
	"CN=LicenseUsers,OU=Groups,DC=example,DC=com": "DLS_USER"
  }
}
        

Key Points:

• Group DN Format: Use the full Distinguished Name (DN) of the LDAP group
• Case Sensitivity: Group DNs are case-sensitive; ensure exact match with your LDAP directory
• Role Values: Must be one of: “DLS_ADMIN”, “DLS_OPERATOR”, “DLS_USER”

Complete Example:

            

            
curl -X POST 'https://192.0.2.10/auth/v1/ldap' \
  --header 'x-api-key: 0ae280b9-58e2-809c-3c24-4069c5bd40c2' \
  --header 'Content-Type: application/json' \
  --data-raw '{
	"enable_ldap": "true",
	"ldap_server": "192.0.2.50",
	"ldap_port": 389,
	"use_secure": "false",
	"authentication_type": "NTLM",
	"domain": "example.com",
	"root_dn": "dc=example,dc=com",
	"search_base": "CN=Users,DC=example,DC=com",
	"search_filter": "(&(objectCategory=Person)(userPrincipalName=*))",
	"username_attribute": "sAMAccountName",
	"search_scope": "SUBTREE",
	"ldap_group_role_mapping": {
  	"CN=DLS-Admins,OU=Security Groups,DC=example,DC=com": "DLS_ADMIN",
  	"CN=DLS-Operators,OU=Security Groups,DC=example,DC=com": "DLS_OPERATOR",
  	"CN=DLS-Users,OU=Security Groups,DC=example,DC=com": "DLS_USER"
	}
  }'
        

Behavior Scenarios:

Scenario 1: No Group Mapping Configured

If ldap_group_role_mapping is empty or not provided:

• All authenticated LDAP users receive DLS_ADMIN role by default
• Use case: Quick LDAP setup or environments where all LDAP users should have admin access

Scenario 2: Partial Group Mapping

If only some groups are mapped:

• Only users in mapped groups can log in
• Users in unmapped groups are denied access to the DLS Web UI portal.
• Use case: Controlled access where only specific teams should access DLS

Scenario 3: Multiple Group Membership

If a user belongs to multiple groups with different role mappings:

• User receives the role with highest privilege (lowest privilege_level number)
• Example: User in both “DLS-Admins” (DLS_ADMIN, level 1) and “DLS-Users” (DLS_USER, level 3) receives DLS_ADMIN role

• Use case: Users with overlapping responsibilities

Role Determination Logic:

            

            
Step 1: Check group-to-role mapping
	↓
	If user belongs to one or more mapped groups:
  	→ Assign role with highest privilege (lowest privilege_level number)
	↓
	If user belongs to no mapped groups:
  	↓
  	Check if any mappings are configured:
    	→ If NO mappings: Assign DLS_ADMIN (default)
    	→ If mappings exist: Access Denied
        

Example Scenarios:

Scenario 1: Multiple Group Membership with Highest Privilege User: jane.smith LDAP Groups: [CN=LicenseAdmins,DC=example,DC=com, CN=LicenseUsers,DC=example,DC=com]

Group Mapping:

CN=LicenseAdmins,... → DLS_ADMIN (privilege_level=1)

CN=LicenseUsers,... → DLS_USER (privilege_level=3)

Result: DLS_ADMIN (highest privilege = lowest level number)

Scenario 2: No Mappings Configured

User: new.user

ldap_group_role_mapping: {} (empty)

Result: DLS_ADMIN (default when no mappings exist)

Scenario 3: Access Denied

User: unknown.user

LDAP Groups: [CN=Some_Other_Group,DC=example,DC=com]

User Mapping: (no match)

Group Mapping: CN=LicenseAdmins,... → DLS_ADMIN (no match)

Result: Access Denied (403 Forbidden error)

2.8.7.3. Testing LDAP Configuration

Testing Before Saving Configuration::

Use the test_ldap parameter to validate LDAP connectivity before saving configuration:

            

            
{
  "test_ldap": true,
  "test_ldap_creds": {
	"username": "testuser",
	"password": "TestP@ssw0rd123"
  }
}
        

What Gets Tested:

• LDAP server connectivity
• Search base validity
• Search filter correctness
• Username attribute mapping
• Authentication mechanism (NTLM/SASL)
• Group retrieval (if configured)
• Role mapping logic

Success Response (HTTP 200):

            

            
{
  "message": "LDAP configuration updated successfully",
  "enable_ldap": true,
  "test_result": {
	"status": "Success",
	"username": "testuser",
	"ldap_role": "DLS_OPERATOR",
	"groups": [
  	"CN=LicenseOperators,DC=example,DC=com"
	]
  }
}
        

Error Response (HTTP 400):

            

            
{
  "error": "Bad Request",
  "message": "LDAP connection test failed: Unable to connect to LDAP server at 192.0.2.50:389"
}
        

Testing After Configuration Saved:

After saving LDAP configuration, test authentication:

1. Attempt Login:
   • Navigate to DLS Web UI login page
   • Enter LDAP username and password
   • Click Login
2. Verify Successful Login:
   • User is redirected to DLS Dashboard

   • User’s role is displayed in user profile

   • User can access features appropriate to their assigned role

3. Check Audit Logs:

   • Navigate to Events in DLS Web UI

   • Filter by “Login” events

   • Verify LDAP authentication events are logged

2.8.7.4. Retrieving LDAP Configuration

To view the current LDAP configuration:

1. Log in to DLS Web UI with DLS_ADMIN role
2. Navigate to Settings page
3. Locate the LDAP Configuration section
4. View all configured settings including:
   • Server connection details
   • Search configuration
   • Group-to-role mappings

5. Sensitive fields (passwords, certificates) are masked for security

To Completely Remove LDAP Configuration:

1. Navigate to Settings page
2. Locate the LDAP Configuration section
3. Click Delete LDAP Configuration or Remove
4. Confirm deletion
5. All LDAP settings and group mappings are removed

2.8.7.5. About Multi-Domain LDAP on a DLS Virtual Appliance

Perform this reading task before you configure LDAP for more than one domain or more than one directory on DLS.

What is multi-domain LDAP on DLS?

Organizations often have users in more than one Active Directory domain, or in more than one directory altogether. DLS can authenticate those users for the management Web UI in two different ways, depending on how your directories are set up.

LDAP authentication does not change license checkout.

Select the correct situation for your needs

DLS does:

• Bind to your directory with the user’s credentials (or the authentication type you configure).
• Search for the user in the configured search base.
• Map LDAP groups (and optional user overrides) to DLS roles: Administrator, Operator, or User.
• When multiple identity sources exist, DLS uses enabled LDAP identity sources in priority order for a plain username. UseDOMAIN\username or user@domain to select a directory explicitly.

DLS does not:

• Replace your Active Directory or LDAP servers.
• Automatically merge two forests into one login without domain-qualified usernames (when names could overlap).
• Use Kerberos/SASL across multiple identity sources (use NTLM for Active Directory when more than one source is configured).

How login works when you have more than one directory

Best practice: Use <DOMAIN>\<username> or <username>@<domain> to select a directory explicitly, especially when usernames overlap across directories.

How this relates to local passwords and SSO

What to do next

1. Review Before You Configure Multi-Domain LDAP.
2. If you have one forest with child domains, see Configuring LDAP for One Forest with Multiple Domains.
3. If you have separate directories, see Configuring Multiple LDAP Identity Sources.
4. Set Mapping LDAP Groups to DLS Roles for each directory.
5. Review Signing In with LDAP.

2.8.7.6. Before You Configure Multi-Domain LDAP

Ensure that the following requirements are met before you configure LDAP for multiple domains or multiple identity sources on a DLS virtual appliance or containerized DLS instance.

Who should perform these tasks?

• A DLS administrator who can change authentication settings on the appliance.
• A directory / Active Directory administrator who knows domain names, Global Catalog hosts, and group Distinguished Names (DNs).
• Optionally, a network administrator for firewall rules between DLS and each LDAP host.

General requirements

1. The DLS management Web UI is reachable from your administrators’ browsers over HTTPS.
2. You know whether you have one Active Directory forest or separate directories (see About Multi-Domain LDAP on a DLS Virtual Appliance).
3. Network connectivity exists from the DLS appliance to every LDAP or Global Catalog host and port you will use.
4. You have DLS Administrator rights (or equivalent permission to configure LDAP).
5. For API configuration, you have an Enterprise-scoped API key from the NVIDIA Licensing Portal, if your organization uses the REST API.

Secure LDAP (LDAPS)

If you enable a secure connection:

1. Use the correct port (commonly 636 for LDAPS, or 3269 for Global Catalog over TLS).
2. Upload the CA certificate that issues your directory’s TLS certificate.
3. When you use multiple identity sources, upload a CA certificate per source if each directory uses a different trust chain.

Information to collect from your directory team

For one forest with child domains

• Forest root DNS name and forest-root Distinguished Name (for example DC=corp,DC=example,DC=com).
• Hostname of a Global Catalog server.
• Whether to use LDAP (3268) or LDAPS (3269) to the Global Catalog.
• Group DNs used for DLS Administrator, Operator, and User access.
• Approximate number of users in scope (so you can set a search page limit if the directory is large).

For multiple identity sources

For each directory, collect:

• Display name (admin-friendly label).
• Domain / NetBIOS alias and DNS domain (for login routing).
• One or more LDAP hostnames (ordered for failover).
• Port, TLS, search base, search filter, search scope.
• Group-to-role mappings for that directory.
• Test account credentials for connection testing.

Decide which source is the default for plain-username login (for example jsmith with no domain prefix).

Upgrade note

If the appliance already has a single LDAP configuration, upgrading to a release that supports multiple identity sources migrates that configuration automatically into one default identity source. Existing logins continue to work. You can add more sources afterward without replacing the migrated settings.

What to do next

• For one forest with child domains, see Configuring LDAP for One Forest with Multiple Domains.
• For separate directories, see Configuring Multiple LDAP Identity Sources.

2.8.7.7. Configuring Multiple LDAP Identity Sources

If you only have child domains in one forest, skip thi topic and procede to Configuring LDAP for One Forest with Multiple Domains

Perform this task when DLS must authenticate users against more than one LDAP directory — for example two Active Directory forests

Before you begin, complete Before You Configure Multi-Domain LDAP and About Multi-Domain LDAP on a DLS Virtual Appliance.

Setup Overview

1. Confirm that each directory needs its own identity source..
2. Add the first (or default) identity source and test it.
3. Add additional identity sources for the other directories.
4. Map groups to DLS roles per source.

LDAP users enter their username and password in the standard DLS sign-in form. There is no LDAP provider selector. For a plain username, DLS uses enabled LDAP sources in priority order. To target a directory explicitly, enter <DOMAIN>\<username> or <username>@<domain>. Use the domain or alias configured for that directory. SAML and OIDC sign-in instead use the separate Sign in with <provider> buttons.

1. Save the identity source.
2. Repeat for each additional directory.

Verify sign-in with a plain username and confirm the assigned role. Then verify each directory with a domain-qualified username. Use domain-qualified usernames when the same username exists in more than one directory.

1. Multi-source Active Directory login requires NTLM.
2. Up to 10 hostnames per identity source (API limit).Enter connection settings
3. Overlapping plain usernames across forests require domain-qualified login.
4. Optionally run Test connection with a valid directory user before saving.
5. Save the identity source.
6. Repeat for each additional directory.

To make a source handle plain usernames, select Set as default (during create or afterward).

Edit or delete an identity source

• Edit — Changes apply only to that source. Other sources are unchanged.
• Delete — Removes one source. Deleting the last source disables LDAP authentication on the appliance.

Map roles and verify

1. Configure group (and optional user) mappings for each source. See Mapping LDAP Groups to DLS Roles.
2. Sign out and sign in with a user from the default directory using a plain username.
3. Sign in with a user from a second directory using DOMAIN\username or user@domain.
4. Confirm each user receives the expected DLS role.

If verification fails, see Troubleshooting Multi-Domain LDAP.

Configuring via the RESTful API (optional)

Administrators who automate configuration can use the identity-sources API under/auth/v1/identity-sources (list, create, update, delete, set default, test, and policy). These operations require LDAP configuration permission and, for programmatic access, an Enterprise API key.

The legacy/auth/v1/ldap endpoints remain for compatibility and operate on the default identity source only; they do not remove sibling sources.

Limitations

• Multi-source Active Directory login requires NTLM.
• Up to 10 hostnames per identity source (API limit).
• Overlapping plain usernames across forests require domain-qualified login.

What to do next

• Document required login formats for each user population. See Signing In with LDAP.
• Keep a local Administrator break-glass account available until multi-directory login is proven in your environment.

2.8.7.8. Configuring LDAP for One Forest with Multiple Domains

Perform this task when your Active Directory has one forest with a root domain and one or more child domains, and you want users from those domains to sign in to the DLS Web UI with one LDAP configuration.

Before you begin, complete Before You Configure Multi-Domain LDAP.

Why use the Global Catalog?

For forest-wide login, connect DLS to a Global Catalog host, set the search base to the forest root, and use SUBTREE scope.

Recommended settings

Procedure (Web UI)

1. Sign in to the DLS Web UI as an Administrator.
2. Open Settings → LDAP configuration (same page as the existing single-directory procedure in the User Guide).
3. Set LDAP Server to a Global Catalog host.
4. Set Port to 3268 or 3269
5. Enable secure connection if you use 3269, and upload the CA certificate.
6. Set Search base to the forest-root DN.
7. Set Search scope to SUBTREE.
8. Enable Follow referrals.
9. Configure the search filter so it matches the users who should access DLS. Include memberOf for the groups used for DLS access when your directory team recommends it.
10. Map LDAP groups to DLS roles using full group DNs. See Mapping LDAP Groups to DLS Roles.
11. Test with a user from the root domain and a user from a child domain, then save.

Search filter guidance

Prefer filters that include the groups allowed to use DLS. Example pattern (replace the group DN with your own):

            

            
(&(objectCategory=Person)(sAMAccountName=*)(memberOf=CN=YourGroup,OU=Groups,DC=corp,DC=example,DC=com))
        

Checklist

1. Port is 3268 or 3269 (Global Catalog).
2. Search base is the forest root DN.
3. Search scope is SUBTREE.
4. Follow referrals is enabled.
5. Group DNs in role mapping match the directory exactly
6. Page limit is set when the user population is large.
7. Test logins succeed for root-domain and child-domain users.

What to do next

• If you later need a second forest or OpenLDAP alongside AD, add a second identity source. See Configuring Multiple LDAP Identity Sources.
• Review Signing In with LDAP for username formats.

2.8.7.9. Signing In with LDAP

Perform this task after LDAP authentication is configured on the DLS virtual appliance.

This topic supplements Logging in to a DLS Virtual Appliance in the DLS User Guide.

Before you log in

• Your administrator has enabled LDAP and mapped your directory groups to a DLS role.
• You know whether your organization uses one directory or multiple identity sources.
• You use the DLS management URL provided by your administrator.

Sign in with a plain username

1. In a supported web browser, go to the DLS management interface.
2. Enter your directory username without a domain prefix (for example jsmith).
3. Enter your directory password.
4. Submit the form.

DLS uses enabled LDAP identity sources in priority order for a plain username. Use a domain-qualified username to select a directory explicitly. Invalid credentials or a role-mapping access denial stop the sign-in attempt; DLS does not treat them as a reason to try another source.

Sign in with a domain-qualified username

Use these formats when multiple LDAP identity sources are configured, or when your administrator requires them.

1. On the DLS login page, enter the domain-qualified username exactly as your administrator documented it.
2. Enter your password for that directory.
3. Submit the form.

DLS selects the identity source that matches the domain portion of the username.

What happens if the password is wrong?

Login fails immediately for the directory DLS selected. DLS does not try another identity source or another LDAP hostname after invalid credentials.

After you are signed in

• Your permissions follow the DLS role from LDAP group mapping: Administrator, Operator, or User.

• Day-to-day pages behave the same as for locally authenticated users with that role.

• Sign out using the Web UI sign-out control when you finish.

What to do next

If sign-in fails, contact your DLS administrator and see Troubleshooting Multi-Domain LDAP.

2.8.8. Configuring Single Sign-On (SSO) Authentication

Single Sign-On allows administrators and operators to open the DLS Web UI by signing in with your corporate identity provider, instead of (or in addition to) a password stored on the DLS appliance.

2.8.8.1. About Single Sign-On on a DLS Virtual Appliance

Perform this reading task before you configure Single Sign-On (SSO) for the DLS management interface. See Password Management, Configuring LDAP Authentication, and Configuring Single Sign-On (SSO) Authentication.

What is Single Sign-On on DLS?

Single Sign-On allows administrators and operators to open the DLS Web UI by signing in with your corporate identity provider, instead of (or in addition to) a password stored on the DLS appliance.

Licensed clients (for example vGPU clients) continue to obtain licenses as they do today. SSO does not change how licensed clients check out licenses.

What DLS does and does not do

DLS does:

• Redirect the browser to your identity provider when the user chooses an SSO sign-in option.
• Accept a successful sign-in result from that provider.
• Map the signed-in user (and their groups, if configured) to an existing DLS role: Administrator, Operator, or User.
• Create the normal DLS Web UI session after a successful mapping.

DLS does not:

• Replace your identity provider.
• Implement its own multi-factor authentication (MFA), smart card, or conditional-access policies. Those remain policies on your identity provider.
• Support starting login from the identity provider alone (users must start from the DLS login page).

SAML or OIDC — which should you choose?

Ask your identity team which standard they prefer for new applications. DLS supports both; you normally enable one of them for the appliance.

How SSO relates to LDAP, SCIM, and local passwords

What to do next

1. Review Before You Configure Single Sign-On.
2. Configure Configuring SAML Authentication or Configuring OpenID Connect (OIDC) Authentication.
3. Set Mapping Identity Provider Groups to DLS Roles.
4. Verify Logging in with Single Sign-On.

2.8.8.2. Before You Configure Single Sign-On

Ensure that the following requirements are met before you configure SAML or OpenID Connect (OIDC) authentication on a DLS virtual appliance or containerized DLS instance.

Who should perform these tasks?

• A DLS administrator who can change authentication settings on the appliance.
• An identity administrator who can create an application (relying party / client) in your corporate identity provider.
• Optionally, a network or platform administrator for DNS and firewall rules.

General requirements

1. The DLS management Web UI is reachable from your administrators’ browsers over HTTPS.
2. You know the stable public address that browsers use for DLS (host name preferred). Users and the identity provider must use the same address that DLS advertises for sign-in return URLs.
3. Clocks on the DLS host and the identity provider are synchronized with a reliable time source (for example NTP). Large time differences can cause sign-in to fail.
4. You have decided whether to use SAML or OIDC for this appliance.
5. You understand that enabling SAML or OIDC identity sources means LDAP identity sources must not be enabled at the same time (see protocol exclusivity below).

Network and connectivity

Stable public address

DLS must advertise consistent URLs to your identity provider, including:

• Where the identity provider should send the user after sign-in (assertion / callback URL).
• The DLS application identifier (entity ID / audience), when applicable.

Ensure that:

1. Administrators always open DLS with the same host name (or address) you register with the identity provider.
2. Any load balancer or ingress in front of DLS preserves HTTPS and the public host name that users see.

If your deployment requires an explicit public base URL setting for SSO, set it to the HTTPS address users type in the browser (no trailing slash), for example https://dls.example.com.

Protocol exclusivity

At most one of the following may have enabled identity sources at a time:

• LDAP
• SAML
• OIDC

You may keep disabled draft configurations for a future cutover.

Local DLS password login can remain available for emergency access when your organization allows it.

Information to collect from your identity team

For SAML

• Whether you will use a metadata URL, a metadata file, or manual IdP details.
• IdP entity ID (issuer), single sign-on URL, and signing certificate (if not using metadata).
• How usernames and groups appear in the SAML response (attribute names and example values).
• Which AD / IdP groups should map to DLS Administrator, Operator, and User.

For OIDC

• Issuer URL (discovery base).
• Client ID and client secret (if the client is confidential).
• Redirect / callback URL that DLS will use (your identity team registers this on the IdP).
• Which token claims carry username and groups.
• Which groups should map to DLS roles.

Multi-factor authentication (MFA)

If your organization requires MFA, enable it on the identity provider. After MFA succeeds, DLS only sees a successful SSO completion. No MFA secrets are stored on DLS.

What to do next

• To configure SAML, see Configuring SAML Authentication.
• To configure OIDC, see Configuring OpenID Connect (OIDC) Authentication.

2.8.8.3. Configuring SAML Authentication

Perform this task to allow users to sign in to the DLS Web UI through a SAML 2.0 identity provider. Before you begin, complete Before You Configure Single Sign-On and About Single Sign-On on a DLS Virtual Appliance.

Setup Overview

1. Create a SAML application (relying party) for DLS in your identity provider.
2. Configure a SAML identity source on DLS with your IdP details.
3. Register DLS’s service provider information (entity ID and return URL) with the identity provider.
4. Map groups or users to DLS roles.
5. Enable the SAML identity source and verify sign-in.

Create the application in your identity provider

In your identity provider’s administration console, create a SAML application or relying party trust for DLS.

Typical choices:

• Use a claims-aware / SAML web application profile (not a legacy non-claims profile).
• Prefer importing DLS metadata from a file or entering identifiers manually if your IdP cannot consume DLS’s metadata URL format.
• Allow access for the user groups that should use DLS (for example Permit everyone in a lab, or a specific group in production).

Finish claim (attribute) rules after you know which username and group values DLS expects. See Mapping Identity Provider Groups to DLS Roles.

Add a SAML identity source on DLS

In the DLS Web UI, open the settings area used for identity sources / authentication (same family of settings as LDAP).

Create a new identity source and choose SAML.

How DLS learns about your identity provider

Choose one approach:

If the metadata URL uses a private or internal HTTPS certificate, you may also need to provide trusted CA certificates so DLS can verify that HTTPS connection. This is separate from the IdP signing certificate used to verify login messages. Optional settings you may need

Register DLS with the identity provider

From DLS, obtain the service provider values for this identity source:

On the identity provider, set:

1. The relying party identifier / audience to the DLS entity ID.
2. The SAML ACS (HTTP-POST) endpoint to the DLS ACS URL.
3. Claim rules so the assertion includes the username and groups DLS will map.

Map roles and enable the source

1. Configure group and optional user mappings as described in Mapping Identity Provider Groups to DLS Roles.
2. Disable any enabled LDAP or OIDC identity sources if you are switching to SAML.
3. Enable the SAML identity source.
4. Keep local password login available until you have verified SSO in your environment.

Verify the configuration

1. Sign out of the DLS Web UI.
2. Open the DLS login page.
3. Confirm that a button such as Sign in with <your display name> appears.
4. Complete sign-in at the identity provider (including MFA if required).
5. Confirm that you land in the DLS Web UI with the expected role.

If verification fails, see Troubleshooting Single Sign-On.

What to do next

• Document the break-glass administrator procedure for your operations team.
• If you use multiple replicas of DLS, ensure all copies share the same public address and site configuration so sign-in can complete on any healthy copy.

2.8.8.4. Configuring OpenID Connect (OIDC) Authentication

Perform this task to allow users to sign in to the DLS Web UI through an OpenID Connect identity provider.

Before you begin, complete Before You Configure Single Sign-On and About Single Sign-On on a DLS Virtual Appliance.

Setup Overview