Your team lead drops a ticket on you: stand up a virtual machine for a new app. Four CPUs, eight GB of RAM, a hundred GB disk. You open the new VM wizard and a dozen fields stare back. Sockets or cores per socket? Thin or thick disk? E1000 or VMXNET3? Which SCSI controller? Nobody walked you through it, and choosing wrong in this exact spot is how a VM ends up slow, out of disk space, or sitting there with no network on its first morning.
Here is the calmer way to see it. A VM is a build-to-order computer where every part is a setting instead of a physical component. On a real PC you choose a processor, sticks of RAM, a drive and a network card, then screw them in. A VM has the same four parts, but you pick each from a menu, and you can resize most of them later without touching hardware. Learn to name those four parts and the one sane default for each, and that intimidating wizard turns boring. Boring is the goal.
The four parts, at a glance
Every VM you ever build is some combination of the same four virtual components, plus a small text file (the .vmx config) that records your choices. Here is the whole map before we zoom into each piece.
| Virtual part | Physical equivalent | What you set | Sane default |
|---|---|---|---|
| vCPU | The processor | Number of vCPUs, cores per socket | Start at 2, grow only if proven |
| vRAM | The memory sticks | Amount of memory | What the app docs ask for, no more |
| Virtual disk | The hard drive | Size, thin or thick, controller | Thin, on a datastore with room |
| Virtual NIC | The network card | Adapter type, port group | VMXNET3 |
vCPU: slices of a real processor
A vCPU is the part people misread the most. A virtual CPU is not a private, dedicated physical core that belongs to your VM. It is the right to be scheduled onto a real core whenever your VM has work to do. ESXi has a scheduler whose whole job is to take all the vCPUs from all the running VMs and hand them time on the host physical cores, in tiny slices, fast enough that every guest believes it has its own processors.
Sockets versus cores per socket
The wizard splits CPU into two boxes: number of vCPUs, and cores per socket. For almost every VM you will ever build, the simple answer is to set the total you want and leave cores per socket alone, which gives you that many single-core sockets. The setting exists for software licensed per physical socket, where you might present, say, 8 vCPUs as 2 sockets of 4 cores to fit a licence. If no licence is forcing your hand, do not overthink it. A VM does not run faster because you arranged its cores into a prettier shape.
More vCPUs is not more speed
Here is where I will disagree with the instinct every fresher has. When a VM feels slow, the reflex is to add vCPUs. Most of the time that makes things worse, not better. ESXi prefers to find enough free physical cores at the same moment to run all of a VM vCPUs together. Give a VM 8 vCPUs on a busy host and it now has to wait for 8 cores to come free at once, so it sits in a queue. That wait shows up as a metric called CPU Ready, the percentage of time a vCPU was ready to run but had to wait for a physical core. As a rough field rule, once CPU Ready climbs past roughly five percent per vCPU, users start feeling the lag. Oversized VMs are one of the most common causes of slowness I have seen junior admins create while trying to fix slowness.
The official maximums are huge. vSphere 8 supports up to 768 vCPUs on a single VM. You will almost never see double digits in a normal first job. Web servers, app servers and small databases usually live happily on 2 to 4. Start small, watch the actual usage, and grow only when the numbers prove you need to.
vRAM: configured is not the same as used
Virtual RAM is the amount of memory the guest OS believes it has. The number you type is the ceiling, not a permanent reservation of host memory. A VM configured with 8 GB might only actively touch 2 to 3 GB most of the day, and ESXi is smart about only backing the memory that is really in use. That lets a host run VMs whose configured memory adds up to more than the physical RAM installed, which is called memory overcommitment.
It works well right up until too many VMs get busy at once. When the host runs short, ESXi reclaims memory using techniques like the balloon driver, which is part of VMware Tools and politely asks the guest to give back pages it is not using. If pressure gets severe, the host falls back to swapping memory to disk, and that is when guests crawl. The practical lesson for a fresher is the same as with CPU. Do not pad memory for comfort. Give the VM what the application actually needs, leave overcommitment to the host to manage, and watch for memory pressure on the cluster rather than on one VM.
The virtual disk: a file that pretends to be a hard drive
The guest OS thinks it has a normal hard drive. In reality, that drive is a file (or a small pair of files) on a datastore, the shared storage ESXi uses. The format is VMDK. A typical virtual disk is a tiny descriptor file ending in .vmdk that holds the settings, plus a large flat file that holds the actual data. Delete the wrong VMDK and you delete a disk, so treat these files with respect.
Thin versus thick, the choice that catches people out
When you create a disk you choose how its space is allocated. The three options sound technical but the idea is simple.
| Disk type | What it does | Good for |
|---|---|---|
| Thin | Takes only the space data actually uses, grows on demand up to its size | Most VMs, labs, anywhere you want to use storage efficiently |
| Thick lazy zeroed | Reserves the full size up front, zeroes each block on first write | Steady workloads where you want space guaranteed |
| Thick eager zeroed | Reserves the full size and zeroes all of it immediately at creation | Cases that require it, such as certain clustering features |
The common advice you will read is blunt: use thick provisioning for anything performance-sensitive and avoid thin in production. I think that advice is dated for most workloads on modern all-flash storage, where the gap between thin and thick is small and the storage efficiency of thin is real money saved. I run thin by default and reach for thick only when something specifically asks for it. That is my opinion, and a senior admin at your shop may have a house rule that overrides it. Ask what the local standard is, then follow it.
Gotcha
Thin disks let you hand out more virtual disk space than the datastore physically has. That is fine until the VMs grow into it. If a datastore fills to 100 percent, every VM with a thin disk on it can freeze at once, because none of them can write. The classic trap is a forgotten log file or a runaway snapshot quietly inflating thin disks until the whole datastore hits the wall. Monitor datastore free space, not just per-VM disk size.
One more box on the disk screen is the SCSI controller, the virtual device the disk attaches to. New VMs often default to an LSI Logic SAS controller, which works everywhere. For a disk that will push heavy input and output, the VMware Paravirtual controller (PVSCSI) gives more throughput with less CPU cost, the same paravirtual idea you will meet again with the network card. For a normal first VM, the default is fine; remember PVSCSI exists for when a database team asks why their disk is the bottleneck.
The virtual NIC: where new VMs lose their network
The virtual network card connects the VM to a port group, which is its doorway onto the network. The choice that matters is the adapter type, and there are two you will meet constantly: E1000 (and its sibling E1000E) and VMXNET3.
E1000 is a software emulation of a real Intel gigabit card, the 82545EM. Its one advantage is that almost every guest OS already ships a driver for that chip, so the network works the instant the OS boots, no extra software needed. VMXNET3 is different. It is a paravirtual adapter, meaning it was designed for virtualization rather than pretending to be old hardware. It gives higher throughput and lower CPU usage, and it is what VMware recommends for nearly every modern guest.
Gotcha
Build a VM with a VMXNET3 card, install a fresh copy of Windows, and you may find it has no network at all. The reason trips up every fresher once: the guest OS does not ship a built-in VMXNET3 driver. That driver arrives with VMware Tools. So a brand-new install sees the card but cannot use it until Tools is installed. People burn an hour checking switches and port groups when the real fix is to install VMware Tools. I still pick VMXNET3 anyway, because the fix is one install and the payoff lasts the life of the VM.
VMware Tools: the part everyone forgets
VMware Tools is a small package you install inside the guest OS, and it keeps coming up because it quietly powers a lot of what makes a VM behave well. It supplies the paravirtual drivers for VMXNET3 and PVSCSI, the balloon driver that helps the host reclaim memory, time sync, a heartbeat that lets features like High Availability know the guest is alive, and the ability to take a clean, quiesced snapshot. A concrete tell that Tools is missing: in vCenter, the graceful Shut Down Guest and Restart Guest options are greyed out, because there is nothing inside the VM to receive that request. Treat installing VMware Tools as the last required step of every build, not an optional extra.
Worked example: right-sizing instead of guessing
Say your host has 2 sockets of 16 cores, so 32 physical cores. You are asked to run 40 small app VMs on it. The ticket template says 4 vCPUs each out of habit. That is 40 times 4, which is 160 vCPUs riding on 32 cores, a 5 to 1 ratio. Light apps can survive that, but the scheduler now has to line up 4 cores at a time for every VM, and CPU Ready creeps up across the cluster.
Now you check real usage and most of these VMs peak at well under 2 vCPUs. Drop them to 2 vCPUs each. That is 80 vCPUs on 32 cores, a 2.5 to 1 ratio, and each VM only needs 2 free cores to run, so it waits far less. Same hardware, same 40 VMs, noticeably snappier, just because you stopped handing out CPUs nobody used. Right-sizing is the cheapest performance fix you will ever make.
A weak answer just adds the vCPUs. A strong answer says: first I would look at the metrics before changing anything. I would check CPU Ready and actual CPU usage on that VM. If usage is low but Ready is high, the VM may already have too many vCPUs and is waiting for cores, so adding more would make it worse. I would also rule out memory pressure and slow storage, since both feel like a slow CPU to a user. Only if the VM is genuinely CPU-bound, with high usage and low Ready, would I add vCPUs, and I would do it in small steps. This shows you measure before you change, which is exactly the habit they are hiring for.
Try it yourself
You do not need a datacenter for this. Install the free VMware Workstation Player on your own machine, or use a nested ESXi lab if you have one. Create a new VM but do not install an OS yet. Open its settings and find all four parts: the vCPU count, the memory, the disk, and the network adapter.
Now the disk experiment. Create the virtual disk as thin, sized at 20 GB. Power the VM on, install a small OS, then look at the actual .vmdk file on your real disk. The check that you got it right: the file on disk is only a few GB, far smaller than 20 GB, because thin only stores what was written. Change the network adapter to VMXNET3 and notice whether the guest gets an IP before and after installing VMware Tools. Seeing the no-driver moment once means you will never be fooled by it on the job.
FAQ
Is a vCPU the same as a physical CPU core?
No. A vCPU is scheduled time on a physical core, not a core of its own. Many VMs share the same physical cores, and ESXi hands out slices fast enough that each guest feels like it has dedicated processors. Only under heavy contention does the sharing become visible as CPU Ready time.
How many vCPUs should I give a VM?
Start with the minimum the application asks for, often 2, and grow only when measurements prove it is CPU-bound. More vCPUs can slow a VM down on a busy host because it has to wait for that many cores to free up at once. Right-sizing beats guessing every time.
Thin or thick provisioning, which should I pick?
Thin for most workloads, since it uses only the space actually written and saves storage. Use thick when a specific feature or a local house rule requires it. Whichever you choose, watch datastore free space, because thin disks can overcommit a datastore and fill it.
Why does my new VM have no network?
The most common reason is a VMXNET3 adapter with no driver yet. That driver ships with VMware Tools, so a fresh OS install will not have network until you install Tools. Check that before you start blaming switches or port groups.
Can I change vCPU, RAM or disk after the VM is built?
Yes. You can grow a virtual disk and, on supported guests with the right settings, even hot-add CPU and memory while the VM runs. Shrinking is harder and riskier, which is another reason to start small and grow rather than oversize from day one.
Your move
You can now read any VM settings page and know what every box does and why. Next we leave the single VM and look at where its disk actually lives: datastores and the storage that holds every VM on the host.
Open the full VMware for Beginners guide and pick your next part.
References
- vSphere Configuration Maximums, Broadcom
- Choosing a network adapter for your virtual machine, Broadcom
- Installing VMware Tools, Broadcom TechDocs
About The Author
DrJha