virtualbox.org

Installation of VBox version 4.2.0 went without issues. I decided to re-create Existing VMs so that the .vbox files have all the new attributes and properties of the newest version. I moved the .vbox files to another folder and tried recreating the VMs using the previous names and the existing .vdi files. I received the error that VBox was not able to create the specific folders and to check if they exist or if access rights are granted. I renamed the VM folders and tried again and was successful (between creating the VM and attaching the .vdi to it, I moved the .vdi to the newly created VM folder.) Version 4.2.0 can create new VM folders but cannot access existing VM folders when creating a VM of the same name.

EDIT - I removed the VMs from VBox before I updated to version 4.2.0

Are you sure you removed the original VMs before upgrading? I ask because your symptoms seem to correspond to a known bug - and I have not tested recently whether it still exists - in which VirtualBox retains a memory of deleted files and folders for some time. You have to shut it down and wait a good while (i.e. until the background VBoxSVC process unloads itself) then run VBox again. This problem surely could not apply if VBox was upgraded during the shutdown period.

Yes, I removed the VMs via the GUI before upgrading but I forgot to remove the .vbox files from the folders until I recieved the error message after the upgrade. I removed them, tried again, received the error message again, shut down VBox but I didn't really wait that long, maybe a minute or two. Maybe it is the known bug. On the otherhand, it isn't anything that will stop an experienced user from getting to where he needs/wants to go.

Thanks for replying.

P.S. The previous version (4.1.22) didn't show this behaviour, but then, I had removed the .vbox files before starting the upgraded version.

So if I understand correctly what you were doing: you removed the VMs from the GUI but did not physically delete, nor did you move any of the existing folders. You then created new VMs with the same names as the old VMs, with the intention that the existing VM folders would be reused? You intended to remove the .vbox files from the VM folders in the interrim period but forgot.

It's something I have never tried.

mpack wrote:So if I understand correctly what you were doing: you removed the VMs from the GUI but did not physically delete, nor did you move any of the existing folders. You then created new VMs with the same names as the old VMs, with the intention that the existing VM folders would be reused? You intended to remove the .vbox files from the VM folders in the interrim period but forgot.

Exactly!
I don't do it with every new release. I did it with version 4.1.22 because I hadn't updated in months and then again with release 4.2 because it is a new minor version.

Etepetete wrote:I don't do it with every new release. I did it with version 4.1.22 because I hadn't updated in months...

Is there any technical reason for doing such a series of manual steps instead of simply upgrading (=installing the new release over the old one) and letting the VBox setup program deal with the needed (if/when needed) changes?

In other words: what adverse side effects could arise by just upgrading with the setup program?

There are no adverse effects, in fact, that is how you have to update VBox. The setup program updates the VBox software. I re-create the VMs every now and then so that the .vbox files (the VMs), which are XML files, have the latest attributes and properties contained in them. My experience from the past is, if you have an older VM, the .vbox file will not be changed (updated) but will be kept as is. For example, in the newest version of a .vbox file there are properties such as <VideoRecording /> and <DragAndDrop />, which are not inserted into an existing older version of a .vbox file automatically. The VMs will still work, because for example, if the .vbox file doesn't have the property <DragAndDrop /> in it, it will show in the GUI as deactivated.
I just prefer having my .vbox files up-to-date. Note: which properties and attributes are contained in your .vbox files, depends on when, i.e. how long ago (with which version) you created the VM.
Tip: With Notepad++ you can read the .vbox files and if you configure it to recognize .vbox files as XML then it makes reading them a lot easier (due to the tag highlighting).

Thanks for the explanation.
I know both Notepad++ and XML, so I think I understood well your point. I also tend to be rigorous and like light and neat configurations.

However I still don't see any reason for going through such a sequence of manual steps, especially when the number of VMs is not little.
Besides, as you said, new xml elements can always be added to the .vbox files by browsing the VM's settings in the GUI and selecting/activating new features.

Armando wrote:However I still don't see any reason for going through such a sequence of manual steps, especially when the number of VMs is not little.

I don't have enough space on the HDD of my host to just copy .vdi files and create new VMs.

Armando wrote:Besides, as you said, new xml elements can always be added to the .vbox files by browsing the VM's settings in the GUI and selecting/activating new features.

No I didn't. I said some missing attributes and properties in the .vbox file are displayed in the GUI as being deactivated. Depending on how long ago the VM was created, there can be significant differences in the content of the .vbox file as compared to the present, updated version. Some changes are "under the hood" and are not reflected in the GUI. If you search the forum, you will find plenty examples. Here is an example of an extreme situation, i.e. the VM didn't launch.