The future of FreeNAS 9

[Bostjan]

Thats not entirely true. A CPU core does not get pinned to VM unless you really want it to. You can have as many VMs as you want. It will use more CPU for sure, because it has a whole new OS to handle but does not mean it can't be shared.
Now speaking of memory, yes it will use a lot more memory too.

Why jails are not in Corral? Good question. I guess people do not felt it was needed and you could run them within a VM. That might _change_ in the future.

For home users, non really technical, with not so beefy hardware, jails (installing and managing them from GUI) are more suitable than VM – looking mainly from hardware stand point – jails needs less resources to run.

 

[William Grzybowski]

For home users, non really technical, with not so beefy hardware, jails (installing and managing them from GUI) are more suitable than VM – looking mainly from hardware stand point – jails needs less resources to run.

Completely agree and I think jails should still be a first class "citizen".

Thats why we are trying to make it better in the 9.x series.

 

[jkh]

Please tell me this thinking is wrong and that you can run more than 4 VM in 4 core system.

Your thinking is wrong. :)

All that a "core" in bhyve means is that you're running a kernel thread to simulate a core. If you have 4 "cores" you're running 4 threads. The kernel can obviously accommodate far more threads than it has physical cores, which is basically the scheduler's whole job. It's not a "hard mapping" in other words, it's more of a soft limit, the same as for "memory size". Remember, these are virtual machines, folks! You're basically just setting resource limits, and if you have 8 more or less idle VMs with "4 cores each" on a 4 core machine, fine. It's more about the aggregate CPU load on the host than anything else. Memory is also allocated on-demand, so if the VM doesn't touch all of its virtual pages, it's not going to fault in and allocate the entire "memory size" you allocated to it, either.

 

[William Grzybowski]

Your thinking is wrong. :)

All that a "core" in bhyve means is that you're running a kernel thread to simulate a core. If you have 4 "cores" you're running 4 threads. The kernel can obviously accommodate far more threads than it has physical cores, which is basically the scheduler's whole job. It's not a "hard mapping" in other words, it's more of a soft limit, the same as for "memory size". Remember, these are virtual machines, folks! You're basically just setting resource limits, and if you have 8 more or less idle VMs with "4 cores each" on a 4 core machine, fine. It's more about the aggregate CPU load on the host than anything else. Memory is also allocated on-demand, so if the VM doesn't touch all of its virtual pages, it's not going to fault in and allocate the entire "memory size" you allocated to it, either.

No, but you can't say it doesn't use _more_ memory. The kernel and the userland processes within the guest OS take some considerable amount of "space".

 

[jkh]

No, but you can't say it doesn't use _more_ memory. The kernel and the userland processes within the guest OS take some considerable amount of "space".

I was responding to a question asking whether it was possible to run more than 4 VMs in a 4 core system, which of course it is. I wasn't comparing jails overhead to VM overhead at all, if that's what you're suggesting? Obviously "containerization" in the form of FreeBSD jails or Linux LXDs is always going to be lower overhead, and if FreeBSD had 100% Linux64 ABI compatibility and an LXD compatible container implementation, we wouldn't have to run Docker containers inside VMs at all! Oh well, one can always dream.

 

[William Grzybowski]

I was responding to a question asking whether it was possible to run more than 4 VMs in a 4 core system, which of course it is. I wasn't comparing jails overhead to VM overhead at all, if that's what you're suggesting? Obviously "containerization" in the form of FreeBSD jails or Linux LXDs is always going to be lower overhead, and if FreeBSD had 100% Linux64 ABI compatibility and an LXD compatible container implementation, we wouldn't have to run Docker containers inside VMs at all! Oh well, one can always dream.

I am not suggesting anything. I am simply stating the footprint is a lot lower.

 

[picklefish]

With the introduction of VM support with Bhyve to 9.10.3 would I be able to have a Bhyve VM open while my old VMWare is open, and then once my Bhyve VM is setup properly upgrade to Corral (tossing the old VMWare one obviously). Thank you for this new upgrade pathway if so :)

 

[William Grzybowski]

With the introduction of VM support with Bhyve to 9.10.3 would I be able to have a Bhyve VM open while my old VMWare is open, and then once my Bhyve VM is setup properly upgrade to Corral (tossing the old VMWare one obviously). Thank you for this new upgrade pathway if so :)

That was not really the thinking here, but if it works for you, great!

 

[leonroy]

Whilst it's great that you guys want to support 9 and 10 I'm a little surprised that such major features are being added to 9 and worry that might impact development and polishing of Corral.

Also what JS framework was used to build Corral? Best I can tell it's not Angular so why is 9 being built using that?

Either way thanks for the great work regardless, hope you guys get a well deserved break soon!

 

[William Grzybowski]

Whilst it's great that you guys want to support 9 and 10 I'm a little surprised that such major features are being added to 9 and worry that might impact development and polishing of Corral.

Also what JS framework was used to build Corral? Best I can tell it's not Angular so why is 9 being built using that?

Either way thanks for the great work regardless, hope you guys get a well deserved break soon!

The core JS framework of Corral is MontageJS, however the GUI developers are already thinking about rewrite it using Angular or something similar.

 

[Ericloewe]

Another GUI rewrite for Corral? You guys would have an easier time writing the GUI in Python with whatever cross-platform graphics libraries are available for Python, run it on the client and remotely connect to the server.

 

[Patrick M. Hausen]

May I suggest going for py-iocage instead of iocage.sh?

Kind regards
Patrick

 

[m0nkey_]

The core JS framework of Corral is MontageJS, however the GUI developers are already thinking about rewrite it using Angular or something similar.

Wait. What?

 

[William Grzybowski]

May I suggest going for py-iocage instead of iocage.sh?

Kind regards
Patrick

Thats what we will be doing ;) Already did actually. The middleware bits are in, we will be in the process of changing the GUI for it.

 

[Patrick M. Hausen]

Great! Cheers to Brandon! Tell him I'm working with Joachim. It was a pleasure working with him (Brandon).

Patrick

 

[fracai]

With both jails and iohyve VMs changing how they're managed will existing jails and VMs be migrated to the new management structure? I have a few custom jails and a Debian VM and I see a few options:
1. Upgrade existing jails, plugins, and iohyve VMs to the new system (py-iocage and whatever is managing bhyve now)
2. Leave them functioning under the old system as a transition point while new jails and VMs are created with the new tools
3. Abandon them as old (they won't start after upgrading) and require new jails and VMs to be created
4. Something else?

I'm especially excited about the possibility that the new jail system could make it in to Corral and allow a smoother upgrade path.

 

[William Grzybowski]

With both jails and iohyve VMs changing how they're managed will existing jails and VMs be migrated to the new management structure? I have a few custom jails and a Debian VM and I see a few options:
1. Upgrade existing jails, plugins, and iohyve VMs to the new system (py-iocage and whatever is managing bhyve now)
2. Leave them functioning under the old system as a transition point while new jails and VMs are created with the new tools
3. Abandon them as old (they won't start after upgrading) and require new jails and VMs to be created
4. Something else?

I'm especially excited about the possibility that the new jail system could make it in to Corral and allow a smoother upgrade path.

We have not decided this, but I would think for jails we will make the best as we can to migrate under the new system. For the plugins we will probably leave them functioning under the old system as a transition point since its going to be a whole new and different framework. Now for iohyve I can't promise anything, we need to figure out how many people have been using it and if it is worth investigate a migration path, although manually moving to the GUI VMs should be straightforward.

But again, nothing is decided yet, we will ask the users what they think and then decided what the best course of action is.

 

[Patrick M. Hausen]

I agree with Jordan that the old (warden) system was convoluted, hard to understand and few people ever knew how to actually create plugins.

I personally would be perfectly satisfied with a system that allowed me to manage jails as far as root directory and network interfaces are concerned, but create the content of these jails entirely myself. My main motivation for wanting jails back is the simplicity and beauty of mount_nullfs to get "FreeNAS data" into those jails. No 9P, no NFS, no overhead ...

Whatever it is you come up with - I'm positive it will be just as awesome as FreeNAS Corral currently is. ;)

Patrick

 

[Brandon Schneider]

Great! Cheers to Brandon! Tell him I'm working with Joachim. It was a pleasure working with him (Brandon).

Patrick

It was also my pleasure! Don't be a stranger and send more PR's! >:D

Glad to see the excitement here, it's an exciting time for FreeNAS.

 

[diskdiddler]

Does this mean FN9 could do docker images eventually?