Sensor: VM / Bare Metal
Use this deployment for persistent Linux servers, virtual machines, appliances, and bare-metal telecom hosts that use systemd. The Console generates the complete install command for the selected host.
Prerequisites
- Root or sudo access
- systemd and
systemctl curlx86_64oraarch64- Linux kernel 5.4 or newer
- BTF at
/sys/kernel/btf/vmlinux - BPF filesystem available at
/sys/fs/bpf - Outbound HTTPS access to the Console
Run the checks in Requirements before installation.
Deploy from the Console
- Open Sensors > Deploy.
- Select VM / Bare Metal.
- Enter a unique node name.
- Select the node role and Sensor flavor.
- Add site, environment, network, or ownership tags as needed.
- Generate the install command.
- Run the command on the target host as root before the token expires.
Use Standard for general Linux security. Use Telecom when the host should provide 5G, O-RAN, telecom protocol, network-function, and capture visibility in addition to the Standard feature set.
The generated command is preferred over a hand-written command because it includes the correct Console address, enrollment token, node identity, flavor, and optional tags.
Verify the service
On the target host:
systemctl status telovix-sensor
journalctl -u telovix-sensor -n 100 --no-pagerIn Sensors > Fleet, confirm:
- the node appears within approximately one minute;
- status returns to healthy;
- architecture, version, flavor, and role are correct;
- the last-seen time continues to update;
- Live Feed and Runtime Explorer show current evidence.
If the service is running but the node does not appear, test the exact Console hostname from the Sensor host and generate a fresh command if the one-time token expired.
Node identity and tags
Choose a stable name that identifies one operating-system instance. Good examples include a cloud instance name, hardware inventory name, or telecom appliance name.
Use tags to support fleet search and rollout scopes, for example:
environment:productionsite:tokyo-1network:5g-coreowner:ran-team
Do not reuse one node name for multiple simultaneously active hosts.
Reinstall and re-enroll
Use the action shown on the Sensor detail page when credentials need replacement or a legacy installation needs one manual refresh. Re-enrollment preserves the existing Sensor record when the Console provides a Sensor-specific re-enrollment flow.
Do not use a new ordinary one-time token as a substitute for re-enrollment unless you intentionally want a new Sensor identity.
Upgrade
Current VM and bare-metal Sensors that report managed update capability can be upgraded from Sensors > Fleet by selecting Upgrade Fleet. Older installations may require one final Console-generated reinstall before managed upgrades become available.
Use Rolling or Canary for production. See Upgrading Sensors.
Uninstall
- Open the Sensor detail page.
- Select Uninstall this Sensor.
- Choose the displayed
curlorwgetcommand. - Run it on the Sensor host as root.
- Confirm the service is removed and the Console record is decommissioned.
The detail page uses the Sensor's recorded deployment type to show the correct procedure. Do not use a Kubernetes uninstall command for a systemd installation.
Troubleshooting
| Symptom | Check |
|---|---|
| Installer reports unsupported architecture | Confirm uname -m is x86_64 or aarch64. |
| Installer cannot use systemd | Use the Kubernetes deployment for cluster nodes or a supported systemd host. |
| Download fails | Verify DNS, Console reachability, token expiry, and the generated Console URL. |
| Service repeatedly restarts | Review the service log for kernel, BTF, BPF filesystem, or enrollment errors. |
| Sensor is stale | Confirm the service is running and outbound Console connectivity is stable. |
| Runtime events are absent | Check Fleet delivery health and Console analytics health before changing Sensor policy. |
| Managed upgrade is unavailable | Perform the one-time reinstall shown in the Sensor detail page. |