During my work experience, I created, configured, and maintained virtual machines (VMs) on VMware ESXi hosts to support different organizational requirements. This report covers the process of creating VMs, allocating resources, configuring virtual hardware, and managing snapshots and VM exports for backup and recovery purposes I have done.
Create virtual machines based on the operating system and service requirements.
Configure virtual hardware, including CPU, memory, storage, and network interfaces.
Optimize resource allocation based on workload requirements and service priorities.
Configure virtual disk provisioning and disk modes based on service requirements.
Use snapshots and VM exports to support backup and recovery.
VMware ESXi
VMware vSphere Client
Virtual Machines (VMs)
Virtual CPU and Memory Allocation
Virtual Disk Provisioning (Thin and Thick)
VM Snapshots
OVF and VMDK Virtual Machine Export Formats
Depending on the operating system required by the services, their resource consumption, and their intended functions, I created multiple VMs on ESXi hosts. The following sections describe the main steps and configurations I used when creating and deploying these VMs.
To create a VM, I selected “Create a New Virtual Machine”.
To ensure compatibility, I selected the appropriate guest operating system and the closest available version matching the intended OS.
I then selected the datastore where the VM files would be stored. Some ESXi hosts used shared network storage, while others had multiple local disks or datastores available.
In the VM customization settings, I configured the following options:
CPU, Memory, and Hard Disk: I allocated resources according to each VM's purpose and workload. For example, Linux servers running services with low resource requirements were typically assigned up to two virtual CPU cores, 4 GB of RAM, and 10 GB of disk space. MikroTik CHR VMs were assigned one virtual CPU core, 256 MB of RAM, and 1 GB of storage. Windows Server VMs hosting resource-intensive services, such as IIS or Hyper-V, were assigned eight virtual CPU cores, at least 16 GB of RAM, and 80–200 GB of disk space.
Disk Provisioning: I selected the provisioning type based on storage requirements and the intended workload. For services such as MikroTik CHR, where storage performance was not a major concern, I used Thin Provisioning to allocate physical storage as the virtual disk grew. For workloads such as Active Directory, where predictable storage allocation and write performance were important, I used Thick Provisioned – Eagerly Zeroed when appropriate. This provisioning type reserves the full configured disk capacity and zeroes its blocks during disk creation (format disk space), making the storage ready for subsequent writes.
Shares: I adjusted resource shares according to each VM's importance and priority. I assigned lower shares to less critical VMs and higher shares to more important VMs. These settings help determine how CPU or memory resources are distributed between competing VMs when resources are constrained. Shares do not reserve resources or guarantee that a VM will receive a specific amount.
Disk Mode: I generally kept the operating system disk in Dependent mode so that it could be included in snapshots. For additional disks used for databases or reference files, I sometimes selected Independent – Persistent mode when those disks did not need to be included in VM snapshots. Changes written to an independent persistent disk remain on the disk and are not reverted when reverting to a VM snapshot. This is because databases are backed up using more reliable methods and automatically, and does not needed to be included in snapshots.
After creating a VM, I reviewed its configuration and modified the default settings when necessary. To do this, I right-clicked the VM and selected Edit Settings.
The most common changes included adding network interface cards (NICs) and additional virtual hard disks to meet the requirements of the services running on the VM.
After installing the operating system, deploying the required services, and completing the initial configuration, I created snapshots of selected VMs. These snapshots provided a convenient way to return a VM to an earlier state when configuration changes or software installations caused problems.
To create a snapshot, I right-clicked the VM and selected Snapshots > Take a Snapshot.
Snapshots were used primarily as short-term recovery points rather than as independent backups. Because snapshots depend on the underlying virtual disks and datastore, they do not protect against every type of storage failure or data loss. Therefore, for some VMs that required significant time to install and configure, I also exported the VMs to preserve a portable copy that could later be imported or deployed on another compatible ESXi host.
To export a VM, I right-clicked it and selected Export. Depending on the export method and selected options, the process produced files such as:
OVF (.ovf): Contains the virtual machine's configuration and hardware metadata.
VMDK (.vmdk): Contains the virtual disk data, including the operating system and installed services.
Manifest (.mf): Contains checksums used to verify the integrity of files included in the export.
These files could be used to deploy the exported VM on another compatible environment.