Please enter search query.
Search <book_title>...
Veritas Access Software-Defined Storage (SDS) Management Platform Solutions Guide
Last Published:
2018-07-24
Product(s):
Access (7.4)
Platform: Linux
- Introduction
- Deploying the SDS Management Platform with Veritas Access
- Using the SDS Management Platform interface
- Setting up SSL in the SDS Management Platform
- Performing authentication
- System backup and restore
- Troubleshooting
- Log locations
- Diagnostic reports
- Java Virtual Machine (JVM) parameters
- SDS Management Platform known issues
- If multiple bucket creation requests with different inputs for attributes such as size and layout are in progress in parallel, then a bucket can get created with incorrect attributes
- When editing a storage resource or backup server, an Advanced button is available that shows options that you should not change
- If you add a Veritas Access cluster where the host includes the protocol (such as, https://10.20.30.40), the provider gets added and collects data but running the LTR workflow fails
- When you create a bucket, the status of the task appears as DONE, even though the creation is still in progress
- Clicking on a non-mapped Veritas Access cluster directs you to an empty wiki page which shows a table and some data
- If you restart the operating system, the SDS Management Platform does not start automatically
- When you add a storage resource or backup server, the added resource is not automatically visible
- After the SDS log is rotated, the log messages from either Veritas Access or the SDS plugin go to the rotated file instead of the new file
- Some of the storage resources may appear as faulted and a warning sign appears next to the cluster IP address in the Infrastructure> Storage Resources page
- Creation of STU fails if the S3 user is changed
- Software limitations
After the SDS log is rotated, the log messages from either Veritas Access or the SDS plugin go to the rotated file instead of the new file
The SDS log (located at /var/log/sds_fops.log) is rotated every day. SDS contains two services, the SDS plugin and the Veritas Access plugin, which share the log file. Because of bug in Python, a race condition occurs and one of the two services starts logging to a new file while the other service continues logging in the rotated file.
Workaround:
Check the last updated timestamps of the current log file and the rotated log file and the, co-relate the logs from different services for debugging.