Deploying VMware Data Services Manager for VCF PAIS

This follows the manual OVA deployment used in my lab. DSM 9.1.1 also has a native VCF Automation deployment experience; use the supported workflow for your environment rather than combining instructions from both installation methods. Broadcom describes that integration in its DSM 9.1.1 announcement.

Hostnames below use lab.example.com as placeholders. Substitute your DNS names, addresses, storage policies, and service accounts. Build numbers document what I tested; they are not a recommendation to bypass your compatibility matrix or upgrade policy.

1. Plan appliance placement and prerequisites

I placed the DSM management appliance in the management cluster and targeted the workload vCenter for database infrastructure. The location of the DSM appliance does not force database nodes to run on that same cluster: workload placement comes from the infrastructure configuration and policies.

Before deploying, reserve the DSM address and DNS record, confirm the target vCenter name matches its certificate, and identify the workload network, address pool, VM classes, and storage policy. Check routing and firewall rules from the appliance and database networks, including access to your object storage endpoint.

These PowerShell checks are useful from the workstation. Repeat equivalent checks from the relevant service networks; a successful workstation test alone does not establish appliance connectivity.

Resolve-DnsName dsm.lab.example.com
Resolve-DnsName vc-workload.lab.example.com
Resolve-DnsName s3.lab.example.com
Test-NetConnection vc-workload.lab.example.com -Port 443
Test-NetConnection s3.lab.example.com -Port 443

2. Deploy the DSM OVA

1. Download the DSM appliance and the required bundles from your entitled Broadcom downloads. Record versions and compare published checksums before transferring files into an offline lab.
2. In vSphere Client, select the management cluster or intended resource pool and choose Deploy OVF Template.
3. Select the appliance OVA, provide a VM name, and choose compute, datastore, storage policy, and the management network.
4. Review the template details and license terms, then fill in the appliance customization fields.
5. Review the complete configuration, deploy, and power on the appliance.

My appliance file was dsm-va-9.1.1.0100.25777183.ova. Its inspected template defaults were 8 vCPU and 16 GiB RAM. Treat these as this OVA’s defaults and check the sizing guidance for your database fleet.

Get-FileHash -Algorithm SHA256 'C:\Lab\dsm-va-9.1.1.0100.25777183.ova'

The inspected OVA describes the supplied vCenter credentials as initial registration credentials: DSM creates a dedicated service account. Verify the required privileges rather than assuming the account name alone guarantees registration success.

If you export the target vCenter’s leaf certificate through a trusted channel, this PowerShell example formats its SHA-256 fingerprint. Independently verify the certificate belongs to the intended server.

$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new('C:\Lab\vc-workload.cer')
$sha256 = [System.Security.Cryptography.SHA256]::Create()
($sha256.ComputeHash($cert.RawData) |
    ForEach-Object { '{0:X2}' -f $_ }) -join ':'

Review optional internal subnet reservations if they overlap existing networks. Leave the internal-use-only VCF-Managed Mode property at the default for this manual workflow; it is not a general-purpose integration switch.

3. Complete initial configuration

1. Wait for appliance initialization, then open https://dsm.lab.example.com.
2. For this manual OVA route, use the initial root access described by the appliance template to complete user setup. Use a DSM administrative account for ongoing GUI administration.
3. Confirm the intended vCenter is associated and the DSM integration is visible in vSphere Client.
4. Review appliance health, DNS, time, and certificate settings before provisioning databases.
5. Import the issuing CA certificates needed for trusted external services, including the internal S3 endpoint.

Do not assume an OVA installation and the native VCF Automation deployment have identical initial credential or recovery behavior. If registration fails, inspect the deployment error and required permissions; Broadcom documents a vCenter registration failure caused by missing privileges.

4. Connect the S3 storage appliance built for backups

The storage design separates the operating system from persistent object data and metadata, exposes an internal HTTPS S3 endpoint, and uses bucket-scoped service credentials. Use the actual endpoint, region, and credentials created on your appliance. An S3-compatible lab implementation still needs compatibility and restore testing before production use.

There are three independent storage configurations. Setting up the system log repository does not create a database backup location.

Bucket names above are examples. Create separate credentials for each purpose and grant the operations DSM needs. Keep keys in your password manager; never include them in screenshots or configuration examples posted publicly.

1. On the S3 appliance, verify the buckets exist, authentication is required, and the service identities can access their intended buckets.
2. In DSM, import the S3 endpoint’s issuing CA into the trusted certificate configuration.
3. Open Settings → Storage Settings and configure the system backup repository.
4. Enter https://s3.lab.example.com, the appropriate access key and secret key, the system backup bucket, and the appliance’s configured region.
5. Enable Force Path Style when using the path-style endpoint configuration described below. Save and validate the repository.
6. Configure System Log Repository URL separately using its bucket and credentials.
7. Create Database Backup Storage separately using its own storage name, bucket, credentials, and matching endpoint settings. Ensure the database policy can use this location.

For my lab endpoint, the region was us-east-1. This is a storage configuration value, not a requirement that every DSM repository use that region. The three storage settings and CA trust are also illustrated in this DSM object storage walkthrough.

Why Force Path Style mattered

My first log repository test tried to resolve a bucket-prefixed hostname and failed:

Virtual-hosted style: https://dsm-logs.s3.lab.example.com/
Path style:           https://s3.lab.example.com/dsm-logs/

The appliance had the endpoint DNS name and certificate, not a DNS record for every bucket hostname. Enabling Force Path Style made DSM use the endpoint name with the bucket in the path. If you deliberately use virtual-hosted style, provide the corresponding DNS and certificate coverage instead.

My recorded S3 checks passed signed object put/get/list/delete operations and cross-bucket isolation; anonymous access was denied. Those checks validate storage access. They do not replace a DSM backup and an isolated restore test.

Protect the S3 appliance itself, including object data, metadata, configuration, certificates, and credentials. A single VM or datastore holding the only recovery copy remains a shared failure point. Avoid independent object expiration rules until their interaction with database retention and recovery dependencies has been validated.

5. Verify bundles and enable database versions

1. Review the DSM data plane and data service bundle inventory.
2. Confirm required bundles show Ready. In an offline environment, import the matching bundles using the supported workflow for your installed DSM release.
3. Check which database versions are enabled for provisioning.
4. Allow the intended versions in the namespace’s Data Service Policy.

My DSM inventory already contained Ready bundles for Postgres, MySQL, and SQL Server. A download page showing only one individual bundle did not mean the other services were absent from the appliance.

For reference, the PostgreSQL bundle was 9.1.1.0100.25745731, and the associated data plane bundle was 9.1.1.0100.25746620. The Postgres bundle manifest listed versions 18.6, 17.11, 16.15, 15.19, and 14.24. Check your own inventory rather than assuming this list applies to another bundle.

6. Prepare workload placement and policies

Keep infrastructure placement and database consumption policy distinct. A vSphere namespace existing in vCenter does not, by itself, complete DSM configuration.

Supervisor-backed placement used in my lab

1. Confirm the target workload Supervisor and its Kubernetes service are healthy.
2. Install or verify the compatible DSM Consumption Operator Supervisor service, configured for your DSM endpoint and certificate trust. Obtain the service definition and matching configuration from Broadcom; select the appropriate standard or offline/legacy artifact for your environment. The Supervisor Services catalog explains artifact selection and compatibility checks.
3. Create or select the workload vSphere namespace. Assign appropriate VM classes, storage policies, permissions, resource limits, and network capacity.
4. In vSphere Client, select the target vCenter and open Configure → Data Services Manager → Infrastructure Policies. Use Add vSphere Namespace to register the intended namespace for DSM placement.
5. In DSM, verify the infrastructure policy is available to the database consumption configuration. Associate the appropriate Data Service Policy and backup storage with the DSM namespace used to create databases.

When integrating through VCF Automation, follow its dedicated Data Services organization and project/namespace workflow. Do not assume any unrelated application namespace is the correct target. Cormac Hogan’s VCF Automation/DSM integration walkthrough shows the infrastructure registration relationship.

DSM-managed infrastructure policies are another placement option and can coexist with namespace-backed policies. Choose the supported model intentionally; do not create an extra DSM-managed policy merely because a vSphere namespace is missing from a picker.

Prepare the database consumption policy

1. Select the intended infrastructure policy and storage resources.
2. Allow the required Postgres version or supported version range.
3. Make the database backup location available through the policy.
4. Associate the policy with the DSM namespace used by the database creator.
5. Reopen the database creation wizard and confirm its namespace and version selectors now contain the expected choices.

If the wizard reports “None of the database versions are enabled,” revisit the global version enablement and policy association. Changing namespace labels is not a substitute for those configuration steps.

7. Check offline Kubernetes release prerequisites

My first database deployment failed because DSM requested a KubernetesRelease that was not present on the Supervisor. Other Ready releases were installed, including a newer patch, but the requested object name still had to exist.

With an authenticated Supervisor context, run these read-only checks:

kubectl config current-context
kubectl get kubernetesreleases
kubectl get clustercontentlibraries
kubectl get kubernetesreleases v1.35.5---vmware.1-vkr.1

The final command reflects the exact release requested in my lab. Inspect your deployment error and bundle requirements before choosing a release. I staged the required content in the offline depot and synchronized the subscribed Kubernetes Service Content Library. Provisioning could proceed once the requested release showed Ready=True and Compatible=True.

A DSM bundle being Ready and a content library subscription existing are useful checks, but neither proves the exact Supervisor KubernetesRelease has been registered. Confirm the object explicitly rather than editing release metadata or substituting a different version name.

8. Validate the foundation

• DSM is healthy and associated with the intended workload vCenter.
• Appliance and service networks have working DNS, time synchronization, routing, and TLS trust.
• The existing Ubuntu S3 appliance accepts authenticated access to the intended buckets.
• System backup, system log, and database backup storage are configured separately.
• Required bundles are Ready, database versions are enabled, and policy access is correct.
• Infrastructure placement has the required namespace, VM classes, storage, network addresses, and permissions.
• The exact Kubernetes release required for Supervisor-backed provisioning is available.
• A system backup and isolated restore exercise are included in the acceptance plan before relying on this for production.

Problems I would check first

With these prerequisites resolved, my managed PostgreSQL instance reached Ready. The next post will cover creating that database, configuring DNS and certificate trust, and preparing the connection used by Private AI Services.

Lab notes: OVA field names and defaults were checked against the deployed DSM 9.1.1 template. Storage validation and provisioning observations come from my lab build. A full DSM system restore and database recovery drill are separate acceptance tasks and are not claimed as completed here.