Unique Immutable Drive situation...

[serker]

Can't quite get the pattern down, and need some advice.

Running OpenSuse 14.2 x64, VBox is 5.1.14_SUSE r112924

Have a guest Win7, that has been updated and cleaned, with a 17Gb dynamic disk.
Just created a new dynamic VDI named Swap, attached it on SATA3. Loaded Windows, formatted (E:), and redirected the pagefile to this drive (4.02GB, giving me 4060 dedicated swap). I then disabled swap on C:, leaving just E:.

My expectation is this: Windows created the pagefile, but used nearly nothing of it, and won't until next reboot. Virtuabox confirms this, by saying that the is 355MB in size for a 4.02 dynamic.

Next Steps....

Disconnected SWAP.vdi from the VM, Went to Virtual Media Manager, and Modified SWAP.vdi as Immutable. In this interface, SWAP.vdi has a little arrow next to it, showing that there is a sub partition named {fc4248c3-7e8b-4536-bcac-c928022338ba}, which corresponds with a new {fc4248c3-7e8b-4536-bcac-c928022338ba}.vdi file in the snapshots directory of my guestos profile.

Boot Win 7, and everything works as expected. No issues in Win 7, and, rebooting recreates the pagefile.sys each time (as expected, per how I shut down Win7).

Problem is, while VBox interfaces report that SWAP.vdi is 355MB in size, i have the following discrepancies:

SWAP.vdi is 35.5k.
\snapshots\{fc4248c3-7e8b-4536-bcac-c928022338ba}.vdi is 3.1GB.

As far as "immutable" goes, this snapshot is never deleted, I also do not have the ability to make the {fc4248c3-7e8b-4536-bcac-c928022338ba} "immutable", since it is a sub drive of SWAP.vdi.

In my research, it seems that some configurations/versions do not immediately delete, and there have been bugs with this in the past. But there are enough variables in this that could certainly be doing this in the wrong order, and would like someone to critique.

My expectation was that the permanent snapshot file would not "grow". Have I set this up improperly? Or are my expectations completely wrong?

Thank you, and, if I've missed any pertinent information, please ask.

Serker

[socratis]

My expectation was that the permanent snapshot file would not "grow".

Nope, that's not what happens. The snapshot grows as it's used more and more and it is reset on the next power up. The immutable base is the one that never grows/changes.

Read User Manual Ch. 5.4 Special image write modes, paragraph 4 for the full details.

[serker]

Thank you, you have cleared up part of the issue. Part of these answers though, are a little misleading, and I suspect it's the old "host/guest" issue.

Per your statement, I have now discovered that, after rebooting the host machine, \snapshots\{fc4248c3-7e8b-4536-bcac-c928022338ba}.vdi is now 355MB, which is what I was expecting.

From the manual, Section 5.5, statement #2.

Immutable images. When an image is switched to "immutable" mode, a differencing image is created as well. As with snapshots, the parent image then becomes read-only, and the differencing image receives all the write operations. Every time the virtual machine is started, all the immutable images which are attached to it have their respective differencing image thrown away, effectively resetting the virtual machine's virtual disk with every restart.

This implies that, when you either shutdown or restart the guest OS, that the differencing image is "thrown away". In my configuration, this is not the case--shutting down the virtual machine was not the key, in fact, rebooting the Host OS is the key.

To prove this, I've just run the VM AFTER discovering the file is 355MB, for the first time since bootup. Again the file grows to 3.1GB, yet, when I shutdown the guest OS, the file stays at 3.1GB.

I've scanned a "ps aux" for any vbox services running, and there aren't any. But rmmod the vbox modules DOES reduce the file to 355MB.

Therefore, I feel like this is solved, and I appreciate the help in tracking this issue down. Perhaps in other configurations on other hosts, the manual is correct. But in my case, (and I think the ultimate answer is reasonable), the manual does NOT describe when the image is released. YMMV, and, I now know what I have to script (unloading/reloading of modules) to recover dedicated drive space when dealing with swap/pagefile drives.

Thank you so much for the input!

Serker

[socratis]

the manual does NOT describe when the image is released

Oh yes it does. You actually quoted it:

Every time the virtual machine is started, all the immutable images which are attached to it have their respective differencing image thrown away, effectively resetting the virtual machine's virtual disk with every restart.

With every restart of the guest. And we're not talking reboot from within the guest, we're talking a complete shut down of the guest and a fresh startup. You shouldn't need to either reboot your host or remove the vbox modules. If you have to, something is not right.

[serker]

the manual does NOT describe when the image is released

Oh yes it does.

Hmmm...I thought I made that clear, starting the quoted sentence with "But in my case, ..." Evidently, something is wrong, because it takes an unload of vbox modules to revert the snapshot. At the moment that the modules unload, I can watch the snapshot vdi reduce in size from 3.1GB to 355MB, using the watch command with a one second update. Since I can reproduce this, I'm left suspecting that the routine that "clears", for some reason isn't being released by the host VBox, and is tied in some way to something in the module.

Again, this is a workable solution for my needs, and I can patiently wait. Nevertheless, I have exported this VM as a 2.0 ova, and imported into a windows host, to find that the manual is accurate under this OS (this problem does not occur). I've also, out of the same curiosity, imported this ova into a new Tumblweed (Suse) build, and I'm getting the same issue that requires unloading the modules to reset the snapshots.

With my limited experimenting, I'm not comfortable saying that this is a bug in Vbox, There are too many variables here (Linux distro, Kernel, combinations of various libraries, proc, hardware, etc...), and quite frankly some offending code elsewhere could easily be the culprit. I suspect that I need to attempt this on another distribution, or simply wait for a few days as Suse repositories tend to update decently often.

I may attempt the import on a .deb system...Ubuntu probably, simply to see if this is a Linux only or Linux distro issue. Other than this, I can't pursue any testing on any OSX builds, as they're not available to me at this time.

Thank you for the time though, I may have further input after some continued testing...

Serker

[mpack]

I'm not sure what you're watching, but the only differencing image reduction feature (p.s. it isnt a snapshot) in VirtualBox that I can think of has to do with SSD trim emulation... and btw that is a feature of VirtualBox, not of the host, so you certainly wouldn't see that in operation after VirtualBox unloads.

I suspect you were looking at host OS caching, not at a disk space allocation.

VirtualBox never shrinks an immutable drive allocation. Why would it ever do anything so laborious? When the diff is no longer needed, VBox simply deletes it. I.e. on next startup, right before creating a new one.