Global View virtual appliance deployment

The Global View virtual appliance is delivered as an OVA (Open Virtualization Appliance) package that ships as a pre-configured, self-contained VM to simplify deployment and reduce operational overhead. Instead of manually installing and configuring each component, you deploy a single OVA that includes everything needed to run Global View out of the box.

The following components are pre-installed and configured. No manual setup required.

Component	Role
K3s	Lightweight, CNCF-certified Kubernetes distribution running Global View microservices.
Helm	Kubernetes package manager used to deploy and manage application components.
Docker	Container runtime for building and managing container images.

If you are deploying the Virtana Infrastructure Observability (IO) OVA, see IO Virtual Edition Guide.

Virtual appliance deployment prerequisites

Before deploying the Virtana Global View virtual appliance, you must complete the following prerequisites outlined in this document. Each step is critical to ensuring a successful deployment.

OVA resource requirements

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.

Table 24.

Configuration parameter	Configuration
Compatibility	ESXi 6.5 and later
Guest OS	Ubuntu 64-bit (Linux)
CPU	12 vCPUs
Memory	48 GB RAM
Disk 01 (root volume)	200 GB (Thin Provision)
Disk 02 (Virtana data)	300 GB (Thin Provision)
SCSI Controller	VMware Paravirtual
Network Adapter Type	VMXNET3

SMTP configuration

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:

Parameter	Description
`SMTP_HOST`	SMTP server hostname or IP address
`SMTP_PORT`	SMTP server port (typically 25, 587, or 465)
`SMTP_USERNAME`	SMTP authentication username
`SMTP_PASSWORD`	SMTP authentication password
`SMTP_FROM_EMAIL`	Sender email address

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 records

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:

Table 25.

Service	Purpose	Example Hostname
Keycloak	An open-source identity and access management, SSO, and user authentication	`example-keycloak.example.com`
GlobalView	Main application dashboard	`example-globalview.example.com`
GrowthBook	An open-source platform for feature flagging (controls GV feature rollout)	`example-growthbook.example.com`
GrowthBook API	GrowthBook API endpoint	`example-growthbook-api.example.com`

Download and verify the OVA

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

Files to download:

virtana-k8s-xxxx.ova
virtana-k8s-xxxx.ova.sha256

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

Download the image bundle (Optional)

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

Internet access - no private registry

Images will be automatically pulled from the Docker Hub Virtana registry. No additional steps required. Proceed to install applications.

Internet access - with private registry

Perform the steps:

Download the image list text file from Virtana Egnyte.
Pull images on an internet-connected machine and push them to your private registry.
Update the IMAGE_REGISTRY and DOCKER_SERVER variables in the input file input.env to point to your private image registry:
```
CONNECTIVITY_TO_INTERNET='yes'
IMAGE_REGISTRY='custom-registry:8443'
DOCKER_SERVER='https://custom-registry:8443/'
```

No internet access - with private registry

Perform the steps:

Download the image list text file gv-images-list.txt, from Virtana Egnyte.
Pull images on an internet-connected machine and push them to your private registry.
Download Helm charts from Egnyte and place them in /home/virtana/helm-charts/ on the VM.
Update the IMAGE_REGISTRY and DOCKER_SERVER variables in the input file input.env to point to your private image registry:
```
CONNECTIVITY_TO_INTERNET='no'
IMAGE_REGISTRY='custom-registry:8443'
DOCKER_SERVER='https://custom-registry:8443/'
```

No internet access - without private registry

Perform the steps:

Download the image bundle from virtana-global-view-<GV_VERSION>-images-bundle.tgz from Egnyte.
Copy the bundle to /opt/virtana on the Virtana OVA VM.
Do not extract the bundle manually. The deploy script handles extraction automatically.
Set in CONNECTIVITY_TO_INTERNET='no' in input.env.

Virtual appliance installation

Select the hypervisor platform you are deploying to:

VMware vCenter -
Nutanix
KVM
OpenShift Virtualization

Deploy OVA in VMware vCenter

Deploying the OVA in VMware vCenter is a critical step when setting up the Virtana Global View Virtual Appliance. The OVA serves as a pre-packaged, self-contained virtual machine that bundles the entire Global View application stack, including Keycloak (authentication), GrowthBook (feature management), and the main dashboard, into a single deployable unit. This approach ensures consistent, error-free deployments by eliminating manual OS and software configuration.

Deploy using either the VMware vSphere Client UI or the following ovftool CLI:

./ovftool --X:logFile=ovftool-log.txt \
  --X:logLevel=verbose --acceptAllEulas \
  --name="virtana-globalview" \
  --datastore="ds01" \
  --network="dv-net-xx" \
  --diskMode=thin \
  --vmFolder="testfolder" \
  ./virtana-k8s-xxxx.ova \
  vi://${USERNAME}:${PASSWORD}@${vCENTER_HOSTNAME}/<DATACENTER>/host/<COMPUTE_CLUSTER>/

This is a sample of the ovftool command. Modify parameters as needed.

Deploy OVA in Nutanix

Deploying the OVA in Nutanix is essential when setting up the Virtana Global View Virtual Appliance, as it provides a hyperconverged infrastructure (HCI) platform capable of hosting the pre-packaged virtual appliance. By deploying through Nutanix, organizations that have standardized on HCI infrastructure can leverage their existing environment without needing a separate VMware setup.

Deployment in Nutanix consists of two steps:

Upload virtana-k8s-xxxx.ova and deploy the OVA from Prism Central. Refer to Deploying an OVA as VM for detailed steps.
Power on and verify the VM from Prism Element. Refer to Managing a VM (AHV) for detailed steps.

Deploy VM in KVM

Deploying the Virtual Machine in KVM (Kernel-based Virtual Machine) is essential when setting up the Virtana Global View Virtual Appliance on a Linux-based infrastructure. KVM is an open-source, type-1 hypervisor built directly into the Linux kernel, making it a cost-effective and high-performance alternative to proprietary platforms like VMware or Nutanix. The Global View application stack can be deployed as a VM on KVM by converting the OVA into a compatible disk image, such as QCOW2, and importing it using tools like virt-manager or virsh.

Perform the following steps:

Download virtana-gv-kvm-xxxx.x.x.tar.gz from Egnyte and extract it:

KVM_FILES_PATH="/var/lib/libvirt/images"   
mkdir -p ${KVM_FILES_PATH}/virtana
cd ${KVM_FILES_PATH}/virtana
tar -xvzf virtana-gv-kvm-xxxx.x.x.tar.gz -C ${KVM_FILES_PATH}/virtana/

(Optional) Update the OS machine type in vm.xml (default: q35). Get supported types with: /usr/libexec/qemu-kvm -machine help
```
vim virtana-gv-kvm-xxxx.x.x/vm.xml
  <os>
    <type arch="x86_64" machine="q35">hvm</type>
  </os>
```

Update the network bridge in vm.xml (default: network):

vim virtana-gv-kvm-xxxx.x.x/vm.xml
    <interface type="network">
      <source network="default"/>
      <model type="virtio"/>
    </interface>
Or
    <interface type="bridge">
      <source bridge="virbr0"/>
      <model type="virtio"/>
    </interface>

Update disk file paths in vm.xml (default: /var/lib/libvirt/images):

vim virtana-gv-kvm-xxxx.x.x/vm.xml
    <disk type="file" device="disk">
      <source file="/var/lib/libvirt/images/virtana/virtana-gv-kvm-2026.2.1/disk1.qcow2"/>
      ...
      <source file="/var/lib/libvirt/images/virtana/virtana-gv-kvm-2026.2.1/disk2.qcow2"/>
    </disk>

Define and start the VM:

virsh list --all
virsh define virtana-gv-kvm-xxxx.x.x/vm.xml
virsh start virtana-gv-kvm-xxxx.x.x
virsh list --all
virsh dominfo virtana-gv-kvm-xxxx.x.x

Access the VM console and get the IP address:

virsh console virtana-gv-kvm-xxxx.x.x
virsh domifaddr virtana-gv-kvm-xxxx.x.x --source agent | grep -E "ipv4" | grep -Ev "(lo|docker0|tunl0)"

Deploy VM in OpenShift Virtualization

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

Create the namespace:
```
oc new-project controlplane
```
Check available StorageClasses:
```
oc get sc
oc get sc <sc-name> -o yaml | grep volumeBindingMode
```
Note
volumeBindingMode must be Immediate. Recommended StorageClass type is RWX (RWO is acceptable if RWX is unavailable).
Create a working directory: mkdir -p ./virtana && cd ./virtana

(Optional) Create a StorageClass with volumeBindingMode: Immediate:

cat << EOF > virtana-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <STORAGE_CLASS_NAME>-immediate
provisioner: <PROVISIONER>
parameters:
  type: <STORAGE_TYPE>
  encrypted: "true"
reclaimPolicy: Retain
volumeBindingMode: Immediate
allowVolumeExpansion: true
EOF
oc apply -f virtana-storage-class.yaml

Create DataVolumes (CDI Import) - 170Gi for root, 320Gi for data:

cat << EOF > virtana-rootdisk.yaml
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: virtana-rootdisk
  namespace: controlplane
spec:
  source:
    upload: {}
  pvc:
    accessModes:
      - <ReadWriteOnce / ReadWriteMany>
    resources:
      requests:
        storage: 170Gi
    storageClassName: <STORAGE_CLASS_NAME>
EOF

cat << EOF > virtana-datadisk.yaml
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: virtana-datadisk
  namespace: controlplane
spec:
  source:
    upload: {}
  pvc:
    accessModes:
      - <ReadWriteOnce / ReadWriteMany>
    resources:
      requests:
        storage: 320Gi
    storageClassName: <STORAGE_CLASS_NAME>
EOF

oc apply -f virtana-rootdisk.yaml
oc apply -f virtana-datadisk.yaml

Verify DataVolume status is UploadReady:

oc get datavolume -n controlplane
oc get pvc -n controlplane

Download and extract the GlobalView KVM tar file from Virtana Support:
```
tar -zxvf virtana-gv-kvm-xxxx.x.x.tar.gz
```

Install virtctl (skip if already installed):

tar -zxvf virtctl.tar.gz
chmod +x virtctl
sudo mv virtctl /usr/local/bin/
virtctl version

Upload disk images to DataVolumes:

virtctl image-upload dv virtana-rootdisk \
  -n controlplane \
  --image-path=./virtana-gv-kvm-xxxx.x.x/disk1.qcow2 \
  --insecure

virtctl image-upload dv virtana-datadisk \
  -n controlplane \
  --image-path=./virtana-gv-kvm-xxxx.x.x/disk2.qcow2 \
  --insecure

Deploy the GlobalView VirtualMachine object:

cat << EOF > virtana-globalview-vm.yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: virtana-globalview
  namespace: controlplane
spec:
  runStrategy: Manual
  template:
    metadata:
      labels:
        kubevirt.io/domain: virtana-globalview
    spec:
      domain:
        cpu:
          cores: 12
        resources:
          requests:
            memory: 48Gi
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
              bootOrder: 1
            - name: datadisk
              disk:
                bus: virtio
          interfaces:
            - name: default
              masquerade: {}
          rng: {}
        features:
          acpi: {}
        machine:
          type: q35
      networks:
        - name: default
          pod: {}
      volumes:
        - name: rootdisk
          dataVolume:
            name: virtana-rootdisk
        - name: datadisk
          dataVolume:
            name: virtana-datadisk
EOF
oc apply -f virtana-globalview-vm.yaml

The following table describes each field in the configuration file.

Table 26.

Field	Description	Default value
Metadata and API
`apiVersion`	Specifies the KubeVirt API version used to define the virtual machine resource.	`kubevirt.io/v1`
`kind`	Declares the resource type as a VirtualMachine managed by KubeVirt.	`VirtualMachine`
`metadata.name`	The unique name assigned to this virtual machine within the cluster.	`virtana-globalview`
`metadata.namespace`	The Kubernetes namespace where the VM will be deployed.	`controlplane`
Run strategy
`runStrategy`	The VM will not start automatically. It must be manually started by the administrator.	`Manual`
CPU and memory
`domain.cpu.cores`	Allocates 12 CPU cores to the VM, matching the OVA resource requirement of 12 vCPUs.	`12`
`domain.resources.requests.memory`	Requests 48 GB of RAM for the VM, matching the OVA resource requirement.	`48Gi`
Disks
`disks[0].name`	The root volume disk for the OS and application stack.	`rootdisk`
`disks[0].disk.bus`	Uses the virtio bus for high-performance disk I/O.	`virtio`
`disks[0].bootOrder`	Marks this disk as the primary boot device.	`1`
`disks[1].name`	The secondary disk for Virtana application data.	`datadisk`
`disks[1].disk.bus`	Also uses virtio bus for optimal data disk performance.	`virtio`
Networking
`interfaces[0].name`	The primary network interface for the VM.	`default`
`interfaces[0].masquerade`	Uses masquerade (NAT) mode, allowing the VM to access external networks through the pod's IP.	`{}`
`networks[0].name`	Maps to the default pod network.	`default`
`networks[0].pod`	Connects the VM to the Kubernetes pod network.	`{}`
Device and machine features
`devices.rng`	Provides a virtual random number generator for cryptographic operations and security.	`{}`
`features.acpi`	Enables ACPI (Advanced Configuration and Power Interface) for proper power management and graceful shutdown.	`{}`
`machine.type`	Uses the Q35 machine type, a modern chipset emulation that supports PCIe and is recommended for production VMs.	`q35`
Volumes
`volumes[0].name`	Links to the root disk defined in the disks section	`rootdisk`
`volumes[0].dataVolume.name`	References a KubeVirt DataVolume that provisions the 150 GB root storage	`virtana-rootdisk`
`volumes[1].name`	Links to the data disk defined in the disks section	`datadisk`
`volumes[1].dataVolume.name`	References a KubeVirt DataVolume that provisions the 300 GB Virtana data storage	`virtana-datadisk`
Labels
`template.metadata.labels.kubevirt.io/domain`	A label used for identifying and selecting this VM's pods within the cluster, useful for networking and service discovery	`virtana-globalview`

Start the VM and verify it's running:

virtctl start virtana-globalview -n controlplane
oc get vmi virtana-globalview -n controlplane

Access the VM console or via SSH:

virtctl console virtana-globalview -n controlplane  
virtctl ssh virtana@vmi/virtana-globalview -n controlplane

Press ctrl+] to exit.

(Optional) Create a LoadBalancer service for external access:

cat << EOF > virtana-globalview-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: virtana-globalview-svc
  namespace: controlplane
spec:
  type: LoadBalancer
  selector:
    kubevirt.io/domain: virtana-globalview
  ports:
    - name: ssh
      port: 22
      targetPort: 22
    - name: https
      port: 443
      targetPort: 443
EOF
oc apply -f virtana-globalview-svc.yaml
oc get service virtana-globalview-svc -n controlplane
ssh virtana@<LB_IP/HOSTNAME>

Access the VM

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.

(Optional) Configure a Static IP Address for the VM

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.

Step 1: Gather network configuration details

Before making any changes, collect the following details from your network team:

Table 27.

Required Information	Description
Static IP Address	The fixed IP to assign to the VM.
Default Gateway	The network gateway address.
DNS Server Addresses	One or more DNS server IPs.
DNS Search Domain	The domain used for DNS resolution.

Step 2: Update the Netplan configuration

Switch to the root user and open the Netplan configuration file for editing:

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

Replace the contents with the following, substituting the placeholder values with the actual details gathered in Step 1:

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>

Step 3: Validate and apply the configuration

Perform the following steps:

Validate the configuration to check for syntax errors before applying:
```
sudo netplan generate
```
Apply the new network configuration:
```
sudo netplan apply
```

Note

Applying a new network configuration may temporarily interrupt SSH connectivity if the IP address changes. Ensure you have an alternative way to access the VM before proceeding.

Install and upgrade Global View

This section walks you through preparing the environment configuration, installing Keycloak and GlobalView, and upgrading to newer versions on the Virtana OVA VM.

Prepare the input environment file

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.

Table 28.

Field	Description
Mandatory configuration
`CONNECTIVITY_TO_INTERNET`	Whether the VM has internet access. Set to `no` for air-gapped/closed network environments.
`IMAGE_REGISTRY`	Address of the private container image registry used for deployment.
`DOCKER_SERVER`	Docker registry server URL for pulling images.
`DOCKER_USERNAME`	Username for authenticating with the Docker registry.
`DOCKER_PASSWORD`	Password for authenticating with the Docker registry.
`KEYCLOAK_HOSTNAME`	External DNS hostname for the Keycloak identity/authentication server.
`GLOBAL_VIEW_HOSTNAME`	External DNS hostname for the Global View application UI.
`GROWTHBOOK_HOSTNAME`	External DNS hostname for the GrowthBook feature flagging UI.
`GROWTHBOOK_API_HOSTNAME`	External DNS hostname for the GrowthBook API endpoint.
`TENANT_NAME`	Name of the tenant or organization being configured.
`INITIAL_ADMIN_USER_FIRSTNAME`	First name of the initial administrator user.
`INITIAL_ADMIN_USER_LASTNAME`	Last name of the initial administrator user.
`INITIAL_ADMIN_USER_EMAIL`	Email address of the initial administrator user.
SMTP configuration
`SMTP_CHECK_ENABLED`	Enables or disables SMTP email functionality. Set to `false`if no mail server is available.
`SMTP_HOST`	Hostname of the SMTP mail server.
`SMTP_PORT`	Port number for the SMTP server.
`SMTP_USERNAME`	Username for SMTP authentication. Leave blank if auth is not required.
`SMTP_PASSWORD`	Password for SMTP authentication.
`SMTP_FROM_EMAIL`	The sender email address used in outgoing emails.
Application versions
`CO_NORTH_HELM_VERSION`	Helm chart version for the CO North component.
`GLOBAL_VIEW_HELM_VERSION`	Helm chart version for the Global View component.
Virtana AI Copilot
`VIRTANA_AI_MODEL_PROVIDER`	The LLM provider to use, such as OPENAI, GEMINI, or LITELLM.
`VIRTANA_AI_API_KEY`	API key for the selected AI model provider.
`VIRTANA_AI_INFERENCE_ENDPOINT`	Inference endpoint URL. Only needed for self-hosted LiteLLM deployments, and leave blank for OpenAI/Gemini.
Remote wisdom agent
`ENABLE_REMOTE_WISDOM`	Enables integration with the Remote Wisdom agent.
`THINGWORX_PLATFORM_URL`	URL of the ThingWorx platform for Remote Wisdom connectivity.
`THINGWORX_AGENT_MODEL`	ThingWorx agent model identifier. Values provided by Virtana Support.

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.

Install applications

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

Keycloak must be installed before GlobalView. 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:

Table 29.

Action	Command
Install Keycloak and Global View together	`bash /home/virtana/deploy.sh all`
Install Keycloak only	`bash /home/virtana/deploy.sh keycloak`
Install GlobalView only	`bash /home/virtana/deploy.sh globalview`

Post-deployment troubleshooting

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:

Deployment completes successfully with no errors.
SMTP test email is received successfully, confirming SMTP configuration is correct.
The registration/invitation email for the initial admin user has not been delivered.
Without the registration email, the Global View UI cannot be accessed.

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:

Confirm that SMTP settings in /home/virtana/input.env are correct and that the SMTP test email was received successfully.

Check user-settings-service logs for authorization-service communication errors:

kubectl logs deploy/user-settings-service -n controlplane | grep -i "authorization"

If the logs confirm the inter-service communication failure, clean up the existing deployment and perform a fresh redeployment:
```
bash /home/virtana/deploy.sh all
```

Upgrade the Global View version

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:

The VM does not have internet connectivity.
A private container image registry is not available in your environment.
You prefer to deploy using a pre-packaged image bundle.

Perform the steps to use the image bundle:

Obtain the image bundle file (virtana-global-view-<GV_VERSION>-images-bundle.tgz) from the Virtana Support team.
Copy the bundle file to the Virtana OVA VM under the /opt/virtana directory.
Do not extract the bundle manually.
The deployment process will automatically extract and load the images.

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

Table 30.

Actions	Command
Upgrade Keycloak and GlobalView together	`bash /home/virtana/deploy.sh all`
Upgrade Keycloak only	`bash /home/virtana/deploy.sh keycloak`
Upgrade GlobalView only	`bash /home/virtana/deploy.sh globalview`

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.

In this section:

Global View virtual appliance deployment

Virtual appliance deployment prerequisites

OVA resource requirements

SMTP configuration

DNS records

Download and verify the OVA

Download the image bundle (Optional)

Internet access - no private registry

Internet access - with private registry

No internet access - with private registry

No internet access - without private registry

Virtual appliance installation

Deploy OVA in VMware vCenter

Deploy OVA in Nutanix

Deploy VM in KVM

Deploy VM in OpenShift Virtualization

Note

Access the VM

(Optional) Configure a Static IP Address for the VM

Step 1: Gather network configuration details

Step 2: Update the Netplan configuration

Step 3: Validate and apply the configuration

Note

Install and upgrade Global View

Prepare the input environment file

Install applications

Post-deployment troubleshooting

Upgrade the Global View version

Search results