Skip to main content

Global View OVA upgrade

Use this section to upgrade an existing Global View Open Virtualization Appliance (OVA) deployment to a newer version.

The following guidelines apply to every Global View OVA upgrade:

  • OVA-to-OVA upgrades aren't supported: After you deploy the OVA as a virtual machine (VM), don't deploy a newer OVA over that VM to upgrade it.

  • Upgrades run in place on the existing VM: Run every upgrade on the VM that already runs Global View.

Select the upgrade topic that matches the Global View version you want to upgrade to:

Global View OVA upgrade (2026.9.1)

Starting with Global View OVA (virtual appliance) release 2026.9.1, upgrade the appliance with a single tool, apply-patch-bundle.sh. The tool replaces the manual, version-specific deploy.sh edits that earlier releases require. It brings the appliance forward to any target release in one pass, including when you skip several releases at once.

The current release has a general procedure upgrade. Use it whenever your target release is 2026.9.1 or later, regardless of the release that you currently run (for example, 2026.2.1, 2026.4.1, or 2026.6.1). The tool is pre-installed on appliances that already run Global View 2026.9.1 or later. On appliances deployed before 2026.9.1, install the tool once in Step 2: Install the upgrade too.

Prerequisites

Complete the following preparation before you upgrade Global View OVA to 2026.9.1 or later:

  • Schedule a maintenance window. The application is unavailable during the upgrade, and the appliance might need to reboot.

  • Make sure that you can log in to the appliance as the virtana user. If you deployed your appliance before 2026.9.1, you also need the virtana-admin user for the one-time setup in Step 2: Install the upgrade too. Credentials for virtana-admin aren't included in the documentation for security reasons. If you don't have them, contact Virtana Support.

  • Have the images bundle for the target release available: virtana-global-view-<TARGET_VERSION>-images-bundle.tgz. You can obtain the bundle from Virtana Support.

  • If your appliance runs an OVA or Global View version earlier than 2026.9.1, take a VM-level backup before you begin. A VM-level backup is a backup of the entire virtual machine (VM). If your appliance already runs 2026.9.1 or later, you don't need a VM-level backup, because the tool creates a restore point automatically. For details, see Step 3: Apply all patches.

Upgrade the appliance

Complete the following eight steps to upgrade your Global View virtual appliance to release 2026.9.1.

Step 1: Copy the images bundle to the appliance

Place the images bundle for the target release in the /opt/virtana directory on the appliance. The commands in this topic use the TARGET_VERSION shell variable to refer to the release that you're upgrading to. If you open a new shell session, set the variable again.

  1. Obtain the images bundle for the target release from Virtana Support. The file name is virtana-global-view-<TARGET_VERSION>-images-bundle.tgz.

  2. Copy the bundle to the /opt/virtana directory on the appliance as the virtana user. For example, use SCP (Secure Copy Protocol) or SFTP (SSH File Transfer Protocol).

  3. On the appliance, go to the /opt/virtana directory and set the TARGET_VERSION variable to your target release. The example uses 2026.9.1:

    cd /opt/virtana

TARGET_VERSION="2026.9.1"

  4. Confirm that the bundle is present:

    ls -l virtana-global-view-${TARGET_VERSION}-images-bundle.tgz

    The command lists the bundle file.

If your appliance already runs 2026.9.1 or later, you can use the patch bundle for the release instead of the images bundle.

Step 2: Install the upgrade tool (appliances deployed before 2026.9.1 only)

The apply-patch-bundle.sh tool isn't installed yet on an appliance that you deployed before 2026.9.1. In this one-time setup, you extract the image bundle and mark it as extracted as the virtana user. Then you install the tool and its sudo rule as the virtana-admin user.

Important

Skip this step if your appliance already runs Global View 2026.9.1 or later. The upgrade tool is pre-installed on those appliances, so continue with Step 3: Apply all patches.

To install the tool, complete the following steps:

  1. As the virtana user, extract the images bundle from the /opt/virtana directory:

    tar -zxvf virtana-global-view-${TARGET_VERSION}-images-bundle.tgz

  2. Mark the bundle as already extracted. This marker lets apply-patch-bundle.sh and deploy.sh reuse the extraction instead of extracting the multi-GB archive a second time:

    mkdir -p /opt/virtana/virtana-global-view-${TARGET_VERSION}-images-bundle/.state
touch /opt/virtana/virtana-global-view-${TARGET_VERSION}-images-bundle/.state/untar_done

  3. Open a separate terminal session and log in to the same VM as the virtana-admin user. If you don't have the virtana-admin credentials, contact Virtana Support.

  4. In the virtana-admin session, run the following commands to install the tool and its sudo rule. Because this is a new session, the commands set the TARGET_VERSION variable again. Change its value if your target release isn't 2026.9.1:

    sudo su -

TARGET_VERSION="2026.9.1"

cp /opt/virtana/virtana-global-view-${TARGET_VERSION}-images-bundle/apply-patch-bundle.sh \
   /usr/local/bin/virtana/apply-patch-bundle.sh
chmod 0755 /usr/local/bin/virtana/apply-patch-bundle.sh

cp /opt/virtana/virtana-global-view-${TARGET_VERSION}-images-bundle/app-config/system-scripts/20260901/files/virtana-sudoers-file \
   /etc/sudoers.d/virtana
chmod 0440 /etc/sudoers.d/virtana

exit

    The commands start a root shell, copy apply-patch-bundle.sh to /usr/local/bin/virtana/, copy the sudoers file to /etc/sudoers.d/virtana, set the file permissions, and leave the root shell.

  5. Log out of the virtana-admin session.

Note

This step uses the virtana-admin user instead of the virtana user because the sudo rules for the virtana user on appliances deployed before 2026.9.1 have no entry for apply-patch-bundle.sh. The virtana-sudoers-file that you copy in this step adds that entry. Until the entry exists, only an account with broader access, such as virtana-admin, can install the tool. After this step, the virtana user can run apply-patch-bundle.sh with sudo on its own.

Step 3: Apply all patches (recommended)

Apply all three patches with one command. The --apply-all option runs the application configuration patch, the system patch, and the OS package update, in that order. Run the command in your virtana user session.

Warning

On an appliance deployed before 2026.9.1, the first run of the system patch changes the running system. The patch retires a legacy account and rotates a security-sensitive credential. The patch does the following:

  • Removes the legacy virtana-admin user.

  • Creates the visvc account. The account has a locked password and accepts SSH keys only. Virtana Support reserves the account for its own use.

  • Rotates the root password.

  • Updates the SSH welcome banner and the sudo rules for the virtana user.

After the patch removes the virtana-admin user, you can no longer log in with that user. For details, see Root password and administrative access.

Run the following command to apply all patches:

sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version ${TARGET_VERSION} --apply-all

To skip the single confirmation prompt that the tool shows at startup, add -y or --yes to the command.

The --apply-all option runs the following patches, in this order:

Order

Patch

Description

1

Application configuration patch

Adds the new input.env variables that the target release introduces. The patch doesn't modify or reorder existing values.

Always advances CO_NORTH_HELM_VERSION, GLOBAL_VIEW_HELM_VERSION, and STACKSTORM_HELM_VERSION to the values for the target release.

Replaces deploy.sh and the two core Helm templates. Virtana owns these files, so put any customizations in override-global-view-values.yaml or override-keycloak-values.yaml. The patch never modifies the override files.

Backs up the previous input.env, deploy.sh, and templates, and writes an upgrade report.

2

System patch

Applies operating system (OS) fixes.

Upgrades K3s, the lightweight Kubernetes distribution that runs on the appliance, if the target release ships a newer K3s version. The K3s upgrade restarts the cluster.

On appliances deployed before 2026.9.1, the patch also rotates the root password, removes the legacy virtana-admin user, creates the visvc account, and updates the SSH banner and the sudo rules for the virtana user.

3

OS package update

Applies a full, offline snapshot of the OS packages that ship with the bundle. The update doesn't need internet access.

The tool refuses to run the update if the Ubuntu version of the bundle doesn't match the Ubuntu version of the appliance.

While the command runs, and after it finishes, the tool behaves as follows:

  • Restore point: Before it makes any changes, the tool automatically takes a snapshot of the root volume with LVM (Logical Volume Manager) if the root volume is LVM-backed. The tool doesn't show a prompt for the snapshot. If the root volume isn't LVM-backed, the tool asks you to confirm that you took a VM-level backup.

  • K3s upgrade confirmation: If the target release ships a newer K3s version, the tool always asks you to confirm the K3s upgrade separately. The -y and --yes options don't skip this confirmation.

  • Running the command again: Running the tool again, for the same release or for a later release, is always safe. The tool applies only what it hasn't applied yet and automatically skips completed steps.

  • Upgrade report: When the tool finishes, it writes an upgrade report and stops. The tool doesn't run Helm and doesn't deploy the application. You deploy the application in Step 5: Deploy the application.

For all options of the tool, including --bundle and --skip-failures, see Command reference for apply-patch-bundle.sh. For the locations of snapshots, reports, and logs, see Report, backup, and log locations.

Alternative: apply the patches individually

Use the --apply-all option unless you need to apply the patches separately. To apply the patches separately, run the following three commands in the order shown. After the third command, continue with Step 4: Reboot and Step 5: Deploy the application.

  1. Apply the application configuration patch. The patch updates input.env, deploy.sh, and the Helm templates:

    sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version ${TARGET_VERSION} --apply-application-patch

  2. Apply the system patch. The patch applies OS fixes and the K3s upgrade. For the changes that the first run makes on appliances deployed before 2026.9.1, see the warning in Step 3: Apply all patches:

    sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version ${TARGET_VERSION} --apply-system-patch

  3. Apply the OS package update. The update installs the offline package snapshot that ships with the bundle:

    sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version ${TARGET_VERSION} --apply-os-packages

Step 4: Reboot (if required)

Some OS package upgrades, such as an upgrade of the Linux kernel or of the C library (libc), take effect only after you reboot the VM. If the VM needs a reboot, the final output of the previous step ends with a boxed REBOOT REQUIRED banner that shows the exact command to copy and run. If the output shows the banner, reboot the VM.

  1. Check the final output of the previous step. If the output doesn't show the REBOOT REQUIRED banner, skip this step and continue with Step 5: Deploy the application.

  2. Reboot the VM:

    sudo reboot

  3. After the VM restarts, log in to the appliance as the virtana user.

Important

If the tool required a reboot, you must redeploy the application after the VM restarts. Continue with Step 5: Deploy the application. The upgrade isn't complete until you deploy the application.

Step 5: Deploy the application

Deploy the Global View application with the deploy.sh script. The apply-patch-bundle.sh tool updates the files that deploy.sh uses, but the tool doesn't run Helm and doesn't deploy the application. If you customized the Helm values template on a release earlier than 2026.9.1, first complete Carry forward custom Helm values (optional). Otherwise, continue with Deploy with deploy.sh.

Carry forward custom Helm values (optional)

This optional section explains how to carry your custom Helm values forward from the old template to the override file. Earlier releases asked you to put custom Helm value changes directly in the /home/virtana/templates/global-view-values.yaml template. Starting with 2026.9.1, that template is vendor-owned, and the application configuration patch replaces it. Custom values now belong in the dedicated override file, /home/virtana/override-global-view-values.yaml. Upgrades never modify the override file.

Important

Skip this section if you never edited the /home/virtana/templates/global-view-values.yaml file. This section applies only if you made custom changes to the Helm values template on a release earlier than 2026.9.1. If you skip this section, continue with Deploy with deploy.sh.

If you customized the old template, copy only your custom changes into the override file before you deploy. Complete the following steps:

  1. Locate the previous template in the backup directory that the application configuration patch created. List the contents of the backup directory:

    ls -l /home/virtana/backups/

    Open the most recent <timestamp>-pre-<version>/ directory, and find the backed-up global-view-values.yaml file.

  2. Identify the values that you changed in the backed-up file. Add only those keys to the /home/virtana/override-global-view-values.yaml file, and keep the same YAML structure (parent keys and indentation). Don't copy the entire template.

Note

Virtana AI (Copilot) settings that you configured in input.env carry forward to the override file automatically. Examples of these settings are VIRTANA_AI_MODEL_PROVIDER, VIRTANA_AI_API_KEY, and VIRTANA_AI_INFERENCE_ENDPOINT. You don't need to copy these settings manually.

Deploy with deploy.sh

To deploy the application, review the upgrade report and then run the deploy.sh script. Complete the following steps:

  1. Review the upgrade report, and set values for any variables that the tool newly added to input.env. The report is the upgrade-report.txt file in the /home/virtana/backups/<timestamp>-pre-<version>/ directory. For the locations of all upgrade files, see Report, backup, and log locations.

  2. Deploy Keycloak and Global View together:

    bash /home/virtana/deploy.sh all

Alternatively, deploy the components individually with the keycloak and globalview arguments. If you deploy the components individually, upgrade Keycloak first, because you must upgrade Keycloak before Global View:

bash /home/virtana/deploy.sh keycloak
bash /home/virtana/deploy.sh globalview

Step 6: Validate the application

Confirm that the K3s service and all pods are healthy, and then confirm that Global View works as expected. For more checks, see Validate the Global View OVA deployment.

  1. Check the status of the K3s service:

    sudo systemctl status k3s

    The output shows that the service is active (running).

  2. Check the status of all pods in the cluster:

    kubectl get pods -A

    Healthy pods are in the Running or Completed state.

  3. Log in to Global View. Confirm that the dashboards load and that data collection works as expected.

Step 7: Verify the restore point, then keep or undo the patch

Verify the pre-patch snapshots, and then decide whether to keep or undo the patch. The tool creates a restore point only when the root volume is LVM-backed. If the root volume isn't LVM-backed, the tool doesn't create a restore point, and this step doesn't apply. In that case, you confirmed a VM-level backup in Step 3: Apply all patches instead.

Confirm that the pre-patch snapshots are healthy. First, check the status of the restore point:

sudo /var/lib/virtana/restore-points/current/restore-point.sh status

Then list the logical volumes and snapshots. The Data% column shows how full each snapshot is:

sudo lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent,lv_time,lv_tags ubuntu-vg

Warning

Decide promptly whether to keep or undo the patch. The snapshot fills up as the VM writes data. At 100%, the snapshot becomes unusable, and you can no longer roll back.

After you verify the application, choose exactly one of the following options. Option A keeps the patch, and Option B undoes the patch.

Option A: Keep the patch (everything works)

Commit the patch after you confirm that the application works as expected. The commit keeps the patched system. It deletes the pre-patch snapshot or snapshots and the /boot copy, so you can no longer roll back after the commit. Run the following command:

sudo /var/lib/virtana/restore-points/current/restore-point.sh commit
Option B: Undo the patch (something is wrong)

Undo the patch if the application doesn't work as expected after the upgrade. The rollback returns the appliance to the state that it had when the tool took the restore point.

Warning

If you undo the patch, you lose everything that the appliance wrote after the tool took the restore point, including application data. Undo the patch only if you can accept this data loss.

To return the appliance to the restore point, complete the following steps:

  1. Start the rollback. The command asks you to type ROLLBACK to confirm:

    sudo /var/lib/virtana/restore-points/current/restore-point.sh rollback

  2. Reboot the VM. The snapshot merge completes during the boot:

    sudo reboot

  3. After the VM restarts, check the status of the restore point. The output must include Rollback complete:

    sudo /var/lib/virtana/restore-points/current/restore-point.sh status

  4. Remove the restore point directory:

    sudo /var/lib/virtana/restore-points/current/restore-point.sh cleanup

If the status command reports that the rollback is still in progress, follow the lvs guidance that the command prints. A second reboot is often required.

Step 8: Clean up the previous release's images

Reclaim disk space by cleaning up the images of the release that you upgraded from. VMs in closed networks use offline image bundles, so each VM stores container images from several releases. Over time, these images can use a significant amount of space in the root (/) volume.

Important

Clean up only after the new release is running and verified. The cleanup removes the images bundle of the previous release. If you clean up before you deploy and verify the new release, the appliance has no images for either release.

To clean up the images of the previous release, complete the following steps:

  1. Confirm that the new release is up and working correctly. For the checks, see Step 6: Validate the application.

  2. Log in to the VM as the virtana user. Then run cleanup.sh from the bundle directory of the previous release. Replace <PREVIOUS_VERSION> with the release that you upgraded from:

    cd /opt/virtana/virtana-global-view-<PREVIOUS_VERSION>-images-bundle
bash cleanup.sh

    The script removes only the container images that are no longer in use. It's safe to run even when the images of the previous release overlap with the images of the deployed release, because the script leaves alone every image that a running container uses. The cleanup doesn't break your current deployment.

  3. After cleanup.sh finishes, delete the directory and the .tgz file of the previous images bundle. The cleanup.sh script removes only container images, and it can't remove the directory that contains it, so you delete the directory in a separate step. The rm commands permanently delete the files, so check that each path contains the release that you upgraded from. Replace <PREVIOUS_VERSION> with that release:

    cd /opt/virtana/
rm -rf /opt/virtana/virtana-global-view-<PREVIOUS_VERSION>-images-bundle
rm -f /opt/virtana/virtana-global-view-<PREVIOUS_VERSION>-images-bundle.tgz
Remove only the StackStorm images (optional)

If you set ENABLE_STACKSTORM='yes', the StackStorm images .tgz file and its extracted directory are in the Stackstorm/ folder inside the Global View images bundle. They aren't a separate top-level download. The deletion in the previous procedure removes them together with the bundle, so you don't need a separate cleanup.

To remove only the StackStorm payload, for example, because you keep the rest of an old bundle for another reason, run the following commands. Replace <PREVIOUS_VERSION> with the release that you upgraded from, and replace <PREVIOUS_STACKSTORM_VERSION> with the StackStorm version of that release:

rm -rf /opt/virtana/virtana-global-view-<PREVIOUS_VERSION>-images-bundle/Stackstorm/virtana-stackstorm-<PREVIOUS_STACKSTORM_VERSION>-images-bundle
rm -f /opt/virtana/virtana-global-view-<PREVIOUS_VERSION>-images-bundle/Stackstorm/virtana-stackstorm-<PREVIOUS_STACKSTORM_VERSION>-images-bundle.tgz

Report, backup, and log locations

In the paths in this section, <timestamp> is the date and time of the run, and <version> and <VERSION> are the target release. The upgrade tool and the restore point scripts write files to the following locations:

What you can find

Path

Upgrade report (one for each run)

/home/virtana/backups/<timestamp>-pre-<version>/upgrade-report.txt

Backups of the previous input.env, deploy.sh, and templates

/home/virtana/backups/<timestamp>-pre-<version>/

Full run log

/var/log/virtana/apply-patch-bundle-<VERSION>-<timestamp>.log

Restore point directory and the restore-point.sh script

/var/lib/virtana/restore-points/current/

Image bundles, extracted bundle directories, and the .state/untar_done extraction marker

/opt/virtana/

Command reference for apply-patch-bundle.sh

The apply-patch-bundle.sh tool is pre-installed at /usr/local/bin/virtana/apply-patch-bundle.sh on appliances built on release 2026.9.1 or later. The tool updates the application configuration, applies one-off OS-level fixes (including a K3s version upgrade if the bundle ships one), and can refresh OS packages. All of these actions run offline, without redeploying the VM. The following sections describe the options of the tool, the bundles that it accepts, and its snapshot behavior.

Patch options

If you don't specify a patch option, the tool applies only the application configuration patch. Use the following options to choose which patches the tool applies:

Option

Description

Requires root (sudo)

--apply-application-patch (default)

Adds any new input.env variables. The patch never modifies or reorders existing values.

Replaces deploy.sh and the core Helm templates. Your customizations live separately in the override-*.yaml files, and the patch leaves them untouched.

If the bundle ships them, the patch also updates deploy-stackstorm.sh and the StackStorm Helm templates in the same way. Appliances that don't have StackStorm enabled aren't affected.

No

--apply-system-patch

Runs the one-off OS fixes of the release, for example, security hardening and stale-user cleanup.

Upgrades K3s if the bundle ships a newer K3s version.

Yes

--apply-os-packages

Applies a full, offline OS package snapshot that ships with the bundle. The update doesn't need internet access.

The tool refuses to run if the snapshot doesn't match the Ubuntu version of the VM.

Yes

--apply-all

Runs all three patches in order.

The tool asks for one confirmation first. Add -y or --yes to skip the confirmation.

Yes

Note

The application configuration patch always updates CO_NORTH_HELM_VERSION, GLOBAL_VIEW_HELM_VERSION, and STACKSTORM_HELM_VERSION in input.env to the values for the release, even if you already set these variables. The patch moves these version pins forward by design, so it overwrites any value that you set for them.

General options

Use the following options to control how the tool runs:

Option

Description

--version <VERSION>

Sets the target release, for example, 2026.9.1.

-y, --yes

Skips the single confirmation prompt that the tool shows at startup. The tool never skips the separate confirmation for a K3s upgrade.

--skip-failures

Keeps going after a failed step and reports every failure at the end. Without this option, the tool skips every step after the first failure, so a later step never runs against a VM that a previous step left in a partial state.

--bundle <PATH>

Uses the specified bundle file instead of automatic discovery under /opt/virtana.

Examples

The following examples show common ways to run the tool. The examples use release 2026.9.1. Replace the release number with your target release.

# Application configuration patch only (the default; no root access needed)
/usr/local/bin/virtana/apply-patch-bundle.sh --version 2026.9.1

# OS-level fixes, plus a K3s upgrade if the bundle ships a newer version (needs root)
sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version 2026.9.1 --apply-system-patch

# OS package upgrade, entirely offline (needs root)
sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version 2026.9.1 --apply-os-packages

# Everything, without the startup confirmation prompt
sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version 2026.9.1 --apply-all -y

# Keep going after a failure and report every failure at the end
sudo /usr/local/bin/virtana/apply-patch-bundle.sh --version 2026.9.1 --apply-all --skip-failures

# Use a specific bundle file instead of automatic discovery under /opt/virtana
/usr/local/bin/virtana/apply-patch-bundle.sh --version 2026.9.1 --bundle /opt/virtana/virtana-global-view-2026.9.1-patch-bundle.tgz

Bundles and the upgrade report

The tool uses the release bundle that you copy to the /opt/virtana directory. You can use either of the following bundles:

  • Patch bundle: virtana-global-view-<TARGET_VERSION>-patch-bundle.tgz. Obtain the patch bundle for the release from Virtana Support.

  • Images bundle: virtana-global-view-<TARGET_VERSION>-images-bundle.tgz. If you already downloaded the full images bundle for the release, it also works, because the images bundle includes the application configuration patch.

The tool finds the bundle in /opt/virtana automatically. To use a bundle in a different location, use the --bundle option. Step 2: Install the upgrade too installs the tool from the images bundle, so use the images bundle on an appliance deployed before 2026.9.1.

When the tool finishes, it writes a report and stops. The tool never runs Helm for you. Review the report, set values for any newly added input.env variables, and then deploy the application with the deploy.sh script. The script accepts one of the following arguments: virtana-gateway, keycloak, globalview, or all.

Automatic LVM snapshots

Before --apply-system-patch or --apply-os-packages changes anything, the tool checks whether the root volume is LVM-backed. On older two-disk appliances, the tool also checks the data volume. The tool then does one of the following:

  • LVM-backed volume: The tool takes a snapshot with lvcreate --snapshot automatically and shows no prompt. LVM-backed volumes are the default from OVA release 2026.9.1 onward. For details, see OVA resource requirements.

  • Volume that isn't LVM-backed: On older appliances, the tool asks you to confirm that you took a VM-level backup or snapshot before it continues.

The tool never removes snapshots automatically. The final report of the tool shows the exact commands to review, discard (lvremove), or roll back (lvconvert --merge) each snapshot. The following commands show the format of the discard and roll back commands. For the standard keep-or-undo decision, use the restore-point.sh commands in Step 7: Verify the restore point, then keep or undo the patch.

# Discard a snapshot after you confirm that nothing is wrong
sudo lvremove /dev/<vg>/<lv>_prepatch_<timestamp>

# Roll back to the pre-patch state if something is wrong
sudo lvconvert --merge /dev/<vg>/<lv>_prepatch_<timestamp>

Root password and administrative access

For security, the appliance doesn't ship with a fixed or known root password. Virtana Support uses the root account during troubleshooting or recovery. Day-to-day install and upgrade tasks require only the virtana user. On an appliance deployed before 2026.9.1, the first run of the system patch in Step 3: Apply all patches rotates the root password, removes the virtana-admin user, and creates the visvc account.

How the root password is set

On first boot, the firstboot.sh script automatically generates a random, unique root password and sets it on the root account. The script derives the password from a per-appliance UUID (universally unique identifier). The appliance never displays or logs this password.

Reset the root password

If you need Virtana Support to access root on the appliance, or if you want to rotate the current root password, run the following command:

sudo /usr/local/bin/virtana/reset-root-password

The command generates a new UUID, backs up the previous UUID to serial-number.bak, and resets the root password to the passphrase that's derived from the new UUID. The command doesn't print the password. It prints only the new UUID, as in the following example:

Root password reset successfull.
New UUID: 6F1A2B3C-...

Note: Share the UUID with Virtana Support.

Share the printed UUID with Virtana Support through your support channel. Virtana Support uses the UUID to derive the actual password. The reset-root-password command is pre-installed on every appliance and doesn't need internet access.

The visvc account

Appliances also provision an account named visvc. The account has a locked password and accepts SSH keys only. Virtana Support reserves the account for its own key-based administrative access. The visvc user can't log in with a password. When visvc runs sudo, sudo asks for the root password of the appliance, not a password of the visvc account, so the account can't escalate privileges without the root password. You don't need to take any action for this account.

Global View OVA upgrade (2026.6.1)

This topic describes how to upgrade a Global View OVA (virtual appliance) deployment to version 2026.6.1. Upgrades run in place on the existing virtual machine. Update the deployment script and configuration, then redeploy the Global View application components with Helm.

OVA upgrade guidelines

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

  • OVA-to-OVA upgrades are not supported: After you deploy the OVA as a virtual machine, perform all later Global View upgrades with the standard application upgrade process. Deploying a new OVA version over an existing VM is not supported.

  • Upgrades run in place on the existing VM: Once the Global View VM is deployed and running, you run all future upgrades on the same VM by upgrading the application components with Helm.

  • Review the version-specific upgrade notes first: Starting with Global View 2026.6.1, version-specific upgrade instructions are published for each release. Read the notes that match the version you are upgrading from.

  • Update the Helm values as required: Before you upgrade, review the applicable upgrade notes and make any required changes to the Helm values files in /home/virtana/templates/ , in particular templates/global-view-values.yaml . For the values changes specific to your source version, see the Global View upgrade (2026.6.1).

  • Run the standard deployment script: After you apply the configuration changes, run bash deploy.sh <deployment-type> to perform the upgrade.

Update deploy.sh before you upgrade to 2026.6.1

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:

  • Redis : The image repository name changes from redis to dhi-redis .

  • SeaweedFS : This component is new in 2026.6.1 and requires image registry configuration.

  • VirtanaAI (Copilot) : The configuration keys move from the LiteLLM paths to the VirtanaAI paths.

  • CRD installation : The CRD deployment step must use the patched values file.

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

  1. Update the Redis image repository:

     sed -i \ 's|\.redis\.image\.repository = strenv(IMAGE_REGISTRY) + "/redis"|.redis.image.repository = strenv(IMAGE_REGISTRY) + "/dhi-redis"|g' \ deploy.sh

  2. Add the SeaweedFS image registry configuration:

     sed -i '/dhi-redis/a\ yq e -i '\''.seaweedfs.image.registry = strenv(IMAGE_REGISTRY)'\'' "$PATCHED_GLOBALVIEW_VALUES" ' deploy.sh

  3. Update the VirtanaAI configuration keys:

     sed -i \ -e 's/\.cp-configs\.litellm\.litellm_api_key/.cp-configs.virtana_ai.virtana_ai_api_key/g' \ -e 's/\.cp-configs\.litellm\.litellm_inference_endpoint/.cp-configs.virtana_ai.virtana_ai_inference_endpoint/g' \ deploy.sh

  4. Update the CRD deployment command so that CRD installation uses the patched values file:

     sed -i '/tags\.crds=true/ { /PATCHED_GLOBALVIEW_VALUES/! s|--set tags\.crds=true \\|--set tags.crds=true -f "$PATCHED_GLOBALVIEW_VALUES" \\| }' deploy.sh

Update the Global View version in the input file

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

Update the versions

Update GLOBAL_VIEW_HELM_VERSION and, optionally, CO_NORTH_HELM_VERSION in the input.env file to the latest versions available in the Virtana Helm repository. Run the following commands to find the latest available versions:

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

Update Virtan AI (Copilot) configuration

The OPENAI_API_KEY variable is replaced with a provider-based configuration model that supports OpenAI, Gemini, and LiteLLM. Update the VirtanaAI section of input.env as follows:

# Supported values: 
VIRTANA_AI_MODEL_PROVIDER='' 
VIRTANA_AI_API_KEY='' 
VIRTANA_AI_INFERENCE_ENDPOINT=''
VIRTANA_AI_SSL_VERIFY="true"
LITELLM_PROXY_ENABLED="true"

Variable

Description

Default value

VIRTANA_AI_MODEL_PROVIDER

AI provider for the VirtanaAI Copilot. Supported values: OPENAI , GEMINI , LITELLM .

—

VIRTANA_AI_API_KEY

API key for the selected provider (OpenAI, Gemini, or LiteLLM).

—

VIRTANA_AI_INFERENCE_ENDPOINT

Inference endpoint URL. Leave blank for OpenAI or Gemini. For a self-hosted LiteLLM deployment, provide the LiteLLM endpoint URL (for example, https://litellm.example.com ).

—

VIRTANA_AI_SSL_VERIFY

Controls SSL certificate validation. Set to true by default to verify SSL certificates, or set to false to skip certificate verification.

true

LITELLM_PROXY_ENABLED

Indicates whether LiteLLM is used as a proxy. Set to true when LiteLLM is used/enabled as a proxy. Set to false when connecting directly to providers such as OpenAI or Gemini.

true

Download the image bundle (optional)

This step 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.

To use the image bundle:

  • Obtain the release-specific 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 in the /opt/virtana directory.

  • Do not extract the bundle manually. The deployment process extracts and loads the images automatically.

Customize or update the Helm values

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.

Note

Review the version-specific upgrade notes before you modify existing values files or upgrade, because configuration options and defaults can change between releases.

Run the upgrade

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.

Action

Command

Upgrade Keycloak and Global View together

bash /home/virtana/deploy.sh all

Upgrade Keycloak only (step 1 of 2)

bash /home/virtana/deploy.sh keycloak

Upgrade Global View only (step 2 of 2)

bash /home/virtana/deploy.sh globalview

In this section: