Branch office with ESXi hosts — with and without vCenter in Veeam? (English)

Recently a customer asked me: “Is it actually a problem if I add a branch office with ESXi hosts that are managed by a vCenter to Veeam as standalone hosts instead of adding the vCenter? What impact does that have?”

The short answer: Yes, it can have noticeable impact — functionally, operationally, and also in terms of backup consistency when VMs are moving (with vMotion). Best practice in general is to add the vCenter as the management instance in Veeam, not the individual ESXi hosts.

Okay, but why?

What is vCenter — and why is it more than “just” a GUI?

vCenter Server is the central management instance for VMware vSphere environments. It centrally manages objects such as clusters, hosts, VMs, folders, resource pools, tags, roles/permissions, HA/DRS, and many automation features.

For backup solutions, vCenter is important because it provides a stable, always up-to-date inventory and object referencing ID (keyword: MoRef).

Moe? Like that bartender from The Simpsons?

Äh no — that’s Moammar "Moe" Szyslak by the way. But we’re getting off topic.

MoRef ID stands for Managed Object Reference ID. VMware assigns a unique identifier to every object in its inventory (since vSphere 4.0), and that identifier is the MoRef ID. Using this ID, you can address an object via vCenter, and then it doesn’t matter which host the object is currently running on. Alternatively, you can address an object directly via an ESXi host — but in that case the ID can change as soon as a VM moves from one host to another (vMotion), due to the fact that each ESXi Host has his own MoRef ID table.

Ok ok, so I need this vcenter only for this complete cluster aware MoRef ID and nothing else?

Core VMware features that typically only make “proper” sense with vCenter

No. Many vSphere features only really come into play with vCenter — or can only be used with it. These include:

• vMotion
• HA (High Availability)
• DRS (Distributed Resource Scheduler)
• Cluster objects and policies
• Centralized RBAC (roles/permissions)
• Inventory structure (folders, resource pools) and tags
• …and many more....

These things are not just “nice to have” — they also affect how well the backup system can integrate with the platform. They determine which hypervisor features the backup solution can leverage and how reliably it can discover and track virtual workloads.

Licensing / API foundation: Free ESXi cannot be backed up (agentless)

Before even discussing standalone vs. vCenter configurations, one thing must be 100% clear:

From a Veeam backup perspective, a standalone ESXi host must be a licensed ESXi edition. The free ESXi version is not supported by Veeam because VMware has disabled the required APIs (vStorage APIs) for agentless backups. So if you are using the free ESXi version, you must either license the ESXi host or switch to an agent-based backup approach.

Veeam with standalone ESXi only: what limitations do typically show up?

When Veeam only knows standalone ESXi hosts, it sees each host in isolation rather than as part of a unified cluster. As a result, Veeam is limited to the perspective and identifiers of each individual ESXi host.

This leads to a few practical issues:

• Environmental changes (VMs moved to another host, hosts replaced, ...) more quickly result in manual rework.
• Backup job design and structuring is less elegant. For example: “everything in folder X” or “everything with tag Y” is not possible without the vCenter inventory context.

VM migrations: Veeam detects the VM as “new” instead of “known”

In a standalone scenario, the VM identity is tied to the identifiers coming from the individual ESXi host. If a VM moves from Host A to Host B or is re-registered (regardless of whether it’s done manually in powered on or off state, via HA, or via DRS), Veeam may no longer recognize it as the same object. From Veeam’s perspective it appears as a new VM on the target host, which means it needs to be added to backup again.

Impact:

• The VM shows up as missing in the backup job on Host A.
• The “new VM” must be added again to the backup job on Host B.
• Veeam cannot continue the existing backup chain because it’s treated as a different VM object, which triggers a new full backup (new chain).
• If the VM moves back to Host A, the jobs have to be adjusted again and another new chain/full backup is necessary.

More administrative effort for accounts/permissions

With vCenter, you can create a central service account and manage permissions and passwords centrally. This significantly simplifies credential management in Veeam.

With several hosts, this isn’t possible: you have to maintain at least one account per host (including password changes/rotation per host).

Limitations for dynamic VM selection (tags/folders/resource pools)

Many customers deliberately use dynamic job scopes in Veeam to assign VMs to the right backup jobs with the desired RPO/RTO and data protection requirements, for example:

• “Back up all VMs with tag Backup=Gold like this”
• “Back up everything in folder Branch01 with this policy"
• “Do not Back up resource pool Test”

Without vCenter, these kinds of filters cannot be configured. As a result, backup job handling becomes much more inconvenient and static (manual VM lists). That may be manageable in very small branch offices at first, but it quickly becomes time-consuming as soon as the environment changes or grows.

Veeam CDP (if relevant): a vCenter-based use case

Also Veeam CDP (Continuous Data Protection) in VMware environments is tightly coupled to vSphere/vCenter integration and is not feasible with Veeam when using standalone ESXi hosts only.

With vCenter, everything will be fine

Bottom line: with vCenter, day-to-day operations become significantly easier — less manual maintenance, more stable VM mapping, and overall fewer surprises when VMs move between hosts via vMotion/HA/DRS. Of course, Veeam needs proper connectivity to vCenter, including the right network routes, DNS/name resolution, and the required firewall ports opened. In practice, this is typically TCP 443 (vCenter/ESXi API). Depending on which Veeam features you use, additional ports may be required, for example CDP (e.g., 33034/33035) or PowerNFS (e.g., TCP 111, 1058+, 1063+, 2049+). The exact ports always depend on the backup design and the veeam version in use — the Veeam documentation is the best reference here.