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

[Roman Kagan]

On Tue, Jun 05, 2018 at 11:03:12AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 12:55:59PM +0300, Roman Kagan wrote:
> > 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.
> 
> AFAIK, the RDO project doesn't provide any claim of compatibility
> with Virtuozzo. So I don't think having a virtual "Provides: qemu-kvm-rhev"
> makes the situation worse wrt compatibility claims.
> 
> Right now at least, Nova doesn't care about machine type names. In future
> there is possibility that the Nova RPMs in RDO will care about specific
> machine type names provided by qemu-kvm-rhev/qemu-kvm-ev.  If that ever
> happened, you would have to modify the nova.conf to override this to
> work with your own QEMU builds.

Understood, thanks a lot.  I think short term our best bet is to provide
qemu-kvm-rhev in our QEMU package indeed.

Thanks,
Roman.