Small hosting teams and managed service providers often want to run several client environments on a single physical server. It is efficient, and it lets a small team offer dedicated-style resources without buying a server per client. It also carries risk. Without a deliberate layout, one client’s backup job can slow down everybody else, and a single configuration mistake can expose one customer’s traffic to another.
This guide describes a practical layout for a single VMware ESXi host: how to separate networks, share resources, plan storage and protect the data. It assumes you already know the basics of the hypervisor and want a design that can be repeated for each new client.
Check the Licensing Before You Design Anything
Start with the commercial question, because it can change the whole plan. Licensing for VMware products has changed significantly in recent years, including the way products are bundled and how they can be used in service provider scenarios. Find out which edition you are entitled to, whether your use counts as hosting for third parties, and which features that edition includes. Host-level isolation features, backup APIs and central management may not be available in every licence.
Treat the VMware vSphere documentation as the technical reference, but take licensing answers from the vendor or an authorised partner, in writing. A hosting provider that supplies the server may not supply the licence, so clarify who is responsible for what before signing anything.
Separate the Networks
Network design is where most isolation mistakes happen, so give it the most care. A simple pattern works well for small hosts:
- One port group per client, each mapped to its own VLAN or to a private network created by a virtual firewall.
- A virtual firewall or router per client, or one shared appliance with strict rules, acting as the only path in and out of each client network.
- A separate management network for ESXi itself, which should never be exposed directly to the public internet. Reach it through a VPN or a restricted out-of-band path.
- A separate network for backup and storage traffic, so that nightly jobs do not compete with client traffic.
On a virtual switch, leave promiscuous mode, MAC address changes and forged transmits rejected unless a specific appliance needs them. Then test the layout. Put a test machine in one client network and confirm that it cannot reach another client, the management interface or the backup network.
Share CPU, Memory and Disk Fairly
Without limits, the busiest virtual machine gets the most resources. Resource pools let you express a policy that matches what each client has paid for.
|
Resource |
Setting |
Practical guideline |
|
CPU |
Shares and optional limits per client pool |
Avoid giving a VM more vCPUs than it needs, because oversized VMs can wait longer to be scheduled |
|
Memory |
Reservations for critical VMs |
Keep total allocated memory at or below physical RAM unless you have tested overcommitment carefully |
|
Disk |
Storage I/O limits per VM |
Cap the heaviest workloads so backups and databases cannot starve others |
|
Network |
Traffic shaping on port groups |
Set limits for clients with bursty transfers |
Watch ready time on CPU and latency on datastores, since these show contention before clients notice. If ready time climbs consistently, you have too many busy vCPUs for the host, whatever the average utilisation looks like.
Plan the Storage Layout
Storage decides how well the host copes when several clients are busy at once. Use fast NVMe where you can, with hardware or software redundancy suitable for your edition and hardware. Check drive and controller compatibility before you order, as ESXi support for controllers can be stricter than for general Linux.
Keep it simple:
- One datastore for production virtual machines, with enough free space for snapshots and growth.
- A separate volume for backup staging, if backups stay on the host for any time.
- A clear policy on snapshots. They are not backups, and long-lived snapshots slow down write performance and consume space quickly.
Leave free capacity on purpose. A datastore that fills up can pause VMs across all clients, so alert well before that point and review the trend every month, because backup staging and forgotten snapshots tend to grow quietly.
Backups and Failure Planning
One host means one shared failure domain, and clients should know this. A sensible plan has three parts. First, take image-level backups of each client’s VMs and store them away from the host. Second, test a restore each month, ideally onto different hardware. Third, write down the recovery order, so that if the server fails, you know which client comes back first.
When a host has grown beyond a handful of clients, the risk may justify a second server for replication. Decide on the trigger for this in advance, such as a total number of clients or a contractual recovery time, rather than after a failure.
Choosing the Physical Server
For this role, memory is usually the first limit you hit, followed by storage performance, and then CPU. Look for plenty of RAM, NVMe drives on a supported controller, a remote console such as IPMI, and network ports with enough capacity. Check that the provider supports the hypervisor on that hardware. A specialist esxi dedicated server hosting offer can save time here, as compatible hardware and remote console access are normally part of the package, but licence responsibility should still be confirmed separately.
Before going live, run the checks that matter:
Once this template works, you can add clients by repeating it: a new port group, a new firewall, a new resource pool and a new backup job. Repeatability is the real benefit, because it lets a small team manage more environments without inventing a new design each time.
