VirtualBox on Mac Host VMDK file issue

[Obeone]

Hello everyone, new to this forum so treat me gently. I found that Parallels PD6 in Mountain Lion is no longer supported so made the decision that I wasn’t prepared to pay out for yet another upgrade. Following that decision I thought I would try VirtualBox and was pleasantly pleased with the results – it works really well on the Mac with Windows 7 as the VM.

The only downside has been an inability to shrink/compress the virtual HD. To import Parallels PVM file into VirtualBox I used the VMware converter tool (not sure if that was the right thing to do or not?). This then left me with the VirtualBox VM as a VMDK file rather than the default VDI file. In the Windows environment I read that one can use CloneVDI to shrink a VDI HD but there doesn’t appear to be a similar tool for the Mac Host. I have also not been able to come across an easy method for shrinking a VMDK file on a Mac Host. This being the case the VM file is bound to grow and grow with time. Has anyone else been able to overcome this issue? In all other respects VB meets all my needs but I'm going to end up with a very large VM if I can't reclaim the empty space.

[Perryg]

Convert it back to a VDI file and either use the VBoxManage commands or CloneVDI Tool which should work in wine.

See http://www.virtualbox.org/manual/ch08.h ... e-clonevdi to convert the safe way.

[Obeone]

I didn't think Wine worked on Mountain Lion?

[Obeone]

Right people – thanks for the heads up regarding wine. I downloaded WinOnX from the Mac app store for just a few pounds, installed it then installed CloneVDI. From there everything went like clockwork. I now have a working VDI clone of my original VMDK HD.

I do have a further couple of queries though – 1. I now have a cloned VDI HD in the same VirtualBox folder as the original VMDK VM. Would it be safe or possible to now delete the VMDK HD files (lots of HD files broken into chunks, 2 gig max) or would this corrupt the VM? Obviously with cloning the VM the file size is now twice as large as the one I started with.

2. Although the original file was compressed in the cloning process this will expand again as I use the VM. I still cannot see anyway of keeping the file size down other than to keep re-cloning the HD and tick the check box in CloneVDI to compress the file whilst cloning. Is there a less time intensive method of keeping the file size reduced?

[Obeone]

I'm somewhat bemused that no one on the virtualbox forum appears not to have an answer to what is after all a virtualbox question? Oh well, not to worry.

[Perryg]

It would have been better to bump the topic instead of placing a sarcastic reply to your question. Most of the people here are in the middle of a major release and have a lot on their plate and on occasion do miss posts.
Answer 1 = yes. Answer 2 is actually answered in your user manual. Use compact as long as you leave it as VDI.

For your convenience here is the link to the online version VirtualBox online users manual

[Obeone]

It would have been better to bump the topic instead of placing a sarcastic reply to your question. Most of the people here are in the middle of a major release and have a lot on their plate and on occasion do miss posts.
Answer 1 = yes. Answer 2 is actually answered in your user manual. Use compact as long as you leave it as VDI.

For your convenience here is the link to the online version VirtualBox online users manual

Puzzled by your use of the word "sarcastic" I was simply bemused that no one appeared to have an answer. Not sure if you are UK based but I wouldn't call what I wrote sarcastic so could be a cultural thing. Thanks for the response anyway.

[Obeone]

To be perfectly honest I'm none the wiser having looked at the manual. It might have been better if you had identified the item I need to read as much of it appears to refer to Linux. My situation is a Mac Host with a Windows Guest. If I'm too use Terminal on the Mac to compact the VDI then I need a Mac command, and given this is something I'm not too familiar with then simple to follow instructions would be appreciated. Not everyone has the same level of knowledge.

[Perryg]

At the level of VirtualBox the commands are the same, be it Linux, Mac, Windows, Solaris, Etc.

Code: Select all

VBoxManage modifyhd <uuid>|<filename>
                    [--type normal|writethrough|immutable|shareable|
                    readonly|multiattach]
                    [--autoreset on|off]
                    [--compact]
                    [--resize <megabytes>|--resizebyte <bytes>]

So the command would be VBoxManage modifyhd <filename.vdi> --compact
Note: if you are not in the folder that actually has the file (including the extension .vdi) you must provide the absolute path.

[mpack]

Hmm. I would say that since you already have Wine and CloneVDI installed, it would be better to simply keep using CloneVDI once a month or so to compact the disk - or just let the disk grow until the size is objectionable. Read the CloneVDI release notes, you might learn a few things. E.g. the most convenient way to compact the drive in CloneVDI is to make the source and dest filenames (and paths) fields the same, and enable the "Keep UUID" option. That way you don't have to juggle disk image files afterwards. Sounds unsafe, read the release notes to see why it's perfectly safe. Caveats: VirtualBox must not be running at the time, and the VM must not use snapshots.

[Obeone]

At the level of VirtualBox the commands are the same, be it Linux, Mac, Windows, Solaris, Etc.

Code: Select all

VBoxManage modifyhd <uuid>|<filename>
                    [--type normal|writethrough|immutable|shareable|
                    readonly|multiattach]
                    [--autoreset on|off]
                    [--compact]
                    [--resize <megabytes>|--resizebyte <bytes>]

So the command would be VBoxManage modifyhd <filename.vdi> --compact
Note: if you are not in the folder that actually has the file (including the extension .vdi) you must provide the absolute path.

Thanks, this seems to have worked and thanks to mpack for the second option - always better to have a back up plan.

[mpack]

Err.. I would not have intervened in the discussion if CloneVDI was just a backup plan - in fact it's the only plan so far suggested which actually results in a compacted disk (modifyhd --compact would require an "sdelete" preprocessing pass before the compact stage did anything, and even when it works the total time is far longer than CloneVDI).

[Perryg]

Adding my comment as well. CloneVDI is what I use as well, but the question was how to do this with VirtualBox thus the answer using VirtualBox. While CloneVDI may seem like a longer approach, look at what you actually get. A compacted guest with one step and a backup to boot. In that regards it serves a better purpose. IMHO.

[Obeone]

Err.. I would not have intervened in the discussion if CloneVDI was just a backup plan - in fact it's the only plan so far suggested which actually results in a compacted disk (modifyhd --compact would require an "sdelete" preprocessing pass before the compact stage did anything, and even when it works the total time is far longer than CloneVDI).

Apologies, bad choice of words. What I meant was it is always good to have two options. However, if I understand you correctly you are advocating that the best and only option to keep the file size down is to do a monthly cloning operation, or do one whenever the file size grows to an unacceptable level? I find the biggest culprit for the file size growing is restore points/shadow copies. It is tempting to switch this option off but then sods law would dictate that the minute you do some disaster will strike.

[mpack]

I find the biggest culprit for the file size growing is restore points/shadow copies.

Obviously that is beyond the scope of these forums. If it was me (and I'm not familiar with OS X), I would not apply such generic host procedures to VMs - the file sizes, frequency of changes etc make it all too cumbersome. Instead I would make simple copy/backups to secondary media, as and when or on a regular schedule, depending on the importance of the data.