title: Automatic setup description: Discovery → "Set up automatically": scan networks, identify devices, verify credentials, create hosts with checks — and what remains as a task list. last_verified: 2026-09-02

Automatic setup¶

Automatic setup takes the results of Discovery and turns them into monitored hosts: determine the device type, verify stored credentials against the device, create the host, enable the checks of the matching device profile and, after the first readings, verify that the checks really deliver. Anything Vesana can't decide on its own appears as a task.

You find it under Discovery → Set up automatically. After the first login on a fresh instance, Vesana asks exactly once whether you want to set up automatically or manually — "Set up automatically" leads straight to this tab, "Set up manually" keeps it reachable at any time anyway.

Three promises shown in the start window that the run keeps:

Only unambiguously identified devices are created. Everything else becomes a task — a device is never guessed.
New hosts only alert once the first readings are in.
Credentials are never tried blindly in sequence. SSH is tested exactly once with what you entered.

Prerequisites¶

Permission Hosts → Create to start and edit; Credentials → Manage to store credentials in the start window.
A collector of the tenant or the Active Collector ("Active collector (server checks itself)" — counts for every tenant, but only sees what the server itself reaches). A collector of another tenant is rejected.
For switches, firewalls, NAS and UPS devices: enable SNMP on the device and allow UDP 161 from the collector network. Without SNMP these devices become tasks.

Start window¶

"Start setup" opens a review before anything happens:

Section	Content
These networks will be scanned	all known networks of the tenant with origin and "N devices known"; deselect or add via "Add network" (CIDR). Excluded networks can be expanded. Large networks are marked as "long scan". Below: "Scanned by: …" with the collectors involved (offline marked).
Enable SNMP first	the hint from above — SNMP devices without SNMP only produce a task.
Credentials used for probing	the tenant's credential sets. "Store credentials" creates a new set right here (SNMP v2c, SNMP v3, SSH, API token) — stored in the tenant credential vault, so also available later when creating hosts; entries can be removed here too. Without an SNMP community: "Add an SNMP community for better results."
Scan networks now (recommended) / Use existing data	whether the run triggers a fresh network scan or works with the latest discovery results ("last …"). If no collector is online, only the existing data remains.
Folder for new hosts (optional)	target folder in the host structure for all hosts this run creates.

At most one run per tenant; "Start setup" while a run is active shows the current state. With several tenants, the tab remembers the last chosen customer; other active runs are listed as "Also active: …" in the header.

How a run proceeds¶

Identify → check credentials → create checks → verify. The header shows the real state: Network scan running (with scan progress) · Setup running ("N of M devices assessed", "N checks created") · N tasks open · Setup finished · Setup was stopped.

For each device, Vesana decides based on the same traits as Discovery (identity traffic light, open ports, SNMP response):

Windows and Linux machines (Proxmox hosts included) take the agent path — they are not asked for SNMP. If there is no specific profile for the system, Vesana uses the base profile of the operating system.
SNMP devices (switches, firewalls, NAS, UPS, printers): Vesana tries the tenant's stored SNMP credentials against the device (v2c communities and v3 sets), creates the host with the identified device profile on success and enables its checks.
Devices are re-assessed as soon as the network scan delivers complete data — while it runs, Vesana doesn't ask for the device type, because the question usually answers itself. A confirmation you gave yourself is never overwritten.
Devices that already exist as hosts are not a task: they appear under Already monitored.

A run that hasn't seen a single device after 30 minutes ends with an empty summary. A run that has only been waiting for you for two weeks counts as finished — open devices come back in the next run. If a collector involved stops reporting, the header says so ("Collector X is not reporting. Setup pauses …") instead of silently stalling.

Staying quiet and verification¶

Freshly created hosts get a setup downtime: they don't alert until the first readings are in — the row shows "waiting for first readings" and the time of the assessment. About 12 minutes after creation, Vesana assesses every created check:

Delivers values → stays.
Reports that the device doesn't know this value (e.g. an OID this model doesn't have) → is removed ("N checks removed after verification — show them" on the row, "removed as dead" in the summary).
No answer (timeout, wrong community) → stays and is only reported — a dropout is not proof.
Never a first result → is removed.

If no check remains, the device is not set up: it gets the task Add credentials ("All N checks created stayed without a result and were removed — most likely the credentials do not match"). The setup downtime ends with the assessment, at the latest after two hours.

Device list and filters¶

A single list — no device appears in two places. The numbers above the list are filters:

Filter	Contains
Open tasks	devices where it's your turn — grouped by task type (see below)
In progress	Vesana is working, including "waiting for first readings"
Set up	host with checks created and verified
Already monitored	was a host before the run
Skipped	excluded by you with "Don't set up"/"Remove", or not created because of the license
Failed	with cause and "Retry"
All	everything

Plus a search (name, IP). Each row shows the name and where it came from, the identification pill as in Discovery (including "VM on Proxmox"), what the device was identified by ("open ports 22, 443", "responds to SNMP", "probably Synology"), what happens next or why nothing is happening right now, and after creation "N checks", "Open host", "N checks not created — show reasons".

Actions per row: Retry and Remove. "Retry" only applies to devices with an open task, skipped and failed ones (from v1.9.439) — a fully set-up device is no longer re-assessed by accident and a finished run is not reopened; in any other state the reason is stated in plain words. After a retry the device's setup grace period starts over. "Remove" means ("Don't set up this device" — not in later runs either; "Retry" brings it back).

Task types¶

Tasks sit under their own heading so that 14 silent switches are one group, not 14 cards.

Task	When	What you do
Resolve SNMP access	The device answers SNMP but none of the stored credentials match — or it doesn't answer SNMP at all	"Enter SNMP credentials": v2c (community) or v3 (user + passwords; Vesana detects the protocols itself), pick a saved set or enter new ones, then "Verify & apply". The input is verified against the device right away; if it works, it is remembered as a credential set and applied to all waiting devices — with twenty switches, one entry is enough. If verification fails, the message names the community that was tried and the collector it was tried from — a device in another VLAN may not be reachable from there. Devices that only speak SNMPv1 are recognised and run on v1 afterwards.
Resolve SSH access	The device is queried over SSH	"Enter SSH access": user and password or key (port optional). Verified exactly once against the device and remembered — stored credentials are never tried in sequence.
Install agent	Windows/Linux machines	"Install agent" opens the install command (Linux one-liner; for Windows the installer and the PowerShell variant — with detected Windows, the Windows tab comes first). Copy, run on the device, done: once the agent reports in, Vesana creates the checks and the task disappears. No checkbox needed.
Confirm device type	Identification is ambiguous or there is no matching profile	First the simple question: "Identified as Proxmox VE. Is that correct?" → Yes, apply. With No, pick another the picker searches the whole catalog (local and community profiles; community profiles are downloaded when applied). Only what Vesana really identified is suggested. If more identically recognised devices exist, Vesana asks: "Apply to N more identically recognized devices". If a question resolves itself through new scan data, that is noted in the history.
Add credentials	The device profile needs an API token, a community or SSH access that doesn't exist yet — or all checks stayed without a result	Enter exactly the missing field (saved or new), then setup continues. If a profile needs several, it says "Still missing afterwards: …".
No response	The device didn't answer any probe	Enable SNMP on the device and "Rescan all N" (targeted scan of just these devices), enter credentials — or remove the device.

Agent and device profile side by side¶

A detected Proxmox host, a NAS or a Windows machine can get both: the agent for values from inside and a device profile for values from outside. The agent task then shows "Add checks from {profile}" — but only if the profile really measures something different from the agent (otherwise it would only repeat what happens anyway). If you choose both paths, the checks of both are created. If the profile lacks credentials (e.g. a Proxmox API token), the task "Add credentials" follows.

Bulk actions¶

For large networks:

Selection via the checkboxes → Retry or Don't set up for all selected; "Clear selection". Fully set-up devices cannot be selected; if devices are skipped during a bulk retry (in progress or already set up), that is stated in the bulk bar instead of a silent "0 retried".
"Commands for all N devices" on the "Install agent" group: a window with one Linux command per device — "Copy all" or "Save as file". For Windows devices use the per-row dialog.
Bulk confirmation of identical devices in "Confirm device type" (see above).
"Rescan all N" on the "No response" group.

Every action reports a failure directly on the row.

License host limit¶

If no further host fits the license (or it has expired), the run does not create the device silently: it lands under "Skipped" with the reason ("The license allows no further hosts (N of M in use) — "hostname" was not created"). Delete hosts or upgrade the license, then "Retry". Deleted hosts in the trash don't occupy a slot.

Stopping¶

"Stop setup" shows what that means beforehand: no further devices are set up, open tasks are dropped, hosts already created alert again. If devices already have a host but no checks yet, the dialog lists them: "Remove these empty hosts" cleans them up on request — otherwise they remain as empty entries and won't appear in any later run. Devices still awaiting their first assessment keep their unverified checks.

Summary and history¶

After the run, the Summary shows: "N of M devices set up", "N of them fully automatic", "N checks created", "N removed as dead", "N skipped", "N failed", "Left open: …" — with "View created hosts" and "Set up again". "Since the last run: N new unhandled devices" tells you whether a new run is worthwhile. "Show earlier runs" lists the summaries of past runs.