Global View virtual appliance deployment

An OVA (Open Virtual Appliance) is a pre-packaged virtual machine file used to deploy software in virtualized environments like VMware ESXi. The Virtana Global View application is distributed as an OVA file, such as virtana-k8s-xxxx.ova, allowing you to deploy the entire platform as a ready-to-use virtual appliance.

The configuration below is bundled with the OVA. No manual modification is needed unless your environment requires customization.

SMTP (Simple Mail Transfer Protocol) is the standard Internet protocol used for sending emails between servers. SMTP configuration is mandatory for Global View deployment. The deployment validation will fail if valid SMTP details are not provided. SMTP configuration is mandatory for Global View deployment to enable email-based functionality, including user onboarding invitations, forgot password/password reset emails, and alert and notification emails.

Gather the following details from your existing SMTP server before beginning deployment:

These values must be provided during Global View deployment in the input.env file. The deployment process validates the SMTP configuration to help prevent application setup failures caused by incorrect SMTP settings.

DNS (Domain Name System) records are entries in a DNS server that map human-readable domain names (like globalview.example.com) to machine-readable IP addresses (like 192.168.1.10) or other domain names. DNS records are required for deployment because the platform exposes multiple web-accessible services that must each be reachable through a dedicated hostname.

Create the following DNS records, all pointing to the VM's IP address:

The OVA files are available on demand. Contact Virtana Support if you'd like to try it out.

Files to download:

After downloading, verify the integrity of the OVA locally.

Run the command in your local environment.

sha256sum -c virtana-k8s-xxxx.ova.sha256

Expected output:

virtana-k8s-xxxx.ova: OK

The approach depends on whether the VM has internet access and whether you have a private registry.

Perform the following steps to deploy Global View using OpenShift Virtualization:

SSH into the VM using the default credentials:

Username: virtana
Password: changeme

You can change the default password immediately after the first login in any production environment.

By default, the appliance VM is configured to use DHCP (Dynamic Host Configuration Protocol) networking. If DHCP-based IP address allocation is not available in your environment, you can configure a static IP address by following the steps below.

su -
vim.tiny /etc/netplan/00-installer-config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens192:
      dhcp4: false
      addresses:
        - <STATIC_IP_ADDRESS>/24
      routes:
        - to: default
          via: <DEFAULT_GATEWAY>
      nameservers:
        search:
          - <example.com>
        addresses:
          - <DNS_SERVER_01>
          - <DNS_SERVER_02>

Ensure that all required inputs are provided in the file located at /home/virtana/input.env on the VM. Below is the sample configuration:

CONNECTIVITY_TO_INTERNET='yes'
IMAGE_REGISTRY='localhost:5000'         
DOCKER_SERVER='https://index.docker.io/v2/'  
DOCKER_USERNAME='freeops'
DOCKER_PASSWORD='8Ua9d6uxBjQ!P@WK'
KEYCLOAK_HOSTNAME='example-keycloak.example.com'
GLOBAL_VIEW_HOSTNAME='example-globalview.example.com'
GROWTHBOOK_HOSTNAME='example-growthbook.example.com'
GROWTHBOOK_API_HOSTNAME='example-growthbook-api.example.com'
TENANT_NAME='xxxxx'                     
INITIAL_ADMIN_USER_FIRSTNAME='xxxxx'
INITIAL_ADMIN_USER_LASTNAME='xxxxx'
INITIAL_ADMIN_USER_EMAIL='xxxxx.xxxxx@xxxxx.com'

SMTP_CHECK_ENABLED='true'
SMTP_HOST='smtp.xxxxx.com'
SMTP_PORT='587'
SMTP_USERNAME='xxxxx'
SMTP_PASSWORD='xxxxx'
SMTP_FROM_EMAIL='noreplies@xxxxx.com'
CO_NORTH_HELM_VERSION='xxxx.x.x'
GLOBAL_VIEW_HELM_VERSION='xxxx.x.x'

VIRTANA_AI_MODEL_PROVIDER=''
VIRTANA_AI_API_KEY=''
VIRTANA_AI_INFERENCE_ENDPOINT=''

ENABLE_REMOTE_WISDOM='no'
THINGWORX_PLATFORM_URL=''             
THINGWORX_AGENT_MODEL=''               

The following table describes each field in the configuration file.

Do not change the values of IMAGE_REGISTRY and DOCKER_SERVER unless using your own private registry.

Run these commands from the OVA VM to find the latest available Helm chart versions for CO_NORTH_HELM_VERSION (Helm chart version for the Container Observability backend component) and GLOBAL_VIEW_HELM_VERSION:

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

The OPENAI_API_KEY is not required for initial setup. See the Configure LLM Provider for Virtana AI for instructions on generating one when needed.

Both Keycloak and Global View must be installed. You may install them together or sequentially.

Keycloak must be installed before Global View. If installing separately, always run Keycloak first.

Ensure that the values for CO_NORTH_HELM_VERSION and GLOBAL_VIEW_HELM_VERSION in the input.env file are updated to the latest versions available in the Virtana Helm repository.

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

Additionally, if you need to override or customize any Helm chart configuration, you can modify the values.yaml file before deployment.

To override any Helm chart configuration, modify the values templates before deployment:

ls -l /home/virtana/templates/

The following table shows the actions and the respective commands:

After a successful Global View deployment, the initial admin registration email may not be received even though SMTP is correctly configured and validated. This can occur when the user-settings-service fails to communicate with the authorization-service during the initial setup sequence.

You may view the following symptoms:

A transient inter-service communication failure may occur during the initial deployment, where the user-settings-service is unable to reach the authorization-service. The following error in the user-settings-service logs confirms this issue:

{"level":"error","service":"user-settings-service","error":"Post \"http://authorization-service-svc:5000/internal/authorization/oauth/authorize\": dial tcp 10.43.52.101:5000: connect: connection refused","method":"POST","url":"http://authorization-service-svc:5000/internal/authorization/oauth/authorize","message":"Failed to handle http request."}

If the registration email is not received after a fresh deployment, perform the following steps:

Ensure that the GLOBAL_VIEW_HELM_VERSION and CO_NORTH_HELM_VERSION (optional) values in the input.env file are updated to the latest versions available in the Virtana Helm repository.

Run the following commands to get the latest available version.

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

(Optional) This action is required if any of the following conditions apply:

Perform the steps to use the image bundle:

The following table shows the respective commands to upgrade both Keycloak and Global View:

Direct OVA-to-OVA upgrades are not supported. To move to a new OVA version, deploy a new VM from the latest OVA and back up and restore the data volumes from the previous OVA. The backup and restore flow is to be tested and validated.

Check the Current K3s Version and the node's health. To display the current Kubernetes version managed by K3s and the node's health, run the following commands in your terminal:

sudo k3s kubectl version
sudo k3s kubectl get nodes
sudo k3s kubectl get pods -n kube-system

Find the latest stable K3s version. To determine the latest stable K3s release available, run the following commands:

curl -s https://update.k3s.io/v1-release/channels | jq -r '.data[] | select(.id == "stable") | .latest'

Review the K3s release notes for version-specific considerations.

curl -sfL https://get.k3s.io | sudo INSTALL_K3S_VERSION="<<K3s_VERSION>>" INSTALL_K3S_EXEC="--flannel-backend=none --disable traefik --disable servicelb --write-kubeconfig-mode 644" sh -s -

sudo k3s kubectl version
sudo k3s kubectl get nodes
sudo k3s kubectl get pods -n kube-system

sudo k3s certificate check --output table

sudo k3s certificate rotate
sudo systemctl restart k3s

KVM - VM Networking defines hosting of VMs on a KVM hypervisor to communicate with the underlying host, physical network, and external services. Understanding this networking model helps you correctly configure VM IP addresses, VLAN tagging, and DNS routing, as well as troubleshoot connectivity issues between the GV VM, its internal Kubernetes pods, and external services such as DNS, SMTP, or upstream APIs.

Host Linux bridge

The host Linux bridge acts as a software switch, connecting VM network interfaces directly to the host's physical NIC. This allows VMs to appear as first-class nodes on the physical network, enabling full Layer 2 connectivity without NAT.

The following diagram illustrates the traversal of network packets through the host’s physical NIC, VLAN interfaces, and bridges before reaching the VM, and how traffic originating from the VM flows back to the external network.

Packet flow

• Inside the VM, a packet leaves eth0 and hits the host's vnetX via a tap/virtual link.

• vnetX is a port on Bridge-60 that forwards traffic into the bridge.

• Bridge-60 routes external traffic out via its uplink enp7s0.60 (VLAN 60 sub-interface).

• enp7s0.60 tags/untags VLAN 60 on the way to the physical NIC enp7s0, which puts bits on the wire.

DNS traffic flow

Understanding the DNS traffic path is important for troubleshooting name resolution issues, validating network connectivity, and ensuring that both the VM and its workloads (running on K3s) can reliably reach upstream DNS services through the configured bridge network.

VM-level DNS resolution path

Even though the VM subnet is 10.10.60.0/23, DNS servers at 10.10.2.6/7 are reachable through normal routing:

GV VM (10.10.60.101) -> vnet12 (tap) -> Bridge-60 -> enp7s0.60 -> physical switch/router -> DNS (10.10.2.6/7)
Return: 10.10.2.6 -> router -> VLAN 60 -> enp7s0.60 -> Bridge-60 -> vnet12 -> VM

So VM and host are both just regular nodes on 10.10.60.0/23 that can reach DNS at 10.10.2.6/7 through routing.

Pod-level DNS resolution path

Inside the GV VM running K3s (pod CIDR: 10.43.0.0/16, CoreDNS service: 10.43.0.10):

Pod (10.43.A.B) -> kube-proxy/iptables -> CoreDNS service (10.43.0.10) -> CoreDNS pod
-> GV VM kernel routing -> vnet12 -> Bridge-60 -> enp7s0.60 -> physical switch/router -> External DNS
Return: External DNS -> router -> VLAN 60 -> enp7s0.60 -> Bridge-60 -> vnet12 -> GV VM -> CoreDNS pod -> kube-proxy -> Pod

GV VM's first-class L2 connectivity via Bridge-60 ensures pod DNS requests reach the upstream network without additional NAT.

VM -> vnet -> virbr0 (DHCP + NAT) -> Host NIC -> Switch -> Internet

This section outlines the security baseline applied at image build time, the supported upgrade and patching strategies, and the operational responsibilities shared between you and Virtana. You can refer to this section to understand the boundaries of supported operations.

The following enhancements are planned and do not impact the current support model:

GV OVA is supported as a managed, hardened virtual appliance. Operations outside the documented and supported workflows may impact supportability. For questions related to security posture, upgrades, or operations, contact Virtana Support.

Review the following guidelines before you upgrade a Global View OVA:

The deploy.sh script included in Global View OVA versions earlier than 2026.6.1 does not include the configuration changes introduced in Global View 2026.6.1. As a result, upgrades from earlier OVA versions to 2026.6.1 do not correctly update the image registry configuration and the Helm deployment options required for the following components:

Before you run deploy.sh during the upgrade, apply the following updates to the existing script.

Update the Helm version variables and the VirtanaAI (Copilot) configuration in the input.env file before you run the upgrade.

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

# Supported values: 
# OPENAI / GEMINI / LITELLM VIRTANA_AI_MODEL_PROVIDER='' 
# API key for OPENAI, GEMINI, or LITELLM VIRTANA_AI_API_KEY='' 
# Leave blank when using OPENAI or GEMINI. 
# For self-hosted LiteLLM deployments, 
# provide the LiteLLM endpoint URL. 
# Example: https://litellm.example.com VIRTANA_AI_INFERENCE_ENDPOINT='' 

This step is required if any of the following conditions apply:

To use the image bundle:

You can customize the deployment by editing the Helm values template files before you upgrade. The template files are in /home/virtana/templates/ :

 ls -l /home/virtana/templates/ 

Update the appropriate values file to override the default configuration, such as resource requests and limits, storage settings, ingress configuration, node scheduling preferences, or application-specific parameters.

After you patch deploy.sh , update input.env , and adjust the Helm values, run the deployment script to upgrade Keycloak and Global View. To upgrade only Global View, upgrade Keycloak first, then Global View.