FreeBSD problems and preliminary ways to solve

[Robert Watson]

On Wed, 17 Aug 2011, Vadim Goncharov wrote:

>> 2. Lack of drivers and poor guest virtualization.
>
> It is known that FreeBSD supports less hardware than competitors. It is, 
> however, a matter of popularity - the more system will have users, the more 
> drivers will be created by 3rd parties, so we cannot directly affect this. 
> It's kind of exclusive circle.
>
> But there is one area - virtualization - without supporting it the FreeBSD 
> niche will collapse very fast. It is necessary to say that it is about guest 
> (para-)virtualization only, not host mode. Host mode market is already lost 
> for FreeBSD for quite some time, may be something in the future, but today 
> it will waste of resources. What is needed here is just analogue to OpenVZ 
> (and jails/rctl already done more than half of the work here).
>
> And in guest mode FreeBSD *urgently needs* working drivers/utilities for all 
> common suits, Citrix XenServer, VMWare vSphere (ESXi), Xen*, Microsoft 
> Hyper-V, etc. This must be the primary direction for developers' forces and 
> FreeBSD Foundation's money. We have may be about 1 year here. Why?  Because 
> of cloud computing and VPS/VDS. It's no matter what OS runs hoster if 
> clients will use FreeBSD and we still have users. I've been already asked by 
> a customer for which I wrote a non-portable kqueue-based daemon to rewrite 
> for Linux because they want to go for Amazon EC2 (it's cheaper as only used 
> resources are accounted) and FreeBSD there has still many in ISSUES scaring 
> them...

Thanks for your post -- it has made a very interesting read!

I'd also agree that failurely to rapidly adopt full-machine virtualisation 
(especially in light of our early jail success in the OS virtualisation space) 
has been a big problem.  However, I think it's worth observing why we're now 
improving that support even though it took a while to do it: as embedded "grew 
up" into the MMU-capable CPU space, increasing numbers of FreeBSD developers 
were employed by embedded and appliance companies.  It's only as those 
companies begin to realise that they want virtualisation in their products 
that we're seeing dramatic improvements in Xen support, the arrival of bHyve, 
etc.  This is unfortunate in two senses: first of all, it would have been 
great to provide those features that our ISP users really wanted, and second, 
the features would have been much more mature by the time the 
embedded/appliance space got to them.  I think we now are running in the right 
direction but could use a more focused effort targeted more at EC2 and the ISP 
space to supplement the appliance world.

(Case in point: for appliances, limiting Xen support to guest HVM with amd64, 
but with a nice set of both front and back drivers, meets most needs.  EC2 
requires full PV, which we don't support on amd64, but not back drivers.)

One potential direction to think about here is improved distributed system 
support -- integrated OpenAFS, easy-to-deploy Kerberos, a distributed shared 
memory scheme of some sort, large-scale management tools, improved support for 
caching distributed credentials, and easy-to-install distributed computation 
frameworks.  Provide EC2 images that make it really easy to manage a large 
number -- not just because EC2 makes it easy to clone VMs, but also by 
providing OS-side management tools that DTRT.

Robert