This project is read-only.

"VHDX space must be allocated on 1MB boundaries" Error

Sep 3, 2015 at 4:59 PM
I'm currently using the Altaro Hyper-V Backup product, which uses discutils internally.

I've converted a fileserver hard drive using the Disk2VHD tool and added it to a VM and it's been backed up by Altaro.

In the program though I'm unable to use the File Level Restore option because of the "VHDX space must be allocated on 1MB boundaries" error that Altaro is receiving from Discutils.

Altaro has also mentioned that the issue has only been encountered once before from someone else that had performed a Disk2VHD conversion.

Does anyone have an idea of what I can do to fix the VHDX file so that it will work properly with Discutils?
Sep 3, 2015 at 7:26 PM
Without looking at the file, my guess would be that disk2vhd didn't extend the VHDX file out to a multiple of 1MB. If you look at the VHDX file size using dir, is it an exact multiple of 1,048,576 bytes?

On a copy of the file you can try using one of the techniques here to pad the end of the file with zeros:

Sep 3, 2015 at 9:52 PM
Thank you so much Ken for your response!

When I check in on my end dir replies with:
Volume in drive C has no label.
Volume Serial Number is 8279-8551

Directory of C:\ClusterStorage\Volume4\IT903S-FS1_DATA

08/30/2015 07:23 PM <DIR> .
08/30/2015 07:23 PM <DIR> ..
08/30/2015 07:23 PM 3,008,205,160,448 IT903S-FS1_DATA.VHDX
           1 File(s) 3,008,205,160,448 bytes
           2 Dir(s)  1,389,361,364,992 bytes free
And if I take that and divide that by the value you provided it seems to return a whole number:
3,008,205,160,448 / 1,048,576 = 2,868,848

The VHDX file itself was created via Disk2VHD from a 5 TB volume (with about 2.8 TB used) that was connected to one of our VMs via iSCSI Initiator (since our backup tools could not see the iSCSI Initiated drive so converting it to a VHDX was necessary in order to allow it to be backed up). The backup itself appears to be's simply opening/mounting it via discutils (which seems to be used at an underlying level within the Altaro product) that seems to be the issue (and prevents the File Level Restore feature from being used, which is one of the primary use cases we would have for the product).

Right now with the information I've shared above appearing to check out OK, would you have any other possible thoughts on what the issue could be?

Sep 5, 2015 at 9:27 PM
Edited Sep 5, 2015 at 9:28 PM
Any other thoughts on this one?

With the extra info I provided hopefully that'll help a bit to figure something out.

This weekend I'm actually going through the same conversion for another server that holds our My Documents files, so I'll be able to find out probably by the end of the day on Monday, whether or not this issue will effect that VHDX file that gets created too.

From Altaro I've received the following responses (you can probably get the context of the questions they were replying to in the paragraphs below):
"This is not a ‘known issue’ on Disk2VHD at all actually… we have several customers who have used Disk2VHD successfully.
To be more specific, the error means that the vhdx that discutils (the component we use for File Level Restore) is trying to open does not comply with the Microsoft VHDX specification properly. So discutils fails to open it.

Yes a full restore will work just fine! Your issue is with file level restore only because our software needs to mount that VHD of yours which throws back an error when doing so.

Correct, however we do not know what in particular is wrong with your particular VHDX, but we do know that it does not comply with the Microsoft VHDX specification, which you can see in more detail here if you like:

This most certainly IS an uncommon situation, as I have previously mentioned this has occurred just 1 time before (we have over 30,000 customers using this product), and many Disk2VHD conversions have been successful. I cannot say whether or not the Optimize-VHD cmdlet will help you out here, but it is worth a try on your end if you like."

I haven't tried the Optimize-VHD cmdlet on my end (still not 100% sure what the procedure would be to try it, but it seems like the main cmdlet to try out to maybe fix the VHDX file). Then again, it could simply be a bug in discutils that only occurs in a very specific/rare scenario (which I don't know how to fix).

Thanks for any additional thoughts you might have on the issue!