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.

> 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"