Troubleshooting Virtual Edge Offline Issues

This article helps you diagnose and resolve Virtual Edge (VE) appliances showing as Offline in Cloud Control Center (CCC), including cases caused by connectivity loss, in-progress or stalled upgrades, and host-level resource or filesystem issues. For background on the Virtual Edge Dashboard and status indicators referenced here, see Managing Virtual Edges and Virtual Edge Nodes.

How Virtual Edge Offline Status Works

Cloud Control Center determines Virtual Edge availability using a heartbeat (keep-alive API) that the VE sends to CCC on a regular interval. When CCC stops receiving that heartbeat, the VE is marked Offline and an alert is raised.

A Virtual Edge Node (VEN) going offline is a related but distinct condition: the VE itself is reachable and Online, but it can no longer poll a switch it manages (the VE polls each VEN with show version approximately every 30 seconds). If your VE shows Online but one or more of its VENs show Offline or Degraded, follow the node-level checklist in Initial Troubleshooting for Elisity Policy and Connectivity instead, which covers cabling/power checks and the Restart Restconf action. This article focuses on the VE itself going offline.

Symptoms

• A Virtual Edge shows Offline in the Virtual Edge Dashboard, with all VENs it manages also going Offline as a result.
• The VE was reachable and Online prior to a scheduled or in-progress software upgrade.
• The VE alternates between Online and Offline (flapping) rather than staying down consistently.
• The VE has been Offline since a host-level event: a hypervisor reboot, a switch reload, a power event, or a storage/disk issue on the host.

Resolution Steps

Step 1: Confirm the Status and Timing in Cloud Control Center

Open the Virtual Edge Dashboard and locate the affected VE. Click its Status to open the Status Details view, which includes a Last Changed timestamp. This tells you exactly when the VE stopped sending heartbeats, which helps correlate the outage with a known change (an upgrade window, a maintenance activity, a network change) versus an unplanned event.

Step 2: Check Physical and Network Connectivity to the VE

Confirm the VE host itself is up and can reach the internet/CCC before assuming a software problem:

• Switch-hosted VE: Log in to the switch hosting the Virtual Edge application and confirm the switch is powered on, has not reloaded unexpectedly, and that no cabling or network change has cut off its path to CCC.
• Hypervisor-hosted VE: Log in to the hypervisor and confirm the VE virtual machine is powered on and running, and that it has a valid IP address and route to the internet.
• Verify DNS resolution and that outbound HTTPS to your CCC endpoint is not being blocked by a new firewall rule, proxy change, or expired outbound allow-list entry. If your environment uses an HTTP/HTTPS proxy, confirm the proxy configuration is still correct (see Step 4).

Step 3: Check That the VE Application Is Actually Running

If the host is reachable but the VE is still Offline in CCC, confirm the VE application/container itself is running:

• Switch-hosted VE: Run show app-hosting list to confirm the VE app state is RUNNING. Run show app-hosting detail appid VE for more detail, including the app's resource usage and the host switch's available compute resources. If the app is not running, restart it with app-hosting stop appid VE followed by app-hosting start appid VE.
• Hypervisor-hosted VE: Log in to the Ubuntu OS hosting the VE and run docker ps to confirm the Virtual Edge container is up. If it is not listed or is repeatedly restarting, this points to a resource or filesystem problem on the host (see Step 4) rather than a network issue.

Step 4: Check VE Health and Resources from the veshell

If the application is running but the VE still cannot reach CCC, session into the Virtual Edge shell (veshell) via console or SSH and run the following diagnostic commands:

• show status — status of core VE processes.
• show system — CPU, memory, and disk usage on the VE. High disk utilization or a full filesystem can prevent the VE service from writing logs or state and cause it to stop sending heartbeats.
• show log — review bootstrap and VE service logs for errors around the time the VE went offline (cross-reference with the Last Changed timestamp from Step 1).
• show ccc-cert-details — performs a TLS handshake to the configured CCC endpoint and displays the certificate chain. Use this to rule out an expired or untrusted certificate as the cause of a failed connection.
• show ntp — confirm the VE's clock is synchronized. A significant clock drift can break TLS handshakes to CCC.
• show proxy and show config — confirm proxy and network settings are still correct, especially if anything changed recently in your network.
• ping — check basic ICMP/TCP connectivity from the VE to your CCC endpoint or another known-good destination.

Step 5: Check for a Stalled or Incompatible Upgrade

If the VE went offline during or immediately after a scheduled upgrade, check its current reported Software Version in the Virtual Edge Dashboard (or via show version in the veshell) and compare it to the version you expected it to be running. A VE that is mid-upgrade should reconnect once the upgrade completes; an upgrade that has stalled or left the VE on an unexpected version should be escalated (see Step 7) — upgrade scheduling and rollback are managed by the Elisity team and are not a self-service action from the VE shell.

Step 6: Restart the VE Service, or Reboot the VM if Needed

If the checks above don't surface a clear cause (or you've corrected a proxy/DNS/certificate/resource issue and the VE still hasn't reconnected), restart the VE service from the veshell:

• restart — restarts the Virtual Edge service without rebooting the underlying VM or switch. Try this first.
• reboot — reboots the virtual machine. Use this if a service restart doesn't bring the VE back Online, particularly if show system showed resource exhaustion that a simple service restart wouldn't clear.

Allow a few minutes after either action for the VE to re-establish its heartbeat and for its status to update in the Virtual Edge Dashboard.

Step 7: Escalate to Elisity Support

Contact support@elisity.com if any of the following apply:

• The VE remains Offline after confirming host connectivity, application status, and VE health, and after a service restart/reboot.
• The VE appears stuck mid-upgrade, or is running an unexpected version and needs the upgrade rescheduled or rolled back.
• The hypervisor-hosted VE's Docker container is not running and does not come back after docker ps confirms it's down.
• You see repeated certificate handshake failures from show ccc-cert-details that aren't explained by a certificate you manage.

When escalating, include the VE's Last Changed timestamp from Step 1, relevant output from show system and show log, and a summary of what you've already checked — this significantly speeds up root-cause analysis.