<div dir="ltr">Thanks for the responses, especially for your input Bryan.<div><br></div><div>I have an update on this as of today. I finally got around to working on this again, and decided I really wanted a rolling distro to help avoid host reinstalls as much as possible, so I went with Arch. So far it's been a better experience for me than Ubuntu 16.04.</div><div><br></div><div>So I got everything set up, but using virt-manager 1.3.2 remotely from my Ubuntu 14.04 laptop I still didn't see any Firmware dropdown under Overview. I decided to try virt-manager 1.2 just to see if there was any difference. It was still the same problem, however I did notice something interesting: all of my remote connections were automatically available to my freshly extracted virt-manager 1.2. This made me think maybe virt-manager had some global state somewhere which was being shared across versions. So I thought maybe this global state had locked virt-manager into using an older version of the remote libvirtd protocol. So I decided to try 1.3 from a completely different machine. I simply spun up an Ubuntu 16.04 VM for the purpose and installed virt-manager 1.3 from the official repos. Sure enough after connecting virt-manager to the host (virtception!) there was now a Firmware dropdown and I could select the OVMF file, which worked great. This has lead me to a couple new questions:</div><div><br></div><div>1) Is my intuition about global state affecting the features of virt-manager correct? If so, where are these files located? The other thought I had is that maybe it has to do with the libvirt-python version, but I updated to 2.1 from PyPi and it still didn't work.</div><div><br></div><div>2) There don't seem to be warnings when using version mismatches between virt-manager and libvirtd that affect the features available. This may be a naive question, but what is the reason virt-manager wasn't implemented as a host daemon that provides a web interface, so the UI is also determined by the host libvirt stack, not what the remote client happens to be using?</div><div><br></div><div>Thanks,</div><div>//anders</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 1:34 PM, Bryan Smith <span dir="ltr"><<a href="mailto:b.j.smith@ieee.org" target="_blank">b.j.smith@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cole Robinson wrote:<br>
<span class="">> Anders Pitman wrote:<br>
>> On a related note, is there a recommended platform for running kvm<br>
>> with the features I'm trying to get working? A lot of people seem to<br>
>> be using Arch and maybe Fedora. I would be fine with that, but I'm a<br>
>> little concerned about stability. The host will only be used for VM<br>
>> hosting purposes, so I really only care about virtualization features<br>
>> and stability. I can use guests if I need other specific software. So I<br>
>> guess my question is what's the best distro for keeping up with<br>
>> important kvm features but still being relatively stable?<br>
><br>
> Personally I recommend Fedora, I think it's the distro that the largest<br>
> chunk of virt stack development is performed on.<br>
<br>
</span>I'm a mega-lurker here, and a total leacher, building<br>
libvirt/oVirt/SPICE et al. for usability, among other, enterprise<br>
network-oriented Upstream like SSSD/IPA, Foreman/Katello/et al., and<br>
contributing very little (pulling a lot, pushing virtually nothing).<br>
<br>
So, on-point to Anders' inquire, I'll post for once.  Let me heavily<br>
emphasize two (2) things for those that want to build, get features<br>
and "just work" ...<br>
<br>
1)  First, to second what Cole said ...<br>
<br>
If you're trying to leverage Upstream developed by Red Hat, you're<br>
going to have a lot less issues with Fedora.  I say this as someone<br>
who's been around many Debian and Fedora-based efforts, and all I can<br>
say is there just aren't enough maintainer and user interests at times<br>
on things like SSSD/IPA, libvirt/oVirt/SPICE, etc... when it comes to<br>
the Debian-based world.  I have had great issues getting many peers to<br>
even understand their importance, even if there are some great<br>
maintainers with Debian, Ubuntu, et al. who really do their best, they<br>
could really use more testers, which they just don't get enough in<br>
comparison.<br>
<br>
That's a huge factor that Cole is trying to point out ... I have to<br>
"fight" things on a Debian-based platform, when it's heavily developed<br>
from a heavy Red Hat oriented contributor base.<br>
<br>
2)  A lot of us run Fedora as not just a development and test<br>
platform, but even for production when it comes to these technologies<br>
...<br>
<br>
The only caveat with Fedora is that we rotate our systems every year,<br>
given the 2 release + 1 month support cycle.  However, if you're<br>
building Upstream software, it makes far more sense than Ubuntu LTS,<br>
especially since Ubuntu is only 9 months, but also RHEL/CentOS.  In<br>
the case of the latter, things like major subsystem changes, like<br>
libvirt, oVirt, etc... also don't fall under the benefits of [Red Hat]<br>
Software Collections ([RH]SCL), which solved a lot of issues with<br>
alternative language and database releases, but do nothing when you<br>
are changing out major details.<br>
<br>
But even when you upgrade, because Fedora does not have external<br>
dependencies or proprietary mix-ins, it upgrades very, very smoothly,<br>
in my experience.  I've run a lot of production RHEL and Ubuntu LTS<br>
atop of Fedora, and the container solutions in development, alone with<br>
OpenStack, really benefit from some of the newer features that you<br>
don't get in the more Enterprise Linux lifecycles.  They newer<br>
systemd, firewalld, et al. features are virtually required for dynamic<br>
infrastructure changes too, although that's more of an OpenStack<br>
detail than a traditional virtualization, and may not be applicable in<br>
your case.**<br>
<br>
I know out there who have never used Fedora(TM) assume a lot based on<br>
trademark, but it's just a trademark.  If you need to, call it Red<br>
Hat(R) Linux in your mind, because that's what it is -- 100%<br>
technically -- same exact release cycle, with Red Hat never stating,<br>
and even re-iterating (at sevearl points), more than 1 year support<br>
(the only exception was the 3 year SLA offering on Red Hat Linux 6.2<br>
Enterprise [Edition]).<br>
<br>
I.e., a lot of people (wrongly) assume a lot about non-LTS<br>
distributions, from using the LTS distributions -- especially LTS some<br>
6 months after release -- and that's bitten them too (hard, in too<br>
many first-person cases).  At least a 2 release + 1 month Fedora is<br>
not remotely like the 9 month release of another, non-LTS distro.  I<br>
cannot stress this enough, I've cleaned up a lot and I mean a lot of<br>
corporate messes in my time.**<br>
<br>
And in the end, here's the thing ...<br>
<br>
Since you're working with VMs, you can always move them.  So why not<br>
recycle another system, one you can reach over the network, but Fedora<br>
on it, and see how your build, get features and "just work" does, when<br>
it comes to these developments?<br>
<br>
Again, just offering this advise, only coming out of lurker-mode,<br>
since it seems like you want it to "just work," and are working on<br>
heavily Red Hat-developed technologies.  That's the context I want to<br>
stress here.<br>
<br>
-- bjs<br>
<br>
**P.S.  Understand this includes integrating, supporting and filing a<br>
lot of bugs on the leading edge OpenStack development at major<br>
accounts working for one one major hardware-software vendors out there<br>
that uses Debian and Ubuntu LTS, instead of Fedora or RHEL.  I<br>
suddenly felt like I was 2-3 years behind, constantly running into<br>
issues that Fedora, and even RHEL in some cases, had addressed long<br>
ago.  Of course, OpenStack is a far more complex beast than libvirt,<br>
oVirt, SPICE, et al., but it still factors in.<br>
<br>
<br>
--<br>
Bryan J Smith  -  <a href="http://www.linkedin.com/in/bjsmith" rel="noreferrer" target="_blank">http://www.linkedin.com/in/<wbr>bjsmith</a><br>
E-mail:  b.j.smith at <a href="http://ieee.org" rel="noreferrer" target="_blank">ieee.org</a>  or  me at <a href="http://bjsmith.me" rel="noreferrer" target="_blank">bjsmith.me</a><br>
</blockquote></div><br></div>