virtualbox.org

I've just tried several times to increase the disk size of my VDI guest OS, which states that completed successfully and the data presented in the VBoxManager screen showes the new size. Then when attaching gparted to the guest OS (Win7) and booting it does not indicate any additional space of unallocated HD to use, simple stays the same no matter what I do. Any help would be greatly appreciated.

Details:
VBox version: 4.0.6
Host: Ubuntu Lucid
Guest: Win7 (original HD 20Gb)

Command used to resize was:

If the guest is Windows 7 you do not need gparted. You can expand the partition from Computer Management|Disk Management (if there is space to expand into).

yeah, doesn't matter as the drive doesn't indicate it has been expanded (the first attachment) still just shows the original 20Gb with 800Mb remaining not the additional 20Gb that was added to make the drive a total of 40Gb.

cheers

Most likely you are using snapshots and have only enlarged the base VDI. Resizing a virtual drive that uses snapshots, while maintaining the snapshot structure, is... tricky.

charless wrote:yeah, doesn't matter as the drive doesn't indicate it has been expanded (the first attachment) still just shows the original 20Gb with 800Mb remaining not the additional 20Gb that was added to make the drive a total of 40Gb.

What I see in the first image is a list of existing partitions that are on that disk. What you did was make the disk bigger, but unless the newly added space would show up as "unpartitioned space" or something in that list I wouldn't expect it to change - what you'd have to do (haven't used gparted in a long time) would be resizing the last partition (i.e. C:) and adding the extra space to it. I'm pretty sure the "unused space" listed here is the unused space left in your NTFS file system in that partition...

Leak wrote:I'm pretty sure the "unused space" listed here is the unused space left in your NTFS file system in that partition...

I agree. I was kinda puzzled about that first image, because although the OP mentions gparted the picture is obviously not from that... I'm not at all sure where it's from. It's not the Windows Disk Manager because I know that clearly shows uninitialized space on a drive.

So, it does appear to be an issue when you have Snapshots of the VDI machine. I ran a clonevdi command from the root VDI image and then ran the modifyhd witht he --resize flag on that new clone and I can instantly see the unallocated space to expand with any tool (gparted, windows native disk management, esasus). Now the question is how do you expand the size when you have a VM with snapshots.....


@mpack
Note the first image was from ESASUS partition master software, but the same results when using any disk management tools.

charless wrote:Now the question is how do you expand the size when you have a VM with snapshots.....

Just a guess, but if you expanded every VDI in the snapshot chain then I expect it should work. You can't just enlarge the oldest VDI, because as you've seen the newest incarnation of the drive will know nothing about the change (the oldest VDI is supposedly frozen - there isn't supposed to be any change!). You can't just enlarge the newest incarnation either, because for unallocated blocks (i.e. all that extra space) it will look in the earlier VDIs for possible fulfillment, and maybe get confused when those areas don't exist. No, I think you have to do it to all VDIs in the chain, identifying each one using its own UUID.

tried that with no luck, gives the following error on all snapshot VDI's.

About the only thing that I know you can do to be able to keep the original intact is to export the guest and enlarge the exported version. You will not have any snapshots in the exported version though as it merges all snapshots into the final product. The only thing that I am having a problem with is just what is going to happen when you export? You have enlarged the base and when they merge what is going to actually happen? I would make a really good backup before messing with it myself.

Perryg wrote:You will not have any snapshots in the exported version though as it merges all snapshots into the final product.

Actually, if merging the snapshot chain into a single VDI is acceptable, I would suggest "VBoxManage clonehd <latest-snapshot-uuid>" rather than export/import. The merged VDI can then be resized, and incorporated into a new VM (snapshots complicate mounting in existing VM). This is all assuming that merging works at all with a snapshot chain damaged in this way!

Perryg wrote:You have enlarged the base and when they merge what is going to actually happen? I would make a really good backup before messing with it myself.

I think it should work ok, but it sounds like an interesting experiment.

I did try the clonehd command, but it did not include any of the snapshot states in the final solution. It did however expand just fine, but doesn't help with all the missing apps and configurations I need. Thanks for the suggestion.

charless wrote:I did try the clonehd command, but it did not include any of the snapshot states in the final solution

Well, I note that you haven't provided any details of what you tried. I assume you know that you need to clone one of the state files named {1234.5678.etc.vdi} if you want to include data up to and including that state, in the clone. Cloning the base VDI file will obviously only give you what was in the base VDI - i.e. nothing except what came before the first snapshot.

I did try that before, but it gave the me the error (as noted in previous post). The exported appliance is an OVF file and did not contain any of the snapshot updates of the VM.

charless wrote:

Code: Select all

vboxmanage modifyhd /home/user/.VirtualBox/Machines/Win7-CFI/Snapshots/\{244a4707-4fb1-4bab-8c0a-9c79ffb7752e\}.vdi --resize 40000

Eh? Why are you showing me the "modifyhd --resize" attempt? We were talking about how you clone the current snapshot state, using clonehd. Resize is done later, on the clone. Also, none of my suggestions involved an exported appliance, that was PerryG. That may be a valid approach, but isn't one I know anything about, so if that's the approach you want to follow then I'll have to bow out.