Global View upgrade (2026.6.1)
Global View is one of the core components of the Virtana Platform. It provides a centralized, unified dashboard to monitor and manage performance across your entire infrastructure, consolidating insights from multiple sources into a single pane of glass.
This topic describes how to upgrade an existing Global View installation from version 2026.4.1 to version 2026.6.1.
Prerequisites
Before you upgrade Global View to 2026.6.1, confirm that your environment meets the following requirements:
An existing Virtana Platform installation running version 2026.4.1.
A Kubernetes cluster with Helm 3.x installed.
Access to the Virtana Helm repository.
Valid Docker registry credentials.
DNS records configured for the Global View, Keycloak, and GrowthBook hostnames.
What's new in 2026.6.1
Version 2026.6.1 changes several parts of the Global View values files. Review these changes before you prepare your configuration:
VirtanAI (Copilot) configuration: The single
OPENAI_API_KEYvariable is replaced with a provider-based model that supports OpenAI, Gemini, and LiteLLM.SeaweedFS replaces MinIO: Global View now uses SeaweedFS as its object storage backend. Remove all MinIO configuration from your values files.
Redis image repository renamed: For private-registry deployments, the Redis image repository changes from
redistodhi-redis.Keycloak image updated: The Keycloak container image changes from
quay.io/keycloak/keycloak:26.3todhi.io/keycloak:26.
Prepare the Helm values file
Create a file named global-view-values.yaml, and replace all placeholder values with your environment-specific settings. The following sections describe each block in the file.
Global configuration
The global configuration block sets ingress behavior, the PostgreSQL backing store, registry credentials, identity provider settings, and tenant details. Add the following block to global-view-values.yaml:
global:
controlplane:
ingress:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
postgresql:
migration:
enabled: false
storage:
size: 50Gi
environment: app
secret_source: valuesfile
storageClass: &defaultStorageClass ""
dockerRegistryCredentials:
DOCKER_SERVER: "https://index.docker.io/v2/"
DOCKER_USERNAME: "username"
DOCKER_PASSWORD: "password"
keycloak:
hostname: <KEYCLOAK_HOSTNAME>
adminUser: "vpadmin"
adminPassword: "P@ssW0rd@123"
public_dns_host_name: <global_view_hostname>
public_dns_host_am_suffix: -oc-<global_view_hostname>
organization_details:
organization_name: "<TENANT_NAME>"
first_name: "John"
last_name: "Doe"
contact_email: "xxxx.xxxx@domain.com"
create_tls_selfsigned_certs: true
affinity: &affinity {}
nodeSelector: &nodeSelector {}
tolerations: &tolerations []The following table describes the fields in the global configuration block:
Field | Description | Default value |
|---|---|---|
| Controls the behavior of the NGINX Ingress for the control plane. | — |
| Controls automatic HTTP-to-HTTPS redirection. |
|
| When enabled, forces all incoming traffic to be served over HTTPS. |
|
| Configures the PostgreSQL database that backs the platform. | — |
| Controls whether database migration jobs run automatically. Keep this value set to |
|
| Size of the persistent volume for PostgreSQL. |
|
| Deployment environment name or type. |
|
| Specifies where secrets come from. Supported values: |
|
| Default Kubernetes StorageClass for persistent volume claims (PVCs). If blank, the cluster default StorageClass is used. |
|
| Credentials used to pull container images from a Docker registry. | — |
| URL of your private registry. Use this when you deploy in an air-gapped environment. |
|
| Registry username. |
|
| Registry password. |
|
| List of servers used when you pull images directly from Docker Hub. Don't change the list. |
|
| Integrates the platform with a Keycloak identity provider. | — |
| Public hostname where Keycloak is accessible. |
|
| Credentials for the Keycloak admin account that configures realms, clients, and users. |
|
| Main DNS name for the Global View UI. |
|
| Suffix used to construct additional hostnames for auxiliary services. |
|
| Metadata about the tenant or organization. | — |
| Tenant or company name. |
|
| Primary contact person. |
|
| Contact email for notifications and support. |
|
| Controls TLS certificate handling. |
|
| Kubernetes pod affinity and anti-affinity rules. An empty value ( |
|
| Maps pods to nodes by label. An empty value ( |
|
| Allows pods to schedule onto tainted nodes. An empty value ( |
|
VirtanAI (Copilot) configuration
In 2026.6.1, VirtanAI (the Copilot chatbot) uses a provider-based configuration model that supports OpenAI, Gemini, and LiteLLM. This model replaces the single OPENAI_API_KEY variable used in earlier releases.
Add the following blocks to global-view-values.yaml:
virtana-ai:
enabled: true
env:
VIRTANA_AI_MODEL_PROVIDER: ""
cp-configs:
virtana_ai:
virtana_ai_api_key: ""
virtana_ai_inference_endpoint: "" The following table describes the VirtanAI configuration fields:
Field | Description | Default value |
|---|---|---|
| Enables the VirtanAI (Copilot) component. |
|
| Selects the model provider. Supported values: |
|
| API key for the selected provider. Replaces the former |
|
| Inference endpoint URL. Leave blank for OpenAI or Gemini. For a self-hosted LiteLLM deployment, set the LiteLLM endpoint URL, for example |
|
Set the following variables in the input.env file:
VIRTANA_AI_MODEL_PROVIDER='' VIRTANA_AI_API_KEY='' VIRTANA_AI_INFERENCE_ENDPOINT=''
The following table maps VirtanAI setting to its OVA configuration.
OVA Variables | Description |
|---|---|
| Selects the model provider. Supported values: OPENAI, GEMINI, LITELLM. |
| API key for the selected provider. Replaces the former OPENAI_API_KEY variable. |
| Inference endpoint URL. Leave blank for OpenAI or Gemini. For a self-hosted LiteLLM deployment, set the LiteLLM endpoint URL, for example |
SMTP configuration
The SMTP configuration block sets the mail server that Global View uses to send notification emails. Add the following block under cp-configs in global-view-values.yaml:
cp-configs:
smtp:
smtpHost: smtp.gmail.com
smtpPort: "587"
smtpUsername: ""
smtpPassword: ""
smtpFromEmail: "noreplies@virtana.com"
smtpTlsInsecureSkipVerify: "false"The following table describes the SMTP configuration fields:
Field | Description | Default value |
|---|---|---|
| SMTP server address. |
|
| SMTP port. |
|
| Authentication credentials for the SMTP server. |
|
| Sender address for outgoing notification emails. |
|
| When set to |
|
GrowthBook configuration
The GrowthBook configuration block sets the ingress, hostnames, and scheduling rules for the GrowthBook feature-flag service. Add the following block to global-view-values.yaml:
growthbook:
ingress:
enabled: true
annotations:
nginx.ingress.kubernetes.io/cors-allow-origin: "https://<GROWTH_BOOK_HOSTNAME>"
appOriginName: <GROWTH_BOOK_HOSTNAME>
apiHostName: <GROWTH_BOOK_API_HOSTNAME>
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerationsThe following table describes the GrowthBook configuration fields:
Field | Description | Default value |
|---|---|---|
| Restricts browser CORS requests to the GrowthBook UI hostname. |
|
| Hostname for the GrowthBook web UI. |
|
| Hostname for the GrowthBook API endpoint. |
|
Storage and infrastructure components
The storage and infrastructure block configures MongoDB, object storage, Redis, Kafka, PostgreSQL, metrics, and alerts. In 2026.6.1, SeaweedFS replaces MinIO as the object storage backend, so the minio block is removed. Add the following block to global-view-values.yaml:
cp-mongodb:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
migration:
enabled: false
persistence:
size: 50Gi
seaweedfs:
image:
registry: <REGISTRY_NAME>
allInOne:
data:
type: persistentVolumeClaim
size: 20Gi
storageClass: *defaultStorageClass
nodeSelector: *nodeSelector
affinity: *affinity
tolerations: *tolerations
redis:
persistentVolumeClaim:
existingPersistentVolumeClaim: "redis-data-controlplane-infra-redis-master-0"
strimzi-kafka-operator:
controller:
persistence:
size: 50Gi
cloud-native-postgresql-cluster:
affinity: *affinity
cp-metrics-service:
victoria-metrics-single:
rbac:
create: true
namespaced: true
server:
size: 100Gi
alerts-service:
solrdb:
enabled: true
persistent_ebs:
spec:
resources:
requests:
storage: 100Gi
solr:
enabled: false
persistence:
size: 50Gi
zookeeper:
persistence:
size: 20GiThe following table describes the storage and infrastructure fields:
Field | Description | Default value |
|---|---|---|
| Controls whether MongoDB data migrations run. |
|
| MongoDB storage for control plane documents. |
|
| Object storage for files and artifacts. SeaweedFS replaces MinIO in 2026.6.1. |
|
| Image registry for SeaweedFS. Set this for private-registry deployments. |
|
| Reuses the existing Redis PVC from the prior installation to preserve data during the upgrade. | — |
| Storage for the Strimzi Kafka operator controller state. |
|
| Time-series metrics database size. RBAC is namespaced. |
|
| Enables the SolrDB component. |
|
| EBS-backed Solr database for alert indexing. |
|
| Enables the in-chart Solr deployment. |
|
| Disk size for Solr. |
|
| ZooKeeper persistence volume size for the Solr coordination service. |
|
Note
For an upgrade, Redis references an existingPersistentVolumeClaim instead of creating new storage. This preserves data continuity from the previous Redis deployment.
Note
SeaweedFS replaces MinIO in 2026.6.1. Remove all MinIO configuration from global-view-values.yaml. Existing MinIO data is migrated automatically during the upgrade. If you don't provide a SeaweedFS block, Global View deploys SeaweedFS with default settings.
Private container registry override (optional)
Create a file named global-view-image-registry.yaml to pull images from your own container image registry instead of Virtana's official Docker registry. For the full list of override values, see Overriding the private container registry.
Note
When you build global-view-image-registry.yaml for 2026.6.1, apply these changes: remove the minio block, set the SeaweedFS image registry through seaweedfs.image.registry in global-view-values.yaml, and change the Redis image repository from redis to dhi-redis.
Deploy Global View
In this step, you apply the prepared Helm values and image registry overrides to roll out the upgraded Global View stack to your Kubernetes or OpenShift cluster. The deployment runs in three phases — CRDs, infrastructure modules, and service modules, so that custom resources, storage, messaging, and application services are created and upgraded in a controlled, dependency-aware order. All three phases use the virtana-repo/virtana-global-view Helm chart.
For the detailed deployment commands, see Deploying Global View.
Note
The Keycloak container image changes from quay.io/keycloak/keycloak:26.3 to dhi.io/keycloak:26 in 2026.6.1. Keycloak deploys from a separate chart in the keycloak namespace. Apply the Keycloak image update during the same maintenance window as the Global View upgrade.
Verify the upgrade
To confirm that Global View is accessible after the upgrade, complete the following steps:
Open your web browser and go to
https://<global_view_hostname>/ui. Replace<global_view_hostname>with the hostname you defined during configuration.Sign in with the organization email address and the password you created during registration.
When the UI loads and sign-in succeeds, the upgrade is complete.