bhyve and legacy

Aryeh Friedman aryeh.friedman at gmail.com
Thu Jan 23 03:19:50 UTC 2014


On Wed, Jan 22, 2014 at 7:54 PM, Tycho Nightingale <
tycho.nightingale at pluribusnetworks.com> wrote:


Now with respect to bhyveload, while it certainly does have some
FreeBSD-specific uses, it is a bit of a barrier to supporting non-FreeBSD
guests and furthermore supporting them well e.g. reboot without bhyve
exiting.  If 'true' support existed for booting from an iso, then with a
quick 'mkisofs' you could achieve the same kernel-to-VM turnaround without
bhyveload.

We (the developers of PetiteCloud) fully agree. In general we feel that
bhyve should follow the "wall socket" model, in that it should respond to
hardware level state changes the same way a physical PC does.  The most
glaring shortfall here is bhyve should exit on halt(8) and restart the vm
on reboot(8).   Unified boot is a good step here since there is likely no
way to handle this correctly in all OS's except with unified boot.   My
suggestion would be: when in doubt on semantics, the QEMU model and/or the
wall socket model should be followed.


 At the present time, PetiteCloud deals with non-FreeBSD guests as follows:
All our instance images are raw format  and thus will work on any
hypervisor (for example I tested QEMU with several instances I made with
bhyve).   One of the main problems we face in interface design is making
sure that you cannot run a non-working instance on the host (e.g. Linux on
stock 10-RELEASE bhyve).   Keep in mind one of our goals is to make the
WebUI so that it is "physically impossible" to enter invalid values (the
only place this is currently possible is the instance name and we have a
fix for this coming out soon).

We are planning to take advantage (and encourage people to play around with
the same idea) of using PetiteCloud to either make a starter script you can
use for booting (if it is non-standard) instances at host boot time or some
other means of the fact we support nothing but raw format by perhaps doing
some postprocessing after the install but the first boot.   If done right
this can lead to some very interesting custom instances that may or may not
be distributable depending on what the instance depends on.   We have made
a start with this with our xAMP image on down2earthcloud.com and in the
next day or so expand this with Linux (we are looking at LAMP and DevStack
as the two of the first candidates) instead of just FreeBSD images.

Another small request to the bhyve developers: making it so bhyve can be
run nested would greatly speed the development of PetiteCloud, and we
suspect several other projects too.

-- 

Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


More information about the freebsd-virtualization mailing list