This is a collection of information about storage concepts such as Hard Drives, Disks, Partitions, Volumes, Snapshots, Shadow Copies.  This is meant to be a quick reference, primarily for Windows Server and Hyper-V, with links to additional information.  This page may be updated periodically so it may change slightly over time.

 

 

TERMINOLOGY

Typically "disk" = the physical disk, and "drive" = the logical drive, but they are often used interchangeably.

The terms "partition" and "volume" are commonly used interchangeably and are usually referring to the same thing, but a partition can only reside on one fixed disk or logical drive, whereas a volume can span multiple partitions on multiple drives. A partition usually refers to a portion of a logical drive that is discovered by the system, whereas volumes can be assigned dynamically to a single partition, multiple partitions or be placeholders that refer to drives that are not always present (i.e. removable, CD, DVD). Numbering for Disks and Volumes starts with 0, but numbering for partitions starts with 1. So the first disk found is always 0, the first partition found is always 1, and the first volume assigned is always 0. In the past, partitions on a Windows disk were always defined in the Master Boot Record (MBR) and were limited to 4 primary partitions, or 3 primary partitions and 1 extended partition that can contain multiple volumes, Windows refers to this as a Basic Disk. Newer partition schemes like Dynamic Disks and GUID Partition Table (GPT) disks do not have this limitation.

Links:

Basic and Dynamic Disks

Disk Management Concepts

 

 

DRIVE LETTERS

The first time Windows detects a disk, it looks for a disk ID. If the ID is not found, Windows needs to write a unique ID to the Master Boot Record (MBR) before it can be used. If the disk is connected to a different system or a dual boot system, the existing ID is recognized and used by other instances of Windows.

The first time Windows detects a volume, it assigns the next available drive letter at the time, and saves that assignment to the registry. But this can be overridden manually and the registry will be updated. After that, every time Windows detects that same volume it will use the drive letter stored in the registry, unless that letter is in use by another volume. If a volume and a mapped network drive have the same drive letter saved in the registry, the volume wins because this is enumerated at bootup before the mappings at user logon. If a volume is connected to a different system or a dual boot system, the stored drive letter does not follow the volume since it is stored in the registry on the other instance.

The drive letters that are used for volumes start with C:, drives A: and B: are only assigned to floppy drives for backwards compatibility. You can manually assign A: and B: if they are not assigned to floppy drives, but this can cause problems with some apps that do not recognize A: and B:.

 

MULTIPLE VOLUMES WITH SAN STORAGE OR VMs

The more drive "spindles" that are used for a particular server usually improve performance. But creating separate volumes on VMs or LUNs that use the same physical disks won’t help I/O performance. Aside from I/O performance, separate volumes on the same LUN/VHD/VMDK/VDI can also be useful for other things such as VSS, quotas, auditing, backup storage limits, backup times, restore times, chkdsk completion times, etc. Separating data and logs from the OS and Applications installs can prevent the server from crashing and might allow apps/services to handle drive full errors more gracefully. It can also make it easier to move things around if the SAN admin needs to make changes to how the disks are carved up. Sometimes your backup scheme can also dictate your config, especially if you want the virtual host to backup the guest VMs rather than each VM backed up individually.

 

 

VIRTUAL HARD DRIVES AND CONTROLLERS

Hyper-V supports two types of drive controllers:

  • IDE (Emulated or Synthetic)
  • SCSI (Emulated or Synthetic)

By default, both controllers emulate common physical hardware for the BIOS boot, and use existing drivers installed in the guest OS for the emulated physical hardware. Once the Hyper-V Integration Services are installed in the guest OS, the Hyper-V specific "Synthetic" drivers are used and offer improved performance.

In Hyper-V, bootable drives and operating system drives must be attached to the primary IDE controller. SCSI controllers can only be used for data, not the OS. In Hyper-V, drives attached to SCSI and IDE virtual controllers offer the same performance if they use the synthetic drivers. Virtual SCSI synthetic controllers are preferred for servers, since they support SCSI emulation mode and forced unit access (FUA). If FUA is not supported, or if IDE is used, you should manually disable the write caching for drives that hold AD and critical databases.

Hyper-V supports these types of drives:

  • Fixed VHD
  • Dynamic VHD
  • Differencing VHD (Dynamic but linked to a parent VHD)
  • Pass-thru disks

In Hyper-V, fixed VHDs provide a very slight performance increase over Dynamic but not much, not as much as they did in Virtual Server 2005. Fixed is preferred for servers and any production system, since the physical drive space is reserved up front. Fixed VHDs can be resized larger (expanded) but require the VM to be shutdown first. Fixed VHDs can not be resized smaller, but free tools exist to clone a fixed VHD to a new file with a smaller size (limited by how much free space is available at the end of the disk). Backing up a fixed VHD requires the entire file to be copied, not just the used space (deleted blocks still contain data but any blocks that have never had data written to it will be heavily compressed but still affect the amount of time to back it up compared to a dynamic VHD). Fragmentation only occurs when the file is created on the physical drive, and if that file is defragmented it will never become fragmented again. When fixed VHDs are created in Hyper-V, the entire file is written out and the disk space is securely wiped, if security is not a concern, free tools exist that can quickly create a fixed VHD as a sparse file.

Dynamically expanding VHDs could run into unexpected physical space issues as the size increases. Expanding VHDs can be resized larger (expanded) but require the VM to be shutdown first. Dynamic VHDs are more likely to be corrupted in the event of a power loss or unexpected restart. Dynamic VHD files are much more likely to be fragmented as they expand on the physical drive.

Differencing VHDs are dynamic VHDs that are linked to an existing parent VHD, and store only the changes so the parent VHD never changes. All reads are first attempted from the Differencing VHD, and then retrieved from the parent VHD if the data has not changed. Differencing VHDs start out small but over time can grow as large as the parent. The parent must be marked read only and never change, or all differencing VHDs linked to it are corrupted. The parent VHD can be fixed, dynamic or differencing.

Pass-thru disks can provide additional performance over VHD, assuming the physical SAN is adequate, some types of benchmarking show a considerable increase, but the difference is minimal in benchmarks that simulate real word type data transfers. Pass-thru disks do not support snapshots (but snapshots are discouraged for production servers, and unsupported for DCs). The underlying disk storage system can be expanded and the VM’s operating system can expanded the volume without downtime. LiveMigration of VMs that use pass-through disks are noticeably slower and often include an interruption of service. Because pass-through disks are not cluster resources, they must be temporarily taken offline during transfer of ownership. The Hyper-V VSS writer cannot process a pass-through disk, any VM-level backup software will have to take the virtual machine offline while backing it up. Pass-through disks are less portable, access to the physical drives might not be moved to another Hyper-V host as easy as a VHD.

Links:

Frequently Asked Questions: Virtual Hard Disks in Windows 7 and Windows Server 2008 R2

VHD Performance white paper

What’s new in Windows Server 2008 R2 Hyper-V Performance and Scale?

VHD File format

Hyper-V Guest Design: Fixed vs. Dynamic VHD

Managing Hyper-V virtual disks

Understanding Virtual Hard Disks with Native Boot

 

 

VIRTUAL MACHINE SNAPSHOTS

Most virtualization products use the term snapshots, VMM uses the term checkpoints, Virtual PC uses Undo Disks, Xen uses both snapshots and checkpoints.

If you only want the current state of the VM, and you don’t ever need to restore to a previous snapshot, then you just delete all of the snapshots. When you delete the most recent snapshot, you merge the current state into the previous snapshot or the original hard drive if there are no previous snapshots. When you delete an older snapshot (not the most recent), then that snapshot is merged into the previous snapshot or the original hard drive if there are no previous snapshots. Deleting snapshots can take a while to merge depending on how much has changed, so expect the hard drive to be busy for a while. Restoring snapshots is always fast because the changes are just discarded and not merged. I like to think of the snapshots as queued writes to the drive that are waiting to be merged into the next older version of that drive. If there are multiple trees of snapshots then it gets a little more complicated.

Hyper-V and Virtual PC refer to deleting the snapshot as Apply Changes. VMM, VMware, VirtualBox all refer to this as Delete Snapshot. Not sure about XenServer. I’ve seen seasoned VMware experts lose data in Hyper-V because the Apply Changes term is confusing. Regardless of the name used, this really means merge the changes in that snapshot with the previous snapshot or the original hard drive if there are no previous snapshots.

Most products use the term restoring a snapshot, but Virtual PC uses the term Discard Changes.

Most products allow multiple snapshots and multiple snapshot trees. Virtual PC only allows one snapshot for each VM, and refers to this single snapshot as Undo Disks (using a plural name even though it only allows one – I guess this makes some sense since a VM can have more than one disk).

Hyper-V does not support snapshots for pass-thru disks.

Hyper-V does not delete snapshots when the GUI says they are deleted, they remain on disk until the VM is shutdown. When the VM is shutdown, the snapshot deletion (merge) begins, but if you start up the VM before it is finished you get no indicator that the process is not complete, and all progress is lost and will be attempted again at the next shutdown. A Hyper-V VM with multiple deleted snapshots can use enormous amounts of disk space until it is shut down for an extended period.

 

 

SHADOW COPIES / VSS

The max number is of software shadow copies for each volume is 512. However, by default you can only maintain 64 shadow copies that are used by the Shadow Copies of Shared Folders feature. To change the limit for the Shadow Copies of Shared Folders feature, use the following registry key: MaxShadowCopies.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\Settings

Create a value with the name MaxShadowCopies and type DWORD. The default data for this value is 64. The minimum is 1. The maximum number of shadow copies is 512 per volume.

Windows Server 2003: On cluster servers, MaxShadowCopies registry value’s data may need to be set to a lower number. For more information, see When you use the Volume Shadow Copy Service on Windows Server 2003-based computers that run many I/O operations, disk volumes take longer to go online.

Windows XP: This registry value is not supported.

Links:

http://msdn.microsoft.com/en-us/library/bb891959.aspx#maxshadowcopies