[Fixed] Virtualbox Hangs at 0% Starting Virtual Machine

[noteirak]

I've encountered the same problem. The installed virtual machine works fine

The OP issue is that the virtual machine doesn't even start, so I fail to see how that qualifies as "the same problem".
Please start your own topic and provide the Minimum information needed for assistance.

[HarryMan]

I am experiencing the same symptoms running vbox 5.1.8 on Centos 6.8. Albeit, perhaps the cause is different, but please don't flame me for not opening yet another thread on this topic. I feel this is appropriate, as this thread is not marked "SOLVED."

Today, I tried upgrading from vbox 5.0 to 5.1. I had tried this earlier this year, but had problems due to some library incompatibility. I don't remember now what that was, but it does not appear to be an issue any longer. Either the newer library I needed has been added to CentOS 6.8, or maybe VBox no longer requires it, etc. Again, that particular issue is gone.

But I am still having trouble launching VMs from the GUI. I can do it successfully from the command line. So I set off to try to figure out why this is so. I can launch the VM successfully by calling "vboxmanage startvm MyVM."

I noticed that the GUI launches the VM by calling "/usr/lib/virtualbox/VirtualBox --comment MyVM --startvm 3f41d939-fa5b-21e2-a030-bfbe5f976b6d --no-startvm-errormsgbox" (I have obscured the actual VM name and VM UUID here, if you don't mind; I'm paranoid). So I tried this same exact string from the command line by copy-and-paste from ps(1). It fails to start, giving me the same pop-up box error message as before.

I called VirtualBox without the "--no-startvm-errormsgbox" option and -- voila! -- the VM launched without a hitch. Now, I realize this may not be quite kosher, and I think I will revert to 5.0 until I can get some assistance, or at least an OK as a work-around. I'd prefer to use the GUI, but this would work for now, so long as it will not cause damage. My concern is, of course, that there could be some serious errors that don't show that I might want/need to know about.

I am hoping that I can disable the option centrally until the problem can be addressed in an release update.

[HarryMan]

I have another clue now. After installing the extensions, I can launch any VM from the GUI. I am guessing that the GUI wanted to warn me that I did not have the extensions installed, even though no error showed when I launched the same VM from the command line.

I looked at the source code, btw. I am wondering if I am looking at the same source as 5.1.8 because all that option does (--no-startvm-errormsgbox) does is set an internal variable (mShowStartVMErrors), but the accessor never seems to get called. I'd think that the intention of calling VirtualBox with the option enabled would be to quiet the errors altogether. I think an error that could cause a never-ending hang is something worth having the GUI report, regardless of the option enabled or not. Or at least crash gracefully somehow.

[HarryMan]

Well, this next part seals the deal.

I went to create a fixed-size disk and got the following error:

Code: Select all

Failed to create the hard disk storage /virtual/Active_Machines/Obarun/obarun2.vdi.

Could not create the medium storage unit '/virtual/Active_Machines/Obarun/obarun2.vdi'.

VDI: setting image size failed for '/virtual/Active_Machines/Obarun/obarun2.vdi' (VERR_INVALID_PARAMETER).

Result Code: VBOX_E_FILE_ERROR (0x80BB0004)
Component: MediumWrap
Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}

This fails at the command line as well; dynamic-sized disks can be created fine, though. I've only seen one other report of this anywhere as of 6 days ago. This might be related to this newest update (5.1.8 ).

For now, I am going back to 5.0.28 because it still works while these 5.1.x matters get straightened out. BTW, for the record, as soon as I got back on 5.0.28, I created the same fixed-size disk and it works.

[robertwork]

I have the same problem, but occurs randomly.

I tried various things, but, oddly, copying the .vdi file to some random location (not touching the original .vdi file) seems to get it to work.

It's as if VirtualBox refuses to read .vdi file until someone else has read the whole thing.

Next, I'm going to try "dd of=/dev/null if=foo.vdi" to see if that's all it needs to kick-start it in 5.1.8 .

(BTW, this never happened with my 2G split .vmdk version, only the .vdi version.)

[Squall2131]

To anyone viewing this coming from a search engine, the original problem I had was solved by user Frank, and was reported and solved in this ticket: https://www.virtualbox.org/ticket/13820

[socratis]

Great, thanks for the feedback. Even after 3 years!!!
Marking as [Fixed].