System reboot when creating VirtualBox jail
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?
#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: https://forums.freenas.org/index.php?threads/virtualbox-in-a-jail-in-freenas.20185/
- 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?
#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.
#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.