Hello, Yes, libvirt's qemu driver works almost fine currently, except the fact that it 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 perform all the configuration manually.
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 <berra...@redhat.com>wrote: > 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. > > Regards, > Daniel > -- > |: 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 > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev