On Tue, Jun 05, 2018 at 10:24:03AM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 05, 2018 at 12:18:59PM +0300, Roman Kagan wrote: > > On Tue, Jun 05, 2018 at 09:09:36AM +0100, Daniel P. Berrangé wrote: > > > On Mon, Jun 04, 2018 at 09:41:07PM +0300, Roman Kagan wrote: > > > > Not so long ago openstack-nova started to require qemu-kvm-rhev instead > > > > of qemu-kvm. > > > > > > > > This made it impossible to install on Virtuozzo, which used to work well > > > > before the change. > > > > > > > > I skimmed through the related tickets > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1367696 > > > > https://review.rdoproject.org/r/1900 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1392820 > > > > https://review.rdoproject.org/r/9858 > > > > > > > > but failed to understand the motivation behind this change. What are > > > > those particular features that are only present in qemu-kvm-rhev and > > > > make the vendor-neutral requirement insufficient? So far we didn't > > > > notice any issues running recent enough QEMU with Nova, but I guess this > > > > must have changed. > > > > > > The qemu-kvm package in RHEL is a stable version based on QEMU 1.5.3, > > > and with many features disabled. > > > > > > For OSP we want to guarantee that users have the qemu-kvm-rhev package > > > present which is rebased on every RHEL update to most recent upstream > > > version and has a broader featureset installed, and is what is actually > > > getting real world testing. > > > > This is exactly my problem: you're mixing up two separate things, the > > QEMU version (vendor-neutral) and the features that can only be found in > > the vendor-specific package, and I'm struggling to understand which one > > is the deal-breaker. > > > > E.g. if I try to install Nova from > > http://mirror.centos.org/centos/7/cloud/x86_64/openstack-ocata/ on my > > Fedora28 machine, I have no way to satisfy this qemu-kvm-rhev > > dependency, even though qemu-kvm installed is at version 2.11.1. > > > > Is this the intended behavior? > > In this case we don't care, because mixing distros is explicitly > unsupported. ie you can't expect RPMs build for CentOS7 to be able > to successfully dep-solve against RPMs biuld for Fedora 28. If it > ever worked, it is purely by luck not design. > > IIUC, RDO project explicitly dropped support for running on Fedora > and only targets CentOS or RHEL.
I see, good to know. > > If it is, and Nova can only be used with this very special QEMU built > > for RHEV, what are the specific features I should be looking out for to > > be able to produce a compatible build? E.g. we (Virtuozzo) ship QEMU > > package based on approximately the same mainline QEMU version as RHEV > > but with different downstream patches and configuration. Is it likely > > not to work with Nova? > > The qemu-kvm-rhev build is not really special - in fact it is probably > more "normal" than the 'qemu-kvm' build because it is a modern QEMU > version and so has relatively few patches backported, compared to the > ancient 1.5.3 which has a load of patches backported. > > So if you have a QEMU build of comparable vintage to qemu-kvm-rhev > that would likely work. You can then solve the deps problem by adding > a virtual "Provides: qemu-kvm-ev = X.Y.Z" Do you mean "qemu-kvm-rhev = X.Y.Z"? We considered this, but the "rhev" part kinda implied vendor affiliation and a claim of compatibility which I wasn't sure we could guarantee. For one, our machine types differ in names and default properties. If this is not a problem we can go down this route indeed. Thanks, Roman. _______________________________________________ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org