VirtualBox

Ticket #12130 (closed defect: fixed)

Opened 9 years ago

Last modified 6 years ago

Linked clones aren't cleaned up when "Remove" performed

Reported by: Metaseller Owned by:
Component: other Version: VirtualBox 4.2.10
Keywords: clone Cc:
Guest type: Linux Host type: Linux

Description

A linked clone, removed, then recreated under the same name, has incorrect state.

Steps to repro:

  1. Download DSL (I used 4.4.10 ISO)
  2. Create a new VM, specifying "Linux 2.4" as type, and allocating it a small hard drive (512MB, huge for DSL); set the DSL ISO as its optical drive.
  3. Boot the VM into DSL and, as root:
    # fdisk /dev/hda
    -- create new primary partition (n, accept defaults, w to quit)
    # mkfs /dev/hda1
    # mkdir hdd; mount /dev/hda1 hdd
    # echo Hello, world! >hdd/hello
    
  4. Shut down the VM, boot fresh, prove that the file is actually there:
    # mkdir hdd; mount /dev/hda1 hdd
    # cat hdd/hello
    
  5. Make a linked clone of the VM with the default name. Boot the clone and change the file ("Goodbye, world!"). Shut down.
  6. Boot either VM, see that the file is unchanged in base and changed in clone.
  7. Shut both VMs down and delete the clone, removing all files. Important
  8. Boot the base again; file is (correctly) unchanged. Alter the file ("Hello, changed world!"), shut down.
  9. Make a linked clone using the same default name. Boot the clone. What does the file have?

Expected result: "Hello, changed world!", because the new clone was created from a VM whose state was that.

Actual result: "Hello, world!" - the unchanged version. Not, as I first thought, the version that the clone had had under its previous name; it's reset to that clone's origin.

Doing all the exact same steps but using a new and unique name for the new clone works correctly ("Hello, changed world!"). At no time were two VMs with the same name in existence, but the reuse of the name causes odd results.

Some discussion at  https://forums.virtualbox.org/viewtopic.php?f=7&t=57342 led to this being posted.

Change History

comment:1 Changed 9 years ago by Metaseller

Another/simpler way to reproduce this problem can be seen by doing the following:

  • make a linked clone of an existing VM - use the default name;
  • delete the clone;
  • change the settings of the original VM - something simple/obvious (in my case I changed Network from "NAT" to "Bridged Adapter");
  • make a linked clone of the same original VM again - using the default name again.

Note that the settings in the new clone have not been copied across - it still has the settings of the previous VM.

--Ric.

comment:2 Changed 9 years ago by kirsche40

Possible duplicate: #12456

comment:3 Changed 8 years ago by klaus

Ah, now I understand. This is something between a user error and surprising GUI behavior (to be fair, it's all caused by how the VirtualBox API works). If you'd use the command line it would be rather obvious.

Let me explain what happens in the GUI (and at the API level).

A linked clone can only be taken "as of a snapshot". When creating the first linked clone, the GUI creates a snapshot automatically, and uses it to create the linked clone. Deleting the linked clone works as it should, it frees some disk space (but leaves the created snapshot of the original VM). When creating the second linked clone the GUI takes another snapshot (with the very same name as the first snapshot), and when it sometimes later needs to identify the right snapshot it compares the names, and gets the first one.

This is the cause of the unexpected behavior. The GUI needs to find the right snapshot (possibly by picking a unique name, or by using the snapshot UUID).

BTW, the GUI (or the API) can't automatically delete the snapshot when deleting the linked clone, because it can't know if this snapshot is useful for (intentionally slightly "older") additional linked clones. This is something the user has to decide.

comment:4 Changed 8 years ago by klaus

To keep this up to date: whatever comes after 5.0.0_BETA4 will have this issue fixed. There it was possible to do a clean solution, which unfortunately can't be applied to 4.3. For 4.3 the only solution I can see is making the GUI create unique snapshot names, working around the problem well enough.

comment:5 Changed 6 years ago by klaus

Fixed ages ago.

comment:6 Changed 6 years ago by klaus

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use