Virtual machine creation and management. This is the single most important skill you need to master for the VCP-DCV exam because nearly everything else—networking, storage, availability, security—builds on top of the virtual machine. If you cannot create, configure, and manage a VM correctly, you cannot pass the exam or do the job.
Jump to a section
A simple way to picture Virtual Machine Creation and Management
12 flats in a single Victorian terrace. Each flat shares the same physical structure—the same roof, the same plumbing stack, the same electrical mains—but every flat is a completely independent home. One family might have a modern kitchen, another might keep the original fireplace; one flat might run a small business from the living room, while another is just a bedroom for one person. The landlord can create a new flat by partitioning off a spare room, install a separate front door, and give it its own utilities meter. That new flat behaves exactly like every other flat: it can be locked, furnished, decorated, and occupied independently. If the tenant stops paying rent, the landlord can “power down” that flat without affecting the neighbours. The crucial point is that all 12 flats rely on the same foundation, the same water pipes, and the same electrical wiring—yet each tenant feels like they own the whole building. This is precisely how virtual machines work. A single physical server (the Victorian terrace) hosts many virtual machines (the flats), each with its own operating system, applications, and data, all sharing the underlying hardware without knowing the others exist.
At its simplest, a virtual machine (VM) is a software computer that runs on top of a physical computer. The physical computer is called a host, and the software that makes VMs possible is called a hypervisor. The hypervisor is a thin layer of software that sits between the physical hardware (CPU, memory, storage, network) and the VMs. It allocates physical resources to each VM and ensures that one VM cannot interfere with another.
Before virtualisation, every physical server ran a single operating system (OS) and a single application. This was wildly inefficient. A typical physical server might use only 10-15% of its capacity, while the rest of the hardware sat idle. IT teams had to buy, power, cool, and manage dozens or hundreds of underutilised servers. This model, called physical bare-metal deployment, cost a fortune and wasted space and electricity.
Virtualisation replaced that model by letting you run many VMs on one physical host. Each VM contains its own OS (called a guest operating system), its own virtual hardware (virtual CPU, virtual memory, virtual disk, virtual network card), and its own applications. From the perspective of a user or an application, a VM looks and behaves exactly like a physical computer. You can install Windows Server 2022 on one VM, Ubuntu Linux on another, and CentOS on a third—all on the same physical host.
When you create a VM in VMware vSphere, you go through a wizard that asks you to specify:
Name and folder: a human-readable name and a location in the vSphere inventory.
Datastore: where the VM’s files (configuration, virtual disk, logs) will be stored. A datastore is a logical container that sits on physical storage (SAN, NAS, local disks).
Guest OS family and version: tells the hypervisor what type of OS will be installed so it can optimise certain behaviours.
Virtual hardware: how many virtual CPUs (vCPUs), how much memory, how much virtual disk space, and which network to attach to.
Once the VM shell is created, you mount an ISO file (a disk image of an OS installer) and boot the VM. You install the OS exactly as you would on a physical machine—except you control it remotely from the vSphere client. After the OS is installed, you install VMware Tools, a set of drivers and utilities that make the VM run better and give you features like graceful shutdown, time synchronisation, and the ability to take snapshots.
Management of VMs involves tasks such as:
Power operations: power on, power off, suspend, reset, and shutdown guest OS.
Snapshot management: capture the current state of a VM so you can revert to it later (useful before a software update).
Configuration changes: add or remove virtual hardware (e.g., more RAM, a second disk, a new network card) without rebooting, thanks to hot-add and hot-plug capabilities.
Migration: move a running VM from one physical host to another with zero downtime using vMotion, or move its storage to a different datastore using Storage vMotion.
Templates: create a golden image of a fully configured VM (OS installed, software configured, patches applied) and deploy new VMs from it instantly.
The hypervisor used in VCP-DCV is ESXi. ESXi is a Type-1 hypervisor, which means it runs directly on the server hardware without needing a parent operating system. This direct access to hardware makes it very efficient. You manage ESXi hosts and VMs through VMware vCenter Server, a centralised management platform that gives you a single pane of glass for hundreds or thousands of VMs.
The key files that make up a VM include: - .vmx: the configuration file (specifies virtual hardware settings). - .vmdk: the virtual disk file (contains the OS and data). - .nvram: stores the VM’s BIOS settings. - .vmsn and .vmsd: snapshot files. - .vmx.lck and .vmdk.lck: lock files that prevent multiple hosts from corrupting the VM.
Understanding these files is important for backup, recovery, and troubleshooting. If any of these files is missing or corrupted, the VM may fail to start.
Virtual machine creation and management is the bedrock of data centre virtualisation. Without VMs, there is no cloud, no modern data centre, no disaster recovery as we know it. For the VCP-DCV exam, you must know every step of VM creation, every management option, and how to troubleshoot common issues.
1. Launch the New Virtual Machine Wizard
Open the vSphere Web Client, navigate to a host, cluster, or resource pool, and click Actions > New Virtual Machine. This launches the wizard that will guide you through setting up the VM's configuration file and virtual hardware.
2. Specify Name and Location
Enter a descriptive name (e.g., App-Web-01) and choose a folder in the vSphere inventory. Folder structure helps organise VMs by department, environment (prod/test/dev), or application. This has no impact on performance but matters for manageability and permissions.
3. Select Compute Resource
Pick the ESXi host, cluster, or resource pool where the VM will run. Choosing a cluster enables high availability (HA) and distributed resource scheduling (DRS) if configured. You must ensure the selected compute resource has enough unreserved CPU and memory to accommodate the VM.
4. Configure Storage
Select a datastore (e.g., a SAN LUN or local disk) to store the VM’s files. You can choose thin or thick provisioning. Thin provisioning is space-efficient but may cause performance issues if the datastore runs out of space. Thick provisioning guarantees performance but wastes space if underused.
5. Define Virtual Hardware
Set the number of vCPUs, amount of memory, virtual disk size, and network adapter. For the exam, remember that memory hot-add requires the VM to be powered off, and that each vCPU should ideally map to one physical core to avoid contention. Also choose the virtual hardware version (compatible with the ESXi host).
6. Mount OS Installation Media and Boot
Attach an ISO file from a datastore or a client device. Boot the VM, open the web console, and install the guest OS just as if you were sitting at a physical server. After the OS is installed, install VMware Tools from the VM menu to enable advanced features.
7. Post-Deployment Customisation and Finalisation
After installation, you can customise the OS (e.g., join a domain, set static IP), take an initial snapshot, or convert the VM to a template. This step ensures the VM is ready for its intended role in the environment and can be repeated if used as a template.
An IT professional at a mid-sized company, let us call her Priya, needs to deploy ten new VMs for a CRM migration project. The project timeline is tight: the VMs must be ready by Friday.
First, Priya opens the vSphere Web Client and authenticates to vCenter Server. She navigates to the Cluster resource pool, which is a group of ESXi hosts that share compute resources. She chooses the custom create VM workflow.
She enters the following details:
VM name: CRM-App-Node-01 through CRM-App-Node-10
Folder: /Datacenters/London/Prod/CRM
Compatibility: ESXi 8.0 U2 (ensures the VM will run on the current hosts)
Guest OS: Microsoft Windows Server 2022 (64-bit)
Datastore: LUN003_SSD (an SSD-backed datastore for performance)
Priya configures the virtual hardware: - 4 vCPUs (because the CRM app is CPU-intensive) - 8 GB RAM - A 100 GB virtual disk (thin provisioned, so it only uses the space actually written) - A VM Network called Prod-VLAN-101 (to connect to the production segment)
She finishes the wizard, which creates a VM shell—a set of files on the datastore. She then mounts a Windows Server 2022 ISO from the shared ISO library, boots the VM, and goes through the Windows installation. After that, she installs VMware Tools from the Guest OS menu, which installs the correct drivers and enables time sync and graceful shutdown.
Because she needs ten identical VMs, Priya realises that repeating this process nine more times is wasteful. Instead, she powers down the first VM, converts it to a Template (right-click > Template > Convert to Template). A Template is a master copy that cannot be powered on—it is used only for deployment. She then selects Deploy VM from this Template, specifying the number of copies (9) and a naming pattern (CRM-App-Node-02 to CRM-App-Node-10). Each new VM is deployed in under 60 seconds with the same configuration.
Next, she tests vMotion: she migrates one running VM to a different ESXi host while users are connected, and confirms zero downtime. Finally, she takes a snapshot of each VM before the CRM application team applies their patches. If the update breaks something, she can revert to the snapshot instantly.
This real-world process demonstrates that VM creation and management is not a one-off task—it is an ongoing lifecycle involving deployment, template management, migration, and snapshots. The VCP-DCV exam expects you to know these workflows step by step.
The VCP-DCV exam (exam code 2V0-21.23) dedicates a significant portion of section 2.1 to VM creation and management. You will encounter scenario-based questions that test depth, not breadth. Here is exactly what you need to know.
Exam topics and question patterns:
Creating VMs from scratch: you will be given a scenario with specific requirements (e.g., Windows Server 2019, 4 vCPUs, 16 GB RAM, thick provisioned lazy zeroed disk). You must know where to set each value in the wizard. A common trap is confusing thick provisioned eager zeroed (all blocks zeroed at creation) with thick provisioned lazy zeroed (zeroed on demand). The exam loves to test these differences.
Deploying from templates and OVF/OVA: questions will ask about the advantages of templates versus OVF. OVA is a single file package (a tar archive of an OVF descriptor and disk files), while OVF is a folder with separate files. You must know when to use each.
VMware Tools: expect at least one question about the importance of VMware Tools, what it provides (drivers, time sync, heartbeat, shutdown, memory ballooning), and what happens if it is not installed (no graceful shutdown, poor performance, no snapshot quiescence).
vMotion and Storage vMotion: questions will give you a maintenance scenario and ask which migration type to use. The trap: vMotion requires the VM to be on shared storage (same datastore accessible by both hosts). Storage vMotion moves the disk to a different datastore. Both can be combined.
Snapshots: the exam tests the snapshot chain concept. Deleting a snapshot consolidates its changes into the parent disk. Taking multiple snapshots creates a chain; a long chain degrades performance. You must know the maximum recommended snapshot count (2-3).
Compatibility settings: questions about virtual hardware version and ESXi version. A VM with virtual hardware version 17 cannot run on an ESXi 6.5 host, which only supports up to version 13. You must know how to upgrade virtual hardware.
Guest OS customisation: the exam tests when customisation is needed (e.g., changing SID for Windows, hostname for Linux) and why it fails if VMware Tools is not installed.
Key definitions to memorise:
ESXi: Type-1 hypervisor.
vCenter Server: Central management platform.
Template: A master copy of a VM that cannot be powered on.
Snapshot: A point-in-time copy of a VM’s state.
Thin provision: Disk starts small and grows as data is written.
Thick provision lazy zeroed: Space allocated at creation, but blocks are zeroed on first write.
Thick provision eager zeroed: Space allocated and zeroed at creation (required for Fault Tolerance).
Traps to avoid:
Confusing virtual disk provisioning types (thin vs thick).
Thinking snapshots are backups (they are not—they are for quick rollback only).
Believing you can vMotion a VM without shared storage (you cannot—unless using vMotion with shared-nothing storage, which is separate).
Forgetting that VMware Tools must be installed for guest OS customisation to work.
Assuming you can delete a snapshot without affecting performance (the consolidation process can be resource-intensive).
Mastering these exam-specific details will give you a strong advantage. Practice in a lab environment to reinforce the concepts.
A virtual machine is a software computer that runs on a physical host via a hypervisor, and it behaves identically to a physical computer from the OS perspective.
The hypervisor (ESXi) allocates and manages physical resources—CPU, memory, storage, network—among multiple VMs without allowing interference.
VMware Tools is mandatory for proper management; without it, you cannot gracefully shut down, synchronise time, or take quiesced snapshots.
Snapshots are for quick rollback, not backups—never use them as a primary backup strategy because they reside on the same datastore as the VM.
Thin provisioning saves disk space by growing the virtual disk file as data is written, whereas thick provisioning allocates the full space immediately.
Templates allow you to rapidly deploy identical VMs, saving time and ensuring consistency across your environment.
vMotion migrates a running VM to a different host with zero downtime, but it requires shared storage accessible by both source and target hosts.
Virtual hardware version must match the ESXi version of the host that runs the VM; you cannot run a VM with hardware version 19 on ESXi 6.5.
The default number of snapshots should be kept to 2-3 maximum; a long chain degrades I/O performance significantly.
Hot-plug (adding resources without powering off) is supported for CPU, memory, and some PCIe devices, but the guest OS must also support it.
These come up on the exam all the time. Here's how to tell them apart.
Thin Provisioning
Allocates disk space on demand as data is written, starting small.
Space-efficient; useful for environments with low disk utilisation.
Can cause performance issues if the datastore runs out of physical space.
Thick Provisioning (Lazy Zeroed)
Allocates the full disk size at creation, but blocks are zeroed only on first write.
Uses more space upfront; guarantees space availability.
No performance penalty from on-demand allocation, but slower first write due to zeroing.
Snapshots
Point-in-time delta file stored on the same datastore as the VM.
Designed for quick rollback (e.g., before a patch).
Does not protect against datastore failure; a long chain degrades performance.
Backups (e.g., Veeam, vSphere Data Protection)
Independent copy stored on separate media (tape, remote storage, cloud).
Designed for disaster recovery and long-term retention.
Survives hardware failure; multiple restore points are possible.
vMotion
Migrates a running VM with zero downtime.
Requires shared storage accessible by both source and target hosts.
Preserves the VM’s entire state (memory, CPU state, storage).
Cold Migration
Migrates a powered-off VM.
Does not require shared storage; files can be copied to a new datastore.
Results in downtime (VM must be off); simpler but disruptive.
VMware Tools (Installed)
Provides SVGA, network, and storage drivers for optimal performance.
Enables graceful shutdown, time sync, heartbeat, and quiesced snapshots.
Required for guest OS customisation (sysprep, hostname changes).
VMware Tools (Not Installed)
Uses generic emulated drivers, causing poor performance.
Guest OS cannot be shut down from vSphere; must use console or RDP.
Snapshot will not be file-system-consistent; customisation will fail.
Mistake
A virtual machine is just a fancy folder of files, so I can copy it from one datastore to another while it is running.
Correct
Copying a running VM’s files manually will cause corruption. You must use Storage vMotion or a proper migration tool to move a running VM’s storage safely.
People assume that because a VM is made of files, it behaves like a Word document. They do not realise the files are locked by the hypervisor and that the VM has active write operations happening in real time.
Mistake
Snapshots are a valid backup strategy. If I take a snapshot every day, I can restore my VM to any point in time.
Correct
Snapshots are not backups. They only capture the state at a moment in time and are stored on the same datastore as the VM, which means if the datastore fails, the snapshots are lost. A snapshot chain longer than 2-3 also degrades performance.
Beginners hear the word “snapshot” and think of phone camera backups. They do not understand that snapshots are delta files that grow over time and are linked to the original disk—they are not independent copies.
Mistake
VMware Tools is optional—the VM will work fine without it, just slower.
Correct
Without VMware Tools, the hypervisor cannot communicate with the guest OS. You lose graceful shutdown, time synchronisation, the ability to quiesce file systems during snapshots, and proper network and storage drivers. The VM will run, but it will be significantly harder to manage and may have poor performance.
Many beginners come from a physical-server background where you never installed additional drivers after the OS. They think of VMware Tools as bloatware rather than essential integration software.
Mistake
If a VM has 4 virtual CPUs, it will be faster than a VM with 2 virtual CPUs, always.
Correct
Adding more vCPUs can actually decrease performance if the physical host does not have enough physical cores to handle the concurrent load. Oversubscription (assigning more vCPUs than physical cores) leads to CPU scheduling contention. More vCPUs are not always better.
People apply the “more is better” logic from physical hardware, not realising that virtual CPU scheduling is a shared resource controlled by the hypervisor.
Mistake
I can install any version of Windows on any virtual hardware version, and it will work the same.
Correct
Virtual hardware version dictates the virtual chipset, BIOS, and supported devices. An older Windows version (e.g., Windows NT 4.0) may not support virtual hardware version 19. You must choose a compatible virtual hardware version for the guest OS.
Beginners assume the hypervisor fully emulates a generic PC, so any OS should boot. They do not understand that virtual hardware versions lock in specific features like UEFI, TPM, or NVMe controllers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A snapshot is a point-in-time copy of a VM’s state stored on the same datastore as the VM. It is designed for quick rollback, not for disaster recovery. A backup is an independent copy stored elsewhere (e.g., on a backup server or tape) that can survive datastore failure.
Yes, if the VM’s virtual hardware supports memory hot-add and the guest OS supports it. You can increase the memory in the VM settings while the VM is powered on, but you cannot decrease it without powering off the VM.
The VM will pause or crash because it cannot write to its virtual disk. Monitoring datastore usage is critical. You can use Storage vMotion to move the VM to a datastore with more free space, or add more physical storage to the datastore.
If you manually copied the VM files (rather than using Storage vMotion), you likely missed a file or corrupted a lock file. Always use the correct vSphere migration tools (Storage vMotion or OVF export/import) to move VMs between datastores.
Yes, you can create an empty VM shell (just the .vmx file and a blank virtual disk). This is useful if you want to attach an existing OS disk from another VM or install the OS from a PXE boot. However, an empty VM is not functional until an OS is installed.
Technically, you can have a large number, but VMware recommends no more than 2-3 snapshots in a chain. Each snapshot creates a delta disk that grows over time. A long chain severely degrades I/O performance and increases the risk of data corruption if a snapshot delete fails.
A template is a VM that has been converted so it cannot be powered on. It serves as a master copy for deploying multiple identical VMs. You can deploy from a template as many times as you want without affecting the original. A template uses the same file format as a VM but has a special flag in the vCenter database.
You've finished Virtual Machine Creation and Management. Continue through the VCP-DCV study guide to build a complete picture of the exam.
Done with this chapter?