Linked clones, removal, and name duplication

[Rosuav / Metaseller]

I'm sure there's something going on here that I haven't understood...

I use VirtualBox to test potentially-destructive upgrade scripts and so on. We're running Debian Linux (Wheezy) as both host and guest, VirtualBox 4.2.10 r84104. I have a standard image that is installed and has our various tools set up, and then I create a linked clone, set it up the way I want, shut down, and proceed to create linked clones to test the upgrade. At the end of the test, I shut down the guest and remove that linked clone. So the "family tree" looks something like this:

Bare Debian Squeeze --> Debian Squeeze Configured --> Debian Wheezy --> PG Upgrade Test --> {many clones}

Most of the clones, since I wasn't keeping them around, were simply called "PG Upgrade Test Clone" - the default name when creating a new clone - and I never had two clones with the same name at the same time.

After doing a few of these, I went back to the base PG Upgrade Test to make a change. There were no clones at the time, but the description still said it was the linked base for etc. I then shut down and created a new clone off PG Upgrade Test, using the default name, and the change had not been applied in the clone. I create a new clone with a unique name, however, and the change is applied.

What happens when a linked clone is removed (Ctrl-R, "delete all files" mode)? Is something retained? If so, for how long? I haven't terminated the VirtualBox GUI app, nor restarted any of the services (/etc/init.d/vboxdrv etc), so it's possible something isn't immediately deleted - but what?

Extremely puzzled. Hoping for any sort of insight here!

[mpack]

The instant you create a linked clone the base disks etc are of necessity frozen, and the owning VM will after that also act as if it's a linked clone: I presume this is what you are saying. AFAIK this is not directly reversible, though you can of course create a full clone of a linked clone and so separate them.

[Rosuav / Metaseller]

It does show that it's a linked clone (actually, you answered another vague question I had, which is "how can I un-mark the base as a linked base", but that's insignificant), but my point is that re-cloning depends on having a new name. It's as if Remove: Delete All Files doesn't delete all files at all, but keeps the disk around, keyed on the VM's name. Creating a new clone with the same name as the removed one recovers its old state; creating a new clone with a new name picks up the base's current state. That's what seems odd to me.

[mpack]

Sorry, it would never cross my mind to delberately create a conflict, i.e. give the clone a name which I know matches an existing VM or VM folder in the target directory. IMHO it doesn't really matter what happens when you do that, you'd be relying on buggy behaviour, not something you can rely on.

In other words: I would advise always choosing a non-conflicting name for the clone.

[Rosuav / Metaseller]

Yeah, but it's not an existing VM - I deleted it before cloning, yet somehow it sticks around.

[mpack]

When you remove a VM from the GUI you are asked if you want to want to delete the physical files too. If you answer no to the latter then the folders and files will stick around.

[Rosuav / Metaseller]

As I said in the first post, I say to delete all the physical files every time.

[mpack]

Then it's a mystery: no-one else has reported such a problem.

[Rosuav / Metaseller]

Then it's a mystery: no-one else has reported such a problem.

Okay! So either I'm going mad, or something weird's happening. (Or both. Won't discount that possibility.) Should I try to make a little test-case to upload somewhere? Since it involves a VM, the files would be fairly large.

[mpack]

If you can test and document a repeatable example of where removing a VM and answering "Yes" to the physical delete question leaves the VMs files or folders behind then yes, you should certainly raise a bugtracker ticket about that. Repeatable of course means that the devs can repeat it, not that you can.

On what VirtualBox should do when a name conflict exists, I've seen people rely on different aspects of this behaviour, so it's debateable what it should do. I doubt your or my opinion on the matter would be enough to tip any balance.

[Rosuav / Metaseller]

Okay, I have steps to repro now. Ticket posted: https://www.virtualbox.org/ticket/12130

[mpack]

Thanks for posting the ticket. However, now I have a problem with what it says:

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

Uh... not it wasn't. If you cloned the base then the clone should be the same as the base, which is "Hello, World". The old clone is gone (deleted), it doesn't matter what it had. If you documented that the file contained "Hello, changed world!" then you would have found a bug.

[Rosuav / Metaseller]

I changed the base before cloning, so it should have been the same as the base at time of cloning. The biggest clue is that the *name* of the clone has some significance. Try the exact steps I listed, and you'll see - unique name does one thing, reused name does quite another.

[mpack]

It isn't me that needs to be convinced, so I'll leave it to the devs to reproduce your finding.

[Rosuav / Metaseller]

I've added another/simpler example that's easier to reproduce.
https://www.virtualbox.org/ticket/12130#comment:1
Regards,
Ric.