[virt-tools-list] No UEFI option in virt-manager 1.3

[Bryan Smith]

Cole Robinson wrote:
> Anders Pitman wrote:
>> On a related note, is there a recommended platform for running kvm
>> with the features I'm trying to get working? A lot of people seem to
>> be using Arch and maybe Fedora. I would be fine with that, but I'm a
>> little concerned about stability. The host will only be used for VM
>> hosting purposes, so I really only care about virtualization features
>> and stability. I can use guests if I need other specific software. So I
>> guess my question is what's the best distro for keeping up with
>> important kvm features but still being relatively stable?
>
> Personally I recommend Fedora, I think it's the distro that the largest
> chunk of virt stack development is performed on.

I'm a mega-lurker here, and a total leacher, building
libvirt/oVirt/SPICE et al. for usability, among other, enterprise
network-oriented Upstream like SSSD/IPA, Foreman/Katello/et al., and
contributing very little (pulling a lot, pushing virtually nothing).

So, on-point to Anders' inquire, I'll post for once.  Let me heavily
emphasize two (2) things for those that want to build, get features
and "just work" ...

1)  First, to second what Cole said ...

If you're trying to leverage Upstream developed by Red Hat, you're
going to have a lot less issues with Fedora.  I say this as someone
who's been around many Debian and Fedora-based efforts, and all I can
say is there just aren't enough maintainer and user interests at times
on things like SSSD/IPA, libvirt/oVirt/SPICE, etc... when it comes to
the Debian-based world.  I have had great issues getting many peers to
even understand their importance, even if there are some great
maintainers with Debian, Ubuntu, et al. who really do their best, they
could really use more testers, which they just don't get enough in
comparison.

That's a huge factor that Cole is trying to point out ... I have to
"fight" things on a Debian-based platform, when it's heavily developed
from a heavy Red Hat oriented contributor base.

2)  A lot of us run Fedora as not just a development and test
platform, but even for production when it comes to these technologies
...

The only caveat with Fedora is that we rotate our systems every year,
given the 2 release + 1 month support cycle.  However, if you're
building Upstream software, it makes far more sense than Ubuntu LTS,
especially since Ubuntu is only 9 months, but also RHEL/CentOS.  In
the case of the latter, things like major subsystem changes, like
libvirt, oVirt, etc... also don't fall under the benefits of [Red Hat]
Software Collections ([RH]SCL), which solved a lot of issues with
alternative language and database releases, but do nothing when you
are changing out major details.

But even when you upgrade, because Fedora does not have external
dependencies or proprietary mix-ins, it upgrades very, very smoothly,
in my experience.  I've run a lot of production RHEL and Ubuntu LTS
atop of Fedora, and the container solutions in development, alone with
OpenStack, really benefit from some of the newer features that you
don't get in the more Enterprise Linux lifecycles.  They newer
systemd, firewalld, et al. features are virtually required for dynamic
infrastructure changes too, although that's more of an OpenStack
detail than a traditional virtualization, and may not be applicable in
your case.**

I know out there who have never used Fedora(TM) assume a lot based on
trademark, but it's just a trademark.  If you need to, call it Red
Hat(R) Linux in your mind, because that's what it is -- 100%
technically -- same exact release cycle, with Red Hat never stating,
and even re-iterating (at sevearl points), more than 1 year support
(the only exception was the 3 year SLA offering on Red Hat Linux 6.2
Enterprise [Edition]).

I.e., a lot of people (wrongly) assume a lot about non-LTS
distributions, from using the LTS distributions -- especially LTS some
6 months after release -- and that's bitten them too (hard, in too
many first-person cases).  At least a 2 release + 1 month Fedora is
not remotely like the 9 month release of another, non-LTS distro.  I
cannot stress this enough, I've cleaned up a lot and I mean a lot of
corporate messes in my time.**

And in the end, here's the thing ...

Since you're working with VMs, you can always move them.  So why not
recycle another system, one you can reach over the network, but Fedora
on it, and see how your build, get features and "just work" does, when
it comes to these developments?

Again, just offering this advise, only coming out of lurker-mode,
since it seems like you want it to "just work," and are working on
heavily Red Hat-developed technologies.  That's the context I want to
stress here.

-- bjs

**P.S.  Understand this includes integrating, supporting and filing a
lot of bugs on the leading edge OpenStack development at major
accounts working for one one major hardware-software vendors out there
that uses Debian and Ubuntu LTS, instead of Fedora or RHEL.  I
suddenly felt like I was 2-3 years behind, constantly running into
issues that Fedora, and even RHEL in some cases, had addressed long
ago.  Of course, OpenStack is a far more complex beast than libvirt,
oVirt, SPICE, et al., but it still factors in.


--
Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
E-mail:  b.j.smith at ieee.org  or  me at bjsmith.me