A teammate pings you at 4 pm: the developers need a fresh test server by morning, nothing fancy, just somewhere to run their app. Six years ago that meant a purchase order, a week of waiting, and a new box humming in a rack. Today you open vCenter, click New Virtual Machine, answer a few questions, and the server exists before your coffee gets cold.

Think of the wizard like the configurator on a laptop-buying website. You are not soldering chips. You are choosing options from menus: how many cores, how much memory, how big a drive, which operating system. The hardware already sits in the datacenter as a shared pool. You are carving off a slice and giving that slice a name.

This part walks through every page of that configurator, then spends most of its time on the two decisions that separate a fresher from someone who knows what they are doing: sizing and disks.

The New Virtual Machine wizard, one page at a time

In vCenter you right-click a host, cluster, or folder and choose New Virtual Machine. The wizard that opens is the same shape whether you are on vSphere 8 or the newer Broadcom-era builds. There are seven pages, and each one asks a single, narrow question. The wizard will not let you skip ahead until the current page is answered, so you cannot get lost.

Page 6 matters more than it looks. Selecting the guest OS does not install anything. It tells ESXi what to expect so it can pre-select the right firmware (BIOS or UEFI), the right default disk controller, and the right network adapter type. Pick the wrong one and the OS may refuse to boot, or it may run with a slow emulated NIC instead of the fast paravirtual vmxnet3 driver. Two minutes of care on this page saves an afternoon of confused troubleshooting later.

Sizing the VM: the part almost everyone gets wrong

Here is the instinct every fresher has, and it is wrong: when in doubt, give the VM plenty of CPU and RAM so it never runs short. On a physical PC that logic holds, because the cores are yours alone. On a shared host it backfires, and understanding why is the single most useful thing in this whole guide.

Why more vCPUs can make a VM slower

The ESXi scheduler runs a multi-vCPU VM by lining up its virtual CPUs against real physical cores. The more vCPUs a VM has, the more physical cores must be free at the same instant for it to get a turn. A VM with 24 vCPUs on a 28-core host has to wait until 24 cores are free together before it can run even one cycle. While it waits, it sits frozen, even though it looks idle in the guest. The metric for this in ESXi is co-stop, shown as %CSTP. Anything that stays above about 3 percent is a flashing sign that the VM has more vCPUs than it can use. The fix is almost always to remove vCPUs, which feels backwards the first time you do it.

VMware gives a soft guideline of roughly three vCPUs per physical core across a host before contention starts to bite, but that is a ceiling, not a target. The sane starting point for almost any new VM is 2 vCPUs. Prove with monitoring that the VM is genuinely CPU-bound before you add more.

This is where I disagree with the cautious advice you will hear from developers and even some vendor sizing sheets. Do not size for the worst day you can imagine. Size for the normal day and add capacity when monitoring proves you need it. A right-sized 2-vCPU VM with 1 percent CPU ready beats an 8-vCPU VM that spends its life waiting for cores to line up. Growing is cheap because of hot-add, which we get to below. Shrinking is hard, not technically, but politically, because nobody believes you when you tell them fewer vCPUs made their server faster. Believe the numbers anyway.

Treat those as starting points, not laws. The point is to begin low and let real numbers, not nerves, decide the rest. Resource controls like shares and reservations, covered in Part 12, are what you reach for when a host gets crowded.

Disks: thin or thick, and what the default really is

On page 4, and again on the hardware page, you choose how the virtual disk sits on storage. There are three options and the names sound harder than the idea. A thin disk consumes only the space actually used and grows as data is written. A thick lazy zeroed disk reserves all its space up front but only writes zeros to each block the first time the guest touches it. A thick eager zeroed disk reserves and zeros the entire space at creation, which takes longer to make but shaves a little latency off the first write to each block.

The default trips people up. On a normal VMFS datastore the wizard defaults to thick provisioned lazy zeroed. On an NFS datastore it usually defaults to thin. So the exact same click can give you very different behavior depending on where the VM lands, which is precisely the kind of detail nobody mentions until a datastore fills up at the wrong moment.

For almost everything, use thin. The old worry that thin disks are slow has not held on modern storage arrays for years. The one real cost of thin is that you must watch datastore free space, because ten 100 GB thin disks can be provisioned on a 500 GB datastore and quietly grow until the datastore is full and every VM on it freezes at once. That is the trade: thin saves space but moves the risk onto your monitoring. Thick eager zeroed still earns its place for latency-sensitive databases and a few clustering features, and almost nowhere else.

From empty VM to a working machine

When the wizard finishes, you have an empty computer with no operating system, the same as a PC with a blank drive. To install one, you point the VM virtual CD-ROM at an ISO image (a single file that is a copy of an install disc), power the VM on, and it boots from that ISO just as if you had inserted a real disc. From there you click through the OS installer like you would on any laptop.

Install VMware Tools first, not last

The moment the operating system finishes installing, install VMware Tools. It is a small package of drivers and helpers that the guest OS does not ship with on its own. Without it the guest technically runs but behaves badly: the wrong screen resolution, a laggy mouse in the console, no clean shutdown from vCenter, no time synchronization, and a slow emulated network card instead of the fast vmxnet3 driver. With it, the guest reports its name and IP back to vCenter, syncs its clock, and supports the quiesced snapshots that backups rely on.

Here is the one that catches freshers. Without VMware Tools the Shut Down Guest and Restart Guest buttons in vCenter are greyed out or simply do nothing, because there is no agent inside the guest to receive the request. New admins then click Power Off instead, which is the equivalent of yanking the plug from a running machine, and later wonder why a database came back with a dirty shutdown. Install Tools and those graceful options light up. On Linux the package is usually open-vm-tools and installs from the normal repositories in one command.

Day-to-day management

Once a VM exists, most of your time goes on a handful of operations: power on, power off, open the console, and edit settings. The Edit Settings dialog is where you change CPU, memory, disks, and network after the fact. On a running modern guest you can often add CPU and memory without a reboot if hot-add is enabled, though removing them still needs a power cycle. Notice the asymmetry: growing is easy and online, shrinking needs downtime, which is one more reason to start small. Where the VM physically runs is handled for you by the cluster, as covered in Part 11 on DRS.

FAQ

How many vCPUs should a new VM have?
Start with 2 unless the application vendor states otherwise. Add more only after CPU ready or co-stop metrics show the VM is short of CPU. More vCPUs do not make a VM faster on their own and can make it slower on a busy host.

Thin or thick provisioning, which is better?
For most VMs, thin. It saves space and performs well on modern storage. The catch is you must monitor datastore free space, because thin disks grow and can fill a datastore. Use thick eager zeroed only for latency-sensitive databases or where a feature requires it.

Do I really need VMware Tools?
Yes. The VM boots without it, but you lose clean shutdown, time sync, the fast network and display drivers, and proper guest reporting in vCenter. Install it as soon as the OS is up, every time.

What is the difference between Power Off and Shut Down Guest?
Power Off is like pulling the plug, instant and unsafe. Shut Down Guest asks the operating system to close down properly through VMware Tools. Always use Shut Down Guest unless the VM is frozen and will not respond.

Can I change CPU and RAM after the VM is built?
Yes, in Edit Settings. With hot-add enabled you can often increase CPU and memory on a running VM. Decreasing them, and most other hardware changes, needs the VM powered off.

The takeaway

Building a VM is the easy part; any wizard can do that. The skill is in the choices. Start small, grow with evidence, prefer thin disks while watching your datastores, and install VMware Tools every single time. Do that and you sidestep the three problems that fill the help desk queue: oversized VMs that crawl, datastores that fill without warning, and guests that will not shut down cleanly. When you are ready to go further, the same building blocks scale up into automated provisioning in the advanced VCF Automation series, and they sit underneath everything in the companion Cloud for Beginners guide.

Next we look at the difference between a snapshot and a real backup, and why confusing the two has ended careers. Bookmark the full VMware for Beginners guide and work through it in order.

References

• Broadcom TechDocs: Create a Virtual Machine with the New Virtual Machine Wizard
• Broadcom KB: Installing and upgrading VMware Tools in vSphere
• VMware Cloud Foundation blog: Virtual Machine vCPU and vNUMA Rightsizing Guidelines

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts