[Solved] Can no longer reboot VMs

[hspindel]

After the latest update to VirtualBox, I can no longer reboot a VM (doesn't matter what the guest OS is).

I always get a screen with the following lines:

ata1 master: VBOX CD-ROM ATAPI-6 CD-ROM/DVD-ROM
ata2 master: Unknown device
ata2 slave: Unknown device
ata3 master: Unknown device
ata3 slave: Unknown device

The guest OS should have booted off of ata2 master AFAIK.

Reboots always used to work. I can start existing snapshots just fine.

(By reboot, I mean issue within the guest: start/shutdown/restart for Windows or sync;sync;sync;reboot for Linux.)

Suggestions?

Thanks!

[mpack]

Pick one VM and give full details, including one log file showing a complete problem session. See Minimum information needed for assistance.

[hspindel]

I have to apologize - I thought that all VMs were failing to reboot, but I've just discovered that in fact the Windows XP VM does reboot successfully. Unfortunately, that's the VM I provided info about above.

Both Vista and Win 7 (32 or 64 bit) VMs fail to reboot as described in the first message.

Here instead is the information about the Vista VM:

VirtualBox version 4.3.8.r92456

Host: Windows 7 10GB (64 bit)
Guest: Windows Vista base memory 512MB (32 bit)

The log file from the Vista VM is attached. The log shows the attempt to reboot Vista at about the 5 minute mark. At the 11 minute mark I powered off the machine instead since it failed to reboot.

Again, I apologize for providing wrong information the first time. I would be happy to provide configuration and logs for the Windows 7 VMs as well if that would be helpful.

One last piece of info: I also tried the following VMs to see if they would reboot: OpenSUSE 32bit (failed), Ubuntu 32bit (failed), Fedora 19 64bit (failed), and Debian 32bit (failed). All failures were the same - Unknown device on ata2 master.

Rebooting all these VMs used to work. I think they started failing when I installed the latest VirtualBox.

[mpack]

Ok, I deleted the message with the XP information, since you said it was not relevant and therefore it was just wasting server space. Speaking of wasting server space, please in future compress log files (e.g. send to .zip) before attaching them.

I find it hard to believe that a Vista guest, even a 32bit one, will be happy with 512MB. I would up this to 2GB.

Also: eject the Vista.ISO file from the CD drive.

[hspindel]

Thank you very much for your help.

In all cases, increasing the base memory allocated to the VM cleared up the issues. I should note that the previous base memory allocated was the default advocated by VMBox when I created the VMs. Perhaps the defaults should be changed?

[mpack]

I'm not on the VBox devteam, so you would need to take up any suggestions you have with them. E.g. raise a BugTracker ticket and/or offer a code patch.

[rseiler]

In all cases, increasing the base memory allocated to the VM cleared up the issues. I should note that the previous base memory allocated was the default advocated by VMBox when I created the VMs. Perhaps the defaults should be changed?

That's interesting, but I think there's more to it.

I mentioned this issue three weeks ago in the "Discuss the 4.3.8 Release" thread, when I saw the issue appear then with a Win 8.1 VM (not Win7 or XP). Like you, I reverted to 4.3.6.

The problem is still around in 4.3.10.

The reason I think there's more to this: the VM already is allocated for 2GB. It certainly doesn't need more.

Update: After updating to the 93012 build, I can no longer reproduce the problem through a number of different sorts of reboots, so it appears that the issue fixed in that build (see below) was the problem here, even though it sounds somewhat different and (I thought) pertained to Linux hosts. Still, it did pertain to hangs.
https://www.virtualbox.org/ticket/12868

[mpack]

Lots of things might make a VM hang, hanging doesn't make it the same problem.

[rseiler]

That we both saw it begin with 4.3.8 probably does though, right? I had the identical screen that he showed. Like with him, 4.3.6 and earlier showed no problem. Anyway, all's well that ends well with the latest fix.

[mpack]

That we both saw it begin with 4.3.8 probably does though, right?

No. Having the same symptoms and the same fix would make it sound like the same issue. If you had the same issue as the OP then the fix would be the same.

[hspindel]

It was suggested to me by private email that I revisit this issue under VBox 4.3.10.

I did not do an exhaustive test of all the VMs. But I did try cutting the Vista VM back to 512MB and rebooting it. I also tried this with the Debian 32 bit VM. Reboots worked for both. So there is some possibility that this is a bug that was fixed in the latest release.

I do think that the advice to increase the memory available to VMs to 2GB is good, and I plan to leave it there. Anybody know if the 2GB allocated is required to be physically present memory in the host or can it be paged out (i.e., could I run six 2GB VMs on a host with 10GB of physical memory)?

[mpack]

Anybody know if the 2GB allocated is required to be physically present memory in the host or can it be paged out?

VM memory for RAM and VRAM must be real, not paged. And it must actually be available when you launch the VM - it's no good if it's all already in use.

However I doubt you need concern yourself. The log showed that your host had almost 8GB available when the VM was launched. I had that in mind when I suggested that you could easily afford 2GB for the VM.

(i.e., could I run six 2GB VMs on a host with 10GB of physical memory)?

No, but you could run 2, maybe 3. And just to emphasise that it's available memory that matters, not total installed memory. When you are measuring the useful capacity of a container you can't ignore things it already contains.

And all this is ignoring CPU, disk bandwith etc. If you stretch any resource then performance will suffer for all, including the host. Better to stay well within reasonable limits.

[hspindel]

Okay, thanks very much for the RAM tutorial.