Ticket #2772 (closed defect: fixed)

Opened 14 years ago

Last modified 12 years ago

Differencing file not deleted after shutdown with immutable disk.

Reported by: wavq Owned by: dmik
Component: virtual disk Version: VirtualBox 2.1.0
Keywords: immutable, differencing, deleted, shutdown Cc:
Guest type: Windows Host type: Linux


I upgraded to 2.1.0 on my 64-bit openSUSE 11.0 machine. XP is virtualized in a 'normal' hard drive.

I unregistered the disk image, and marked it immutable from the CLI. From the GUI, I added the immutable disk to my VM (the GUI confirms it's immutable), and then started up XP.

Upon shutdown, the disk manager shows a differencing file under my immutable image [was expecting it to be deleted], and when I restart XP, I've clearly not reverted back to the base disk image (eg, software/folders that were added post-immutability still present).

Change History

comment:1 Changed 14 years ago by jevidl

Witnessed this behavior on Mac OSX 10.5.6 host as well.

comment:2 Changed 14 years ago by wellwell

Immutable disks support has been definitely broken in v2.1.0. I have it running on Windows XP with various guest OSes and the differencing files stay on the disk upon shutdown of a VM. Clearly immutable disks are no longer immutable as users would have to delete differencing files manually.

comment:3 Changed 14 years ago by bqbauer

I also have observed this problem an XP (32-bit) host and 64-bit OpenSolaris host. Tested with Windows and OpenSolaris guests on both host platforms with the same results--differencing disks are not deleted even though everything seems to be configured properly and immutable disks are properly registered.

comment:4 Changed 14 years ago by frank

This is indeed a regression.

comment:5 Changed 14 years ago by dmik

  • Owner set to dmik
  • Status changed from new to assigned

We changed the whole diff handling logic in 2.1 (in general, diffs are now not deleted automatically), and this is a side effect of that. As a temporary solution, you have to do the following each time to achieve the old behavior:

  1. Power off / kill the VM.
  2. Remember UUID of the attached diff.
  3. Detach this diff.
  4. Unregister and delete this diff (remember that now diffs are not deleted automatically when detached).
  5. Attach the immutable base again (this will create a new clean diff).

A proper solution (most likely a flag with the differencing hard disk that tells it to auto-reset itself on power down) will appear in the next release.

comment:6 Changed 14 years ago by bqbauer

It is completely unacceptable to make such a radical change, not mention it in the documentation or release notes, leave it half-done, and then provide this "solution" only after someone submits a bug report. You broke a feature for everyone, and it was intentional!?

comment:7 Changed 14 years ago by dmik

It is completely unacceptable to have such a radical tone here as you have. Please pour your emotions to some other place next time, they are merely useless here.

comment:8 Changed 14 years ago by david.woodward

I know this is not the place for opinions and feedback, but just to "counter" the negative post I thought I'd give you some positive feedback.

I personally am glad you guys made this change. I just started using Virtualbox and it appears that without this change I would not be able to have several machines built from the same immutable/parent drive image because the changes made to each virtual machine would be lost as soon as I shut them down.

So, for example, I want to make a parent image of Windows 2003 and then create three machines based off of that image for different software configurations I need to test against. Prior to this change that was not possible and I would be forced to either have three full installations of Windows 2003 or use snapshots of the same system with different software configurations.

So, this change essentially saved me 3GB+ of space on my host system. Thanks!

My only request in regards to this change is that future releases add GUI options for flagging a drive image as immutable/normal and unregistering/deleting differncing images. Using the command line for such features is probably going to make it more difficult to get co-workers to use this product instead of other similar products that do offer this functionality though the GUI.

comment:9 Changed 14 years ago by dmik

This was one of the major reasons behind this change. Thank you for the opinion. The relevant GUI changes are also planned.

comment:10 Changed 14 years ago by rickwildfire

FYI the current user manual needs to be updated with this change. Specifically page 73 #2 which still states that the differencing disk is discarded after a shutdown.

comment:11 Changed 14 years ago by jacklikevx

I think this changes are good. Cause sometimes we do need some modification on a immutable disk image, such as downloaded patches on OS.

The only glitch is that the document is wrong, it should be modified to reflect the modification. I just spent time to test this immutable functions and became unhappy because the result is different from the manual and mislead users another mal-function.

Well, I suggest that in the future version, user can decide if a difference image can be applied to immutable base disk directory. That will same lot of time.

comment:12 Changed 14 years ago by nar3

Same problem.

I am working at usings this package in a Classroom environment, the immutable option AS WRITTEN in the Docs would have been perfect, I presently use Virtual PC 2007, which will keep changes from being written.

This solution is not helpful in replacing Virtual PC with Virtual Box.

When will there be a fix so, Immutable will really act Immutable ?

comment:13 Changed 14 years ago by dmik

nar3, please note that Immutable are still Immutable in terms that they are never directly written to by VirtualBox. However I understand your use case and the workaround from comment:5 does not fit it very well.

For the time being, there is another workaround which is much easier:

  1. Create a VM that needs to be "immutable".
  2. Attach necessary hard disks to it. Note that it doesn't not really matter if they are Immutable or Normal (because of the step 3).
  3. BEFORE the first launch of this VM, create a snapshot.
  4. Start the VM, stop/kill it, whatever.
  5. Before each next start, discard the current VM state (rollback to the snapshot you created).

Using VBoxManage, the last two operations will look like this:

# reset hard disk contents and start the VM
VBoxManage VBoxManage snapshot $VM discardcurrent -state
VBoxManage startvm $VM

comment:14 Changed 14 years ago by oldwoman

I too have an issue with this. I'm using virtual box in an educational lab where I have created a script which basically sets up the virtual machine as an immutable disk images (for windows) so the students can't alter the original configuration. Once they shutdown the virtual machine, all the changes are lost and more importantly, the difference image is deleted. As it stands now, I will have to wait until this is resolved. I can not change the script so that it checks to see when the student ends the session. The difference file is located locally on the system, but there are several users using one system so it amounts to a lot of disk space which I can not easily reclaim. Please make sure there is a command line option through VBoxManage to enable the option to delete the difference file when the machine shuts down. Thanks.

comment:15 Changed 14 years ago by frank

See section 5.3 of the VBox 2.2.2 user manual. VBoxManage modifyhd --autoreset should fulfil your needs, correct?

comment:16 Changed 14 years ago by oldwoman

Unfortunately this option, when set, deletes the diff files when the VM STARTS. I need an option to do so when it ENDS. Again, my main problem is disk space which will quickly be consumed and never reclaimed with the existing option. For example, if 10 people use VBOX using diff files, the files are realistically NEVER erased until they startup the VM again. Considering that I have over 50 workstations in my lab, at most there could be one diff file on each machine for every user. This is a lot of disk space as I have over 200 users. I am not willing to write a script which checks to see if a diff file is in use. VBOX dies badly if the diff file is deleted while the VM is in use.

comment:17 in reply to: ↑ description Changed 13 years ago by panzaeron

The VBoxManage modifyhd --autoreset on function does not work for me. If I immutable the vdi-Image the difference-Image will not deleted at the next start and when I set manually --autoreset on with VBoxManage the following error occurs:

>VBoxManage modifyhd --type immutable --autoreset on "example.vdi"
VirtualBox Command Line Management Interface Version 2.2.4
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

ERROR: Hard disk 'example.vdi'is not differencing
Details: code VBOX_E_NOT_SUPPORTED (0x80bb0009), component HardDisk, interface IHardDisk, callee IUnknown
Context: "COMSETTER(AutoReset)(AutoReset)" at line 437 of file VBoxManageDisk.cpp

comment:18 Changed 13 years ago by bflong

This new functionality has bitten me as well. I distributed VM images in packages to our workstations. I have a script the user runs that checks the version of the configured VM, and upgrades it to the disk image. In the process it needs to unregister the VM, and register it. This chokes because when I try to unregister the disk, I get:

ERROR: Hard disk '<NULL>' has 39277568 child hard disks

the 'child' hard disks are the temp working drives for the immutable disk. Because they are left dangling I can't unregister the old VM because I get:

ERROR: Cannot unregister the machine 'VM' because it has 1 hard disks attached

I'm currently trying to find a way around this issue.

comment:19 Changed 12 years ago by frank

  • Status changed from assigned to closed
  • Resolution set to fixed

Removing the child hard disk of an immutable disk should work now, tested with VBox 3.2.8.

comment:20 Changed 12 years ago by frank

Oh, that is, the file can be deleted manually. About auto-deleting the child image, see the user manual.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use