VMware Blockchain 18.104.22.168 | 14 SEP 2021 | Build 80
Check for additions and updates to these release notes.
VMware Blockchain is an enterprise-grade blockchain platform that meets the needs of business-critical multi-party workflows. The patch release includes the following upgrade and fix:
VMware Blockchain Platform is upgraded to the 22.214.171.124 version.
Fixed a problem that prevented Client nodes from resynchronizing data when the data size was greater than 2GB
The problem stopped Client nodes from resynchronizing data from the Replica nodes when the data was greater than 2GB and the data folder was removed due to data corruption. Therefore, any .dar file uploads caused the Client node DAML Ledger API to fail.
The supported domain versions include:
|VMware Blockchain Platform||126.96.36.199 Build 80|
|VMware Blockchain Orchestrator||188.8.131.52 Build 73|
The VMware products and solutions discussed in this document are protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. and its subsidiaries in the United States and other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
- When you upgrade from VMware Blockchain 184.108.40.206 to 220.127.116.11, you can implement the in-place-based upgrade or clone-based upgrade process. See the Perform an In-Place-Based Upgrade or Perform Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.
- When you upgrade from VMware Blockchain 18.104.22.168 to 22.214.171.124, implement the clone-based upgrade process. See the Perform Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.
- Client nodes are unable to resynchronize data when the data size is greater than 2GB
Client nodes cannot resynchronize data from the Replica nodes when the data is greater than 2GB and the data folder is removed due to data corruption. Therefore, any .dar file uploads cause the Client node DAML Ledger API to fail.
- Replica node pruning requires 256GB memory allocation for the pruning process to function without failure
With 500,000 transactions or higher, 256GB memory allocation is required for Replica node pruning to execute successfully. Conversely, transactions that are less than 500,000 might succeed with a memory allocation of less than 256GB.
- Upgrade from VMware Blockchain version 1.1 to 1.2 requires special consideration
Special consideration is required when upgrading from VMware Blockchain 1.1 to 1.2. Contact your Blockchain support engineer.
- Concord containers crash after a long-running continuous load
In certain situations during a continuous-running load when using the expression Assert:
expression '!isFetching(), Concord containers might exit, causing the Blockchain nodes to be down and out of the quorum.
- In rare instances, the Concord containers are unable to start after failing due to metadata inconsistency
Replica nodes might crash, leaving an inconsistent state between blocks and metadata. Replica nodes recover when the mismatch only affects a single block. In workloads when the mismatch spans multiple blocks and block accumulation is deactivated, the Replica node fails to start with the following error message in the logs:
Detected more than one block needs to be deleted from the blockchain - unsupported.
- Replica nodes crash during pruning of large data
In certain circumstances, when there are many thin replica clients, there is high activity on the TRS gRPC channel resulting in a memory consumption problem that causes the Replica nodes to crash during the pruning operation.
- Concord container health metrics service is not available and displays an error message
Concord container health metrics service displays an error message for an otherwise healthy Concord container. The agent container logs show the following error message:
Concord health check will not be unavailable.
DAML package uploads and Ledger configuration submissions with the same submission_id might cause conflict in the DAML Ledger API's index database, rendering the Client node to become unresponsive
In certain situations, uploading DAML packages or setting the Ledger time model with a previously used
submission_idcan cause the Client node to become unresponsive. These operation changes can be executed only by Client node administrators with JSON Web Token containing the admin claim. See the DAML documentation, Access tokens and cliams.
Workaround: Use UUIDs as
submission_idfor all the DAML package uploads and Ledger configuration submissions. For DAML package uploads, if the UUID is left blank, the Ledger API generates a unique identifier for the
The audit.log file overflows, causing the VMware Blockchain node VM to run out of storage space and make the environment unstable
The /etc/audit/auditd.conf system file has a duplicate entry for
max_log_file_action, one entry is
ROTATE, and another entry is
IGNORE. The duplicate entry values prevent log rotation and trigger the audit.log file to overflow.
Workaround: Complete the following tasks:
- Open the
/etc/audit/auditd.conffile on a VMware Blockchain node VM.
- Delete the entry,
max_log_file_action = IGNORE.
- Repeat the deletion process on all the Replica and Client node VMs.
- Open the
Using the ActiveContractsService without specifying a template filter to retrieve active contracts is slow on large index databases
For large databases with more than one billion transaction events recorded in the index database, the query to retrieve all active contracts can take a long time to compute the results and respond to the application. As a result, applications with timeouts around the request to receive all active contracts might run into the timeout and abort the operation.
Workaround: Applications must provide a template filter for requests to the active contracts service. The template filter guarantees that only necessary and expected data is loaded from the database and transmitted to the application.
When a deployed VM is created, the VM might not have a private static IP address due to a race condition
In a rare occurrence, a deployed VM might not have a private static IP address when it is created. The problem occurs due to a race condition in the underlying Photon OS.
Workaround: Remove the deployed VMware Blockchain node VM and re-deploy the blockchain.