Skip to main content

Deploying Global View on Virtana Platform

Global View is one of the core components of the Virtana Platform (VP). Global View provides a centralized, unified dashboard to monitor and manage performance across your entire infrastructure. It helps you gain visibility into distributed environments by consolidating insights from multiple sources into a single view.

Create a new Helm input file

The global-view-values.yaml file is required because it serves as the single source for your environment-specific configuration and secrets. Helm uses this file to deploy Global View's infrastructure and services, keeping these specific values separate from the generic chart defaults. This file defines settings, such as your database sizes, login credentials, and DNS hostnames.

global:
  controlplane:
    ingress:
      annotations:
        nginx.ingress.kubernetes.io/ssl-redirect: "false"
        nginx.ingress.kubernetes.io/force-ssl-redirect: "false"

  postgresql:
    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: " "

  public_dns_host_name: <GLOBAL_VIEW_HOSTNAME> 
  public_dns_host_am_suffix: -oc-<GLOBAL_VIEW_HOSTNAME>

  organization_details: 
    organization_name: "<TENANT_NAME>"
    first_name: " "
    last_name: " "
    contact_email: "xxxx.xxxx@domain.com"

  create_tls_selfsigned_certs: true
  affinity: &affinity {}
  nodeSelector: &nodeSelector {}
  tolerations: &tolerations []

cp-configs:
  smtp: # Provide SMTP details
    smtpHost: smtp.gmail.com
    smtpPort: "587"
    smtpUsername: ""
    smtpPassword: ""
    smtpFromEmail: "noreplies@virtana.com"
    smtpTlsInsecureSkipVerify: "false"

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: *tolerations

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:
    size: 50Gi
  imagePullSecrets:
    - name: dhi-reg-cred
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 256Mi

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: 16Gi

alerts-service:
  solrdb:
    enabled: false
    persistent_ebs:
      spec:
        resources:
          requests:
            storage: 100Gi
  solr:
    enabled: true
    persistence:
      size: 50Gi
    zookeeper:
      persistence:
        size: 20Gi

alerts-service:
  solr:
    securityContext:
      runAsUser: <user_id>
      runAsGroup: <group_id>
    podSecurityContext:
      fsGroup: <fsgroup_id>

    zookeeper:
      securityContext:
        runAsUser: <user_id>
        runAsGroup: <group_id>
      podSecurityContext:
        fsGroup: <fsgroup_id>

Global security parameters

These parameters allows you to access Global View and its interaction with your environment:

Table 1.

Field

Description

Default value

global.controlplane.ingress.annotations

Controls the behavior of the NGINX Ingress for the control plane.

nginx.ingress.kubernetes.io/ssl-redirect

Controls automatic HTTP to HTTPS redirection. The default value decides the outcome.

false

nginx.ingress.kubernetes.io/force-ssl-redirect

Diables all incoming traffic to be served via HTTPS.

false

global.postgresql

The PostgreSQL database backing the platform.

storage.size

Size of the persistent volume for PostgreSQL.

50 Gib

global.environment

Represents the deployment environment name or type.

app

global.secret_source

Specifies where secrets should come from.

valuesfile/none

global.storageClass

Default Kubernetes StorageClass name for PVCs.

&defaultStorageClass ""

If blank, use the default storageClass.

global.dockerRegistryCredentials

Credentials to pull container images from a Docker registry.

DOCKER_SERVER

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/

DOCKER_USERNAME

Private registry username.

"username"

DOCKER_PASSWORD

Private registry password

"password"

global.keycloak

Integrates the platform with a Keycloak identity provider.

keycloak.hostname

Public hostname where Keycloak is accessible

<KEYCLOAK_HOSTNAME>

adminUser and adminPassword

Credentials for the Keycloak admin account used to configure realms, clients, or users for this platform.

global.public_dns_host_name

Main DNS name for accessing the Virtana Global View UI.

<GLOBAL_VIEW_HOSTNAME>

global.public_dns_host_am_suffix

Suffix used to construct additional hostnames, likely for auxiliary or AM services.

-oc-<global_view_hostname>

global.organization_details

Metadata about the tenant or organization

organization_name

Tenant or company name

<TENANT_NAME>

first_name / last_name

Primary contact person

contact_email

Contact email for notifications or support

xxxx.xxxx@domain.com

global.create_tls_selfsigned_certs

Controls TLS certificate handling

true

affinity

Kubernetes pod affinity/anti‑affinity rules. Empty {} means pods can be scheduled anywhere.

&affinity {}

nodeSelector

Simple mapping of labels > nodes. Empty {} means no node label constraints.

&nodeSelector {}

tolerations

Allows pods to be scheduled onto tainted nodes. Empty [] means no special tolerations.

&tolerations []



SMTP parameters

These settings control the outgoing email, such as alerts or notifications.

Table 2.

Fields

Description

Default value

smtpHost

SMTP server hostname

smtp.gmail.com

smtpPort

SMTP port

"587"

smtpUsername / smtpPassword

Credentials for authenticating to SMTP

" "

smtpFromEmail

Sender address used in outgoing emails

"abcd1234@virtana.com"

smtpTlsInsecureSkipVerify

"false": TLS certificates are verified

"true": skip TLS verification

false/true



GrowthBook parameters

GrowthBook is typically used for feature flags and testing.

Table 3.

Fields

Description

Default values

ingress.enabled

Exposes GrowthBook via an Ingress

true

ingress.annotations.nginx.ingress.kubernetes.io/cors-allow-origin

Ensures that web apps loaded from this origin can call the GrowthBook API from browsers

"https://<GROWTH_BOOK_HOSTNAME>"

appOriginName

Hostname for the GrowthBook web UI

<GROWTH_BOOK_HOSTNAME>

apiHostName

Hostname for the GrowthBook API endpoint

<GROWTH_BOOK_API_HOSTNAME>

affinity, nodeSelector, tolerations

Reuse the global scheduling rules via YAML aliases



Storage and infrastructure component configuration

Configure the core storage and messaging services required for MongoDB, MinIO, Redis, Kafka, PostgreSQL, VictoriaMetrics, and Solr-based alerting components. This section defines capacity, persistence, and scheduling parameters to ensure reliable data retention, performance, and resilience across the platform.

Table 4.

Fields

Description

Default value

affinity, nodeSelector, tolerations

Uses the global scheduling policies

migration.enabled

Toggles MongoDB data migrations. If the customer is running GV version 2026121 or above, then this value must always be false.

false

persistence.size

Persistent storage allocated for MongoDB

50 Gib

minio.persistence.size

Size of the MinIO data volume

20 Gib

redis.master.persistence.size

Disk size for persistent Redis data

50 Gib

strimzi-kafka-operator.controller.persistence.size

Size of persistent volume used by the Strimzi controller

50 Gib

cloud-native-postgresql-cluster

Applies affinity rules to the Cloud Native PostgreSQL operator’s cluster resources

victoria-metrics-single

VictoriaMetrics is a time‑series database for metrics

rbac.create

Creates necessary RBAC (Roles/RoleBindings) for this component

true

rbac.namespaced

RBAC resources are namespaced instead of cluster‑wide

true

server.size

Persistent volume size for VictoriaMetrics

100 Gib

alerts-service.solrdb.enabled

Enables the SolrDB component

true

persistent_ebs.spec.resources.requests.storage

Size of the underlying persistent volume

100 Gib

alerts-service.solr.enabled

Disables the in‑chart Solr deployment

false

persistence.size

The disk size for Solr

50 Gib

zookeeper.persistence.size

Zookeeper persistence volume size for Solr’s coordination service

20 Gib



Overriding the private container registry

By default, the deployment process pulls container images from Virtana's official Docker registry. However, your organization might require you to use a private or internal container registry to comply with security policies or to manage network traffic.

If you choose to use a private registry as an optional setting, you must create a configuration file that tells the system where to find the images for various services, such as Redis, Minio, and Virtana AI components.

Note

This setting is needed only in case you want to use your own container image registry instead of Virtana's official Docker registry.

To redirect the image pull requests to your private repository, follow these steps:

  1. Create a new file named global-view-image-registry.yaml in your local deployment directory.

  2. Copy the following code into the file:

    global:
      image_registry: <REGISTRY_NAME>     
      imageRegistry: <REGISTRY_NAME>     
    
    growthbook:
      image:
        repository: <REGISTRY_NAME>/growthbook
    
    redis:
      image:
        repository: <REGISTRY_NAME>/redis
    
    cloudnative-pg:
      image:
        repository: <REGISTRY_NAME>/cloudnative-pg
    
    cloud-native-postgresql-cluster:
      image:
        registry: <REGISTRY_NAME>
    
    strimzi-kafka-operator:
      defaultImageRegistry: <REGISTRY_NAME>
    
    minio:
      image:
        repository: <REGISTRY_NAME>/minio
      mcImage:
        repository: <REGISTRY_NAME>/mc
    
    cp-mongodb:
      image:
        registry: <REGISTRY_NAME>
    
    cp-metrics-service:
      victoria-metrics-single:
        server:
          image:
            repository: <REGISTRY_NAME>/victoria-metrics
    
    alerts-service:
      solr:
        image:
          registry: <REGISTRY_NAME>
        zookeeper:
          image:
            registry: <REGISTRY_NAME>/bitnamilegacy

    The following table describes each field in the configuration file. Replace every instance of <REGISTRY_NAME> with the URL of your private container registry.

    Table 5.

    Fields

    Description

    Default value

    global.image_registry

    Base registry used by charts/components that reference this key for Virtana-maintained images.

    <REGISTRY_NAME>

    global.imageRegistry

    Base registry for upstream/open-source images consumed by the stack.

    <REGISTRY_NAME>

    growthbook.image.repository

    The full repository path for the GrowthBook image.

    <REGISTRY_NAME>/growthbook

    redis.image.repository

    Repository for the Redis server image used by the deployment.

    <REGISTRY_NAME>/redis

    cloudnative-pg.image.repository

    The full image repository path for the CloudNativePG operator image.

    <REGISTRY_NAME>/cloudnative-pg

    cloud-native-postgresql-cluster.image.registry

    The registry hostname where the PostgreSQL cluster images are hosted.

    <REGISTRY_NAME>

    strimzi-kafka-operator.defaultImageRegistry

    The default registry used for all Kafka-related images pulled by Strimzi.

    <REGISTRY_NAME>

    minio.image.repository

    Repository for the MinIO server image.

    <REGISTRY_NAME>/minio

    minio.mcImage.repository

    Repository for the MinIO Client (mc) image used for bucket/user/ILM automation.

    <REGISTRY_NAME>/mc

    cp-mongodb.image.registry

    The registry hostname for the MongoDB container image.

    <REGISTRY_NAME>

    cp-metrics-service.victoria-metrics-single.server.image.repository

    Repository for the VictoriaMetrics single-node image backing the control-plane metrics service.

    <REGISTRY_NAME>/victoria-metrics

    alerts-service.solr.image.registry

    The registry hostname for the Apache Solr image, used for search in the alerts pipeline.

    <REGISTRY_NAME>

    alerts-service.solr.zookeeper.image.registry

    The registry hostname for the ZooKeeper image used by Solr for coordination.

    <REGISTRY_NAME>/bitnamilegacy



  3. Replace every instance of <REGISTRY_NAME> with your actual registry URL, for example, <registry.mycompany.com/virtana>.

  4. Save the file.

Note

When you run your Helm installation or upgrade command, you must include this file using the -f flag to apply your overrides:  -f global-view-image-registry.yaml.

Deploying Global View

The deployment process is divided into three main phases: deploying Custom Resource Definitions (CRDs), deploying infrastructure modules, and deploying service modules. You can perform these steps using the Helm CLI, Argo CD, or Terraform.

Update your Helm repository to ensure you have the latest version of the Virtana charts:

helm repo update
helm search repo virtana-repo/virtana-global-view

Deploying Global View on an OpenShift Kubernetes cluster

OpenShift enforces strict Security Context Constraints (SCCs) that control which user and group IDs a container is allowed to run as. Before deploying GlobalView, you must configure the security contexts for each service so that the IDs fall within the range permitted by your target OpenShift cluster.

Before you begin, obtain the following values from your OpenShift cluster administrator:

  • <user_id>: A numeric user ID (UID) that is within the allowed UID range for your OpenShift project or namespace.

  • <group_id>: A numeric group ID (GID) within the allowed GID range.

  • <fsgroup_id>: A numeric supplemental group ID used to set ownership of mounted volumes, also within the allowed range.

Note

You can find the allowed UID or GID ranges by inspecting the namespace annotation. Run the following command:

oc describe namespace <your-namespace> | grep sa.scc

Perform the following steps:

  1. Open your global-view-values.yaml file in a text editor.

  2. Add the following security context configuration, replacing <user_id>, <group_id>, and <fsgroup_id> with the values obtained from your cluster administrator:

    redis: 
      securityContext:
        runAsUser: <user_id>    
        runAsGroup: <group_id>
        fsGroup: <fsgroup_id>
    
    strimzi-kafka-operator:
      podSecurityContext:
        fsGroup: <fsgroup_id>
      securityContext:
        runAsUser: <user_id>
        runAsGroup: <group_id>
    
    cp-mongodb:
      securityContext:
        runAsUser: <user_id>    
        runAsGroup: <group_id>
      podSecurityContext:
        fsGroup: <fsgroup_id>
    
    minio:
      securityContext:
        runAsUser: <user_id>    
        runAsGroup: <group_id>
        fsGroup: <fsgroup_id>    
    
    cloudnative-pg:
      containerSecurityContext:
        runAsUser: <user_id>
        runAsGroup: <group_id>
      podSecurityContext:
        fsGroup: <fsgroup_id>

    The following table describes the security context parameters used across each service:

    Table 6.

    Parameter

    Description

    runAsUser

    The numeric user ID that the container process runs.

    runAsGroup

    The primary numeric group ID assigned to the container process.

    fsGroup

    A supplemental group ID is applied to all mounted volumes.



    The following table shows which security context parameters apply to each service:

    Table 7.

    Service

    runAsUser

    runAsGroup

    fsGroup

    Description

    redis

    All three parameters are set under a single securityContext block.

    strimzi-kafka-operator

    runAsUser and runAsGroup are set under securityContext (container-level), while fsGroup is set separately under podSecurityContext (pod-level).

    cp-mongodb

    Similar to Strimzi, container-level and pod-level contexts are split across securityContext and podSecurityContext.

    minio

    All three parameters are set under a single securityContext block.

    cloudnative-pg

    Uses containerSecurityContext for runAsUser and runAsGroup, and podSecurityContext for fsGroup.



    Important

    If any value is missing or falls outside the allowed range, OpenShift rejects the pod, and it fails to start.

  3. Save the file.

Deploy Custom Resource Definitions (CRDs)

CRDs define the unique object types that Global View uses within your Kubernetes cluster. You must install these before the other modules.

You can deploy CRDs using three different methods. Choose the one that matches your application environment.

Run the following command in your terminal:

helm upgrade --install controlplane-crds virtana-repo/virtana-global-view \
  --namespace controlplane --create-namespace \
  --set tags.crds=true -f global-view-values.yaml \
  --version <LATEST_VERSION>

Create a file named virtana-cp-crds.yaml and apply it to your Argo CD controller. Ensure you set the tags.crds parameter to true.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: virtana-cp-crds
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: "https://kubernetes.default.svc"
    namespace: controlplane
  source:
    chart: virtana-global-view
    repoURL: "https://virtana.gitlab.io/helm-charts/"
    targetRevision: <LATEST_VERSION>
    helm:
      releaseName: controlplane-crds
      parameters:
        - name: "tags.crds"
          value: "true"      
      values: |
        <contents of global-view-values.yaml>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Define a helm_release resource in your Terraform configuration (for example, virtana-cp-crds.tf). Set the tags.crds value to true.

resource "helm_release" "cp-crds" {
  create_namespace = true
  chart            = "virtana-global-view"
  name             = "controlplane-crds"
  namespace        = "controlplane"
  repository       = "https://virtana.gitlab.io/helm-charts"
  version          = var.helm_version
  timeout          = 1200
  wait             = true

  set {
    name  = "tags.crds"
    value = "true"
  }
}

Deploy infrastructure modules

Infrastructure modules include the backend components that Global View relies on, such as databases and messaging queues (for example, Kafka and PostgreSQL).

You can deploy infrastructure modules using three different methods. Choose the one that matches your application environment.

Run the following command in your terminal:

helm upgrade --install controlplane-infra virtana-repo/virtana-global-view \
  --namespace controlplane --create-namespace \
  --set tags.infra=true -f global-view-values.yaml \
  --version <LATEST_VERSION>

Once the command completes, verify that all infrastructure pods are in a Running and Ready state before proceeding:

watch kubectl get pods -n controlplane

Create a file named virtana-cp-infra.yaml. In the values section, include the full contents of your global-view-values.yaml file and set tags.infra to true.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: virtana-cp-infra
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: "https://kubernetes.default.svc"
    namespace: controlplane
  source:
    chart: virtana-global-view
    repoURL: "https://virtana.gitlab.io/helm-charts/"
    targetRevision: <LATEST_VERSION> # Provide latest version
    helm:
      releaseName: controlplane-infra
      parameters:
        - name: "tags.infra"
          value: "true"
      values: |
        <contents of global-view-values.yaml>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

In your virtana-cp-infra.tf file, use a templatefile function to pass your environment variables (like passwords and hostnames) into the Helm release.

resource "helm_release" "cp-infra" {
  create_namespace = true
  chart            = "virtana-global-view"
  name             = "controlplane-infra"
  namespace        = "controlplane"
  repository       = "https://virtana.gitlab.io/helm-charts"
  version          = var.helm_version
  timeout          = 1200
  wait             = true
  values = [
    templatefile("${path.module}/../values/controlplane-values.yaml", {
      storage_class             = var.storageclass
      docker_password           = var.docker_password
      docker_username           = var.docker_username
      keycloak_hostname         = var.keycloak_hostname
      keycloak_password         = var.keycloak_password
      keycloak_username         = var.keycloak_username
      global_view_hostname      = var.global_view_hostname
      tenant_name               = var.tenant_name
      user_first_name           = var.user_first_name
      user_last_name            = var.user_last_name
      user_email                = var.user_email
      smtp_from_mail            = var.smtp_from_mail
      smtp_password             = var.smtp_password
      smtp_port                 = var.smtp_port
      smtp_server               = var.smtp_server
      smtp_to_mail              = var.smtp_to_mail
      smtp_username             = var.smtp_username
      growthbook_hostname       = var.growthbook_hostname
      growthbook_api_hostname   = var.growthbook_api_hostname
    })
  ]

  set {
    name  = "tags.infra"
    value = "true"
  }
}

Deploy service modules

The final step is to deploy the service modules. These are the functional applications that provide the user interface and API for Global View.

You can deploy service modules using three different methods. Choose the one that matches your application environment.

Run the following command in your terminal:

helm upgrade --install controlplane-service virtana-repo/virtana-global-view \
  --namespace controlplane --create-namespace \
  --set tags.service=true -f global-view-values.yaml \
  --version <LATEST_VERSION>

Create a file named virtana-cp-service.yaml. Similar to the infra step, include your values file and set the tags.service parameter to true.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: virtana-cp-service
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: "https://kubernetes.default.svc"
    namespace: controlplane
  source:
    chart: virtana-global-view
    repoURL: "https://virtana.gitlab.io/helm-charts/"
    targetRevision: <LATEST_VERSION> # Provide latest version
    helm:
      releaseName: controlplane-service
      parameters:
        - name: "tags.service"
          value: "true"
      values: |
        <contents of global-view-values.yaml>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Configure the virtana-cp-service.tf resource. Ensure all SMTP and Keycloak variables are correctly mapped so that the services can communicate and send notifications.

resource "helm_release" "cp-service" {
  create_namespace = true
  chart            = "virtana-global-view"
  name             = "controlplane-service"
  namespace        = "controlplane"
  repository       = "https://virtana.gitlab.io/helm-charts"
  version          = var.helm_version
  timeout          = 1200
  wait             = true
  values = [
    templatefile("${path.module}/../values/controlplane-values.yaml", {
      storage_class             = var.storageclass
      docker_password           = var.docker_password
      docker_username           = var.docker_username
      keycloak_hostname         = var.keycloak_hostname
      keycloak_password         = var.keycloak_password
      keycloak_username         = var.keycloak_username
      global_view_hostname      = var.global_view_hostname
      tenant_name               = var.tenant_name
      user_first_name           = var.user_first_name
      user_last_name            = var.user_last_name
      user_email                = var.user_email
      smtp_from_mail            = var.smtp_from_mail
      smtp_password             = var.smtp_password
      smtp_port                 = var.smtp_port
      smtp_server               = var.smtp_server
      smtp_to_mail              = var.smtp_to_mail
      smtp_username             = var.smtp_username
      growthbook_hostname       = var.growthbook_hostname
      growthbook_api_hostname   = var.growthbook_api_hostname
    })
  ]

  set {
    name  = "tags.service"
    value = "true"
  }
}

Verifying the deployment

Once all three phases are complete, check the status of your pods in the controlplane namespace:

kubectl get pods -n controlplane

All pods should show a status of Running or Completed.

Finalizing your Global View setup

Once the deployment process is complete, you must register your organization and verify that the system is running correctly. You can also configure optional features like Virtana AI or advanced database settings.

Complete registration

After the Helm charts finish installing, the system automatically sends a registration email.

  1. Look for an email sent to the address you provided in the global.organization_details.contact_email field of your global-view-values.yaml file.

  2. Click the link in the email to set your password and complete the account setup.

Verify the installation

To ensure Global View is accessible, perform the following steps:

  1. Open your web browser and navigate to https://<global_view_hostname>/ui. Replace <global_view_hostname> with the hostname you defined during configuration.

  2. Log in using the organizational email address and the password you created during registration.

Adding additional tenants (optional)

Global View supports multi-tenancy, allowing you to manage multiple isolated organizations from a single control plane. To add a new tenant, use a curl command to send a request to the Organization Service.

To add a tenant, perform the following steps:

  1. Run the following command in your terminal, replacing the placeholders with your specific tenant details:

    curl --location 'https://<global_view_hostname>/organization' \
    --header 'Content-Type: application/json' \
    --data-raw '{
        "name": "<TENANT_NAME>",
        "contactName": "Administrator Name",
        "contactEmail": "admin.email@example.com",
        "licenseType": "Professional",
        "licenseModule": "ipm",
        "createSFDCArtifacts": true,
        "utmCodes": {
            "utm_source": "website",
            "utm_medium": "try Virtana",
            "utm_campaign": "perpetual"
        }
    }'

    The output of this command will contain a unique OrgID.

  2. Save this ID for your records, as you will need it for tenant-specific configurations.

Advanced configuration options (optional)

You can further customize your deployment by modifying the global-view-values.yaml file. After making changes, you need to re-run the appropriate Helm upgrade command depending on which component the configuration affects. Run the services upgrade command after Virtana AI is enabled, and run the infra upgrade command after configuring the SolrDB setting.

Enable Virtana AI (Copilot Chatbot)

Virtana AI is a chatbot that helps you interact with documentation, query alerts, and generate policies using natural language. Refer Setting up the Virtana AI Copilot Chatbot for more details.

Global View and IO MCP integration

IO MCP details, such as endpoint and API key, should be provided to the Global View virtana-ai service using the below values. Add the following config to the global-view-values.yaml file:

cp-configs:
  iomcpsecret:
    io_mcp_endpoint: '{"<tenant-id>": {"<instance-name>": {"url": "https://<io-server>/api/sdk/mcp/", "headers": {"Authorization": "Bearer <your-io-token>"}}}}'

Replace the placeholder values as follows:

Table 8.

Placeholder

Description

<tenant-id>

Your tenant identifier.

<instance-name>

A name for the target IO instance.

<io-server>

The hostname of the IO server.

<your-io-token>

A valid API bearer token.



Refer to Virtana’s Model Context Protocol Server for more details.

Configure Solr database settings

Global View uses Solr to manage alert data. You can choose between a simple standalone setup or a high-availability SolrCloud setup.

  • Standalone SolrDB (Default): Select this for smaller environments or testing.

    alerts-service:
      solrdb:
        enabled: true

    Note

    Following configration is already hardcoded, and Standalone SolrDB is deployed by default. No additional changes needed.

  • SolrCloud (Multi-Node): Select this for production environments that require better performance.

    alerts-service:
      solrdb:
        enabled: false
      solr:
        enabled: true
    
      ## Set this to true, if you want to maintain one collection per Tenant.
      solrCollectionPerTenant: false
    
      ## Set this to true, if you are running Standalone SolrDB and want to migrate to SolrCloud
      solrMigrationenable: false

    Fields

    Default value

    Description

    solrCollectionPerTenant

    false/true

    Set this to true if you want to maintain one collection per Tenant.

    solrMigrationenable

    false/true

    Set this to true if you are running Standalone SolrDB and want to migrate to SolrCloud.

Remove a cluster

Global View is the control plane. It doesn't generate any data on its own. It aggregates alerts, metrics, topology, and inventory from downstream data sources, such as IO instances and CO clusters. If you don't register at least one cluster or IO instance, Global View has nothing to display. To remove a registered cluster from Global View, use the organization-service pod.

To remove a registered cluster, complete the following steps:

  1. Enter the pod shell:

    kubectl exec -it deploy/organization-service -n controlplane -- sh
  2. Set your variables and run the delete request:

    REALM_NAME=" "
    CLUSTER_NAME=" "
    
    curl -k -sS --request DELETE --location \
    "http://organization-service-svc.controlplane.svc.cluster.local:5000/internal/organization/${REALM_NAME}/sources/${CLUSTER_NAME}?type=oc"
  3. Type exit to return to your local terminal.