Understanding and Working with VHD(X) Files

Save to My DOJO

Understanding and Working with VHD(X) Files

A virtual machine is an abstract computer, including the VHDX virtual disk file used in Hyper-V to represent the physical hard drive attached to a physical computer. It mimics a physical computer for the purpose of extending the flexibility of the computer system while still providing as many features of the physical environment as possible. Hyper-V, like most hypervisors, defines this abstract computer using files, as in the case of the VHDX file mentioned at the outset. The VHDX virtual disk file provides many features and capabilities that allow IT admins to have advanced functionality for business-critical workloads running in the enterprise. We will also consider the differences in the older VHD vs VHDX file.

Understanding and working with VHDx files

What is a VHD/X file?

VHDX is a semi-open file format that describes a virtual hard disk. With the virtual hard disk represented by a file, it also makes it easy to import VHDX to Hyper-V which allows moving virtual machines and data around easily. You can also restore Hyper-V virtual machine from VHDX since this can contain the operating system installation and all data. The x was added to the current specification’s name so that it would not be confused with the earlier VHD format. Microsoft publishes this specification freely so that others can write their own applications that manipulate VHD/VHDX files, but Microsoft maintains sole responsibility for control of the format.

A VHDX mimics a hard disk. It is not related to file systems, such as NTFS or FAT, or EXT3. It is also not concerned with partitions. VHDX presents the same characteristics as a physical hard drive, SSD, SAN LUN, or any other block storage. It is up to some other component, such as the guest operating system, to define how the blocks are used. Simply, a VHDX that contains a possible NTFS format looks like the following:

VHDX Visualization

VHDX Visualization

 

Where can VHDX Be Used?

This is a Hyper-V blog, so naturally, I will usually only bring up VHDX in that context. It is not particular to Hyper-V at all. Windows 7 and Windows Server 2008 R2 were able to directly open and manipulate VHD files. Windows 8+ and Windows Server 2012+ can natively open and manipulate VHDX files. For instance, the Disk Management tool in Windows 10 allows you to create and attach VHD and VHDX files:

Windows 10 VHD Menu

Windows 10 VHD Menu

When mounted, the VHDX then looks to the operating system like any other disk:

Mounted VHDX

Mounted VHDX

 

The most important thing to know is whether or not you can use VHDX depends entirely upon the operating system that controls the file, not anything inside the data region of the file. The contents of the data area are an issue for the operating system that will control the file system. If it’s used by Hyper-V, then that is the guest operating system. If the VHDX is mounted in Windows 10, then Windows 10 will deal with it entirely. It will do so using two different mechanisms.

The VHDX Driver

Modern Windows operating systems, desktop, server, and Hyper-V, all include a driver for working with VHDX files. This is what that driver sees when it looks at a VHDX:

VHDX View from Hyper-V

VHDX View from Management Operating System

 

Windows 7 and Windows/Hyper-V Server 2008 R2 and earlier cannot mount a VHDX because they do not contain a VHDX driver. They can only work with the earlier VHD format. If a VHDX driver existed for those operating systems, they would theoretically be able to work with those file types. Logically, this is no different than attaching a disk via a SCSI card that the operating system may or may not recognize.

The File System Driver

The file system driver sees only this part:

VHDX View From Inside

VHDX View From Inside

 

There is no indication that the visible contents are held within a VHDX. They could just as easily be on a SAN LUN or a local SSD. For this reason, it does not matter at all to any guest operating system if you use VHDX or some other format. Linux guests can run perfectly well from their common ext3 and ext4 formats when inside a VHDX.

When a VHDX is mounted in Windows 10 or a server OS, it will require both the VHDX driver and the file system driver in order to be able to manipulate and read the contents of the file. You can mount a VHDX containing ext3 partitions inside Windows 10, but it will be unable to manipulate the contents because it doesn’t know what to do with ext3.

VHD vs VHDX?

You might ask the question – under what conditions might it be necessary to create a VHD file rather than a VHDX file? If you will never use the virtual disk file with down-level management operating systems (Windows 7 or Windows/Hyper-V Server 2008 R2 or earlier), then you should always use VHDX (remember that guest operating systems don’t know or care which you use). 

Microsoft Azure still does not support uploading VHDX files, but you can replicate your VHDXs there. If you need to mount them on the Azure side, they will be automatically converted to VHD, although you do need to stay below the 2TB maximum size limit of the VHD file format. . 

Difference between VHD and VHDX

There are several fundamental and important differences to note between VHD and VHDX. Note the following differences (and advantages) of VHDX:

  • VHDX has a larger configuration maximum – 64 TB of storage capacity, compared with 2TB with VHD
  • VHDX includes data corruption protection
  • It is supported in Windows Server 2012 and higher
  • It supports live resizing, which is not supported with VHD virtual disks
  • It supports the 4 KB sector size which is more efficient than the 512 KB sector size of VHD
  • It supports advanced data alignment not supported with VHD
  • It supports data trim operations not supported with VHD
  • Custom metadata support not supported by VHD

VHDX and VHD conversion operations

One of the tasks that may come up for the Hyper-V administrator is converting between various virtual disk formats. When it comes to converting between the VHD and VHDX virtual disk formats, Hyper-V Manager allows IT admins to easily convert between the two. You can convert VHDX to VHD or VHD to VHDX by editing the virtual disk of the virtual machine and selecting the Convert option.

There are many third-party tools, some of which are free, to convert the following:

  • Convert VHDX to VHD without Hyper-V
  • Convert VHDX to VMDK
  • Convert to other virtual disk formats

Configuration Information for VHDX Files

There are a few things to understand about VHDX files before creating them. I have explained the process for VHDX creation in another article.

Generation 1 (VHD) vs. Generation 2 (VHDX)

I’ve seen some people use the Generation 1 and Generation 2 labels with VHD and VHDX. They’re correct in the abstract sense, but the capitalization is wrong because these are not formal labels. I encourage you not to use these terms at all because they easily become confused with Generation 1 and Generation 2 Hyper-V virtual machines. A Generation 1 virtual machine can use both VHD and VHDX as long as the management operating system can use both. A Generation 2 virtual machine can only utilize VHDX (except in Azure where a Generation 2 VM use VHD files).

VHDX Block Sizes

The block size for a VHDX has nothing to do with anything that you know about block sizes for disks in any other context. For VHDX, the block size is the increment by which a dynamically-expanding disk will grow when it needs to expand to hold more data. It can only be set at creation time, and only when you use PowerShell or native WMI commands to build the VHDX. For a fixed disk, it is always 0:

Block Size for Fixed VHDX

Block Size for Fixed VHDX

 

The default block size is 32 megabytes. This means that if a VHDX does not have enough space to satisfy the latest write request and has not yet reached the maximum configured size, the VHDX driver will allocate an additional 32 megabytes for the VHDX and will perform the write. If that is insufficient, it will continue allocating space in 32-megabyte blocks until the write is fully successful. While this article is not dedicated to dynamically expanding VHDXs, I want to point out that there is a persistent FUD that these expansion events kill performance.

The people making that claim have absolutely no idea what they’re talking about. A heavily-written VHDX will either reach its maximum size very quickly and stop expanding or it will re-use blocks that it has already allocated. A VHDX simply cannot spend a significant portion of its lifetime in expansion, therefore it is impossible for expansion to cause a significant performance impact.

Expansion events will cause the new data blocks to be physically placed in the next available storage block on the management operating system’s file space. This, of course, will likely lead to the VHDX file becoming fragmented. Disk fragmentation in the modern datacenter is mostly a bogeyman used to terrify new administrators and sell unnecessary software or oversell hardware to uneducated decision-makers, so expect to be confronted with a great deal of FUD about it. Just remember that disk access is always scattered when multiple virtual machines share a storage subsystem and that your first, best way to reduce storage performance bottlenecks is with more array spindles/SSDs.

For Linux systems, there is a soft recommendation to use a 1-megabyte block size. Space is allocated differently with the Linux file systems than NTFS/ReFS. With the 32 megabyte default, you will find much more slack space inside a Linux-containing VHDX than you will inside a Windows-containing VHDX. The recommendation to use the smaller block size can be considered soft because it doesn’t really hurt anything to leave things be — your space utilization just won’t be as efficient.

VHDX Sector Sizes

The term sector is somewhat outdated because it refers to a method of mapping physical drives that no one uses anymore. In more current terms, it signifies the minimum amount of space that can be used to store data on a disk. So, if you want to write a bit of data to the disk that is smaller than the sector size, it will fill the rest of the space with zeroes. The logical sector size is the smallest amount of data that the operating system will work with. The physical sector size is the smallest amount of data that the physical device will use. They don’t necessarily need to be the same size.

If the logical sector size is smaller than the physical sector size, read and write operations will be larger on the actual hard drive system. The operating system will discard the excess from reading operations. On write operations, the physical drive will only make changes to the data indicated by the operating system although it may need to touch more data space than was called for. There are a great many discussions over “performance” and “best” and the like but they are all largely a waste of time. The VHDX driver is an intermediate layer responsible for translating all requests as best it can. The true performance points are all in the physical disk subsystem. To make your I/Os the fastest, use faster hardware. Do not waste time trying to tinker with VHDX sector sizes.

Remember that “portability” is a major component of virtualization. If you do spend a great deal of time ensuring that your VHDX files’ sector sizes are perfectly in-line with your physical subsystem, you may find that your next storage migration places your VHDXs in a sub-optimal configuration. The “best” thing to do is use the defaults for sector sizes and let the VHDX driver take care of it.

VHDX Files Do Not Permanently Belong to a Virtual Machine

When you create a virtual machine using any of the available GUI methods, you’re also given the opportunity to create a VHDX. Behind the scenes, the virtual machine creation and the virtual hard disk creation are two separate steps, with the act of attaching the VHDX to the virtual machine being its own third operation. That final operation will set the permissions on the VHDX file so that the virtual machine can access it, but it does not mean that the VHDX requires the virtual machine in order to operate. A virtual hard disk file:

  • Can be detached from one virtual machine and attached to another
  • Can be re-assigned from one controller and/or controller location to another within the same virtual machine
  • Can be mounted in a management operating system

I have an article explaining the process for VHDX attachment; it shows the various elements for controller selection as well as remove options so that you can perform all of the above. As for the VHDX files themselves, they can be transported via copy, xcopy, robocopy, Windows Explorer, and other file manipulation tools. If a virtual machine somehow loses the ability to open its own VHDX file(s), use this process to detach and reattach the VHDX to the virtual machine; that will fix any security problems.

Mount a VHDX File to Read in Windows (Even Your Desktop!)

As briefly mentioned in the opening portion of this article, you can mount a VHDX file in Windows 10/11 (as well as Windows 8 and 8.1 and Windows Server 2012+). This allows you to salvage data from a VHDX file if its original operating system had some sort of fatal problem. You can use it for more benign situations, such as injecting installation files into a base image. Just right-click on the file in Windows Explorer and click Mount:

Mount VHDX Using Windows Explorer

Mount VHDX Using Windows Explorer

 

All of the partitions will then be assigned drive letters in your management operating system and you can work with them as you would any other partition.

Note: When mounting VHDX files that contain boot partitions, you will sometimes get Access Denied messages because the file system drivers can’t read from those partitions. These messages do not impact the mount action.

When you’re done, just right-click on any of the partitions and click Eject. If there are no partitions visible in Windows Explorer, right-click the disk in Disk Management and click Detach VHD.

Mount a VHDX File Using PowerShell

You can use PowerShell to mount a VHDX only on systems that have Hyper-V installed. Just having the Hyper-V PowerShell module installed is not enough.

Mount a VHDX:

Mount-VHD -Path D:ImportsImportedDisk.vhdx

Dismount a VHDX:

Dismount-VHD -Path D:DemoDemoDisk.vhdx

If you know the disk number of the mounted VHDX, you can use the -DiskNumber parameter instead of the -Path parameter.

Copy a Physical Disk to a VHDX

There are many ways to get a physical disk into a VHDX. Be aware that just because you can convert a disk to VHDX does not mean that it can successfully boot inside a virtual machine! However, it will always be readable by any management operating system that can mount a VHDX and has the proper file system driver. These are the most common ways to convert a physical drive to VHDX:

Backup and Restore VHDX Files

The “best” way to backup and restore of a virtual machine is to use a backup application specifically built for that purpose. But, the poor man’s way involves just copying the VHDX files wherever they are needed. For a “restore”, you’ll need to attach the virtual disks to the virtual machine that will own them.

Attach an Existing VHDX to an Existing Virtual Machine or Reset VHDX File Security

Occasionally, you’ll need to (re)connect an existing VHDX file to an existing virtual machine. Sometimes, you have to rebuild the virtual machine because its XML file was damaged. I sometimes do this because I have VHDX files that I use for templates that I can usually patch offline, but sometimes need to bring online.

While not directly related to the preceding, there are times when a virtual machine loses the ability to open a VHDX. This is invariably the result of an administrator or security application removing necessary permissions from the VHDX file, often by erroneously setting inheritance from its containing folder.

Both problems have the same solution: use the attach directions. Hyper-V will automatically set the permissions as necessary when it connects the VHDX to the virtual machine.

Move a VHDX from One Bus to Another on the Same Virtual Machine

Generation 1 virtual machines have both a virtual IDE bus and a virtual SCSI bus. It’s rare, but sometimes you’ll want to move a VHDX from one to the other. The volume that contains the system bootstrapper must always be IDE 0 disk 0 (the first one), but any other disk can be moved.

You might need to do this because you accidentally placed a Windows page file on a virtual SCSI disk, which usually doesn’t work (and wouldn’t help with performance if it did, so stop that), or because you discovered the hard way that online resize operations don’t work with IDE-connected VHDX files. You can, of course, also move between different controllers and positions on the same bus type, if you have some need to do that.

Remember that you cannot modify anything on a VHDX connected to the virtual IDE bus while the virtual machine is online. The virtual SCSI bus allows for online modification.

Use the GUI to Move a VHDX to another Bus or Location

You must use Hyper-V Manager for non-clustered virtual machines and Failover Cluster Manager for clustered virtual machines. Or you could use some other application not covered here, like SCVMM.

In the relevant tool, open the settings dialog for the virtual machine and click the drive that you want to change. On the right, choose the new destination bus and location:

VHDX Bus Move

VHDX Bus Move

 

Notice that as you change the controller, the dialog contents will change automatically so that it already appears to be on the destination location before you even click OK or Apply. It will also show In Use for any location that already has an attached drive.

Use PowerShell to Move a VHDX to another Bus or Location

In PowerShell, use Set-VMHardDiskDrive to relocate a VHDX:

Set-VMHardDiskDrive -VMName svtest -ControllerType IDE -ControllerNumber 1 -ControllerLocation 1 -ToControllerType SCSI -ToControllerNumber 0 -ToControllerLocation 0

Warning: If running through a remote PowerShell session, be extremely mindful about second hop and delegation concerns. While it is not obvious, the above cmdlet first detaches the drive from its current location and then attaches it at the specified destination. Far fewer permissions are required to detach than attach. It is entirely possible that you will successfully detach the VHDX… and then the cmdlet will error, leaving the disk detached.

To properly protect your Hyper-V virtual machines, use Altaro VM Backup to securely backup and replicate your virtual machines. We work hard perpetually to give our customers confidence in their Hyper-V backup strategy.

To keep up to date with the latest Hyper-V best practices, become a member of the Altaro DOJO | Hyper-V now (it’s free).

Wrapping Up

As noted, there are many advantages to the newer VHDX virtual disk format. For most running client Hyper-V or Windows Server with the Hyper-V role installed, the VHDX virtual disk format will be the preferred format for running workloads. There are cases where running VHD is still required, such as running virtual machines on legacy Windows Server versions such as Windows Server 2008 and 2008 R2. Hyper-V provides an easy way to convert from VHD to VHDX or from VHDX to VHD.

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!

Frequently Asked Questions

Both the VHD and VHDX files are virtual disk formats available for Microsoft Hyper-V. The VHD file format is the older of the two formats, with the VHDX virtual disk format introduced with Windows Server 2012. The VHDX virtual disk format provides more features and capabilities than the VHD format. The VHDX file contains many advanced features not found in the VHD file, including an advanced file format that has built-in data corruption protection. The VHDX file format has larger configuration maximums, such as a 64 TB storage capacity limit. It also sports other features such as live resizing, data alignment features, and trim support.
In the modern virtual disk format, VHDX files can be mounted and opened in modern versions of the Windows client and Windows Server operating systems, such as Windows 10 & 11, and recent Windows Server versions such as Windows 2016, 2019, and 2022.
The VHDX file format is the newer virtual disk format available in Windows 10 Hyper-V, supporting the newly available features found in the VHDX format. When you create a new virtual machine in Windows 10 Hyper-V, the VHDX format is the default virtual disk created for a new virtual machine, such as a new Windows 10 VHDX. You can, however, still create the VHD virtual disk type when you use the Hyper-V Manager to create a “new virtual disk” instead of creating a new virtual machine. So, client Hyper-V can use either VHD or VHDX virtual hard disks.
Two great features of the VHDX file format are the built-in data corruption protection and live resizing feature.

80 thoughts on "Understanding and Working with VHD(X) Files"

  • Brian Rankin says:

    Great article! Quick question: if I have a large (2TB) VHDX file available from a WAN location via a site-to-site VPN, can I mount it to browse it’s contents? i.e. will the mounting process cause a ton of traffic over the VPN connection?

    And if it’s mounted, will browsing the contents create traffic problems? Again, no application is being run from the VHDX file, it contains just stored data files.

    • Eric Siron says:

      I don’t have the experience to definitively answer your question.
      I do know that if a mount operation does not complete in a certain amount of time, the entire process fails. I have seen this with large files over a 802.11g connection.
      Once it’s mounted, the I/O characteristics would be about as you’d expect. It needs to read the file allocation table to find files, then regular block I/O. That traffic will be encrypted as it traverses your VPN. That’s probably asynchronous encryption, so the data will be very inflated in size while it crosses the inter-site wires. If you’re only reading and writing the occasional small files, the latency would be high but probably tolerable otherwise.

  • Sam says:

    Hello,

    I have a setup where I will run a Ubuntu Server on two VHDX disks.
    System 50GB and Data 4TB. They are located on a mirrored Storage Spaces Pool and are dynamic expanded.

    During the Ubuntu installation the system disk got created on first VHDX as a EXT4 on a LVM pool.

    My question is if its a good idea to use LVM on linux, or just simpel EXT4 on system and / or data-disk.
    Just a “mkfs”, file system creation of the Data-disk to EXT4 result in a 60GB expanded VHDX-file.

    “mkfs -t ext4 -E lazy_itable_init=1 /dev/sdb1”

    I created the machine before I read about the “VHDX Block Sizes”. So maybe thats a reason…

    What are your thoughts?
    Regards,
    Sam

    • Eric Siron says:

      I’m just using the default EXT4 on LVM for all of my Linux machines. The ones that I used the default block size for are larger than necessary, but none of mine have expanded to full.
      I’m not an expert, but I think that the “lazy_itable_init” flag still reformats the entire space, but does it in the background.

  • Tim says:

    great articel! I have a short question:
    I have a hyper-V server which I can just boot from a live USB (no one knows what happens to this server 🙁 ). So I get access to the virtual discs (vhdx, 3TB) from a linux environment. What is now the easierst way to get my files back.

    thank you for your help
    regards,
    Tim

    • Eric Siron says:

      Unless Linux has a way to mount a VHDX, you’ll need to take whatever steps you feel most comfortable with. You can move the VHDX files to any Windows system and mount them to extract data. At least make a copy of them if you haven’t got a backup. You could run an “upgrade” install of Hyper-V Server to restore bootability and then import the VMs where they sit.

  • Jake says:

    Thank you for the article! Very informative.
    I use VHDX and VHDS files with my home desktop, run from internal SSD or NAS.
    I find that running virtual disk over network is more flexible solution than mapping network drive. One thing that really bothers me though, is that every one and again, if I won’t manually dismount network run VHD when shutting down pc, after next logon I get “File is being used by another process” error when trying to mount it. There are also network errors when I use Hyper-V to shrink VHD kept on NAS.

  • dev says:

    Hi Sir,

    I’m interested in the VHDX file data store and retrieving algorithms,

    so created the sample dynamic type VHDX file (around 452MB size) which having some files ,

    Now as per specification (https://www.microsoft.com/en-in/download/details.aspx?id=34750) able to retrieve the Actual disk structure
    i.e
    1. Able to read MBR,
    2. Get Partition Table which having only one partition i.e NTFS
    3. Now looking for MFT entry offset but struggling?

    Will you help me into this findings of MFT File entry physical offset in VHDX file?

    In Fixed type of VHDX getting the proper MFT Entry.

    Regards,
    Dev

    • Eric Siron says:

      I do not currently possess the skill set to answer this question. Hopefully someone else can respond.

  • Kjartan says:

    Hi,

    I’d like to figure out which vhdx file is what drive inside the VM.

    Eg if i have f:VMmyVMmyhd.vhdx which is attached to MyVM, how would i know which disk this is inside the VM. This is very usefull in finding out which vms have grown alot, but then content is deleted so it would be possible to shrink/compact it.

    Is this possible?

    • Eric Siron says:

      If you’re going to be shrinking a VHDX, then you’ll have to take its VM offline. If you’re going to be taking its VM offline anyway, then you can mount the VHDX and look at its contents.
      While the VM is offline and after you’ve figured out what the contents are, detach the VHDX from the VM, rename it to something meaningful, and then re-attach it to the VM.
      I don’t know of any way off-hand to match them otherwise. I’m sure that I could come up with a solution, but I think that fixing the file names is a superior long-term solution.

  • Bob Sauers says:

    I really enjoy reading your material. We have multiple copies of Altaro Backup for our Hyper-V servers.

    I have what I think is a “quick question” regarding one of the articles posted on your website:
    https://www.altaro.com/hyper-v/understanding-working-vhdx-files/

    In the article, it discusses VHDX Block sizes and VHDX sector sizes.
    Since we are creating fixed size VHDXs, I know to leave the Block Size at 0.

    The paragraph about VHDX Sector Sizes basically suggests that you not tinker with it.

    On my Hyper-V 2012 R2 servers, the DEFAULT sector sizes are:

    Logical sector size 512
    Physical sector size 512

    HOWEVER, the screen shot of a powershell window in the article shows:

    Logical sector size 512
    Physical sector size 4096

    So, do I take the recommendation to not tinker with it and leave it at 512/512 or do I follow my gut and use 512/4096 to match the NTFS default cluster size (which also matches what the article shows in the powershell screenshot)?

    • Eric Siron says:

      Do you know if you have drives with physical 4k sectors? If you do, then I would override to that. If your drives have 512 byte sectors, then what your system has selected is fine.
      You might also do some performance testing both ways. If you have to override every single VHDX that you create, that could get tedious.
      I wouldn’t expect a lot of difference. Windows will still work in 4k blocks regardless of the underlying sector size so it will almost definitely be a wash in terms of performance.

  • Stephen Goemans says:

    Hi Eric, thanks for this very useful info. Do you know if the vhdx can contain a hard disk serial number ? We have an application which calls on wmic to grab the hard disk serial number for licencing. Currently, Hyper V shows no way of storing a response to the wmic call ?
    Thank you

  • Pete says:

    Hi Eric,

    Where did you find the information that its possible to mount a VHDX file in Azure and it will be automatically converted to VHD?

    Cheers

    • Eric Siron says:

      This is a really old article and I was extrapolating from early information. If you use Microsoft-sanctioned tools to replicate your VM with VHDX into Azure, they will convert it so that it works. I recommend finding someone with better Azure experience to explain how and when it works. Maybe I just plain misunderstood what I read. I don’t think that you can just straight-up copy the VHDX up there and have it work, though.

  • Fred Marshall says:

    What would you do if you had a VHDX file associated with a GEN2 VM and it would not open or mount? Is there a way to fix it?

    • Eric Siron says:

      Microsoft does not publish any repair tools that I know of. I would start by attaching it to another Linux VM as a secondary drive to see if it would work there. If it won’t mount at all anywhere, then the headers are trashed. I know that VHDX repair tools exist but I have not personally tried any.

  • Darden says:

    Thanks, Eric! If I want to create a Windows 10 VM that I can open on any Windows PC (without Hyper-V), can I do that? I want to put a VM on a USB to take with me. Networking is not a concern.

    • Eric Siron says:

      No, you can’t run a VM without an installed hypervisor. You could export a VM and carry it on a USB disk and import it on any PC running Hyper-V.

  • Sascha says:

    Hi Eric. Great Article.
    I’d like to have a VHDX-disk as sort of a Secured-Storage-Container on a Windows 10 and I like to encrypt it with Bitlocker.
    But at first, I have the problem, that the user with user-rights cant “mount” it. is there a special Access-right for that ? Failure is “you don’t have permission to mount the file” but as mentioned above, the Disk isn’t mount at all on my system.

  • Jason says:

    Eric,

    I have a VHDX which is partitioned as MBR. I cannot expand it due to MBR size limitation of 2TB. It is stored on a logical volume which is partitioned as GPT. Is there a way to convert this VHDX to GPT so I can expand it easily?

    • Eric Siron says:

      This isn’t really about VHDX — you can mount a VHDX in all currently supported Windows environments and manipulate its volume(s) like any other. If it doesn’t contain the VM’s OS’s boot volume, you can usually manipulate it right in the guest OS.
      The big deal is the change from MBR to GPT. That’s non-trivial. I don’t know of any supported non-destructive way to do that. I have seen third-party tools that claim to do it.

  • Roger Clark says:

    Eric:
    have recently started supporting a server running Microsoft Server 2019 with Hyper-V. In Windows Explorer, one of the virtual drives shows it is full and the space is colored red. The physical drive that correlates to it is operable except one mapped drive is no longer accessible. Interestingly, when viewing it in Explorer it is listed but shows no information in terms of its size. When looking at its properties it displays used space and free space of 0.
    I have read on your blog how to expand the file size of a VHDX virtual drive and see where it is necessary to also expand the size of the physical drive as well. My problem is that although I can easily expand the size of the VHDX from 1.6 TB to up to 64 TB, the physical drive is only a 2 TB SATA drive.
    I would like to know how to resolve this issue. I suspect that the fact that the virtual drive shows it is full and red in color that this doesn’t have a direct affect on the physical data. But I wonder if the mapped drive that won’t open is affected by the condition of the virtual drive. I moved 120 GB of data from the physical drive but the status of the virtual drive was unchanged and the problem area is still inaccessible.
    Is it possible to expand the virtual drive from 1.6 TB to something closer to 2 TB like 1.8 TB for example and then expand the physical drive to match it or is 1.6 as much as I can allocate to the physical drive?
    If there is no more room on the physical drive, can I replace the 2 TB drive with a 4 TB drive and then expand the virtual drive to 3.5 TB and match the allocated space on the new drive?
    If you can refer me to an article you have written that speaks to this or recommend a source where I can read to understand this I would be happy to receive that in lieu of you taking time to write out a response. Of course, if you are willing to answer this directly I would happily receive any information you would provide.
    I have been reading some of your material on Hyper-V and have found it very informative. This is a new area for me. The information I have read so far from your blog has been very helpful.
    I would appreciate any direction you would offer.
    Thanks,
    Roger

    • Eric Siron says:

      Sorry for the response delay, I’m not getting notifications for some reason.
      I’m a bit lost on the mapped part. Whatever you do, make sure you are working directly against the problematic resource, not remotely from a client system. Do not troubleshoot more than one thing at a time.
      If a VHDX is dynamically-expanding, then you can technically set it to any size you like up to the format’s stated maximum. But, it can’t expand beyond what the physical drive can provide.
      You can relocate a VHDX to a physical drive or array with larger capacity. I don’t know if I have an article on exactly that because of the multitude of options to make it happen. You can use Storage Migration to move it from one connected physical drive to another. You can replace it inline with a block-copying tool, ensuring that the new disk has the same ID and in-system drive letters as the old one. You can disconnected the VHDX from its owning VM, then copy the file anywhere you want and re-attach it once it has a final home.

  • Spence says:

    Hello, And thank for this work!

    Do you now how I can split my .vdhx in multiple files?

    For backup, I use robocopy (fan of all natives solutions on windows).
    But robocopy copy the entire file each time (logicaly…)

    I hope if i have multiple .vdhx (I have about 25GB vdhx, and want about 25 files og 1GB for an exemple), I can backup and defrag more efficiency (220,000 fragment for my 25vdhx file… very very long to read…)

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.