Re: [rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement
by 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.
5 years, 10 months
Re: [rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement
by Roman Kagan
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?
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?
Thanks,
Roman.
5 years, 10 months
