6.4 7 Create Virtual Hard Disks: Exact Answer & Steps

Need more storage for your virtual machines but don't want to buy new hardware? Creating virtual hard disks is the solution.

What Is a Virtual Hard Disk

A virtual hard disk is essentially a file that acts like a physical hard drive for your virtual machines (VMs). Instead of spinning platters, it’s just data stored on your host machine’s physical storage. Think of it as a digital container for your VM’s operating system, applications, and files. These disks come in different formats—like VMDK for VMware or VHD for Hyper-V—but they all do the same thing: fool the VM into thinking it’s got real hardware.

Key Types of Virtual Disks

• Thick Provision Eager Zeroed: Takes full space upfront and zeroes out all data. Best for performance but slow to create.
• Thick Provision Lazy Zero: Allocates full space upfront but zeroes data on write. Faster to create, slightly slower writes.
• Thin Provision: Starts small and grows as needed. Saves space but risks running out if not monitored.

Why It Matters

Virtual hard disks are the backbone of VM deployments. Without them, your VMs have nowhere to live. Get this wrong, and you’ll face performance bottlenecks, storage waste, or VM crashes. Here’s why it matters:

• Resource Efficiency: You can pack dozens of VMs onto a single physical server by leveraging virtual disks.
• Flexibility: Need more storage? Just expand the disk file instead of adding physical hardware.
• Snapshots: Virtual disks enable point-in-time backups of your entire VM state.
• Portability: Move VMs between hosts by copying disk files.

But here’s the catch: most people treat virtual disks like physical ones. They don’t. Still, they’re files. And that changes everything Surprisingly effective..

How to Create Virtual Hard Disks (Step-by-Step)

Creating virtual disks varies slightly between platforms, but the core process is similar. Let’s break it down for VMware ESXi 6.4 and 7, since that’s our focus.

Using vSphere Client (GUI)

1. Log in to vSphere Client: Connect to your ESXi host or vCenter server.
2. manage to VM Settings: Select your VM, go to "Edit Settings," then "Add Hard Disk."
3. Choose Disk Type: Pick Thick Eager Zeroed, Thick Lazy Zero, or Thin Provision.
4. Specify Size: Enter the disk size in GB.
5. Select Datastore: Pick the datastore where you want the disk stored.
6. Finish: Click "OK" to create the disk.

Using ESXi CLI (Command Line)

For automation or when the GUI isn’t available:

1. SSH into ESXi: Use ssh root@<ESXi_IP>.
2. Run Command:

   vmkfstools -c GB -a  .vmdk -d   
   

   • <size>: Disk size in GB (e.g., 100).
   • <adapter_type>: lsilogic or pvscsi (use pvscsi for modern VMs).
   • <disk_path>: Full path (e.g., /vmfs/volumes/datastore1/disk.vmdk).
   • <disk_type>: eagerzeroedthick, zeroedthick, or thin.
3. Attach to VM: Edit VM settings and add the new disk.

Using PowerCLI (Automation)

For bulk operations or scripting:

New-HardDisk -VM "VM_Name" -CapacityGB 100 -StorageFormat "Thin" -Datastore "Datastore_Name"  

Common Mistakes

People trip up on virtual disks more than you’d think. Here’s where they fail:

• Ignoring Disk Type: Using Thin Provision for critical databases? That’s a recipe for disaster. Thin disks can run out of space silently, corrupting data.
• Overprovisioning: Allocating 500GB when 50GB will do. Wastes storage and backup time.
• Forgetting Snapshots: Thick disks with snapshots bloat performance. Avoid snapshots on production VMs with thick disks.
• Wrong Datastore: Placing I/O-heavy disks on slow storage. Use SSD-backed datastores for VMs with high disk activity.
• Skipping Monitoring: Not tracking thin disk growth. They’ll fill up when you least expect it.

Practical Tips

What actually works in the real world?

• Start Small, Scale Later: Begin with a smaller disk and expand as needed. Use vmkfstools -X to grow disks online.
• Use Thick for Performance: For VMs running databases or heavy apps, always choose Thick Provision Eager Zeroed. The upfront cost pays off in I/O.
• Separate Disks for OS and Data: Split the OS disk from data disks. Makes backups and restores easier.
• Monitor Growth: Set alerts for thin disks hitting 80% capacity.
• Test Backups: Verify disk backups work. A broken backup is worse than no backup.

FAQ

Q: Can I shrink a virtual disk?
A: No, not directly. You can expand, but shrinking requires third-party tools like VMware Converter or manual OS-level shrinking (risky).

Q: How do I move a disk to another datastore?
A: Use Storage vMotion in vCenter, or via CLI:

vmkfstools -i /old/path.vmdk /new/path.vmdk  

Q: What’s the difference between VMDK and VHD?
A: VMDK is VMware’s format; VHD is for Hyper-V. They’re incompatible without conversion Worth knowing..

Q: Can I convert between thick and thin?
A: Yes, with vmkfstools -i to create a new disk from an existing one Simple, but easy to overlook. Which is the point..

Q: Why is my thick disk taking so long to create?
A: Eager Zeroed thick disks zero out all data upfront. For 1TB, expect minutes to hours.

Creating virtual disks isn’t rocket science, but it demands attention to detail. That said, get the type, size, and storage right, and your VMs will hum. Think about it: get it wrong, and you’ll be troubleshooting at 2 AM. So take your time, test thoroughly, and remember: virtual disks are files, not magic. Treat them with the same care you’d give any critical file Nothing fancy..

Advanced Techniques You Might Not Know About

Using vmkfstools for On‑the‑Fly Conversions

A quick cheat‑sheet for the most common one‑liners:

# Convert thin → thick (lazy zeroed)
vmkfstools -i sourceThin.vmdk -d lazyZeroed targetThick.vmdk

# Convert thick → thin
vmkfstools -i sourceThick.vmdk -d thin targetThin.vmdk

# Clone a VMDK while changing the disk type
vmkfstools -i original.vmdk -d eagerZeroed cloned.vmdk

Tip: Always run the conversion on a datastore with at least 20 % free space. The process creates a temporary copy before swapping the files, so you need headroom.

Automating Disk Management with PowerCLI

If you’re managing dozens of VMs, manual CLI work quickly becomes a bottleneck. PowerCLI lets you script the entire lifecycle:

# Example: Find all thin‑provisioned disks > 100 GB that are > 80% full
Get-VM | Get-HardDisk |
Where-Object {
    $_.StorageFormat -eq 'Thin' -and
    $_.CapacityGB -gt 100 -and
    ($_.CapacityGB * (1 - $_.FreeSpaceGB/$_.CapacityGB)) -gt 80
} | Select-Object VMName, Name, CapacityGB, @{N='PctUsed';E={"{0:N1}" -f (100-($_.FreeSpaceGB/$_.CapacityGB*100))}}

You can pipe the result into a remediation step—e.g., automatically migrate the offending VMDK to a larger datastore or trigger a notification ticket It's one of those things that adds up. And it works..

When to Involve the Storage Team

Even the most seasoned admins hit a wall when the underlying storage architecture changes. Here are the red flags that merit a hand‑off:

1. Datastore Near Capacity (<10 % free) – Some storage arrays start throttling I/O dramatically before you see a full alert.
2. Latency Spike > 5 ms – If the latency is not VM‑specific but appears across many VMs, it’s a storage array or network issue.
3. Unexpected VMFS Resignature – When a datastore disappears and reappears, you may be dealing with hardware‑level LUN masking problems.
4. vSAN Stretched Cluster Failover – Requires coordination with the SAN admin to verify quorum and witness health.

A quick “ping‑test” of the storage LUN (esxcli storage core device list) can confirm whether the problem is local to the ESXi host or systemic Most people skip this — try not to..

Checklist Before You Hit “Power On”

Real‑World Example: Migrating a Production Database VM

Scenario: A 500 GB SQL Server VM running on a legacy NFS datastore is experiencing I/O latency spikes during peak hours.

Steps Taken

1. Baseline Metrics – Collected IOPS, latency, and datastore utilization via vRealize Operations.
2. Chosen Disk Type – Switched the data VMDK from Thin to Eager Zeroed Thick to eliminate thin‑provisioning overhead.
3. Datastore Move – Executed a Storage vMotion to an SSD‑backed VMFS‑6 datastore with a 4 K block size.
4. Snapshot Policy – Disabled scheduled snapshots for the production VM; instead, leveraged Veeam’s application‑aware backup.
5. Post‑Migration Validation – Re‑measured IOPS; latency dropped from 12 ms to 3 ms, and query response times improved by ~30 %.

The lesson? The right combination of disk format, datastore tier, and snapshot strategy can turn a sluggish VM into a high‑performing asset without any hardware changes.

Conclusion

Virtual disks are the backbone of any VMware environment, but they’re often treated as “just files.” In reality, the choices you make—thin vs. thick, datastore selection, snapshot discipline, and ongoing monitoring—directly impact performance, capacity planning, and reliability.

• Pick the right provisioning for the workload (thin for dev/test, eager‑zeroed thick for I/O‑intensive production).
• Keep an eye on growth; thin disks are convenient until they silently fill up.
• put to work automation (PowerCLI, vRealize) to stay ahead of capacity and health issues.
• Never ignore storage alerts; a full datastore or rising latency is a symptom, not a bug.

By following the practical tips, avoiding common pitfalls, and using the advanced techniques when needed, you’ll keep your VMs humming, your backups clean, and your midnight support calls at zero. Treat each VMDK with the same care you’d give any critical piece of data, and the virtual infrastructure will reward you with stability and performance for years to come.

Some disagree here. Fair enough.