Picture a small airport with three runways. Each runway can land and launch planes perfectly well by itself. A pilot can radio that one runway directly and get permission to land. Now add ten more runways and a few hundred planes a day. Nobody runs that airport by talking to each runway separately. They build one control tower that sees every runway, every plane in the air, and every gate, and decides where each plane goes.
In Part 3 you met ESXi, the runway. It runs your virtual machines and you can log into a single host directly through your browser. That works fine for one host. The moment you have three, or thirty, logging into each one separately and copying VMs around by hand stops being reasonable. vCenter Server is the control tower. This part explains what it is, what it gives you that a lone host cannot, and the one setup decision that quietly causes the most pain for beginners.
What vCenter Server actually is
vCenter Server is a management service. You point it at your ESXi hosts, and from then on you manage all of them, and every VM on them, through a single browser interface called the vSphere Client. Instead of opening one host at a time, you open one address and see your whole environment as a tree: data centers, clusters, hosts, and the VMs inside them.
The important mental shift is this. ESXi is where work happens. vCenter is where decisions happen. A VM never runs on vCenter. It runs on an ESXi host. vCenter watches the hosts, holds the inventory, enforces the rules you set, and gives commands. If vCenter goes offline for an hour, your VMs keep running, because the hosts are still up. You just lose the central view and the cluster features until vCenter comes back.
Why bother, if a host can run VMs alone?
Most tutorials gloss over this. vCenter is not just a convenience for looking at many hosts in one window. It is a hard requirement for the features that make VMware worth paying for. Without vCenter you have standalone hosts and nothing more. With vCenter you can group hosts into a cluster, and a cluster can do things a single host never can.
vMotion moves a running VM from one host to another with no downtime, so you can take a host offline for maintenance without anyone noticing. High Availability (HA) restarts your VMs automatically on a surviving host if a host dies. DRS balances load by deciding which host each VM should run on and moving them around as demand shifts. All three are covered in later parts. What matters now is that none of them work without vCenter, because something has to watch every host at once and make the call. That something is vCenter.
vCenter is an appliance now, not a Windows install
Older guides talk about installing vCenter on a Windows Server. Forget that. The Windows version was deprecated in vSphere 6.7 and removed entirely in 7.0. Since then there is one way to run vCenter: the vCenter Server Appliance, almost always shortened to VCSA. It is a ready-made Linux virtual machine, built on VMware’s own Photon OS, that you deploy onto an ESXi host. You do not install an operating system or a database yourself. It all comes inside the appliance.
There is a small mind-bender here that trips up beginners. vCenter is a VM, and it usually runs on one of the very hosts it manages. The control tower sits on top of a runway it is also controlling. This is normal and supported. It just means you bootstrap carefully: you deploy the appliance onto a host first, then let it adopt that host and the others into its inventory.
Deployment runs in two stages
The installer has two stages, and knowing this saves confusion when you watch someone do it. Stage 1 copies the appliance onto a host and powers it on. Stage 2 configures it: network details, the time source, and the identity domain. You also pick a size up front, based on how many hosts and VMs you expect to manage. You can grow later, but you cannot shrink, so people tend to start small.
The sizing choice maps to real limits. Here are the two smallest tiers, which cover most labs and small production setups.
| Size | Manages up to | vCPU | RAM |
|---|---|---|---|
| Tiny | 10 hosts / 100 VMs | 2 | 14 GB |
| Small | 100 hosts / 1,000 VMs | 4 | 21 GB |
Login domain: where beginners hurt themselves
When you log into vCenter, you are not logging into a host. You are logging into a built-in identity system that came with vCenter, historically called Single Sign-On (SSO). It has its own little directory of users, and that directory lives in a domain. During setup, vCenter asks you to name that domain, and it suggests a default: vsphere.local. The first account you use is usually administrator@vsphere.local.
This is worth going deeper on, because it is the single most common self-inflicted wound for newcomers. Here is the trap. Your company already has an Active Directory domain, say company.local, and it feels tidy to name the vCenter SSO domain the same thing so everything matches. Do not do this. If the vCenter SSO domain name collides with your real Active Directory domain name, authentication gets confused about which directory owns a user, and you end up with login failures that are genuinely annoying to untangle. The fix is to never let them match in the first place.
Clock skew: the error you will hit
The other thing that breaks vCenter setup and ongoing logins is time. vCenter, its identity system, and the ESXi hosts all sign certificates with timestamps. If the clock on vCenter and the clock on a host drift apart by more than a few minutes, the certificates look invalid and you get cryptic failures during stage 2 or when adding a host, often phrased as a clock skew or certificate validation error. The real cause is almost never a broken appliance. It is that NTP, the network time service, was not set the same on both ends. Point vCenter and every host at the same time source and the problem disappears. This one fact will save you an afternoon someday.
How big can one vCenter get?
A single vCenter Server in vSphere 8 is rated to manage up to 1,000 ESXi hosts, 40,000 powered-on VMs, and 45,000 registered VMs. If you need more, you can link up to 15 vCenter Servers together and see them in one view, reaching 15,000 hosts and well over 100,000 VMs across the group. These are tested ceilings, not targets. Most companies run far below them.
Worked example
Say a company is consolidating 10 old physical servers onto 2 new ESXi hosts. Each old box averaged 1 app, lightly used. The 2 hosts have plenty of CPU and RAM to hold all 10 as VMs with room to spare. How much vCenter do they need? 2 hosts and roughly 10 to 20 VMs sits comfortably inside the Tiny tier (10 hosts, 100 VMs). They could deploy a Tiny VCSA on the first host, 2 vCPU and 14 GB RAM, and never come close to a limit. The lesson: for small environments, the constraint is your host hardware, not vCenter. vCenter only becomes a sizing conversation at hundreds of hosts.
Real interview question
"What is the difference between ESXi and vCenter, and can you do vMotion without vCenter?"
Answer it cleanly: ESXi is the hypervisor that runs VMs on a single physical server; vCenter is a separate management server that controls many ESXi hosts from one place. Then nail the second half, because it is the real test: no, you cannot do vMotion, HA, or DRS without vCenter, because those features need something watching all the hosts at once and coordinating between them, and that coordinator is vCenter. A standalone host can run VMs but cannot move them to another host on its own. Saying this shows you understand why vCenter exists, not just what it is.
Try it yourself
You do not need vCenter to feel why it exists. On a free home lab, install ESXi (nested inside VMware Workstation is fine, covered properly in Part 17), then open the host directly in a browser at https://your-host-ip/ui. This is the ESXi Host Client. Create a small VM and poke around.
Now look for what is missing. You will find menus to create, start, and stop VMs, but you will find no vMotion, no cluster, no HA, no DRS anywhere. That absence is the lesson. Those options only appear once a vCenter is in charge. How to check you got it right: if you can power a VM on from the Host Client but cannot find a single "migrate to another host" option, you have correctly seen the ceiling of a standalone host.
What your first week in the vSphere Client looks like
Once vCenter is up, almost everything you do as a junior happens in the same left-hand tree. You expand the data center, find a cluster, open a host, and click into a VM. The four actions you will use most in week one are power on, power off, open the console, and the snapshot menu. Clicking around a test VM is the fastest way to get comfortable, and it is hard to break anything by looking. The thing that surprises new joiners is how much of vCenter is just right-click. Right-click a VM and you get its whole life in one menu: power, snapshot, migrate, edit settings, clone. Right-click a host and you get maintenance mode. Learning those right-click menus is honestly half the day-to-day job.
FAQ
Is vCenter free?
No. ESXi has a basic free path historically, but vCenter is a licensed product, now sold by Broadcom as part of a vSphere subscription. There is no free vCenter for production. For learning, you use time-limited evaluation licenses, which give you the full feature set for 60 days.
Do I need vCenter just to run a few VMs?
No. A single ESXi host runs VMs perfectly well on its own through the Host Client. You only need vCenter when you have multiple hosts to manage together, or when you want vMotion, HA, or DRS.
What is the difference between vSphere and vCenter?
vSphere is the name of the whole product suite. ESXi and vCenter are the two main pieces inside it. So vCenter is a component of vSphere, not a separate product line.
Can vCenter run as a virtual machine on the host it manages?
Yes, and that is the normal setup. The VCSA appliance runs as a VM, usually on one of its own managed hosts. You just deploy it onto a host first so it has somewhere to live before it adopts the rest.
Can I still install vCenter on Windows?
No. The Windows version was deprecated in vSphere 6.7 and removed in 7.0. The appliance (VCSA) is the only option now, and it is simpler anyway because the OS and database are built in.
References
- VMware vSphere 8.0 documentation, Broadcom TechDocs
- vSphere Configuration Maximums, Broadcom
- vSphere 7.0 Release Notes (Windows vCenter removal), Broadcom
About The Author
DrJha