Date: Wed, 22 Jan 2014 22:19:49 -0500 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: Tycho Nightingale <tycho.nightingale@pluribusnetworks.com> Cc: "freebsd-virtualization@freebsd.org" <virtualization@freebsd.org> Subject: Re: bhyve and legacy Message-ID: <CAGBxaXmGTNk43FBov-kKeTsk270e=qiHWtGUt-X7NwH%2BUZJdDA@mail.gmail.com> In-Reply-To: <22CF9C41-3320-4E98-A475-A6372799024B@pluribusnetworks.com> References: <201401221715.42164.jhb@freebsd.org> <22CF9C41-3320-4E98-A475-A6372799024B@pluribusnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 22, 2014 at 7:54 PM, Tycho Nightingale < tycho.nightingale@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXmGTNk43FBov-kKeTsk270e=qiHWtGUt-X7NwH%2BUZJdDA>