Running exec in start callback always fails as VM isn't ready

[chiefy]

I am having an issue, and I know the reason why it's happening, but I am unsure if there is a way to solve it.

When I issue a virtualbox.start(vm_name, cb) the callback is getting executed before the VM has fully booted. When I try to execute a command in said VM, it fails as it is not ready for commands. I've "solved" this issue by adding a setTimeout but it feels very hacky. Is there any way to long-poll the VM and query if it's actually ready to accept commands?

Thanks!

[michaelsanford]

Hi @chiefy ,

virtualbox.start() actually spawns vboxmanage on the host and starts the named virtual machine in headless mode.

The vboxmanage tool will return once the virtual machine has successfully started, which is not the same thing as fully booted. So, your callback gets executed at that point (when vboxmanage returns).

How do you define "booted"? On a linux machine, runlevel 3? What about Windows Server? How does vboxmanage know? What about other operating systems, or systems that might not have guest-utils installed.

You can test it yourself with the Virtualbox GUI open, and running the commandline vboxmanage -nologo startvm "Name" (optionally --type headless) and see when you get a command prompt back versus what state the machine is in.

My workaround

Even checking the VMState property (from vboxmanage showvminfo --machinereadable "Name") will only show you "poweroff" / "running" / "paused" states, which is not useful.

The most reliable way I've found to ensure that your virtual machine is actually completely operational before doing something with it is to actually ping a real service on your virtual machine and check the response.

In one of my deployments, I needed to make sure that a node API was running, so I just asked the API if it was alive.

You could probably modify your callback to start a setInterval that checks for such a response every couple of seconds, and when it receives it, kill the interval and do whatever the callback was supposed to do in the first place.

[chiefy]

@michaelsanford dude - thanks for such a great explanation. I was going to look at what Vagrant does, but that totally makes sense. Thank so much for the reply!

[michaelsanford]

My pleasure, @chiefy ! Your question is surely to be asked by others, so I felt it ought to be thoroughly addressed. Your question even prompted me to start writing a little article on node + vm management patterns.

I've been working extensively with node and virtualbox recently, so found a lot of interesting pitfalls and workarounds. I hope to test and merge a big update soon — 2bf68fc.