Global View virtual appliance

The OVA bundles the configuration below, so you don't need to modify it unless your environment requires customization. Provision a VM that meets these minimums.

Global View requires access to an SMTP (Simple Mail Transfer Protocol) server, and deployment validation fails if you don't provide valid details. The appliance uses SMTP to send user onboarding invitations, password reset messages, and alert and notification emails.

Gather the connection details for your existing SMTP server, including the host, port, sign-in credentials, and sender address. You provide these values during deployment, and the deployment process validates them to catch incorrect settings early.

DNS (Domain Name System) records map hostnames to the VM's IP address. They're required because the platform exposes several web-accessible services that each need a dedicated hostname. Create the following records, all pointing to the VM's IP address.

The OVA files are available on request, so contact Virtana Support to obtain them. You download the OVA along with a checksum file, then verify the download locally before you deploy. Verifying the checksum confirms that the file wasn't corrupted or altered in transit. For the file names and the verification command, see the Global View virtual appliance deployment guide.

How you supply container images depends on whether the VM has internet access and whether you use a private registry. Choose the option that matches your environment:

Deploy the OVA either through the vSphere Client interface or with the ovftool command-line tool. Because the OVA bundles the full Global View stack, including Keycloak for authentication and GrowthBook for feature management, deployments stay consistent across environments.

Nutanix provides a hyperconverged infrastructure (HCI) platform that can host the appliance, so you can standardize on HCI and reuse your environment. Upload and deploy the OVA from Prism Central, then power on and verify the VM from Prism Element.

KVM (Kernel-based Virtual Machine) is an open-source hypervisor built into the Linux kernel, which makes it a cost-effective option for Linux-based infrastructure. Download a KVM-specific package, adjust the VM definition to match your environment if the defaults don't fit, and then define and start the VM. After the VM starts, you connect to its console and find its IP address.

OpenShift Virtualization runs the appliance through KubeVirt, which lets you host the VM alongside your container workloads on OpenShift. Deployment involves creating a namespace, provisioning storage, uploading the disk images, and applying a VirtualMachine manifest before you start the VM. The VM is sized to match the OVA requirements: 12 CPU cores, 48 GB RAM, and separate root and data disks. After the VM is running, you reach it through the console or SSH, and you can optionally expose it externally with a LoadBalancer service.

After installation, connect to the VM over SSH with the default user virtana and password changeme. Change the default password immediately after the first sign-in in any production environment.

By default, the appliance uses DHCP (Dynamic Host Configuration Protocol). If DHCP isn't available in your environment, configure a static IP address instead. Gather the static IP address, default gateway, DNS server addresses, and DNS search domain from your network team, set them in the Netplan file, and then validate and apply the configuration. For the configuration file path and commands, see the Global View virtual appliance deployment guide.

Provide your deployment settings in a single configuration file on the VM before you install. These settings include your connectivity and registry choices, the four service hostnames (Keycloak, Global View, GrowthBook, and GrowthBook API), the tenant name and initial administrator details, the SMTP values, and the Helm chart versions to install. Optional settings configure the Virtana AI Copilot and the Remote Wisdom agent. Keep the registry settings at their defaults unless you use your own private registry.

Install Keycloak and Global View using the appliance's deploy script. You can install them together or separately, but you must install Keycloak before Global View, because Global View relies on Keycloak for authentication. Before you install, confirm that the Helm chart versions in your configuration file are current. For the install commands, see the Global View virtual appliance deployment guide.

After a successful deployment, you might not have received the initial admin registration email. To resolve this issue, first confirm that your SMTP settings are correct and that the SMTP test email arrived. Then check the user settings service logs for communication errors with the authorization service. If the logs confirm the failure, clean up the existing deployment and redeploy. For the log and redeploy commands, see the Global View virtual appliance deployment guide.

To upgrade, update the Helm chart versions in your configuration file to the latest versions in the Virtana Helm repository, then run the deploy script again. If the VM has no internet access and no private registry, you first obtain the latest image bundle from Virtana Support and copy it to the VM so the deploy script can extract it.

Direct OVA-to-OVA upgrades aren't supported. To move to a new OVA version, deploy a new VM from the latest OVA, and restore the data volumes from the previous one.

K3s is the Kubernetes distribution bundled in the appliance, and you upgrade it in place when a new stable release is available. Before you upgrade, check the current version and confirm that the cluster nodes and system pods are healthy. You then review the release notes for the target version, run the K3s upgrade, and verify the version and node health again.

K3s renews its TLS certificates automatically when you restart the service within 90 days of expiry, so most deployments need no manual action. These certificates secure communication between the control plane, the kubelet, and the cluster components. You can check expiration dates at any time, and you can rotate certificates manually if needed. Server and client certificates are valid for 365 days, the certificate authority (CA) certificate is typically valid for 10 years, and K3s raises a warning event within 90 days of expiry.

On KVM, understanding the network model helps you configure VM IP addresses, VLAN tagging, and DNS routing, and troubleshoot connectivity between the Global View VM, its internal Kubernetes pods, and external services such as DNS and SMTP.

The host Linux bridge acts as a software switch that connects VM interfaces directly to the host's physical network adapter, so VMs appear as first-class nodes on the physical network with full Layer 2 connectivity and no NAT (network address translation). A packet leaves the VM's interface, reaches the host through a virtual port on the bridge, and exits through the bridge's VLAN uplink to the physical switch.

For DNS traffic, both the VM and its K3s pods reach upstream DNS servers through the bridge and normal routing. VM-level requests route from the VM through the bridge to the physical network. Pod-level requests go through kube-proxy to the CoreDNS service and pod, then out through the VM's routing and the bridge. The bridge's Layer 2 connectivity lets pod DNS requests reach the upstream network without extra NAT.

The libvirt default network (virbr0) is an isolated, libvirt-managed network with built-in DHCP, DNS, and NAT, using the 192.168.122.0/24 range. Because it NATs VM traffic, external systems can't reach the VMs directly unless you configure port forwarding. Use virbr0 for testing or development only, and use the host Linux bridge for production setups where VMs need routable IP addresses.

The Global View OVA is a hardened, appliance-style VM with defined ownership boundaries between you and Virtana. The points below summarize the security baseline, upgrade and patch strategy, and shared responsibilities.

The security baseline is built on Ubuntu Server 22.04 LTS with CIS (Center for Internet Security) benchmark hardening applied at build time. Virtana provides CIS compliance reports (OpenSCAP) and vulnerability assessment reports (Lynis and Nessus) on request, with critical and high findings resolved before release. SSH access is intended only for bootstrapping and troubleshooting, and you aren't expected to modify the OS or Kubernetes. The bundled K3s cluster is fully managed by Virtana, so you don't perform Kubernetes hardening or lifecycle operations.

Application upgrades are delivered through Helm, which simplifies version management and rollback: the OVA is deployed once, and new releases arrive as upgrade bundles that you apply through the deploy script (air-gapped) or a direct Helm upgrade (with internet access). Virtana remediates vulnerabilities before release and, after deployment, through coordinated patching or remote access when the Remote Wisdom agent is enabled.

Responsibilities are split between you and Virtana as follows:

For deployment files, upgrade bundles, or questions about security, upgrades, or operations, contact Virtana Support. Operations outside the documented workflows can affect supportability.