Reference
snagent Hypervisor Host Agent
The userspace CloudStack KVM host agent for qualified host-assisted backup modes: no kernel driver, no DKMS module, and no CloudStack plug-in to maintain.
The Key Point
snagent is a single Sendense program that runs in user space on supported CloudStack KVM hypervisor hosts, started and supervised as an ordinary system service. It exists to make the qualified host-assisted backup modes possible.
It is not a kernel driver and it is not a DKMS module. Nothing is compiled against your running kernel, nothing is inserted into it, and nothing has to be signed for it or matched to its ABI.
It replaces nothing you already run. The CloudStack KVM agent, KVM, libvirt, QEMU and the host kernel all keep doing exactly what they did before; snagent works alongside them through their supported userspace interfaces.
One userspace binary
snagent ships as one userspace program. The only operating-system package its installer adds is libnbd, a userspace library and its command-line tools.
Why A Host Agent Is Needed
Storage backends expose changed-block information in different ways, and some expose it only on the host that holds the data. Something running on the host can ask each backend for that information in the form that backend actually supports, instead of guessing from outside.
At backup time snagent prepares a temporary point-in-time snapshot of the protected disk, identifies the changed extents for an incremental or the allocated extents for a full, hands snapshot access and that extent information to the SNA, and then removes the snapshot and its tracking state.
Because the SNA is told which regions matter, it reads only those extents rather than every region of the disk on every run.
snagent never carries backup payload. The SNA remains the backup proxy and owns all data movement; snagent only prepares the source and describes it.
Host-assisted backup on a supported backend
On the host
Consistent Snapshot
snagent prepares a temporary point-in-time snapshot of the protected disk using the mechanism appropriate to the configured backend.
Changed or allocated
Extent Collection
snagent collects the changed extents for an incremental, or the allocated extents for a full.
Backup proxy
SNA Reads Extents
The SNA receives snapshot access and the extent information, and reads only the identified extents.
After the backup
Host Cleanup
snagent removes its host-side snapshot and checkpoint state so no stale artifacts accumulate.
Where snagent Runs
snagent runs on supported CloudStack KVM hypervisor hosts as a normal system service. Installation is a one-line command generated by SHA and gated by a single-use install token; it places the agent on the host, adds the libnbd tooling if it is missing, enrolls the host, and starts the service.
Each agent makes its own outbound HTTPS connection to exactly one SHA for enrollment, health, configuration and update downloads. SHA never opens a connection back to the host, so hypervisor hosts need no inbound rules for Sendense management.
Agents on different hosts coordinate with each other over mutually authenticated TLS, using certificates issued by a Sendense-managed private authority and a trust list SHA distributes. That channel carries a fixed set of Sendense backup operations. It is a controlled product protocol, not a remote shell, and it grants no general administrative access to the host.
Sendense reaches CloudStack itself through a scoped API account used for discovery and orchestration. There is no Management Server component and no Backup and Recovery Framework plug-in anywhere in this design.
snagent placement and connectivity
Every host agent connects outbound to exactly one SHA. Agents coordinate host-to-host over mutual TLS, and each agent hands snapshot access to the SNA on its own host.
Text equivalent
- Each hypervisor host runs one snagent in user space, next to the SNA that reads the local data copy.
- Every agent connects outbound to exactly one SHA. SHA never dials into a hypervisor host.
- Agents on different hosts coordinate with each other over mutually authenticated TLS for a fixed set of backup operations.
- Snapshot access is handed to the SNA on the same host; the SNA, not snagent, moves the backup data.
Exactly one hub per agent
The agent belongs to whichever SHA issued its install token and holds a single hub identity. In service-provider deployments that should be the provider-managed SHA - never a tenant SHA.
Peer coordination, not remote administration
Host-to-host requests are limited to Sendense backup operations such as preparing a snapshot, returning extent information and cleaning up afterwards. There is no shell, no arbitrary command execution and no general host administration on that channel.
- Not inside protected VMs. snagent installs nothing in your workloads.
- Not on the CloudStack Management Server, and not inside the CloudStack Backup and Recovery Framework.
- Not in the kernel. It runs in user space, like any other service on the host.
What snagent Interfaces With
Everything snagent touches on the host is a supported userspace interface that your platform already provides. There is no private hook into the hypervisor and no kernel-side integration.
Is snagent A Kernel Driver?
No. A kernel driver runs inside the kernel itself, must be built for the exact kernel it loads into, has to satisfy that kernel's module-signing policy where Secure Boot is enforced, and is usually rebuilt by DKMS every time the kernel changes. snagent does none of that: it is an ordinary userspace program with normal process isolation and normal service management.
- No module is inserted into the kernel. None is built for your kernel, signed for it, or registered for automatic rebuild.
- No inline block filtering of guest I/O. snagent does not sit in the path of a running VM's reads and writes; it works from the temporary snapshot taken for the backup.
- The kernel-sensitive parts of third-party storage components, such as the kernel module a DRBD deployment uses, are neither installed nor supplied by Sendense. They belong to your storage platform and keep their own lifecycle and support boundary.
- The only operating-system package the installer adds is libnbd, in user space.
Host And Kernel Upgrades
Because there is no kernel component, there is nothing to rebuild, nothing to re-sign and no ABI to match when you patch a host. Routine kernel updates and reboots never require removing, disabling or reinstalling snagent, and there is no module that can fail to load on the next boot.
Larger changes are still worth planning. A major operating-system release, hypervisor version or storage-platform change should be validated as a supported combination before it is rolled out fleet-wide, exactly as you would validate it for the rest of your virtualization stack.
After any host maintenance, confirm the agent on that host is healthy and checking in to SHA, then run a backup of a representative VM on that host before you treat it as fully back in service.
CloudStack Upgrades
There is no Sendense plug-in inside CloudStack, so a CloudStack upgrade has nothing of ours to migrate, re-register or re-enable. What it can change is the environment around Sendense, so verify the following afterwards.
- Confirm the new CloudStack and hypervisor combination is supported for the host-assisted modes you use.
- Re-verify the scoped CloudStack API account and its permissions; upgrades can alter roles, accounts and what an API user is allowed to see.
- Re-run discovery and confirm your protected VMs and their storage still resolve as expected.
- Confirm every host agent is healthy and checking in.
- Run a representative backup before you call the upgrade complete.
Rolling Host Maintenance
Host maintenance follows your normal rolling pattern; snagent adds a health check and a test backup at the end rather than a special procedure of its own.
- Drain the host: migrate or shut down its VMs as you normally would.
- Put the host into its CloudStack maintenance state.
- Apply the host update and reboot if the update requires it.
- When the host returns, verify the agent is running and healthy.
- Verify the agent has checked in to SHA and reports its expected version.
- Run a test backup of a VM on that host.
- Return the host to normal service and move to the next one.
- On locality-bound storage such as LINSTOR DRBD, a VM's backup must run where a usable copy of its data lives and an SNA is available, so plan how many data-holding hosts are out at the same time.
Jobs fail loudly rather than switching quietly
While a required agent is unavailable, qualified host-assisted jobs that depend on it fail with an explicit error. Sendense does not silently move those jobs onto a different path, so nothing changes the shape of your protection behind your back.
How snagent Updates Itself
You set one target version for the fleet in SHA. Each agent learns that target at its next check-in, so there is nothing to push to hosts and no separate distribution mechanism to run.
The agent downloads the new build over its own outbound connection and verifies it against the checksum SHA published for that version before staging it. An unverified download is never applied.
If backup work is in flight on that host, the agent defers the update and retries later. It does not interrupt a running backup to update itself.
Applying the update is health-gated. After the swap, the agent must come back, report the expected version and answer its health check. If it does not, the previous version is restored automatically and the outcome is reported back to SHA so you can see what happened.
When snagent Is Required
QCOW NFS, ZFS, and LINSTOR DRBD host-assisted modes require a healthy, correctly placed snagent and can fail if it is unavailable. Those three are the qualified CloudStack KVM host-assisted modes, and the agent is what prepares the source and supplies the extent information they depend on.
It is not required for full-source-read protection. RAW Block does not use snagent and follows the full-source-read EBA path with repository deduplication.
So snagent is not needed in every Sendense deployment. It is needed wherever you want the qualified host-assisted modes on CloudStack KVM.
What snagent Is Not
- Not a kernel driver. It runs in user space and puts nothing inside the kernel.
- Not a DKMS module. Nothing is compiled against your kernel or rebuilt when that kernel changes.
- Not the CloudStack KVM agent, and not a replacement for it. That agent continues to do its own job.
- Not a CloudStack Management Server component and not a Backup and Recovery Framework plug-in.
- Not a guest agent. It runs on the hypervisor host, not inside protected VMs, and installs nothing in your workloads.
- Not the SNA. The SNA is the backup proxy appliance; snagent is a host-side helper for it.
- Not a data mover. Backup payload is carried by the SNA, never by snagent.
- Not a remote administration agent. Its peer channel carries a fixed set of Sendense backup operations, not shell or general host control.
Summary
snagent is a userspace service on supported CloudStack KVM hosts. It uses the interfaces your platform already supports - libvirt, the QEMU guest agent, ZFS, LINSTOR, and the QEMU and libnbd tool families - to prepare a temporary snapshot and describe which regions the SNA should read.
Data movement stays where it always was, in the SNA. Because there is no kernel component and no CloudStack plug-in, snagent sits outside your kernel-driver and Management Server lifecycles: patch hosts on your normal schedule, upgrade CloudStack on its own schedule, and verify agent health and one backup afterwards.
Related Docs