Hyper-V Disk Usage Explained

Table of contents

This post will look at how Hyper-V uses storage in terms of disk space allocation. It will not look specifically at or contrast connectivity or physical platform types.

The Hypervisor

In terms of disk space Hyper-V itself can’t really be distinguished from its management OS. This will use approximately 20 GB, not including a page file. Hyper-V Server 2012 tends to make a reasonably sized page file. In other cases, the operating system will create a default page file based on available physical memory. Since physical computers intended to run hypervisors tend to have high quantities of memory, this may be a much larger size than is actually necessary. We have a post indicating how to check and adjust this.

Aside from what is used, you’ll also need to maintain free space. There are no definite best practices to follow. If you’re going to be backing up the system partition, VSS requires at least 20%. Windows Update patches will occasionally require multiple gigabytes temporarily. You’ll also need to consider antivirus and any other system applications you’ll be installing. Commonly, a modern Windows Server installation is placed on a 40GB partition or greater. This assumes that you won’t be using this partition for anything else, like storing virtual machines.

Virtual Machines

The most obvious storage need for a virtual machine is the VHD files that represent its hard drives (2012 can also use VHDX files; for the purposes of this post, the two types are interchangeable so only .VHD will be talked about). Fixed VHDs are the easiest to account and plan for. They’ll be a tiny bit larger than their allocated size. Dynamic disks will be a little more than their maximum size or less. Differencing disks (whether manually created or snapshots) can grow to fill all available space. If that occurs in a location where VHDs for active virtual machines are stored, Hyper-V will pause them.

You can use the properties of a virtual machine to change the location its snapshots are created so as to reduce the risk of having several virtual machines pause. However, the owning virtual machine will still pause if it has an active differencing disk and its location runs out of space. It can be difficult to merge these if that happens, so be mindful of differencing disk growth. For a manually created differencing disk, you can specify where it will be stored at creation time.


Snapshot Location

When a machine is saved, its state is held in a .VSV file. This contains state information besides disk and memory. They are variable in size, but typically no more than a few megabytes. They are kept in a subfolder of the “Virtual Machines” folder. The subfolder is named with the unique ID of the VM.

Along with the .VSV, a .BIN file may be present. It is intended to hold the contents of the VM’s RAM while it is in a saved state. In 2008 R2, this file is always present and is the same size of the virtual machine’s system memory. The file is simply idle while the virtual machine is powered on; it is pre-allocated so that its space is guaranteed to be available if needed and for quicker response to a save action. On 2012, if a machine’s “Automatic Saved State” is not “Save State”, then the .BIN file is not created. It is still possible to manually save the state as long as there is enough room for the file.

An .XML file representing the configuration of the virtual machine exists in the root of the configuration location. This file can be viewed but is very sensitive to tampering. Use extreme caution (and backups) if you intend to modify it. This file is approximately 32KB in size.

For each active snapshot (as opposed to a snapshot that has been deleted and is awaiting a merge for its .VHD files), there are matching VSV and BIN files.

A “Planned Virtual Machines” folder exists on a Hyper-V Server 2012 installation. Incoming .XML configurations are placed there while non-cluster migrations are in progress.


For the most part, planning storage for a Hyper-V virtual machine centers on the VHD files. As density increases, the cumulative effect of the supporting files is also a consideration. These files also have to be moved during migrations, copied during backups, and tracked during replication, so it’s beneficial to know what to expect. It’s also helpful to be able to answer the “what’s this?” type of questions.


Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

5 thoughts on "Hyper-V Disk Usage Explained"

  • ales75 says:

    Hye !

    you forgot to mention something very important..
    live merge support multichannel.. do you want some screenshots ?!

    take care

  • Abiodun Sobowale says:

    Thank you for this and your other posts….

    A question though…. I want to migrate my Primary DC (currently a virtual server) to a physical server, how would you advise that i approach this?

    • Eric Siron says:

      You might be asking the wrong person. I never advocate for moving, upgrading, tweaking, poking, or even looking a domain controller directly in the eye for any reason. There are far more risks than rewards. I always advise building a new domain controller from scratch and either leaving the original alone until it dies or decommissioning it. FSMO roles, DHCP, DNS — all of that and anything else likely to be found on a DC can all be migrated easily. If you have a problem because you only have a license to operate one Windows Server as a domain controller, build a temporary virtual domain controller using a trial key, migrate roles, decommission the original domain controller, rebuild it in the new location, migrate roles again, and then decommission the temporary domain controller. It sounds like a lot more work than it really is.
      In your situation, I would build the new domain controller on the physical unit, move any critical roles over, and just let the virtual one ride along until you’re tired of it.

  • Jason says:

    Hi, thanks for your article. I’ve a question from a performance perspective.

    I have a 2012 Server which will run a VMs. The host machine spec is 146GB hardware mirror 15k disks, and a 1TB 7.2k hardware mirror data drive.

    The VM needs performance, specifically database lookup so I was considering running this on the boot parition. It’s 50GB in size and won’t grow beyond this. I was thinking of placing that VM on the boot partition because of the faster disk. Is there any performance disadvantage to the host OS because of this? The VM won’t be doing a lot of lookups or writing, it’s a doc management app that needs to do a database lookup and pass the client off to the file repository which is on the slower disk.

    Thanks in advance, Jason.

    • Eric Siron says:

      Hello Jason,
      Out of the box, the management operating system uses very little disk I/O after boot-up. You shouldn’t have any trouble carrying out your plan as long as you don’t use snapshots. If you want to use snapshots, make sure you target them to the terabyte mirror in advance.

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.