Trying to start it eats up ram and virtual memory and does not start.

[ArturPires]

I very much doubt that any such problem exists. The report is not new, it has been reported many times over the years, and it always boils down to a misunderstanding of how caches work.

If that's the case, could you give us an idea of what should be done?

Thanks in advance.

[mpack]

Do nothing. The RAM is managed by the host OS and will be freed up if something needs it.

[ArturPires]

Doing nothing was my first option (obviously), but after 30 minutes I gave up and hit the reset button.

Just curious, how much memory/cache/whatever does the VirtualBox Manager needs? We're not talking about opening a VM, the problem happens when opening the VirtualBox Manager.

[mpack]

how much memory/cache/whatever does the VirtualBox Manager needs?

You misunderstand. VirtualBox itself doesn't need any more RAM than you configured in the VM settings - which ideally is substantially less than the available host RAM. It's the host OS that caches file accesses, and given the large file sizes VirtualBox uses, that can look like a lot of RAM being allocated to the VirtualBox process, if the RAM stats are viewed naively.

And until somebody posts a VM log file which the first reply asked for then this is all pointless speculation.

[ArturPires]

how much memory/cache/whatever does the VirtualBox Manager needs?

And until somebody posts a VM log file which the first reply asked for then this is all pointless speculation.

The third post on the thread (I cannot post links yet) tells you it cannot be done, as it's not possible to open any VM, the error happens before we could do that.

[mpack]

Well, that was not your post, and it leaves us at an impasse: without data we can do nothing but speculate.

[ArturPires]

That's my problem and why I have been looking for an answer, as, from what I have seen, VirtualBox Manager doesn't create any log where we could look for a clue of what is happening.

I suppose I'll just keep on using an older version and wait for a new version without this problem, if it ever appears.

[ArturPires]

Problem partially solved (at least for me).

I did what I should have done yesterday and started thinking what the VirtualBox Manager was trying to do at the start, so I renamed my old VMs folder and the folder where the VirtualBox.xml is, so instead of an upgrade it would work as a new installation.

I installed the new version and it worked!

Then I started adding my VMs one by one and there were two (both Vista guests) that, when I tried to add them, made the VBoxSVC.exe file starting hogging all memory. I killed the process and kept on adding VMs until I had them all back except the two Vista guests that create the problem when the Manager tries to load them.

I hope that helps.

Edited to add that both Vista VMs that create the problem have snapshots.

[mpack]

Well, now it sounds like disk problems of some sort - but I can't think of any reason why this should be version dependent. I don't remember the changelog containing anything related.

Is there anything different about the two Vista VMs? E.g. are they both on some other drive, or do they both reference a shared folder in an unusual location?

[ArturPires]

No, the two Vista VMs are on the same folder as the others, the only difference I find is that they both had active snapshots.

[mpack]

"Active"? Not sure what that means. Snapshots can be present or absent. They could only be called active while the VM is running. Snapshots shouldn't have an effect unless they are somehow stored in an unusual location. Also the fact that two VMs are affected adds to the puzzle: unless one is a clone of the other and the corruption already existed at the time the clone was made (and the clone would have had to preserve the snapshot structure).

[ArturPires]

Sorry for using the word "active", I used it because there was another VM that had a snapshots folder but it was empty.

The two Vista VMs are different, one is 32 bit the other 64.

Meanwhile, I uninstalled version 6.1.36-152435, installed 6.1.32-149290 again, deleted the snapshots, uninstalled version 6.1.32-149290 and reinstalled version 6.1.36-152435.
Then I tried to add the two Vista VMs, now without the snapshots, and it worked, so it looks like there was something with the snapshots that the new version didn't like.

PS: deleting the snapshots took aroud 5 seconds.

[fth0]

Thanks for the investigation so far, interesting topic.

Many of my VMs also have snapshots, but I'm not experiencing the problem described in this thread. There must be more than just having snapshots. Speaking of which:

A snapshot is a preserved state of a VM and includes at least the VM settings and the virtual disk image. As a wild guess, there is one item in the VirtualBox 6.1.36 Changelog that could interact with snapshots, namely the revised handling of the Recording settings.

Did you ever use or modify the VM settings under Screen > Recording in your Vista VMs?

How many snapshots did the Vista VMs have?

Can you provide a zip file containing the VirtualBox.xml, VBoxSVC.log*, selectorwindow.log* files, and a <Vista-VM>.vbox file from earlier?

[mpack]

Many of my VMs also have snapshots, but I'm not experiencing the problem described in this thread.

Yep, I smell a crucial fact still missing from this discussion, for example that all VMs are running from a slow drive, perhaps with Hyper-v also in the mix, and the additional overhead of loading from a bunch of snapshot files is making the lag especially noticeable.

[ArturPires]

Did you ever use or modify the VM settings under Screen > Recording in your Vista VMs?

No, I don't even know how to do that.

How many snapshots did the Vista VMs have?

One each.

Can you provide a zip file containing the VirtualBox.xml, VBoxSVC.log*, selectorwindow.log* files, and a <Vista-VM>.vbox file from earlier?

I think the files in the zip are the ones for the time when I waited several minutes until I had to turn off the power on my computer.