Resizing a Linux partition running under Hyper-V

Resizing a Linux partition running under Hyper-V

We’ve all been there. Setting up a new machine and giving it a 20GB hard drive because it’ll literally only need 4GB ever and then, two years later, it’s somehow full and won’t boot. Unlike Windows based guests on Hyper-V, which can have their drives resized easily by the Hyper-V tools, Linux guests are a little different.

You can certainly resize the disk image in the same way (turn the VM off, choose Edit Disk, and then Expand), but Linux doesn’t see the extra space. To make things worse, if – like me – you set the VM up originally as a Generation 2 machine (with all the UEFI bells and whistles) then some Linux tools and rescue images like gparted and fdisk don’t work properly (with boot errors like ” efi: EFI_MEMMAP is not enabled”). Plus my machine wouldn’t boot to install or run them because, as I said, it was full.

Anyway, here’s how I resized it. This all relates to a Debian 9 guest on Hyper-V on a Windows Server 2016 machine, but the process should be the same for most Linux variants.

Firstly, after turning the VM off, I resized the image in the Hyper-V Manager as above – using Edit Disk.

Then, I made a copy of the disk just in case. Turned out this wasn’t necessary, but better to be safe.

So, since I couldn’t use the current VM to fix my drive (Gen 2, tools don’t work, won’t boot), I set up a new temporary VM in Hyper-V, making sure I chose Gen 1 this time. I added the hard drive image from the real VM as the drive, and then set it to boot from an ISO of gparted. This allowed me to access the drive and resize the partitions. Before I did that, however, gparted had detected a change in drive size and asked if I wanted to fix it – I said yes.

Since I had three partitions (/dev/sda1 to sda3) but it was the second (sda2) that needed expanding, I had to move sda3 to the end of the drive first. It’s all pretty straightforward in gparted – just remember to actually apply your changes when you’re done as otherwise nothing happens!

This temporary VM was then turned off, the drive image was reattached to the original VM and… it didn’t work.

Hyper-V threw immediately threw up a permissions error, as it couldn’t access the disk image any more. ” An error occurred while attempting to start the selected virtual machine(s)”, and this:

Hyper-V Virtual Machine Management service Account does not have sufficient privilege to open attachment 'D:\PathToImage\DriveName.vhdx'. Error: 'General access denied error' (0x80070005). (Virtual machine ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

Luckily, this is fixable. Make a note of the Virtual Machine ID in the error, and then run this command in an admin console substituting the ID for all the Xs and the actual full path to the image:

icacls "D:\PathToImage\DriveName.vhdx" /grant "NT VIRTUAL MACHINE\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx":(F) 

With this done, I could finally boot my original virtual machine successfully. In my case, it did a quick disk check itself automatically, and then everything was working normally only I’ve a lot more disk space to play with!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.