[openstack-dev] FreeBSD hypervisor (bhyve) driver
raj at semihalf.com
Fri Nov 29 09:12:44 UTC 2013
On Fri, Nov 29, 2013 at 8:24 AM, Roman Bogorodskiy
<rbogorodskiy at mirantis.com> wrote:
> Yes, libvirt's qemu driver works almost fine currently, except the fact that
> needs a 'real' bridge driver, so all the networking configuration like
> filtering rules, NAT, etc
> could be done automatically, like for Linux now, instead of making user to
> all the configuration manually.
Networking is actually part of our work for FreeBSD Nova support: we
have a freebsd_net.py driver (equivalent to the linux_net.py), which
manages bridging in the BSD way and we're in the process of bringing
up FlatDHCPManager configuration for nova-network running on the
> I've been planning to get to bhyve driver as well, but probably after
> finishing with the bridge driver
> (but unfortunately, I don't have a full picture what would be the best way
> to implement that).
> On Mon, Nov 25, 2013 at 3:50 PM, Daniel P. Berrange <berrange at redhat.com>
>> On Fri, Nov 22, 2013 at 10:46:19AM -0500, Russell Bryant wrote:
>> > On 11/22/2013 10:43 AM, Rafał Jaworowski wrote:
>> > > Russell,
>> > > First, thank you for the whiteboard input regarding the blueprint for
>> > > FreeBSD hypervisor nova driver:
>> > > https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node
>> > >
>> > > We were considering libvirt support for bhyve hypervisor as well, only
>> > > wouldn't want to do this as the first approach for FreeBSD+OpenStack
>> > > integration. We'd rather bring bhyve bindings for libvirt later as
>> > > another integration option.
>> > >
>> > > For FreeBSD host support a native hypervisor driver is important and
>> > > desired long-term and we would like to have it anyways. Among things
>> > > to consider are the following:
>> > > - libvirt package is additional (non-OpenStack), external dependency
>> > > (maintained in the 'ports' collection, not included in base system),
>> > > while native API (via libvmmapi.so library) is integral part of the
>> > > base system.
>> > > - libvirt license is LGPL, which might be an important aspect for some
>> > > users.
>> > That's perfectly fine if you want to go that route as a first step.
>> > However, that doesn't mean it's appropriate for merging into Nova.
>> > Unless there are strong technical justifications for why this approach
>> > should be taken, I would probably turn down this driver until you were
>> > able to go the libvirt route.
>> The idea of a FreeBSD bhyve driver for libvirt has been mentioned
>> a few times. We've already got a FreeBSD port of libvirt being
>> actively maintained to support QEMU (and possibly Xen, not 100% sure
>> on that one), and we'd be more than happy to see further contributions
>> such as a bhyve driver.
>> I am of course biased, as libvirt project maintainer, but I do agree
>> that supporting bhyve via libvirt would make sense, since it opens up
>> opportunities beyond just OpenStack. There are a bunch of applications
>> built on libvirt that could be used to manage bhyve, and a fair few
>> applications which have plugins using libvirt
>> Taking on maint work for a new OpenStack driver is a non-trivial amount
>> of work in itself. If the burden for OpenStack maintainers can be reduced
>> by, pushing work out to / relying on support from, libvirt, that makes
>> sense from OpenStack/Nova's POV.
>> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/
>> |: http://libvirt.org -o- http://virt-manager.org
>> |: http://autobuild.org -o- http://search.cpan.org/~danberr/
>> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev