[rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement

[Roman Kagan]

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.