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

[Anders Pitman]

Thanks for the responses, especially for your input Bryan.

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.

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:

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.

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?

Thanks,
//anders

On Wed, Jul 13, 2016 at 1:34 PM, Bryan Smith <b.j.smith at ieee.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20160817/3311a393/attachment.htm>