Managing Storage for a Virtual Machine

Lesson purpose

Storage is where virtualization projects most often come up short. Consolidation moves many workloads onto one host, and their CPU, memory, and storage I/O move with them. The VM sees what looks like an ordinary disk, but the hypervisor translates every read and write into operations against files, shared volumes, or arrays on the physical side. Students should leave able to trace a storage request through the virtualization layer, add and prepare a virtual disk, and explain the physical-world techniques (RAID, deduplication, thin provisioning, QoS, SSDs, tiering) that keep a virtual environment fast, efficient, and available.

Learning objectives

By the end of the lesson, students should be able to:

Describe how virtual machines connect to storage resources in the VMware model and the Xen/Hyper-V model.
Distinguish DAS, SAN, and NAS and name the hardware that connects each (storage controller, HBA, NIC).
Explain hypervisor file systems, raw device mapping/passthrough disks, and pooled (software-defined) storage.
Add, initialize, partition, and format a second virtual disk.
Explain why consolidation makes storage throughput a common bottleneck.
Describe mirroring, striping, RAID levels, deduplication, thick vs. thin provisioning, storage I/O control, SSDs, and tiered storage, including each one’s tradeoff.

1. Why storage matters in virtualization

Data volume keeps growing because the data itself has changed. Early systems stored text and numbers; today’s workloads store video, audio, images, logs, and backups. The book cites estimates that the world generated roughly 2 zettabytes of data in 2011 and forecast about 40 zettabytes per year by 2020. The exact figure matters less than the trend: storage capacity and the bandwidth to reach it both have to grow.

The request path is the same idea on any device:

An application asks the operating system for data.
The OS sends the request to the storage subsystem through a device driver.
The storage subsystem locates the data and returns it as like-sized blocks.
The OS hands the blocks to the application.
Changed blocks travel back the same way to be rewritten.

Virtualization inserts a layer into that path, which is why storage design deserves as much attention as CPU and memory sizing.

2. Where the storage lives: DAS, SAN, and NAS

DAS (Direct Attached Storage): disks inside the host (or directly cabled to it), managed by a physical storage controller card.
SAN (Storage Area Network): external disk arrays reached over a dedicated storage network, typically through a Host Bus Adapter (HBA). Fibre Channel is the classic SAN protocol; iSCSI carries block storage over ordinary Ethernet. A SAN presents blocks; the server builds a file system on them.
NAS (Network Attached Storage): storage reached through the regular NIC using a file-sharing protocol such as NFS (common in Linux/UNIX) or SMB/CIFS (common in Windows). The NAS manages its own file system and shares files.

Talking point: SAN and NAS both put storage outside the server, which lets several hosts see the same disks. That shared access is the foundation for clustering, live migration, and high availability (covered in Lesson 13).

3. The virtual storage path

VMware model (hypervisor handles I/O)

The application’s request goes to the guest OS.
The guest sends it to what it believes is a physical SCSI controller.
That controller is an emulation presented by the hypervisor. The SCSI emulator catalogs the request and queues it with I/O from every other VM on the host.
The hypervisor’s own storage driver sends the request to the host’s physical controller (or HBA/NIC).
Returned blocks follow the reverse path, and the hypervisor delivers them to the correct VM.

Xen / Hyper-V model (a privileged guest handles I/O)

The application in a user guest (a user domain) sends the request through the guest OS to a front-end driver (block or network).
The front-end driver passes it to a matching back-end driver in the privileged management guest (Dom0 in Xen; the parent partition in Hyper-V).
Dom0’s real device driver talks directly to the hardware.
Data returns along the reverse path.

The key distinction: in the VMware model the hypervisor itself brokers storage I/O; in the Xen/Hyper-V model a privileged guest with direct hardware access does. Either way, the guest sees an abstraction. A Windows VM’s D: drive looks like a local disk, while its blocks may sit on any array behind any connection type.

Check for understanding: In the Xen model, which component actually talks to the physical storage hardware? (Dom0’s device driver.)

4. Shared storage, file systems, and pooled storage

Shared storage eases migration. A physical server whose data is already on a SAN can be converted to a VM (P2V) and simply remount those data disks instead of copying them. It also allows a quick fallback to the original server during testing, and some organizations run periodic P2V copies as a disaster-recovery option.

Hypervisor file systems hold the VMs’ virtual disk files and make storage easier to manage than giving each VM direct array access:

Platform	Storage for virtual disks
VMware vSphere	VMFS datastores (also NFS and vSAN)
Microsoft Hyper-V	Cluster Shared Volumes (CSV) on NTFS/ReFS
Xen / XenServer	Storage repositories (the book lists XFS; current Citrix/XCP-ng releases use LVM- or file-based repositories)

Raw Device Mapping (RDM) / passthrough disk: presents a physical LUN straight to the VM, bypassing the hypervisor file system. It is the exception, useful for cases like remounting SAN storage between a physical and a virtual server. Older releases favored RDMs for performance; current releases perform essentially the same either way, so use them only when a specific need calls for it.

Pooled (software-defined) storage: small organizations that cannot afford a storage array are often stuck with local disks only, so one host failure takes down every VM on it. Solutions such as VMware vSAN, Microsoft Storage Spaces Direct, and the book’s example of HP StoreVirtual VSA pool the internal disks of several servers into one shared resource every host can use, with no separate array.

5. Lab walkthrough: add a second virtual disk

The book demonstrates this in VMware Workstation Player with a Windows 10 guest. VMware Workstation Player has since been folded into VMware Workstation Pro, which is free for personal and educational use; the screens are essentially the same, and the Windows 11 steps match.

Existing disk utilities (VM powered off, Settings > Hard Disk):

Defragment: rearranges data inside the virtual disk more compactly but does not return the freed space to the host.
Expand: adds capacity to the virtual disk (the guest must then extend its partition).
Compact: shrinks the disk file by reclaiming empty space; requires the VM to be powered off.

Add the disk (VM powered off):

Open Virtual Machine Settings and select Add. Approve the host permission prompt if it appears.
In the Add Hardware Wizard, choose Hard Disk.
Keep the recommended bus type (SCSI, or NVMe if that is what the wizard recommends for the guest).
Choose Create a new virtual disk. Note the alternatives: Use an existing virtual disk reattaches a disk file; Use a physical disk gives the VM direct access to a host device.
Enter 5 GB. Leave Allocate all disk space now unchecked (this makes the disk grow as needed) and choose Store virtual disk as a single file.
Accept the default file name (the existing name incremented) in the VM folder, then Finish.

Back in Settings, the new disk shows a maximum size larger than its actual size, because the space was not pre-allocated. Only Expand is available: the disk is attached but not yet usable by Windows.

Prepare it inside Windows:

Power on the VM. Hovering over the disk icons shows both the 30 GB and 5 GB drives.
Open Disk Management (right-click Start > Disk Management, or Computer Management > Storage > Disk Management).
Accept the prompt to initialize Disk 1 (GPT is the modern default). Confirm it is the new disk.
Right-click the Unallocated space and choose New Simple Volume.
Keep the maximum size, accept drive letter E:, and set the volume label to Second Drive.
Finish and verify the drive in File Explorer under This PC. It is empty except for file-system overhead.

Teaching point: attaching a disk at the virtual-hardware layer and preparing it at the OS layer are separate jobs. The hypervisor provides a blank device; the guest OS must still initialize, partition, and format it, exactly as with a new physical drive.

6. Why storage performance suffers after consolidation

The book’s image: firefighters arrive at a blaze, connect to the hydrant, and discover they brought a garden hose. A host without enough storage throughput is that hose. Consolidation reduces the number of servers, not the amount of I/O. The I/O is squeezed through fewer channels, and because VMs are so easy to create, environments usually end up with more VMs than the physical servers they replaced.

Beginners size hosts for cores and RAM and forget the storage (and network, Lesson 10) paths. The good news is that physical storage best practices translate directly. One long-standing maxim: more spindles are usually better. Many smaller disks beat a few large ones because the array can read and write to them in parallel.

7. Availability and performance techniques

Mirroring and striping

Mirroring: a second disk holds an exact copy of the first. If one fails, the other has every block, and reads can be split across both copies.
Striping: a file system is split into pieces spread across several disks so they work in tandem, speeding reads and writes. Striping alone gives no protection.
Combining them gives both speed and protection, at the cost of doubling the disks.

RAID

RAID originally meant Redundant Array of Inexpensive Disks (now usually “Independent”). Each level describes how data is spread, how much protection it offers, and how it performs:

Level	Technique	Tradeoff
RAID 0	Striping	Fast, no redundancy; one failed disk loses the set
RAID 1	Mirroring	Survives a disk failure; half the raw capacity is usable
RAID 10 (1+0)	Striped mirrors	Fast and redundant; doubles the disk count
RAID 5 / 6	Striping with distributed parity	Rebuilds data from parity after one (RAID 5) or two (RAID 6) disk failures; better capacity efficiency, slower writes

Point out: RAID protects against disk failure, not against deletion, corruption, or ransomware. It is not a backup.

Data deduplication

Deduplication finds identical chunks of data, keeps one copy, and replaces the duplicates with pointers. It is the storage equivalent of the memory page sharing from Lesson 8.

Example: an HR vice president emails a 2 MB policy document to 5,000 employees, and everyone saves it. That is 10 GB of identical data. With deduplication, it becomes one 2 MB copy plus 5,000 small pointers. Deduplication can work at the byte, block, or file level and commonly reclaims 30 to 90 percent of used space, depending on how redundant the data is. It is especially effective for VM storage because many guests share the same OS files.

Thick vs. thin provisioning

Thick provisioning: the full size is allocated when the disk or file system is created. Three 100 GB file systems on 300 GB of storage consume all of it, even if each uses only 50 GB, wasting 150 GB.
Thin provisioning: space is allocated only as data is written. The same three disks using 50 GB each consume 150 GB, leaving room to provision two more 100 GB disks.

Thin provisioning is storage overcommitment, just like memory overcommit. Performance impact is usually minimal, but the risk is sharper: every disk believes it has more space than physically exists. If they fill up together, writes fail and VMs can pause or crash. Use it only with a clear picture of real usage, plus monitoring and alerts on the datastore’s free space.

Storage I/O control and QoS

Consolidated VMs share the same paths to storage with little built-in priority, so one I/O-heavy application can starve a more important one. Like an HOV lane at rush hour, Quality of Service (QoS) policies reserve bandwidth for priority traffic when contention is detected. Storage and network vendors can apply QoS; at the hypervisor level, VMware Storage I/O Control assigns I/O priority per VM. The book calls VMware the only hypervisor with this ability; that was true of the release it covers, but Hyper-V now offers Storage QoS policies as well.

Solid-state drives (SSDs)

SSDs store data in solid-state memory with no spinning platters or moving parts. The book compares roughly 5 ms reads on a hard disk with 0.1 ms on an SSD, about fifty times faster. Current NVMe SSDs widen that gap further and now match or exceed hard-disk capacities in the data center. Tactical uses the book highlights:

Staging virtual desktop templates on SSD so new desktops deploy faster.
Installing the hypervisor on SSD so hosts boot and reboot quickly.

Tiered storage and array offload

Tiered storage mixes classes of storage (fast and highly protected vs. slower and cheaper) in one array. Critical applications go on the fast, RAID-protected tier; lower-demand data goes on cheaper disks. Data can migrate between tiers, sometimes automatically, as needs change.

Modern hypervisors also offload work to the array: large copies, disk initialization, and locking are handed to the storage system (for example, VMware’s VAAI), freeing the hypervisor and finishing faster.

Why not put everything on the fastest tier? Cost. The highest performance and availability carry the highest price, and many applications do not need them. The skill is matching each workload to “good enough” storage within the budget.

Classroom application

Lab: Have students add a second virtual disk to their Windows VM, initialize it, create a simple volume labeled Second Drive, and submit a screenshot of This PC showing both drives. Ask them to record the disk’s maximum and actual size in VM Settings before and after copying a large file to it, and explain the difference.

Capacity exercise (from the book): A host has four six-core processors (24 cores), 256 GB of RAM, and 1 TB of storage. Each web-server VM needs 1 core, 8 GB of RAM, and 100 GB of disk.

By CPU: 24 VMs (one core each). By memory: 32 VMs (no overcommit). By storage: 10 VMs (thick provisioned).
Limiting factor: storage.

Extend it: the servers really use about 25 GB each, so you thin-provision at 30 GB (usage plus headroom).

Storage now supports about 33 VMs (23 more than before).
Memory would need page sharing to reach 33; CPU (24 cores) becomes the new limiting factor, and you would need real CPU utilization data before going past it.
Discussion: should you add them? On a single host, one failure takes down every web server. Build confidence in the environment, plan for availability, and confirm the host handles peak conditions before packing it further.

Checks for understanding:

What does the VM’s “SCSI controller” actually connect to?
What is the difference between a SAN and a NAS?
Why is a newly added virtual disk not usable in Windows right away?
Why does consolidation make storage a bottleneck even when the total amount of work is unchanged?
What happens when thin-provisioned disks outgrow the physical storage?
Which RAID level gives speed with no protection? Which gives protection by mirroring?

Common misconceptions

“A VM’s disk is a real physical disk.” It is usually a file on a datastore or volume, presented through an emulated controller.
“Consolidation reduces storage load.” It concentrates the same (or more) I/O onto fewer paths.
“Thin provisioning creates free space.” It defers allocation; the physical capacity must still exist when data arrives.
“RAID is a backup.” RAID survives disk failures, not deletion, corruption, or site loss.
“Bigger disks are faster.” More disks working in parallel usually outperform fewer, larger disks.
“Put everything on the fastest storage.” Performance and availability cost money; match the tier to the workload.
“Adding the virtual disk finishes the job.” The guest OS must still initialize, partition, and format it.

Lesson summary

Storage demand keeps rising, and virtualization concentrates it. VMs reach DAS, SAN, and NAS through emulated controllers or front-end/back-end drivers, so the guest sees an ordinary disk while the hypervisor or a privileged guest handles the physical I/O. Hypervisor file systems, shared storage, and pooled storage make VM storage manageable and available. Adding a virtual disk takes two steps: attach it in the VM settings, then initialize and format it in the guest. Because consolidation funnels many workloads through fewer paths, adequate I/O bandwidth is essential. Proven physical practices (more spindles, RAID, deduplication, thin provisioning, QoS, SSDs, and tiering) apply directly, each with a tradeoff in cost, risk, or capacity that the administrator has to weigh.