Validate the Global View OVA deployment
After deploying the Virtana Global View OVA and completing initial configuration, verify that all cluster services, databases, messaging queues, and application pods have started and reached their expected operational state.
Check pod status
Open a terminal or SSH session into your Global View appliance and run:
kubectl get pods --all-namespaces
The command returns one row for each pod, grouped by namespace. The output includes the NAMESPACE, NAME, READY, STATUS, RESTARTS, and AGE columns.
virtana@virtana-gv-appliance:~$ kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE calico-system calico-apiserver-64857c5597-nb8zf 1/1 Running 0 68d calico-system calico-apiserver-64857c5597-vkpbp 1/1 Running 0 68d calico-system calico-kube-controllers-6c9d56bcc5-k7mvd 1/1 Running 0 68d calico-system calico-node-crf6m 1/1 Running 0 68d calico-system calico-typha-947b97979-nfh9d 1/1 Running 0 68d calico-system goldmane-7fb659c977-dkmjz 1/1 Running 0 68d calico-system whisker-7d8968f975-zbq8b 2/2 Running 0 68d controlplane actions-service-55888bdd4-zrhvn 1/1 Running 0 67d controlplane alerts-gateway-service-7856fddf75-kq5gh 1/1 Running 0 67d controlplane alerts-service-7cb45df6b-gkxk4 1/1 Running 0 67d controlplane appmon-api-svc-575d6cf654-ggbg5 1/1 Running 0 67d controlplane audit-logs-service-678c7dd4dd-n7kll 1/1 Running 0 67d controlplane authentication-service-6f5977f454-jsjgs 1/1 Running 0 67d controlplane authorization-service-677877cb5c-ztbck 1/1 Running 0 67d controlplane branding-service-7d796b8c7-gndml 1/1 Running 0 67d controlplane controlplane-growthbook-768b8898c7-7xhkw 1/1 Running 0 67d controlplane controlplane-infra-cnpg-operator-77864c548d-pkgj6 1/1 Running 1 (24d ago) 67d controlplane controlplane-infra-kafka-broker-0 1/1 Running 0 67d controlplane controlplane-infra-kafka-broker-1 1/1 Running 0 67d controlplane controlplane-infra-kafka-broker-2 1/1 Running 0 67d controlplane controlplane-infra-mongodb-b8c45cc48-m6gxb 1/1 Running 0 67d controlplane controlplane-infra-postgresql-main-1 1/1 Running 1 (40d ago) 67d controlplane controlplane-infra-redis-0 1/1 Running 0 67d controlplane controlplane-minio-7657c8778b-ljfhn 1/1 Running 0 67d controlplane cp-metrics-service-55f9dcd999-bn9mv 1/1 Running 0 67d controlplane create-databases-hf79k 0/1 Completed 0 67d controlplane insights-service-59f84f5b9c-b29kb 1/1 Running 0 67d controlplane integration-mgmt-service-7474bdf86-dhs9d 1/1 Running 0 67d controlplane inventory-service-55858f9d79-rtrcs 1/1 Running 0 67d controlplane kafka-configurator-8phtv 0/1 Completed 0 67d controlplane licensing-service-5bfc8b8c64-m4jx8 1/1 Running 0 67d controlplane onprem-cost-service-57c795b647-x9tlh 1/1 Running 0 67d controlplane org-creation-h94qk 0/1 Completed 0 67d controlplane org-zero-creation-nrs5z 0/1 Completed 0 67d controlplane organization-service-78cbcc7789-6mttt 1/1 Running 0 67d controlplane reporting-service-68594f7b79-tsmn9 1/1 Running 0 67d controlplane solrcloud-solr-0 1/1 Running 0 67d controlplane solrcloud-solr-1 1/1 Running 0 67d controlplane solrcloud-solr-2 1/1 Running 0 67d controlplane solrcloud-zookeeper-0 1/1 Running 0 67d controlplane solrcloud-zookeeper-1 1/1 Running 0 67d controlplane solrcloud-zookeeper-2 1/1 Running 0 67d controlplane strimzi-cluster-operator-78c9bdd977-626xd 1/1 Running 0 67d controlplane ui-6bd7c7ccfc-r47jx 1/1 Running 0 67d controlplane ui-notification-service-578d949c99-gk9ld 1/1 Running 0 67d controlplane user-service-7dcbbdbc66-5llgn 1/1 Running 0 67d controlplane user-settings-service-7fd99fd766-smd4r 1/1 Running 0 67d controlplane victoria-metrics-single-0 1/1 Running 0 67d controlplane virtana-ai-6c57fdb549-lsdcq 1/1 Running 2 (67d ago) 67d controlplane virtana-mcp-server-69955df887-cvqlb 1/1 Running 0 67d controlplane vp-infrastructure-cloudcapi-5cd9fb7f95-z56sr 1/1 Running 0 67d controlplane vp-sslgen-2tzlm 0/1 Completed 0 67d controlplane vp-swagger-server-7cc574f8d7-w6tj8 1/1 Running 0 67d controlplane workflow-job-service-9956479d8-2jrs4 1/1 Running 0 67d ingress-nginx ingress-nginx-controller-6797f4dc8c-nhbt8 1/1 Running 0 68d keycloak 1-keycloak-sslgen-preinstall-4rxk5 0/1 Completed 0 67d keycloak keycloak-6b7c876948-cl4xg 1/1 Running 0 67d keycloak postgres-0 1/1 Running 0 67d kube-system coredns-697968c856-bhw2c 1/1 Running 0 68d kube-system local-path-provisioner-774c6665dc-9grhh 1/1 Running 0 68d kube-system metrics-server-6f4c6675d5-m6lfv 1/1 Running 0 68d tigera-operator tigera-operator-8458958b4d-6fm9v 1/1 Running 2 (24d ago) 68d
Evaluate pod states
Review the output against the expected states below:
Running: All long-running system, infrastructure, and application pods must be in the Running state, with all ready containers matching the total count.Completed: One-time install and database initialization jobs must showCompleted.Unhealthy States: Any pod in a state such as
CrashLoopBackOff,ImagePullBackOff,Error, orPendingindicates a deployment or resource issue.
Expected pods by namespace
A Global View appliance running version 2026.6.1 distributes its pods across six Kubernetes namespaces. All of the pods listed in this section are mandatory. The ingress-nginx, keycloak, and controlplane namespaces hold the Virtana Platform components that Global View installs. The calico-system, kube-system, and tigera-operator namespaces hold the Kubernetes and networking system components that ship in the OVA and start automatically.
Pods in the ingress-nginx namespace
The ingress-nginx namespace holds the ingress controller, which is the entry point for all external traffic to Global View. If the pod in this namespace isn't running, the Global View web interface and APIs are unreachable even when every other pod is healthy.
The following table lists the pod that must be present in the ingress-nginx namespace.
Pod name prefix | Expected status | Purpose |
|---|---|---|
|
| Routes external HTTP and HTTPS traffic into the cluster and forwards each request to the correct Global View service. |
Pods in the keycloak namespace
The keycloak namespace holds the identity and authentication server that Global View uses to sign users in, along with the PostgreSQL database that stores its realm, user, and session data. If the pods in this namespace aren't healthy, users can't sign in to Global View.
The following table lists the pods that must be present in the keycloak namespace.
Pod name prefix | Expected status | Purpose |
|---|---|---|
|
| Runs the Keycloak identity and authentication server, which handles user sign-in, tokens, and identity provider federation. |
|
| Runs the PostgreSQL database that stores Keycloak realms, users, clients, and sessions. |
|
| Generates the TLS certificate that Keycloak uses. This job runs once, before Keycloak starts. |
Infrastructure pods in the controlplane namespace
The infrastructure pods in the controlplane namespace provide the databases, message bus, search, object storage, and metrics storage that the Global View application microservices depend on. Validate these pods first. If an infrastructure pod isn't running, the microservices that depend on it stay in a transient or failed state. An infrastructure failure is therefore the most common root cause when many pods are unhealthy at once.
The following table lists the infrastructure pods that must be present in the controlplane namespace.
Pod name prefix | Expected status | Purpose |
|---|---|---|
|
| Runs GrowthBook, the feature flag service that controls which Global View features are enabled. |
|
| Runs the CloudNativePG operator, which creates and manages the main PostgreSQL cluster. |
|
| Runs the main PostgreSQL database, which stores the platform's relational data. |
|
| Run the three Kafka brokers that form the platform message bus. Services exchange events through Kafka. |
|
| Runs the Strimzi operator, which creates and manages the Kafka cluster. |
|
| Runs the MongoDB database, which stores the platform's document data. |
|
| Runs the Redis in-memory cache, which services use for caching and short-lived state. |
|
| Runs MinIO object storage, which holds generated files such as reports and exports. |
|
| Run the three SolrCloud nodes that index platform data and serve search queries. |
|
| Run the three ZooKeeper nodes that coordinate the SolrCloud cluster. |
|
| Runs VictoriaMetrics, the time series database that stores platform metrics. |
Application microservice pods in the controlplane namespace
The application microservice pods in the controlplane namespace provide the Global View features that users interact with, such as the web interface, alerting, inventory, reporting, and licensing. Every pod in the following table must show Running with a ready replica count that matches its total replica count, such as 1/1.
The following table lists the application microservice pods that must be present in the controlplane namespace.
Pod name prefix | Expected status | Purpose |
|---|---|---|
|
| Runs the actions that you configure for alerts and automated workflows. |
|
| Receives inbound alert events from monitored sources and passes them to the alerts service. |
|
| Evaluates alert definitions and manages the lifecycle of each alert. |
|
| Serves the application monitoring APIs. |
|
| Records audit log entries for user and system activity. |
|
| Handles sign-in requests and validates tokens, working with Keycloak. |
|
| Enforces the role and permission checks that control what each user can see and do. |
|
| Serves the branding assets, such as logos and themes, that customize the web interface. |
|
| Collects and serves the platform's own operational metrics. |
|
| Generates the insights and recommendations that Global View presents. |
|
| Manages the integrations that connect Global View to external data sources. |
|
| Maintains the inventory of discovered resources and their relationships. |
|
| Validates the license and tracks entitlement and license consumption. |
|
| Calculates cost data for on-premises infrastructure. |
|
| Manages organizations and their configuration. |
|
| Generates reports and runs report schedules. |
|
| Serves the Global View web interface. |
|
| Delivers in-app notifications to the web interface. |
|
| Manages user records and user group membership. |
|
| Stores each user's preferences and settings. |
|
| Provides the AI-assisted analysis features, including Copilot. |
|
| Serves the Virtana Model Context Protocol (MCP) endpoint, which lets AI clients query Virtana Platform data. |
|
| Provides the cloud infrastructure collection API. |
|
| Serves the interactive API reference for the Virtana Platform APIs. |
|
| Runs scheduled and background workflow jobs. |
Installation job pods in the controlplane namespace
The installation job pods in the controlplane namespace run once during installation to prepare the platform, and then exit. Each of these pods must show Completed with a ready count of 0/1. A job pod that shows Error means that an installation task failed, and the services that depend on that task can't start.
The following table lists the installation job pods that must be present in the controlplane namespace.
Pod name prefix | Expected status | Purpose |
|---|---|---|
|
| Verifies the SMTP configuration that the platform uses to send email notifications. |
|
| Creates the platform databases in PostgreSQL. |
|
| Creates the Kafka topics that the platform services use to exchange events. |
|
| Creates the initial organization. |
|
| Creates the default system organization that the platform uses internally. |
|
| Generates the TLS certificates that the platform services use. |
Note
Completed job pods stay in the kubectl get pods output until Kubernetes removes them. If your cluster applies a job cleanup policy, a job pod can be absent from the output even though the installation succeeded. A missing job pod is a concern only when the services that depend on that job aren't Running.
Pods in the system namespaces
The calico-system, kube-system, and tigera-operator namespaces hold the Kubernetes and container networking components that are built into the Global View OVA (Open Virtualization Appliance). These pods start automatically when you deploy the appliance, and Global View can't run without them. Include them in your validation so that you can confirm the appliance's foundation is healthy before you investigate a platform service.
The following table lists the system pods that must be present in a Global View appliance.
Namespace | Pod name prefix | Expected status | Purpose |
|---|---|---|---|
|
|
| Serves the Calico API for network policy resources. Two replicas run by default. |
|
|
| Keeps Calico network state in sync with Kubernetes resources. |
|
|
| Runs the Calico networking agent that programs the network on each node. One pod runs on every node in the cluster. |
|
|
| Distributes Calico datastore updates to the Calico agents, which reduces load on the Kubernetes API server. |
|
|
| Aggregates Calico network flow data. |
|
|
| Serves the Calico network flow visualization interface. This pod runs two containers, so its ready count is |
|
|
| Resolves DNS names inside the cluster so that services can find each other. |
|
|
| Provisions persistent volumes on the appliance's local disk for the platform's stateful components. |
|
|
| Collects CPU and memory metrics for the cluster's nodes and pods. |
|
|
| Installs and manages the Calico networking deployment. |
Troubleshooting Pod states that indicate a problem
A Global View pod that shows any state other than Running or Completed in the kubectl get pods --all-namespaces output points to a specific class of problem. Use the following table to identify the cause of each state and the action to take. Before you investigate an individual microservice, confirm that the infrastructure pods in the controlplane namespace are running. A failed database, Kafka broker, or Solr node causes the microservices that depend on it to fail as well.
The following table describes the pod states that indicate a problem in a Global View deployment.
Pod state | Description | Action |
|---|---|---|
| Kubernetes can't place the pod on a node. The most common causes are insufficient CPU or memory on the appliance and a persistent volume claim that isn't bound. | Run |
| The pod is starting. These states are expected shortly after deployment, while Kubernetes pulls images and runs init containers. | Wait a few minutes and run |
| The container starts and then exits repeatedly. The most common causes are a configuration error and an unavailable dependency, such as PostgreSQL, Kafka, or Solr. | Confirm that the infrastructure pods in the |
| Kubernetes can't pull the container image. The Global View OVA ships with its container images preloaded. This state therefore usually means that an image is missing from the appliance, or that its tag doesn't match the tag the deployment expects. | Run |
| The container exited with a non-zero exit code. For an installation job pod, this state means the installation task failed. | Read the container logs to find the failure: |
| The container is running but hasn't passed its readiness probe, so the pod isn't serving traffic yet. This state often means the service is still waiting for a dependency. | Run |
The pod is missing from the output | Kubernetes never created a required pod, or a cluster cleanup policy removed a completed job pod. | If the missing pod is an installation job and the services that depend on it are |
Important
Don't delete or restart the stateful infrastructure pods in the controlplane namespace, such as controlplane-infra-postgresql-main-1, the controlplane-infra-kafka-broker- pods, or the solrcloud-zookeeper- pods, to clear a failed state. Restarting these pods interrupts data collection and can leave dependent microservices in a failed state. Diagnose the failure first, and contact Virtana Support before you restart an infrastructure pod.