Bug #9126

System reboot when creating VirtualBox jail

Added by FOSS Fan over 6 years ago. Updated about 4 years ago.

Closed: Third party to resolve
Nice to have
John Hixson
Target version:
Seen in:
Reason for Closing:
Reason for Blocked:
Needs QA:
Needs Doc:
Needs Merging:
Needs Automation:
Support Suite Ticket:
Hardware Configuration:
ChangeLog Required:


I've noticed that on a fully updated FreeNAS, system reboots when creating Virtualbox jail.

How to reproduce:
Use fresh FreeNAS, create new volume. On this volume create new dataset "Jails".
Configure Jails to use this dataset.
Create new jail "VBjail1", in advanced options set VirtualBox template.
Accept and wait for FreeNAS to download template.
System reboots as soon as the download reaches 100%.

Tried 5 times.

After reboot systems starts normally. In GUI Jails "No entry has been found", however in dataset, ".warden-template-VirtualBox-4.3.12" and "VBjail1" datasets are created.

FreeNAS is installed on USB drive, so I switched to another computer. There, the jail was created without any problems.

One of differences between these computers is the processor.
Computer where the problem exists:
Intel Core i7-4510U @ 2.00 GHz

Computer without this problem:
Intel Core i7-920 @ 2.67 GHz

Why is this happening?


#1 Updated by Dru Lavigne over 6 years ago

How much RAM on the system? I have not been able to install jails on systems with 8GB RAM or lower.

#2 Updated by FOSS Fan over 6 years ago

Computer where the problem exists: 8 GB RAM
Computer without this problem: 6 GB RAM

#3 Updated by Jordan Hubbard over 6 years ago

BRB: Do you have anything in /data/crash? Can you attach it to this ticket? Thanks.

#4 Updated by FOSS Fan over 6 years ago

I'll check it.

#5 Updated by FOSS Fan over 6 years ago

  • File data added

#6 Updated by FOSS Fan over 6 years ago

Updated FreeNAS to latest version, but the problem still exists.

#7 Updated by John Hixson over 6 years ago

  • Status changed from Unscreened to Screened
  • Target version set to Unspecified

I didn't see this. I think it was because the target version wasn't set.

#8 Updated by Cyber Jock over 6 years ago

Personally, Virtualbox is useless on a system with 8GB of RAM. As I put in the Virtualbox thread on the forums:


  • Lots of RAM. You'll need the 8GB FreeNAS(minimum) plus whatever RAM quantity you plan to provide to virtual machines. For most people 16GB is probably the smallest quantity for a reasonable setup. If you start assigning too much RAM to your VMs and don't leave enough for FreeNAS you stand a very real chance of causing a kernel panic and potentially trashing your pool. So be warned this is not for people that want to be irresponsible.

Honestly, I wouldn't be surprised if your limited RAM isn't to blame for things not working right. I wouldn't even try Virtualbox without at least 16GB of RAM (assuming you don't plan to give more than 4-5GB of RAM to VMs. 8GB is just plain too little RAM for running virtualbox in a jail. Even outside of Virtualbox, we don't recommend 8GB of RAM with jails because jails rob RAM from FreeNAS. So if you want jails, you really need more than 8GB of RAM to operate properly.

Yes, I realize you are probably thinking "but it works with 6GB of RAM on this other system". Well, we know from experience that FreeNAS gets cranky when there isn't enough RAM. The system gets unstable, and the middleware starts having problems, randomly. It doesn't even consistently have problems when you have insufficient RAM. Just because it worked with 6GB of RAM elsewhere doesn't make it a good idea, nor does it mean we should support it. ;)

I think that if you wipe out your current jails dataset and upgrade your RAM you'll find that it will work properly. I have a confirmed case from last night that verified that he was able to install virtualbox with the latest build of FreeNAS 9.3. So I tend to think this is user-error or insufficient resources.

#9 Updated by John Hixson over 6 years ago

  • Status changed from Screened to 15

Well, the panic occurs because of this:

Sleeping thread (tid 100596, pid 6762) owns a non-sleepable lock

pid 6762 is ifconfig. I suspect this is VIMAGE.

Can you try this again and not only attach anything under /data/crash, but also go to system->advanced->"save debug" and attach that as well?

#10 Updated by John Hixson over 6 years ago

Any news on this?

#11 Updated by FOSS Fan over 6 years ago

  • File debug-before.tgz added
  • File debug-after.tgz added

Thanks Cyber Jock for info. Yes, I have heard it before.
It looks like this: I'm looking for software that suits my needs, and one of needs is to run VirtualBox machines. I will buy hardware for FreeNAS later, but only if it will pass my tests. So for me, it won't be a problem to use 16 GB RAM later, it's a problem that it does not work (even slower) with 8 GB RAM now.

Also, it's hard for me to accept reasoning that I should not worry about the problem now, because as soon as I buy new hardware (with 16 GB RAM), all my problems will be gone.

Now, I have once more upgraded the system (it's now FreeNAS-9.3-STABLE-201504152200), the problem persists.

I'm attaching debug files. One during creation of jail, and second after reboot.

#12 Updated by FOSS Fan over 6 years ago

Thank you John on VIMAGE hint. When disabled, the jail is created successfully. If enabled later, the system reboots as soon as the jail is started (not good if enabled with autostart).

#13 Updated by Jordan Hubbard over 6 years ago

VIMage and VBox are clearly incompatible, as are things like VIMage and pf. Answer: Don't use VIMage jails with virtualbox.

#14 Updated by FOSS Fan over 6 years ago

Disabling VIMAGE is a workaround, not a solution. I don't have to disable it on another computer.
I also have to read about difference in operation of VirtualBox virtual machine with and without VIMAGE enabled.

One more thing is that computer where the problem exists has only USB network interface controller, and computer without this problem has integrated NIC.

#15 Updated by Jordan Hubbard over 6 years ago

  • Status changed from 15 to Closed: Third party to resolve

Unless the poster has a kernel patch to suggest which will resolve the incompatibility between vimage and VBox, I suggest we simply close this as 3rd party to resolve (upstream FreeBSD project) and if they someday finish making vimage actually robust then this will simply get fixed somewhere along the way (and at a time of the project's choosing, not ours). We certainly do not have the kernel hackers familiar with vimage that would be necessary for us to fix this ourselves, and the combination has always been a "nice to have" rather than a clear priority since FreeNAS 9.3 is a NAS, not a VM hosting platform. Perhaps that will change in 10 with bhyve (that remains to be proven), but certainly not with virtualbox.

#16 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to N/A

#17 Updated by Dru Lavigne over 3 years ago

  • File deleted (data

#18 Updated by Dru Lavigne over 3 years ago

  • File deleted (debug-before.tgz)

#19 Updated by Dru Lavigne over 3 years ago

  • File deleted (debug-after.tgz)

Also available in: Atom PDF