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 <[email protected]> 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 >
_______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
