Storage policies added to PVDC are displayed as "N/A"
search cancel

Storage policies added to PVDC are displayed as "N/A"

book

Article ID: 378493

calendar_today

Updated On:

Products

VMware Cloud Director

Issue/Introduction

In a VCD with a large number of associated datastores, items are displayed as N/A after adding a new storage policy to the PVDC.

In /opt/vmware/vcloud-director/logs/vcloud-container-info.log, the following log is output where SQL UPDATE times out and causes an error.

2024-08-26 13:33:55,002 | ERROR | Backend-activity-pool-733193 | JDBCExceptionReporter | ERROR: canceling statement due to statement timeout
  Where: SQL statement "UPDATE cached_dgp_sc_metric AS cached
SET
requested_storage_mb = source.requested_storage_mb ,
pvdc_count = source.pvdc_count ,
disk_free_mb = source.disk_free_mb ,
disk_size_mb = source.disk_size_mb ,
disk_uncommitted_mb = source.disk_uncommitted_mb ,
disk_used_mb = source.disk_used_mb ,
disk_provisioned_mb = source.disk_provisioned_mb ,
iops_capacity = source.iops_capacity ,
iops_allocated = source.iops_allocated
FROM
dgp_sc_metrics_view AS source
WHERE
((cached.ds_vc_id = source.ds_vc_id) AND (cached.ds_moref = source.ds_moref))
AND (
cached.requested_storage_mb != source.requested_storage_mb OR
cached.pvdc_count != source.pvdc_count OR
cached.disk_free_mb != source.disk_free_mb OR
cached.disk_size_mb != source.disk_size_mb OR
cached.disk_uncommitted_mb != source.disk_uncommitted_mb OR
cached.disk_used_mb != source.disk_used_mb OR
cached.disk_provisioned_mb != source.disk_provisioned_mb OR
cached.iops_capacity != source.iops_capacity OR
cached.iops_allocated != source.iops_allocated
)"
PL/pgSQL function populate_cached_sc_metrics(integer) line 35 at SQL statement |
2024-08-26 13:33:55,004 | WARN | Backend-activity-pool-733193 | aseCacheRefreshJob$DatabaseCacheRefreshJobActivity | [Activity Execution] Failed to execute stored procedure: populate_cached_sc_metrics - Handle: urn:uuid:########-####-####-####-############ |
org.hibernate.HibernateException: org.hibernate.exception.GenericJDBCException: error executing work
        at com.vmware.vcloud.common.persist.Conversation.monitor(Conversation.java:584)
        at com.vmware.vcloud.common.persist.Conversation.execStoredProcedure(Conversation.java:925)
        at com.vmware.vcloud.common.persist.Conversation.execNonQueryStoredProcedure(Conversation.java:870)
        at com.vmware.vcloud.common.persist.Conversation.execNonQueryStoredProcedure(Conversation.java:861)
        at com.vmware.ssdc.backend.monitoring.DatabaseCacheRefreshJob$DatabaseCacheRefreshJobActivity$DatabaseCacheCleanerPhase$1.run(DatabaseCacheRefreshJob.java:110)
        at com.vmware.ssdc.backend.monitoring.DatabaseCacheRefreshJob$DatabaseCacheRefreshJobActivity$DatabaseCacheCleanerPhase$1.run(DatabaseCacheRefreshJob.java:106)
        at com.vmware.vcloud.common.threadpool.ThreadContextExecutor.executeImpl(ThreadContextExecutor.java:59)
        at com.vmware.vcloud.common.threadpool.ThreadContextExecutor.execute(ThreadContextExecutor.java:52)
        at com.vmware.ssdc.backend.monitoring.DatabaseCacheRefreshJob$DatabaseCacheRefreshJobActivity$DatabaseCacheCleanerPhase.invoke(DatabaseCacheRefreshJob.java:117)
        at com.vmware.vcloud.activity.executors.ActivityRunner.runPhase(ActivityRunner.java:175)
        at com.vmware.vcloud.activity.executors.ActivityRunner.run(ActivityRunner.java:112)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.hibernate.exception.GenericJDBCException: error executing work
        at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:126)
        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:114)
        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:52)
        at org.hibernate.impl.SessionImpl.doWork(SessionImpl.java:1877)
        at jdk.internal.reflect.GeneratedMethodAccessor2887.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at com.vmware.vcloud.common.db.HibernateClassLoaderHelperBeanPostProcessor$SessionInvocationHandler.invoke(HibernateClassLoaderHelperBeanPostProcessor.java:280)
        at com.sun.proxy.$Proxy113.doWork(Unknown Source)
        at com.vmware.vcloud.common.persist.Conversation.lambda$execStoredProcedure$7(Conversation.java:926)
        at com.vmware.vcloud.common.persist.Conversation.monitor(Conversation.java:576)
        ... 15 more
Caused by: org.postgresql.util.PSQLException: ERROR: canceling statement due to statement timeout
  Where: SQL statement "UPDATE cached_dgp_sc_metric AS cached
SET
requested_storage_mb = source.requested_storage_mb ,
pvdc_count = source.pvdc_count ,
disk_free_mb = source.disk_free_mb ,
disk_size_mb = source.disk_size_mb ,
disk_uncommitted_mb = source.disk_uncommitted_mb ,
disk_used_mb = source.disk_used_mb ,
disk_provisioned_mb = source.disk_provisioned_mb ,
iops_capacity = source.iops_capacity ,
iops_allocated = source.iops_allocated
FROM
dgp_sc_metrics_view AS source
WHERE
((cached.ds_vc_id = source.ds_vc_id) AND (cached.ds_moref = source.ds_moref))
AND (
cached.requested_storage_mb != source.requested_storage_mb OR
cached.pvdc_count != source.pvdc_count OR
cached.disk_free_mb != source.disk_free_mb OR
cached.disk_size_mb != source.disk_size_mb OR
cached.disk_uncommitted_mb != source.disk_uncommitted_mb OR
cached.disk_used_mb != source.disk_used_mb OR
cached.disk_provisioned_mb != source.disk_provisioned_mb OR
cached.iops_capacity != source.iops_capacity OR
cached.iops_allocated != source.iops_allocated
)"
PL/pgSQL function populate_cached_sc_metrics(integer) line 35 at SQL statement
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2440)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2183)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:308)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
        at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:150)
        at org.postgresql.jdbc.PgCallableStatement.executeWithFlags(PgCallableStatement.java:77)
        at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:139)
        at com.vmware.vcloud.common.persist.AbstractCallableStatementWork.execute(AbstractCallableStatementWork.java:87)
        at org.hibernate.impl.SessionImpl.doWork(SessionImpl.java:1873)
        ... 22 more

Cause

The problem is observed only when there are more than 500 entries, in the datastore_inv table. VMware Cloud Director has a composite index on its inventory tables. When running a SELECT or UPDATE statements using any view and the composite condition, PostgreSQL might choose not to use the composite index, resulting in the timeout.

Resolution

Workaround:
To work around this issue, open a new case with the Broadcom VMware Cloud Foundation Support Team. For more information, see How to Submit a Support Request

Additional Information

This issue is fixed in 10.6.1.

Powered by Wolken Software