VMware Data Services Manager 1.x Release Notes

About VMware Data Services Manager

VMware Data Services Manager enables Enterprise organizations to host their own Database-as-a-Service offering on VMware-based infrastructure.

Supported Platforms

The following table identifies the supported component versions for VMware Data Services Manager version 1.x:

VMware Data Services Manager Version	VMware vSphere Version (Edition)	VMC Version	MySQL Version	PostgreSQL Version	Microsoft SQL Server Version
1.5.0	6.7.x through 8.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.32	11.19.0, 12.14.0, 13.10.0, 14.7.0, 15.2.0	2019 in Standard, Developer, and Enterprise editions
1.4.0	6.7.x through 7.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.30	10.23.0, 11.18.0, 12.13.0, 13.9.0	2019 in Standard, Developer, and Enterprise editions
1.3.2	6.7.x through 7.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.28	10.22.0, 11.17.0, 12.12.0, 13.8.0	2019 in Standard, Developer, and Enterprise editions
1.3.1	6.7.x through 7.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.28	10.21.0, 11.16.0, 12.11.0, 13.7.0	2019 in Standard, Developer, and Enterprise editions
1.3.0	6.7.x through 7.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.28	10.21.0, 11.16.0, 12.11.0, 13.7.0	2019 in Standard, Developer, and Enterprise editions
1.2.0	6.7.x through 7.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.26	10.20.0, 11.15.0, 12.10.0, 13.6.0	Not Applicable
1.1.1	6.7.x through 7.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.26	10.19.0, 11.14.0, 12.9.0	Not Applicable
1.1.0	6.7.x through 7.0.x (Enterprise Plus Edition)	SDDC 1.14v6	8.0.26	10.18.0, 11.13.0, 12.8.0	Not Applicable
1.0.1, 1.0.2	6.7.x through 7.0.x (Enterprise Plus Edition)	Not Applicable	8.0.23	10.17.0, 11.12.0, 12.7.0	Not Applicable
1.0.0	6.7.x through 7.0.x (Enterprise Plus Edition)	Not Applicable	8.0.23	10.15.0, 11.10.0, 12.7.0	Not Applicable

Upgrading to 1.5.x

If you have configured a Tanzu Net Token, VMware Data Services Manager automatically downloads a new release and upgrades the control plane software and database templates in your installation. If you have not enabled automated updates, you can also choose to do on-demand manual updates for the Provider VM and on-demand manual updates for the database.

You must update the Agent VM soon after the Provider is updated (either manually or through automated updates) to prevent version compatibility issue.

Provider Upgrade

High Availability (HA) feature of the Provider appliance is disabled in VMware Data Services Manager 1.5.0. Therefore, before upgrading VMware Data Services Manager to version 1.5.0, perform the following steps in all the Agent VMs:

SSH into the Agent VM.

Run the command vi update-env-ha-cleanup.sh to create the file update-env-ha-cleanup.sh, and then paste the following script in the file:

#!/bin/bash

if [ "$#" -lt 1 ]
then
        echo "***ERROR*** : Required number of parameters are 1 and usage is as below."
        echo " cmd -> ./update-env-ha-cleanup.sh <1>"
        echo " <1> -> primary provider ip"
        exit -1
fi

result=`/opt/vmware/vpostgres/current/bin/psql -U postgres vmware -t -c "update vmware.tenant_environment set provider_ip='$1';"`

echo "${result}"

Save and close the file update-env-ha-cleanup.sh.
Run the following commands in the Agent VM:
```
chmod +x update-env-ha-cleanup.sh
./update-env-ha-cleanup.sh <primary provider ip>
```
Ensure that you replace <primary provider ip> with the IP address of the Primary Provider.

Contact VMware Support if you run into any issues.

Database High Availability Clusters

To prevent failure of replica promotion, before you upgrade to 1.5.0, ensure that all the nodes of Database High Availability clusters have access to the Primary database's local storage and cloud storage. Replica database's Namespace must have access to the local storage and cloud storage of the Primary database.

Upgrading to 1.4.x

After you upgrade the Provider appliance(s) to 1.4.0, ensure that you perform the following steps, with respect to Provider Backup Repository, certificate validation, and database backups:

Note: At first, apply the Provider and Agent appliance updates. Post the Provider and Agent appliance updates, we recommend you apply the OS and Engine updates of databases only after you have updated the control plane (database core and adapter).

Database Backups

Ensure that you have configured SSL enabled S3 storage bucket for local and cloud database backup storage.
Migrate the existing database backups to new storages and networks.

Provider Backup Repository

Do either of the following:
- If you configured the Provider Backup repository with non-secure S3 endpoints in version 1.3.x, change the S3 bucket configuration to use a secure S3 bucket.
- If you configured the Provider Backup repository with secure S3 endpoints in version 1.3.x, change the S3 bucket to use a different secure S3 bucket.
Verify that a new pgbackrest backup of the Provider VM is available in the newly configured S3 bucket of the Provider backup repository.
After the pgbackrest backup of the Provider VM is successfully completed, you can choose to delete older S3 bucket that were configured with version 1.3.x.

Certificate Validation

Ensure that the certificates involved in secured communication are valid, preferably signed by CA or a self-signed certificate. In case of self-signed certificates, ensure that you resolve hostname and IP address.
Ensure that the certificates of the new S3 storages are updated in the existing database VMs. To update the certificate, see Updating Trusted Certificates.

After the PostgreSQL database VMs get updated with 1.4.0 components:

Wal-g is internally replaced with pgBackRest.
The first backup after the update for each database, either manual or scheduled, is a full backup and a new backup chain is created.
The status of backups prior to the update turns from Active to Available.
Databases cannot be restored using the backups done prior to 1.4.0. Therefore, you can delete those backups. If you do not delete those backups, they will be deleted as per the configured retention policy.

Note: After control plane is updated to 1.4.0:

If the PostgreSQL databases created in 1.3.2 use secure S3 storage, the databases are in Critical state because database backup bin log alert is raised until the first backup has been taken (either manual or scheduled).

If the PostgreSQL databases created in 1.3.2 use non-secure S3 storage, the databases are in Critical state as database backup bin log alert is raised. The alert is cleared after the backup storage is updated to new secure S3 storage, per database.

Upgrading to 1.3.x

Before you upgrade to 1.3.0, ensure the following:

Organizations must have unique FQDN and names. Checks for unique FQDN and names of organizations are case-sensitive.
Delete existing replica databases of database clusters.

If you have deployed Data Management for VMware Tanzu in an air-gapped environment:

Perform the following steps to install the upgraded version of Data Management for VMware Tanzu from 1.2.0 to 1.3.0 or from 1.3.0 to 1.3.1:
1. SSH into the Provider VM as a root user.
2. Run the following command:
  
  echo "" > /opt/vmware/tdm-provider/bin/cap-prevalidate.sh
You must download the new release and manually populate the database templates and software updates in the Provider Repo.

After upgrading to 1.3.0, ensure the following:

Update all the components of a database before you perform any operations like manual backups, cloning, restore, or recover. If Auto Minor Version Upgrade is not activated for a database, you can manually update the VMs.
For the upgraded database clusters, you can clone the existing Primary database to create a new Standalone database. You can create a new High Availability (HA) cluster by creating replica databases of the newly created Standalone database.
For the upgraded Standalone databases, you can clone the existing Standalone database to create a new Standalone database. You can create a new HA cluster by creating replica databases of the newly created Standalone database. You can delete the original Standalone database.
For a Provider HA cluster, perform the following steps:
1. Upgrade the Primary Provider VM.
2. Use the following API to delete all the Standby Provider VMs in a cluster.
```
DELETE https://<provider-ip-address>/appliance/provider-ha/{instanceUuid}
```
3. Reboot the Primary Provider VM.
4. With only the Primary node in the cluster, perform some actions, such as creating a database or a Namespace.
5. Configure two more Provider VMs in 1.3 release, and then register them as Standby VMs to the existing Primary Provider VM to form a complete Provider HA cluster.

If you have configured a Tanzu Net Token, Data Management for VMware Tanzu automatically downloads a new release and upgrades the control plane software and database templates in your installation. If you have not enabled automated updates, you can also choose to do on-demand manual updates for the Provider VM and on-demand manual updates for the database. The Agent VM is updated automatically.

Upgrading to 1.2.x

If you deployed Data Management for VMware Tanzu in an air-gapped environment, you must download the new release and manually populate the database templates and software updates in the Provider Repo.

Release 1.5.x

Release 1.5.0

Release Date: May 31, 2023

VMware Data Services Manager 1.5.0 includes new and changed features and known issues.

New Database Versions Supported

VMware Data Services Manager 1.5.0 includes support for these PostgreSQL versions:

11.19.0
12.14.0
13.10.0
14.7.0
15.2.0

VMware Data Services Manager 1.5.0 starts the support for PostgreSQL 14 and PostgreSQL 15.

VMware Data Services Manager 1.5.0 includes support for MySQL version 8.0.32.

VMware Data Services Manager 1.5.0 includes early access provisioning for Microsoft SQL Server 2019 in Standard, Developer, and Enterprise editions.

What's New?

VMware Data Services Manager 1.5.0 includes the following new and changed features:

Support for a Consolidated Agent

A Consolidated Agent uses a pre-packaged Agent and enables the management of databases on a vSphere environment cluster of your choice. You can onboarding You can onboard a Consolidated Agent VM from the Provider console.

Process Improvement for Provider and Agent VM Deployment

You can now deploy a Provider VM without providing the First Name, Last Name, and name of the Provider Organization. You can modify all these parameters of a Provider after deploying the Provider VM. Therefore, this feature saves deployment time and offers flexibility in Provider VM deployment. You can also create the login credentials of the Provider Administrator when you login to the Provider VM for the first time.
You do not need to provide multiple passwords when you deploy the Provider OVF. Also, you have the option of not providing DNS and NTP properties during Agent OVF deployment.
VMware Data Services Manager has modified the roles and the privileges of the roles that you need to configure when onboarding an Agent. This feature is an enhancement to reduce the number of roles and to modify the privileges for efficient database management in VMware Data Services Manager.

Support for a Single Network Environment

You can now configure a Provider VM and an Agent VM to use the same network as the Management Network and the Database Network. A separate Database network is not required. Communication between the Provider VM, Agent VM, and database VMs is possible over the Management network. This eases the process of network management and provides more flexibility in the choice of networks to manage databases in VMware Data Services Manager.
You have the choice of configuring either DHCP or static IP addresses for the Provider VM and Agent VM on the Management network and Database network. During the installation process, you can either use a single network for management and database traffics or use separate networks for management and database traffics.
You can create databases with or without separate Management network and Database network. By default, the Management network is used to access databases by the applications. However, you can choose to provide a dedicated network for databases access that is separate from the Management network.

Support for PostgreSQL 14 and PostgreSQL 15

VMware Data Services Manager supports creating and managing PostgreSQL 14.7.0 and PostgreSQL 15.2.0 databases from Release 1.5.0 onwards.

Discontinuation of Support for PostgreSQL 10.x

VMware Data Services Manager does not support creating and manging PostgreSQL 10.x databases from Release 1.5.0 onwards. You can upgrade the existing PostgreSQL 10.x databases to later versions of PostgreSQL.

Discontinuation of Support for Provider High Availability

VMware Data Services Manager does not support Provider High Availability through SRM in Release 1.5.0. However, you can use vSphere High Availability feature instead.

Support to Limit the Size of WAL files and Binary Log files

If automated backups are enabled, VMware Data Services Manager limits the size of WAL files of PostgreSQL Primary databases (15% of actual disk size) and Binary log files of MySQL Primary databases (10% of actual disk size) of a High Availability (HA) cluster. This feature prevents the exponential growth of WAL files of Binary log files and helps in the efficient functioning of database HA clusters.

Telemetry Support

With your consent, VMware Data Services Manager collects data and analytics that can be used to help build and scale the product. VMware Data Services Manager provides you the option to allow the use of Telemetry to monitor the usage patterns of the product.

Support for VMXNET3

From Release 1.5.0, VMware Data Services Manager uses VMXNET3 as the network adapter to provision databases because VMXNET3 provides enhanced throughput.

Known Issues and Limitations

VMware Data Services Manager 1.5.0 has the following known issues and limitations:

Deployment:

VMware Data Services Manager supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from VMware Data Services Manager after the user has created any databases. Current workaround:
1. Revoke the user's access to VMware Data Services Manager by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.

Database Configuration:

Sometimes, powering on database VMs can conflict with virtual machine affinity/anti-affinity rules. Therefore, to successfully power on all the VMs in a database cluster after you have powered them off, keep the vSphere DRS turned off.
A user can modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in VMware Data Services Manager.
If OS update of database is pending, creating Replica databases fail.
VMware recommends that you do not try to recover the Primary database of a database HA cluster (MySQL or PostgreSQL) because it can lead to instability of the cluster. Instead, clone the Primary database or perform Restore/PITR from a backup of the Primary database and then create a new cluster.
In a High Availability cluster of PostgreSQL databases, you cannot configure the max_connections of a Replica database lower than that of the Primary database.
VMware recommends that you update Provider and Agent VMs before applying manual database updates.

Certificates:

If you update a Custom CA after you create a database, you must update the CA on each individual database.

Resolved Issues

VMware Data Services Manager 1.5.0 includes the following resolved issues.

Database Configuration:

You can resolve the DNS of database VMs with domain names ending with .local to create Replica databases of those database VMs.
You can change database options without disrupting the functioning of a database cluster.

Release 1.4.x

Release 1.4.0

Release Date: December 20, 2022

With version 1.4.0, Data Management for VMware Tanzu is rebranded and is known as VMware Data Services Manager.

VMware Data Services Manager 1.4.0 includes new and changed features, known issues, and resolved issues.

New Database Versions Supported

VMware Data Services Manager 1.4.0 includes support for these PostgreSQL versions:

10.23.0
11.18.0
12.13.0
13.9.0
14.7.0
15.2.0

VMware Data Services Manager 1.4.0 includes support for MySQL version 8.0.30.

VMware Data Services Manager 1.4.0 includes early access provisioning for Microsoft SQL Server 2019 in Standard, Developer, and Enterprise editions.

What's New?

VMware Data Services Manager 1.4.0 includes the following new and changed features:

Installing Agent VMs from the Provider Console

You can install an Agent VM from the Provider console of VMware Data Services Manager. This feature provides you ease of installing an Agent VM from a single UI and you do not need to shuttle between multiple UIs.

Provision to Onboard Resource Pools

You can onboard Resource Pools from a vSphere cluster or VMC cluster when you onboard an Agent VM. A Resource Pool is a vsphere object that allows logical partitioning of compute and memory resources.

User-defined Scheduled Updates of Provider and Agent Appliances

You can configure the maintenance policy of Provider VM and Agent VM appliances to apply automated updates only during a specified maintenance window. Thus, you can control and manage updates of these appliances, as required, in an automated manner.

Support for Webhooks

You can configure Webhooks, to connect to an external application and send alert notifications for databases provisioned in VMware Data Services Manager. Thus, you can configure customised endpoints to receive alerts of database operation failure or status change, as required.

User-defined Thresholds of Database Alerts

VMware Data Services Manager improves the user experience for managing alerts of database operation failures or status change. You can configure customized alert sets with user-defined thresholds, apply them to databases, and manage them efficiently, as required.

Replacement of Wal-G with Pgbackrest

pgBackRest provides a reliable, scalable, and easy backup and restore solution to the largest databases and workloads by using algorithms that are optimized for database-specific requirements. Therefore, VMware Data Services Manager is replacing Wal-g with pgBackRest to take backup and restore Provider appliance and PostgreSQL database appliances managed by VMware Data Services Manager.

Support for Creating or Deleting Database Clusters at Once

You can create and delete all the nodes of a database HA cluster (MySQL and PostgreSQL) at once. This feature provides you enhanced user experiece while managing database HA clusters because it saves a lot of time that you would have wasted in adding and deleting nodes of a cluster individually.

Improved VM Password Management

VMware Data Services Manager improves the user experience for managing the passwords of Provider VMs, Agent VMs, and Database VMs. You can update these passwords before or after the password expires.

Improved Namespace Management

VMware Data Services Manager simplifies you the process of associating namespaces with organizations. Thus, you can have an enhanced user experience in managing organizations and their association with namespaces.

Enhanced Syncing of vCenter Resources with Databases

VMware Data Services Manager improves the user experience for syncing updates to vCenter resources with the databases created in VMware Data Services Manager. You can synch onboarded environments with the updates of resources in the vCenter and the databases that use those environments are also synched.

Support for Modifying Candidate Priority of Cluster Nodes in a Database Cluster

Candidate priority is one of the parameters that decides which Replica database will be automatically promoted as the Primary node of the databse HA cluster (MySQL and PostgreSQL) during a failover. You can edit candidate priority of any node in a cluster to modify the chances of a node to become the Primary node through automatic promotion.

Known Issues and Limitations

VMware Data Services Manager 1.4.0 has the following known issues and limitations:

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
VMware Data Services Manager supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from VMware Data Services Manager after the user has created any databases. Current workaround:
1. Revoke the user's access to VMware Data Services Manager by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All VMware Data Services Manager user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

Sometimes, powering on database VMs can conflict with virtual machine affinity/anti-affinity rules. Therefore, to successfully power on all the VMs in a database cluster after you have powered them off, keep the vSphere DRS turned off.
Do not perform a recover operation on the Primary database of a cluster. You can clone the Primary database or perform the restore or PITR operation on the Primary database, and then perform the recover operation on the cloned or restored database.
A user can modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in VMware Data Services Manager.
If OS update of database is pending, creating Replica databases fail.
VMware recommends that you do not try to recover the Primary database of a database HA cluster (MySQL or PostgreSQL) because it can lead to instability of the cluster. Instead, clone the Primary database or perform Restore/PITR from a backup of the Primary database and then create a new cluster.
VMware recommends that you update Provider and Agent VMs before applying manual database updates.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promoting a Secondary Provider VM to a Primary Provider VM is not automated and requires user intervention through the CLI.

Release 1.3.x

Release 1.3.2

Release Date: October 21, 2022

Data Management for VMware Tanzu 1.3.2 includes new and changed features, known issues, and resolved issues.

New Database Versions Supported

Data Management for VMware Tanzu 1.3.2 includes support for these PostgreSQL versions:

10.22.0
11.17.0
12.12.0
13.8.0

Data Management for VMware Tanzu 1.3.2 includes support for MySQL version 8.0.28.

Data Management for VMware Tanzu 1.3.2 includes early access provisioning for Microsoft SQL Server 2019 in Standard, Developer, and Enterprise editions.

What's New?

Data Management for VMware Tanzu 1.3.2 includes the following new and changed features:

Status of Provider Nodes in an HA Cluster

For a Provider HA cluster, Data Management for VMware Tanzu provides status of the different Provider nodes and enables you to take necessary action for the smooth functioning of the cluster.

Disaster Recovery (Early Access through SRM)

You can now configure Site Recovery Manager (SRM) with Data Management for VMware Tanzu and ensure disaster recovery of the Provider VMs, Agent VMs, and database VMs from a Primary site to a Recovery site when the Primary site goes down. This feature of disaster recovery for Data Management for VMware Tanzu through SRM enables business continuity from the Recovery site until the Primary site is up again.

Known Issues and Limitations

Data Management for VMware Tanzu 1.3.2 has the following known issues and limitations:

Infrastructure:

When organizations share infrastructure, there is no CPU, network, or storage isolation between their workloads.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

Sometimes, powering on database VMs can conflict with virtual machine affinity/anti-affinity rules. Therefore, to successfully power on all the VMs in a database cluster after you have powered them off, keep the vSphere DRS turned off.
Do not perform a recover operation on the Primary database of a cluster. You can clone the Primary database or perform the restore or PITR operation on the Primary database, and then perform the recover operation on the cloned or restored database.
A user can modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promoting a Secondary Provider VM to a Primary Provider VM is not automated and requires user intervention through the CLI.

Resolved Issues

Data Management for VMware Tanzu 1.3.2 includes the following resolved issues.

Deployment:

In a Provider HA setup, after a failover to an existing Secondary node, you can add a new Secondary node to the cluster.
During failover in a Provider HA setup, if any Secondary node is ahead of the new Primary node of the cluster, the Secondary node rewinds and synchs with the new Primary node.

Database Configuration:

Although updates for the OS components and Engine of a database are shown in the Available Upgrades section of the of the Maintenance tab as soon as available, these updates are processed only after the Provider VM and Agent VMs are updated. Also ensure that the control plane is updated before you update the OS components or Engine of a database.

Release 1.3.1

Release Date: July 27, 2022

Data Management for VMware Tanzu 1.3.1 includes known issues and resolved issues.

Known Issues and Limitations

Data Management for VMware Tanzu 1.3.1 has the following known issues and limitations:

Infrastructure:

When organizations share infrastructure, there is no CPU, network, or storage isolation between their workloads.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

Sometimes, powering on database VMs can conflict with virtual machine affinity/anti-affinity rule. Therefore, to successfully power on all the VMs in a database cluster after you have powered them off, keep the vSphere DRS turned off.
Do not perform recover operation on a Primary database of a cluster. You can clone the Primary database or you perform the restore or PITR operation on the Primary database, and then perform the recover operation on the cloned or restored database.
A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.

Resolved Issues

Data Management for VMware Tanzu 1.3.1 includes the following resolved issues.

Infrastructure:

After on-demand synching of vCenter resources, all other resources of an environment apart from the updated resource are not removed from the environment.

Deployment:

The API to update root password of a VM enables you to reset the password even after the expiry of the password.

Database Configuration:

In a Database HA cluster, if you power off the Primary Database VM in the vCenter, the Replica Database VM is successfully promoted as the new Primary Database VM. Later, if you want to promote the old Primary Database VM after powering it on in the vCenter, the promotion is successful too.
In a Database HA cluster, intermittent failure of DNS resolution at the time of replica creation is fixed.
In a Database HA cluster, intermittent failure of DNS resolution failure at the time of creating a Replica Database VM is fixed.
In a PostgreSQL Database HA cluster, owner of the Monitor VM and the Primary Database VM is same irrespective of who owns the Replica Database VM. Therefore, the owner of the Primary Database VM can access the Monitor VM even if the first Replica Database VM is created and owned by an user that is different from the owner of the Primary Database VM.
In a PostgreSQL Database HA cluster, after a Remote Read Replica Database VM is promoted to a Primary Database VM, its status does not change to Warning.
Each Database VM has a unique hostname that is the DB FQDN of the Database VM, where DB FQDN is VM Name+DB FQDN Suffix. For example if you enter the VM Name (during Database VM creation) as Test and if the DB FQDN Suffix (of the Organization to which the Database VM belongs) is marketing.com, then the hostname of the Database VM is Test.marketing.com.

Release 1.3.0

Release Date: June 20, 2022

Data Management for VMware Tanzu 1.3.0 includes new and changed features, known issues, and resolved issues.

New Database Versions Supported

Data Management for VMware Tanzu 1.3.0 includes support for these PostgreSQL versions:

10.21.0
11.16.0
12.11.0
13.7.0

Data Management for VMware Tanzu 1.3.0 includes support for MySQL version 8.0.28.

Data Management for VMware Tanzu 1.3.0 includes early access provisioning for Microsoft SQL Server 2019 in Standard, Developer, and Enterprise editions.

What's New?

Data Management for VMware Tanzu version 1.3.0 includes the following new and changed features:

High Availability Database Clusters

Data Management for VMware Tanzu enables you to create High Availability (HA) clusters of databases for PostgreSQL and MySQL database engines with auto promotion and manual promotion functionalities to provide high reliability and to prevent downtime.

Introducing Microsoft SQL Server Databases (Early Access)

Data Management for VMware Tanzu enables you to create Standalone Microsoft SQL Server Databases and manage customised database templates that are used to create these databases.

Enhanced Namespaces

Namespaces are created as a pool of resources and a Namespace can be shared across organizations and used by multiple databases. Data Management for VMware Tanzu also enables you to modify associations of organizations to Namespaces and modify resources in a Namespace. Therefore, multiple Namespaces can be associated with different agents, as required, that are created from a shared resource pool. More than one Namespace can be associated with an Environment (Agent) or an Environment (Agent) can have an exclusive Namespace. Enhanced Namespaces provide simplified deployment experience, improved resource management, and Agent Isolation.

Enhanced Role of Provider Administrator

Provider Administrator role is enhanced and it can perform operations on databases such as, create, backup, clone, restore, PITR, replicate, and recover databases. Thus, this imparts enhanced control of the Provider Administrator on operations in Data Management for VMware Tanzu and provides two ways of onboarding an agent for a simplified user experience.

Onboard Agents through the Provider Console

Data Management for VMware Tanzu enables you to onboard an Agent through the Provider console as well as the Agent console. Therefore, you have redundancy in onboarding agents and you can have the option to onboard through the Provider console if the Agent IP is unreachable and vice versa.

Enhanced Reporting

Data Management for VMware Tanzu enables you to download information on databases and system audit events either in XLSX or CSV format. Based on the downloaded data, you can perform various analysis and take informed decisions based on data.

Sync with vSphere Modifications

Apart from scheduled updates to environments and VMs that occur once in 24 hours, Data Management for VMware Tanzu enables on-demand sync of environments with the vCenter resource modifications of the vSphere. Thus, changes made in the vSphere, due to requirements of Data Management for VMware Tanzu environments, can be synced and applied on demand.

Known Issues and Limitations

Data Management for VMware Tanzu 1.3.0 has the following known issues and limitations:

Infrastructure:

When organizations share infrastructure, there is no CPU, network, or storage isolation between their workloads.
After on-demand synching of vCenter resources, all other resources of an environment apart from the updated resource are removed from the environment.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.
The API to update root password of a VM cannot reset the password after the expiry of the password.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

Sometimes, powering on database VMs can conflict with virtual machine affinity/anti-affinity rule. Therefore, to successfully power on all the VMs in a database cluster after you have powered them off, keep the vSphere DRS turned off.
Do not perform recover operation on a Primary database of a cluster. You can clone the Primary database or you perform the restore or PITR operation on the Primary database, and then perform the recover operation on the cloned or restored database.
A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.
In a Database HA cluster, if you power off the Primary Database VM in the vCenter, the Replica Database VM is successfully promoted as the new Primary Database VM. However, if you want to promote the old Primary Database VM after powering it on in the vCenter, the promotion fails.
In Database HA cluster, creation of Replica Database VM can fail due to DNS resolution issues.
In a PostgreSQL Database HA cluster, if the Primary Database VM is owned by an Organization Administrator or an Organization User and the first Replica Database VM is created by a , the Monitor VM is owned by the . Therefore, the owner of the Primary Database VM cannot access the Monitor VM.
In a PostgreSQL Database HA cluster, after a Remote Read Replica Database VM is promoted to a Primary Database VM, its status changes to Warning.
The Database VMs do not have a unique hostname because the common hostname for all the Database VMs is photon.local.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.

Resolved Issues

Data Management for VMware Tanzu 1.3.0 includes the following resolved issues.

Infrastructure:

When organizations share infrastructure, all databases running on shared infrastructure need not have a common sub-domain.

Deployment:

The issue of intermittent failure while publishing database templates in an HA setup is resolved.

Database Configuration:

To prevent databases from moving into an unstable state, you need not update the Provider VM and Agent VM before you manually update OS of databases followed by the Engine of database VMs.

Certificates:

If local and cloud storage are configured with secure S3 endpoints but Provider log settings are not configured or configured with different S3 endpoints, certificates are still propagated to the Provider VM.

Release 1.2.x

Release 1.2.0

Release Date: March 09, 2022

Data Management for VMware Tanzu 1.2.0 includes new and changed features, known issues, and resolved issues.

New Database Versions Supported

Data Management for VMware Tanzu 1.2.0 includes support for the following PostgreSQL versions:

10.20.0
11.15.0
12.10.0
13.6.0

From Release 1.2.0, Data Management for VMware Tanzu extends support for PostgreSQL 13.

What's New?

Data Management for VMware Tanzu version 1.2.0 includes the following new and changed features:

Enhanced Log Management

Configure an external Syslog Server to forward and manage logs from different sources (Provider VM, Agent VM, and databases) of Data Management for VMware Tanzu. In Release 1.2.0, support for vRealize Log Insight as a Syslog server is validated. However, you can also configure other Syslog servers.

Flexibility in Managing Environments:

Configure and manage email notifications for changes in the status and failure of operations of a database.
Validate SMTP settings.
Identify and distinguish operations that are targeted on databases, Provider VMs, database templates, and environment.
Use Namespace as a subset of the environment available to provision a database.

Flexibility in Managing Databases:

Configure and manage tags for a database.
Search and group database VMs based on different filter criterias.
Delete backups of a database with ACTIVE status.

Enhanced Role of Provider Administrator

Onboarding an agent by a Provider Administrator.

Known Issues and Limitations

Data Management for VMware Tanzu 1.2.0 has the following known issues and limitations:

Infrastructure

When organizations share infrastructure:
- There is no CPU, network, or storage isolation between their workloads.
- All databases running on shared infrastructure must have a common sub-domain.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.
If you experience intermittent failure while publishing templates in an HA setup, perform the following steps:
1. Through the Provider logs, identify the Provider node on which the /data/manifests/extracted-manifest folder is created and has JSON files in it.
2. Copy all the JSON files from the data/manifests/extracted-manifest folder of the Provider node where all the json files are present.
3. Paste the JSON files in all the other Provider nodes in the data/manifests/extracted-manifest folder that you create in these nodes.
4. Retry publishing the template in the HA setup.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.
To prevent Database Instances from moving into an unstable state, you need to update the Provider VM and Agent VM before you manually update OS of Database Instances, and then the Engine of Database Instances after the OS update is completed.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.
If local and cloud storage are configured with secure S3 endpoints but Provider log settings are not configured or configured with different S3 endpoints, certificates are not propagated to the Provider VM. Therefore, as a workaround you can do any of the following:
- Configure the same S3 host on provider logs settings as the local and cloud storage, and configure a different S3 bucket for provider logs.
- Configure non-secure S3 storage during agent onboarding for cloud storage.
- Manually copy S3 certificates to the provider appliance key store. Upload S3 certificates through the following API:
```
POST https://agent-ip/onboarding/api/tenant/onboarding?action=add-trusted-certificates
```
  Request parameters:
```
    {
      "certificate: <cert file>",
    }
```

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.

Release 1.1.x

Release 1.1.1

Release Date: December 14, 2021

New Database Versions Supported

Data Management for VMware Tanzu 1.1.1 includes support for the following PostgreSQL versions:

10.19.0
11.14.0
12.9.0

Known Issues and Limitations

Data Management for VMware Tanzu 1.1.1 has the following known issues and limitations:

Infrastructure

When organizations share infrastructure:
- There is no CPU, network, or storage isolation between their workloads.
- All databases running on shared infrastructure must have a common sub-domain.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.

Release 1.1.0

Release Date: December 01, 2021

Data Management for VMware Tanzu cersion 1.1.0 includes new and changed features, known issues, and resolved issues.

What's New?

Data Management for VMware Tanzu version 1.1.0 includes the following new and changed features:

Flexibility in Database Configurations:

Change the Backup configuration of provisioned databases.
Recover a Database if it is corrupted.
Change the Maintenance Policy configuration of provisioned databases and perform on-demand updates for the OS and Engine of a database manually.
Change the level of Maintenance of provisioned databases.
When we create, clone, restore, or replicate a database, select the Application Network from the list of Application Networks that are configured during the process of onboarding an Agent VM.
Change ownership of provisioned database.
Change in default operating system user name for SSH access to a MySQL Database or a PostgreSQL Service Database.
Changes in default configurations and privileges of a MySQL Database.
Changes in default configurations and privileges of a PostgreSQL Database.

Flexibility in Infrastructure Configurations:

Ability to select an Application Network from the list of Application Networks that are configured during the process of onboarding an Agent VM when we create, clone, restore, or replicate a database.
Change networks for provisioned Infrastructure.
Change vCenter credentials for provisioned Infrastructure.
Change VM Datastores for provisioned Infrastructure.
Change Local and Cloud Storage credentials for provisioned Infrastructure.

On-demand Updates to Provider and Databasees:

Manually perform on-demand updates for the Provider VM.
Manually perform on-demand updates for the Engine and OS of a provisioned database.

Deployment of Provider VM, Agent VM, and database in VMware Cloud Service on AWS:

Configuration of two users during the process of onboarding an agent.
Create Remote Read Replicas of a provisioned Primary databases in a vSphere cluster or VMC cluster that is different from the vSphere cluster or VMC cluster of the Primary database.

Authentication Functions:

Data Management for VMware Tanzu stored case-sensitive organization Emails and local user Email IDs. Now, Data Management for VMware Tanzu does not store and manage case-sensitive email identifiers.

Known Issues and Limitations

Data Management for VMware Tanzu 1.1.0 has the following known issues and limitations:

Infrastructure

When organizations share infrastructure:
- There is no CPU, network, or storage isolation between their workloads.
- All databases running on shared infrastructure must have a common sub-domain.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.

Resolved Issues

Data Management for VMware Tanzu 1.1.0 has the following resolved issues:

Infrastructure:

You can define multiple networks when you onboard new infrastructure to Data Management for VMware Tanzu.
You can update infrastructure configuration after you have deployed any databases.
You can remove infrastructure from Data Management for VMware Tanzu after you have deployed any databases, even if you delete all of the databases.

Release 1.0.x

Release 1.0.2

Release Date: September 30, 2021

Known Issues and Limitations

Data Management for VMware Tanzu 1.x has these known issues and limitations:

Infrastructure:

You cannot define multiple networks when you onboard new infrastructure to Data Management for VMware Tanzu.
You cannot update infrastructure configuration after you have deployed any databases.
You cannot remove infrastructure from Data Management for VMware Tanzu after you have deployed any databases, even if you delete all of the databases.
When organizations share infrastructure:
- There is no CPU, network, or storage isolation between their workloads.
- All databases running on shared infrastructure must have a common sub-domain.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.

Resolved Issues

Data Management for VMware Tanzu 1.0.2 resolves the following issues:

Intermittent failure of Promote Replica operation

Sometimes, promoting a Replica database to a Primary database failed when the DHCP server assigned the same IP address to both the Primary database and the Read Replica database. Now, Data Management for VMware Tanzu ensures that the same IP address is not assigned to these instances.
OS software updates that require reboot were not applied to databases

OS software updates that required reboot were not applied to the databases for which you did not select Enable Auto Minor Version Upgrade during the creation of the database. Now, OS software updates that require reboot are applied independent of selecting Enable Auto Minor Version Upgrade during the creation of the database.
SSH connection successful even after deactivating SSH access

If you deactivated SSH access to a database, SSH connections to the database were still successful. Now, SSH connection depends on activating or deactivating SSH access to a database.
Provider restore failed

The process of restoring a Provider backup on a Provider VM failed. Now, the Provider restore operation works more reliably.

Release 1.0.1

Release Date: August 12, 2021

New Database Versions Supported

Data Management for VMware Tanzu 1.0.1 includes support for new MySQL version 8.0.26.

Data Management for VMware Tanzu 1.0.1 includes support for the following new PostgreSQL versions:

10.18.0
11.13.0
12.8.0

Changes

Starting with version 1.0.1 of Data Management for VMware Tanzu, VMware distributes the Data Management for VMware Tanzu Provider and Agent virtual appliance .ovas and the Air-gap Environment Repository on VMware Customer Connect in addition to distributing this software on VMware Tanzu Network.

Known Issues and Limitations

Data Management for VMware Tanzu 1.x has the following known issues and limitations:

Infrastructure:

You cannot define multiple networks when you onboard new infrastructure to Data Management for VMware Tanzu.
You cannot update infrastructure configuration after you have deployed any databases.
You cannot remove infrastructure from Data Management for VMware Tanzu after you have deployed any databases, even if you delete all of the databases.
When organizations share infrastructure:
- There is no CPU, network, or storage isolation between their workloads.
- All databases running on shared infrastructure must have a common sub-domain.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.

Resolved Issues

Data Management for VMware Tanzu 1.0.1 resolves the following issues:

Promote Replica fails for PostgreSQL 10 and 11

Due to a file permission error, promoting a Replica to Primary fails when the databases was deployed with PostgreSQL 10.x or 11.x.
Database Template publishing occasionally fails

Publishing a database template occasionally fails when the Provider Repo is located in AWS S3.

Release 1.0.0

Release Date: July 19, 2021

This is the first release of Data Management for VMware Tanzu.

What's New?

Data Management for VMware Tanzu version 1.0.0 includes the following:

Simplified Database Provisioning and Management for Users:

Provision and manage MySQL and PostgreSQL database VMs from a simple, intuitive graphical user interface.
Provision single node and high availability deployment of databases in just a few clicks.
Define daily backup window for automated scheduled backups, or take a backup on-demand.
Define distinct retention policies on multiple storage endpoints to store backups for different levels of Recovery Time Objectives (RTO).
Fully restore, or perform a point-in-time recovery of, data from database backups and transaction logs.
Define a weekly maintenance window for automated updates of database server software and security patching, or update the database server on-demand.
Generate a log bundle from an impaired database for further troubleshooting and root cause analysis.
Monitor the health of individual databases using metrics on resource utilization, database activity, and usage.

Tailored Managed Data Services Offering for Providers:

Group users with common access to infrastructure resources into organizations.
Share common infrastructure across multiple organizations.
Use database templates to curate and manage the database versions that are available for new database provisioning.
Restrict VM creation and scaling to predefined VM Plans, and scale the resources any time as necessary.
Store database backups to any S3-compatible object storage (AWS S3, MinIO, Dell ECS etc.).

Centralized Control Plane Management for Providers:

Install, deploy, and register the Data Management for VMware Tanzu control plane on vSphere infrastructure using the graphical installer interface.
Deploy the control plane with high availability.
Enable LDAP-based authentication for the Data Management for VMware Tanzu installation.
View the alerts that Data Management for VMware Tanzu automatically raises when it detects connectivity issues that would impact normal operation of the control plane.
Examine the audit log of operations performed on the control plane.
Generate a log bundle for the Provider VM for further troubleshooting and root cause analysis.
Data Management for VMware Tanzu periodically checks for software updates on the control plane; view and apply these updates.
Monitor MySQL and PostgreSQL databases across multiple vSphere clusters from the control plane.

Centralized Infrastructure Management:

Monitor the health of individual Agent VMs using metrics that Data Management for VMware Tanzu generates for resource utilization and the health of Agent services.
View the preemptive and active alerts that Data Management for VMware Tanzu raises when the normal operation of an Agent running on an Onboarded Cluster is impacted in a way that would affect provisioning and management operations.
Use an aggregated view of alerts to monitor the overall health across all Agent VMs, identifying those agents that require attention.
Generate a log bundle from an impaired Agent VM for further troubleshooting and root cause analysis.
Rely on the automatic software updates that Data Management for VMware Tanzu automatically applies on the Agent VM.

Known Issues and Limitations

Data Management for VMware Tanzu 1.0.0 has the following known issues and limitations:

Infrastructure:

You cannot define multiple networks when you onboard new infrastructure to Data Management for VMware Tanzu.
You cannot update infrastructure configuration after you have deployed any databases.
You cannot remove infrastructure from Data Management for VMware Tanzu after you have deployed any databases, even if you delete all of the databases.
When organizations share infrastructure:
- There is no CPU, network, or storage isolation between their workloads.
- All databases running on shared infrastructure must have a common sub-domain.

Deployment:

You cannot move to Standalone Provider mode from a High Availability (HA) Provider deployment.
Data Management for VMware Tanzu supports the following Agent concurrency limits:
- 8 parallel database deployments (create, restore, PITR, clone, add replica operations) with a bounded waiting queue of size two (2).
- Operations with an unbounded waiting queue:
  - 8 parallel database management operations (for example: power on/off, promote, generate log bundle).
  - 5 parallel backups.
  - 5 parallel transaction log uploads.

Organizations and Users:

You cannot remove an organization after you create it.
You cannot remove a local user from Data Management for VMware Tanzu after the user has created any databases. Current workaround:
1. Revoke the user's access to Data Management for VMware Tanzu by resetting the user's password.
2. Have the Organization Administrator manage the user's databases, backups, and logs.
All Data Management for VMware Tanzu user management is performed by the Provider Administrator user. Organization Administrators manage users that are part of the organization and they can view the users and configuration details of their organization.

Database Configuration:

A user is permitted to modify only certain configuration properties after a database is successfully provisioned.
You cannot change the database server administrative password from the console or API after the database has been provisioned.
- You must change this password using a database client.
- When you change this password, the new password is not reflected in Data Management for VMware Tanzu.

Certificates:

If you update a Custom CA after you create a database creation, you must update the CA on each individual database.

Provider Failover:

Promotion of a Standby Provider VM to Primary Provider VM is not automated and required user intervention through CLI.