On Fri, Oct 24, 2014 at 6:11 AM, Conrad Rad <cse.cem@xxxxxxxxx> wrote:
Any idea how soon? Months? A year? 5 years? I'm not comfortable
postponing improvements indefinitely for vaporware. In the wonderful
bhyve-UEFI future, we can ignore/warn about <bootloader>.
Hi,
I have to agree with Conrad here. I hope that any perceived future direction of bhyve is not
going to be used as an excuse to block some of the libvirt patches that Conrad is
submitting. The stuff that Conrad is working on overlaps some of the shortcomings in libvirt/bhyve that
I mentioned here: https://lists.freebsd.org/pipermail/freebsd-virtualization/2014-October/002857.html
I have to agree with Conrad here. I hope that any perceived future direction of bhyve is not
going to be used as an excuse to block some of the libvirt patches that Conrad is
submitting. The stuff that Conrad is working on overlaps some of the shortcomings in libvirt/bhyve that
I mentioned here: https://lists.freebsd.org/pipermail/freebsd-virtualization/2014-October/002857.html
Fixing these issues in libvirt will make libvirt + bhyve more usable today. When the bhyve-UEFI stuff comes out in future,
that will be even better, but there are a few people (me and others) who are trying to put together FreeBSD + bhyve systems today
that are viable alternatives to Linux + KVM for managing many VM's. bhyve is rapidly improving, but
the lack of libvirt support means that a huge ecosystem of software built for libvirt + KVM cannot be used for bhyve.
that are viable alternatives to Linux + KVM for managing many VM's. bhyve is rapidly improving, but
the lack of libvirt support means that a huge ecosystem of software built for libvirt + KVM cannot be used for bhyve.
I hope we can start improving libvirt today to eliminate this problem.
--
Craig
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list