K8s Helm-Based Upgrade
Use this section to upgrade an existing Helm-based Global View deployment to a newer release. Each path updates your global-view-values.yaml file and redeploys with Helm. The path you use depends on the version you run now.
For the latest version upgrade, refer to Global View Upgrade (2026.6.1).
Refer to Global View Upgrade (2026.4.1). To upgrade to the latest version, refer to Global View Upgrade (2026.6.1).
Refer to Global View Upgrade (2025.12.1). To upgrade to the latest version, refer to Global View Upgrade (2026.6.1).
Refer to Global View Upgrade (2025.10.1). To upgrade to the latest version, refer to Global View Upgrade (2026.6.1).
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.
Global View upgrade (2026.4.1)
Global View is one of the core components of the Virtana Platform (VP). 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.
Prerequisities
An existing Virtana Platform installation running version 2025.12.1.
A Kubernetes cluster with Helm 3.x installed is required.
Access to the Virtana Helm repository.
Valid Docker registry credentials.
DNS records configured for Global View, Keycloak, and GrowthBook hostnames.
Prepare the Helm Values File
Create a new file named global-view-values.yaml. Replace all placeholder values with your environment-specific settings.
Global Configuration
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 each field in the configuration file.
Field | Description | Default value |
|---|---|---|
| Controls the behavior of the NGINX Ingress for the control plane. | |
| Controls automatic HTTP to HTTPS redirection. The default value decides the outcome. | false |
| Diables all incoming traffic to be served via HTTPS. | false |
| The PostgreSQL database backing the platform. | |
| Controls whether database migration jobs run automatically. If customer is running GV version 2026.12.1 or above, then this value must always be | false |
| Size of the persistent volume for PostgreSQL. | 50 Gib |
| Represents the deployment environment name or type. | app |
| Specifies where secrets should come from. | valuesfile/none |
| Default Kubernetes StorageClass name for PVCs. | &defaultStorageClass "" |
| Credentials to pull container images from a Docker registry. | |
| If you are deploying in an air gapped environment and using a private docker registry to pull container images then use private registry URL. | https://index.docker.io/v2/ |
| Private registry username. | "username" |
| Private registry password | "password" |
| If you are not using the private registry and pulling container images directly from Docker Hub, then do not change the list of servers. | "https://index.docker.io/v2/" "https://dhi.io/" |
| Docker hub username. | "username" |
| Docker hub password. | "password" |
| Integrates the platform with a Keycloak identity provider. | |
| Public hostname where Keycloak is accessible | <KEYCLOAK_HOSTNAME> |
| Credentials for the Keycloak admin account used to configure realms, clients, or users for this platform. | |
| Main DNS name for accessing the Virtana Global View UI. | <GLOBAL_VIEW_HOSTNAME> |
| Suffix used to construct additional hostnames, likely for auxiliary or AM services. | -oc-<global_view_hostname> |
| Metadata about the tenant or organization | |
| Tenant or company name | <TENANT_NAME> |
| Primary contact person | |
| Contact email for notifications or support | xxxx.xxxx@domain.com |
| Controls TLS certificate handling | true |
| Kubernetes pod affinity/anti‑affinity rules. Empty {} means pods can be scheduled anywhere. | &affinity {} |
| Simple mapping of labels > nodes. Empty {} means no node label constraints. | &nodeSelector {} |
| Allows pods to be scheduled onto tainted nodes. Empty [] means no special tolerations. | &tolerations [] |
SMTP configuration
cp-configs:
smtp:
smtpHost: smtp.gmail.com
smtpPort: "587"
smtpUsername: ""
smtpPassword: ""
smtpFromEmail: "noreplies@virtana.com"
smtpTlsInsecureSkipVerify: "false"The following table describes each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| SMTP server address | smtp.gmail.com |
| SMTP port | "587" |
| Authentication credentials for the SMTP server. | " " |
| Sender address for outgoing notification emails. | "noreplies@virtana.com" |
| "false" verifies TLS certificates | "false" |
GrowthBook configuration
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 each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| 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
cp-mongodb:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
migration:
enabled: false
persistence:
size: 50Gi
minio:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
persistence:
size: 20Gi
redis:
persistentVolumeClaim:
existingPersistentVolumeClaim: "redis-data-controlplane-infra-redis-master-0"
strimzi-kafka-operator:
controller:
persistence:
size: 50Gi
kafka:
controller:
persistence:
size: 50Gi
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
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 each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| Disables MongoDB data migrations | false |
| MongoDB for control plane document storage. | 50 Gib |
| S3-compatible object storage for files and artifacts. | 20 Gib |
| Reuses the existing Redis PVC from the prior installation to preserve data continuity during upgrade. | |
| Storage for the Strimzi Kafka operator controller state. | 50 Gib |
| Storage for Kafka controller/broker nodes. Use low-latency SSD storage in production. | 50 Gib |
| Time-series metrics database. Increase for long retention or high ingestion. RBAC is namespaced. | 100 Gib |
| Enables the SolrDB component. | true |
| EBS-backed Solr database for alert indexing. | 100 Gib |
| Disables the in‑chart Solr deployment. | false |
| The disk size for Solr. | 50 Gib |
| Zookeeper persistence volume size for Solr’s coordination service. | 20 Gib |
Note
For upgrade, Redis references an existingPersistentVolumeClaim instead of creating new storage. This ensures data continuity from the previous Redis deployment
Private container registry override (optional)
Create a file named global-view-image-registry.yaml. For detailed information, see Overriding the Private Container Registry.
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 is performed in the following three phases: CRDs, infrastructure modules, and service modules. It ensures that all required custom resources, storage, messaging, and application services are created and upgraded in a controlled, dependency-aware order using the virtana-repo/virtana-global-view Helm chart.
See the detailed Global View deployment steps in Deploying Global View.
Verify the upgrade
To ensure Global View is accessible, perform the following steps:
Open your web browser and navigate to
https://<global_view_hostname>/ui. Replace<global_view_hostname>with the hostname you defined during configuration.Log in using the organizational email address and the password you created during registration.
If the UI loads and login succeeds, the upgrade is complete.
Global View upgrade (2025.12.1)
Upgrading your Global View deployment keeps your environment secure, reliable, and fully supported. Each new release includes important security and vulnerability fixes for core platform components, performance and scalability improvements for data ingestion and alert processing, and new or enhanced features across the Virtana Platform. Upgrades also ensure Global View stays compatible with supported Container Observability and Infrastructure Observability versions, and they simplify deployment and day‑to‑day operations through improved install and upgrade flows.
Prepare the Helm Values File
Create a new file named global-view-values.yaml. Replace all placeholder values with your environment-specific settings.
Global Configuration
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 each field in the configuration file.
Field | Description | Default value |
|---|---|---|
| Controls the behavior of the NGINX Ingress for the control plane. | |
| Controls automatic HTTP to HTTPS redirection. The default value decides the outcome. | false |
| Diables all incoming traffic to be served via HTTPS. | false |
| The PostgreSQL database backing the platform. | |
| Size of the persistent volume for PostgreSQL. | 50 Gib |
| Represents the deployment environment name or type. | app |
| Specifies where secrets should come from. | valuesfile/none |
| Default Kubernetes StorageClass name for PVCs. | &defaultStorageClass "" |
| Credentials to pull container images from a Docker registry. | |
| If you are deploying in an air gapped environment and using a private docker registry to pull container images then use private registry URL. | https://index.docker.io/v2/ |
| Private registry username. | "username" |
| Private registry password | "password" |
| Integrates the platform with a Keycloak identity provider. | |
| Public hostname where Keycloak is accessible | <KEYCLOAK_HOSTNAME> |
| Credentials for the Keycloak admin account used to configure realms, clients, or users for this platform. | |
| Main DNS name for accessing the Virtana Global View UI. | <GLOBAL_VIEW_HOSTNAME> |
| Suffix used to construct additional hostnames, likely for auxiliary or AM services. | -oc-<global_view_hostname> |
| Metadata about the tenant or organization | |
| Tenant or company name | <TENANT_NAME> |
| Primary contact person | |
| Contact email for notifications or support | xxxx.xxxx@domain.com |
| Controls TLS certificate handling | true |
| Kubernetes pod affinity/anti‑affinity rules. Empty {} means pods can be scheduled anywhere. | &affinity {} |
| Simple mapping of labels > nodes. Empty {} means no node label constraints. | &nodeSelector {} |
| Allows pods to be scheduled onto tainted nodes. Empty [] means no special tolerations. | &tolerations [] |
SMTP configuration
cp-configs:
smtp:
smtpHost: smtp.gmail.com
smtpPort: "587"
smtpUsername: ""
smtpPassword: ""
smtpFromEmail: "noreplies@virtana.com"
smtpTlsInsecureSkipVerify: "false"The following table describes each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| SMTP server address | smtp.gmail.com |
| SMTP port | "587" |
| Authentication credentials for the SMTP server. | " " |
| Sender address for outgoing notification emails. | "noreplies@virtana.com" |
| "false" verifies TLS certificates | "false" |
GrowthBook configuration
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 each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| 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
cp-mongodb:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
migration:
enabled: false
persistence:
size: 50Gi
minio:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
persistence:
size: 20Gi
redis:
persistentVolumeClaim:
existingPersistentVolumeClaim: "redis-data-controlplane-infra-redis-master-0"
strimzi-kafka-operator:
controller:
persistence:
size: 50Gi
kafka:
controller:
persistence:
size: 50Gi
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
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 each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| MongoDB for control plane document storage. | 50 Gib |
| S3-compatible object storage for files and artifacts. | 20 Gib |
| Reuses the existing Redis PVC from the prior installation to preserve data continuity during upgrade. | |
| Storage for the Strimzi Kafka operator controller state. | 50 Gib |
| Storage for Kafka controller/broker nodes. Use low-latency SSD storage in production. | 50 Gib |
| Time-series metrics database. Increase for long retention or high ingestion. RBAC is namespaced. | 100 Gib |
| Enables the SolrDB component. | true |
| EBS-backed Solr database for alert indexing. | 100 Gib |
| Disables the in‑chart Solr deployment. | false |
| The disk size for Solr. | 50 Gib |
| Zookeeper persistence volume size for Solr’s coordination service. | 20 Gib |
Note
For upgrade, Redis references an existingPersistentVolumeClaim instead of creating new storage. This ensures data continuity from the previous Redis deployment
Private container registry override (optional)
Create a file named global-view-image-registry.yaml. For detailed information, see Overriding the Private Container Registry.
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 is performed in the following three phases: CRDs, infrastructure modules, and service modules. It ensures that all required custom resources, storage, messaging, and application services are created and upgraded in a controlled, dependency-aware order using the virtana-repo/virtana-global-view Helm chart.
See the detailed Global View deployment steps in Deploying Global View.
Verify the upgrade
To ensure Global View is accessible, perform the following steps:
Open your web browser and navigate to
https://<global_view_hostname>/ui. Replace<global_view_hostname>with the hostname you defined during configuration.Log in using the organizational email address and the password you created during registration.
If the UI loads and login succeeds, the upgrade is complete.
Global View upgrade (2025.10.1)
As part of the 2025.10.1 release, several infrastructure components were modernized and moved to different Helm charts/operators to mitigate CVEs and modernize the stack.
Important
This upgrade involves data migration. Follow the upgrade instructions carefully.
Component | Old deployment | New deployment | Updates |
|---|---|---|---|
Redis | Bitnami Redis Helm chart | PascalIske Redis Helm chart | Requires PVC reuse during upgrade |
Kafka | Bitnami Kafka Helm chart | Strimzi Kafka Operator | Operator-based Kafka |
PostgreSQL | Bitnami PostgreSQL Helm chart | CloudNativePG (Cloud Native PostgreSQL) | Operator-based and migration workflow introduced |
New Helm tags introduced
New Helm tags were added to support operator-based components and migration workflows.
Tag | Purpose | What Gets Installed |
|---|---|---|
tags.crds=true | Install required CRDs and operators | Strimzi and CloudNativePG CRDs are installed and also deploys the CloudNativePG operator. |
tags.migrations=true | Perform PostgreSQL migration | Deploys a temporary PostgreSQL migration cluster to migrate data from Bitnami PostgreSQL. |
tags.infra=true | Deploy infra layer | Installs Kafka cluster, KafkaNodePools, CloudNativePG main cluster, and other infra components. |
tags.service=true | Deploy service layer | Installs service layer components only. |
PostgreSQL migration flow
The migration runs in two import stages:
Bitnami PostgreSQL migration to Temporary migration cluster
As a part of migration process (
tags.migrations=true), a temporary PostgreSQL cluster is created for migration.An import job copies data from Bitnami PostgreSQL into the migration cluster with import pod name format as
pg-migration-cluster-1-import-xxxxx.This import pod runs for a short duration, depending on size of the data to be migrated.
After successful import, the import pod is deleted automatically. A new pod appears as
pg-migration-cluster-1.Do not proceed to infra deployment until
pg-migration-cluster-1isRunning.
Temporary migration cluster migration to CloudNativePG cluster
When infra deployment is triggered (tags.infra=true), the main PostgreSQL cluster is created. Another import job runs to import data from the temporary migration cluster with import pod name format as
controlplane-infra-postgresql-main-1-import-xxxxx.After successful import, the import pod is deleted automatically.
The main database pod appears as
controlplane-infra-postgresql-main-1. Wait for the pod to be inRunningstate before deploying service components.
Changes in the Helm values
When upgrading to this release, several Helm chart dependencies have changed. The sections below describe the required modifications to your existing global-view-values.yaml file to ensure a smooth upgrade with no data loss and correct resource configuration.
Redis: Reuse the existing PVC
During upgrade, Redis has moved charts, so you must point the new deployment to the existing PVC created by the older Bitnami Redis deployment.
It prevents data loss by reusing the existing Redis persistent volume claim instead of creating a new empty one.
Add the following snippet to your existing global-view-values.yaml:
redis:
persistentVolumeClaim:
existingPersistentVolumeClaim: "redis-data-controlplane-infra-redis-master-0"PostgreSQL: storage/auth moved to global.postgresql
Bitnami PostgreSQL is removed. PostgreSQL storage sizing and auth are now configured under global.postgresql.
It controls storage sizing for CloudNativePG-based deployments. During migration/upgrade, two PVCs will be created, where one used by the temporary migration cluster (tags.migrations=true) and other one used by the main PostgreSQL cluster (tags.infra=true).
Add the following snippet to your existing global-view-values.yaml:
global:
postgresql:
storage:
size: 8Gi
auth:
postgresPassword: ""The other configurations like resources, affinity etc. have been removed from postgresql: and is now available under cloud-native-postgresql-cluster:. It controls CloudNativePG cluster sizing, image version, and resource usage.
cloud-native-postgresql-cluster:
instances: 1
image:
registry: ghcr.io
repository: cloudnative-pg/postgresql
pullPolicy: IfNotPresent
tag: "16.11-standard-trixie"
resources:
requests:
cpu: 100m
memory: 512Mi
limits:
cpu: 500m
memory: 512Mi
afinity: {}Prepare the Helm Values File
Create a new file named global-view-values.yaml. Replace all placeholder values with your environment-specific settings.
Global Configuration
global:
controlplane:
ingress:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
postgresql:
migration:
enabled: true
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 each field in the configuration file.
Field | Description | Default value |
|---|---|---|
| Controls the behavior of the NGINX Ingress for the control plane. | |
| Controls automatic HTTP to HTTPS redirection. The default value decides the outcome. | false |
| Diables all incoming traffic to be served via HTTPS. | false |
| Represents the deployment environment name or type. | app |
| Specifies where secrets should come from. | valuesfile/none |
| Default Kubernetes StorageClass name for PVCs. | &defaultStorageClass "" |
| Credentials to pull container images from a Docker registry. | |
| If you are deploying in an air gapped environment and using a private docker registry to pull container images then use private registry URL. | https://index.docker.io/v2/ |
| Private registry username. | "username" |
| Private registry password | "password" |
| Integrates the platform with a Keycloak identity provider. | |
| Public hostname where Keycloak is accessible | <KEYCLOAK_HOSTNAME> |
| Credentials for the Keycloak admin account used to configure realms, clients, or users for this platform. | |
| Main DNS name for accessing the Virtana Global View UI. | <GLOBAL_VIEW_HOSTNAME> |
| Suffix used to construct additional hostnames, likely for auxiliary or AM services. | -oc-<global_view_hostname> |
| Metadata about the tenant or organization | |
| Tenant or company name | <TENANT_NAME> |
| Primary contact person | |
| Contact email for notifications or support | xxxx.xxxx@domain.com |
| Controls TLS certificate handling | true |
| Kubernetes pod affinity/anti‑affinity rules. Empty {} means pods can be scheduled anywhere. | &affinity {} |
| Simple mapping of labels > nodes. Empty {} means no node label constraints. | &nodeSelector {} |
| Allows pods to be scheduled onto tainted nodes. Empty [] means no special tolerations. | &tolerations [] |
SMTP configuration
cp-configs:
smtp:
smtpHost: smtp.gmail.com
smtpPort: "587"
smtpUsername: ""
smtpPassword: ""
smtpFromEmail: "noreplies@virtana.com"
smtpTlsInsecureSkipVerify: "false"The following table describes each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| SMTP server address | smtp.gmail.com |
| SMTP port | "587" |
| Authentication credentials for the SMTP server. | " " |
| Sender address for outgoing notification emails. | "noreplies@virtana.com" |
| "false" verifies TLS certificates | "false" |
GrowthBook configuration
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 each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| 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
cp-mongodb:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
migration:
enabled: true
persistence:
size: 50Gi
minio:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
persistence:
size: 20Gi
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 each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| MongoDB for control plane document storage. | 50 Gib |
| S3-compatible object storage for files and artifacts. | 20 Gib |
| Specifies the name of a pre-existing Persistent Volume Claim (PVC) that the Redis pod should use for data storage, instead of creating a new one. | "redis-data-controlplane-infra-redis-master-0" |
| Defines the storage capacity allocated to the Kafka controller's persistent volume. | 50 Gib |
| Controls pod scheduling rules that determine which Kubernetes nodes the PostgreSQL cluster pods are placed on. | *affinity |
| When set to | true |
| When set to | true |
| Time-series metrics database. Increase for long retention or high ingestion. RBAC is namespaced. | 100 Gib |
| Enables the SolrDB component. | true |
| EBS-backed Solr database for alert indexing. | 100 Gib |
| Disables the in‑chart Solr deployment. | false |
| The disk size for Solr. | 50 Gib |
| Zookeeper persistence volume size for Solr’s coordination service. | 20 Gib |
Private container registry override (optional)
Create a file named global-view-image-registry.yaml. For detailed information, see Overriding the Private Container Registry.
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 is performed in the following three phases: CRDs, infrastructure modules, and service modules. It ensures that all required custom resources, storage, messaging, and application services are created and upgraded in a controlled, dependency-aware order using the virtana-repo/virtana-global-view Helm chart.
See the detailed Global View deployment steps in Deploying Global View.
Verify the upgrade
To ensure Global View is accessible, perform the following steps:
Open your web browser and navigate to
https://<global_view_hostname>/ui. Replace<global_view_hostname>with the hostname you defined during configuration.Log in using the organizational email address and the password you created during registration.
If the UI loads and login succeeds, the upgrade is complete.