Bug 1463646

You need to install qemu-kvm to make libguestfs work.  On RHEL for
aarch64 qemu-kvm isn't available, so you have to install qemu-kvm-rhev
instead.  This isn't a bug.

(In reply to Richard W.M. Jones from comment #2)
> You need to install qemu-kvm to make libguestfs work.  On RHEL for
> aarch64 qemu-kvm isn't available, so you have to install qemu-kvm-rhev
> instead.  This isn't a bug.

This wont be true in future. Anyway, qemu-kvm-rhev provides qemu-kvm (but qemu-kvm do not provide qemu-kvm-rhev). So the dependency should be changed.

So I had a bit of discussion with Miroslav on IRC.  As there is no
aarch64 virt for RHEL 7.4, we can change the dependency unconditionally
like this:

-%ifarch aarch64 %{power64}
+%ifarch %{power64}
 # RHBZ#1177910
 Requires:      qemu-kvm-rhev
 %endif

That's assuming that the dependency on libvirt-daemon-kvm which
we also have will pull in qemu-kvm indirectly.

just to confirm what I see.
qemu-kvm is available in that compose, as already stated the deps just need to be updated for aarch64

Yup, Happy to validate I have hardware standing by that I can do it with.

Thanks!

I can track this bug.
But I have a few questions:
1. I don't know much about Pegas Rhel 7.4 test compose. 
About the test env, I installed an os using the pegas rhel 7.4 compose and use the following repo ? :
http://download-node-02.eng.bos.redhat.com/devel/candidate-trees/RHEL-ALT-7.4-20170620.t.1/compose/Server/aarch64/os/

There is no libguestfs or qemu-kvm packages in this pegas repo?
Are you using other repoes at the same time? which one?

2. Why are we using this pegas compose to test, shouldn't we use the normal rhel7.4 compose? Any difference ?

3. Is there a specific libguestfs version for pegas rhel7.4 or the package is the same as on normal rhel7.4 like libguestfs-1.36.3-5.el7 ?
If not, this patch will also effect libguestfs on rhel7.4, is that ok? 
And since the situation is the same on RHEL7.4 normal compose , should we just use RHEL7.4 compose to verify this bug?

4. As in comment 3 :"qemu-kvm-rhev provides qemu-kvm (but qemu-kvm do not provide qemu-kvm-rhev). " 
comment 4:"That's assuming that the dependency on libvirt-daemon-kvm which
we also have will pull in qemu-kvm indirectly."

So , is qemu-kvm enough for libguestfs ? if so ,then why did we dpend on qemu-kvm-rhev in the past?

Sorry , a bit confused about these things:(

> So , is qemu-kvm enough for libguestfs ? if so ,then why did we dpend on
> qemu-kvm-rhev in the past?

Either qemu-kvm or qemu-kvm-rhev will work.  We depended on qemu-kvm-rhev
on aarch64 and POWER only because those lacked qemu-kvm and there was
a situation in which you could install libguestfs and there would be
no qemu binary at all.

No idea about the other questions.  Hopefully the reporter will know.

(In reply to Richard W.M. Jones from comment #13)
> > So , is qemu-kvm enough for libguestfs ? if so ,then why did we dpend on
> > qemu-kvm-rhev in the past?
> 
> Either qemu-kvm or qemu-kvm-rhev will work.  We depended on qemu-kvm-rhev
> on aarch64 and POWER only because those lacked qemu-kvm and there was
> a situation in which you could install libguestfs and there would be
> no qemu binary at all.
> 
> No idea about the other questions.  Hopefully the reporter will know.

Thank you for your quick reply:)
I found that :
qemu-kvm-2.9.0-13.el7     have been built on aarch64&ppc64le(may be for pegas?)
but : 
qemu-kvm-1.5.3-140.el7    remain lack on aarch64 (for rhel7.3/7.4)

So , if what you are going to change is the same one libguestfs version on rhel7.4 and you cancel the dependence on qemu-kvm-rhev, how can we ensure the qemu binary be installed ? or the  libvirt-daemon-kvm will also pull qemu-kvm-rhev for us?

That's why I'm hoping (see comment 4) that it will be pulled in
indirectly via the libvirt-daemon-kvm dependency.  If that doesn't
happen then it would be a bug.

(In reply to Richard W.M. Jones from comment #15)
> That's why I'm hoping (see comment 4) that it will be pulled in
> indirectly via the libvirt-daemon-kvm dependency.  If that doesn't
> happen then it would be a bug.

Then who will do that for us? I mean add dependence so that libvirt-daemon-kvm pull the correct qemu package for libguestfs.

Actually, I can't see any deference about depending qemu-kvm by libguestfs or libvirt-daemon-kvm, since the same problem about qemu-kvm is here and we need libvirt any way.

(In reply to Richard W.M. Jones from comment #15)
> That's why I'm hoping (see comment 4) that it will be pulled in
> indirectly via the libvirt-daemon-kvm dependency.  If that doesn't
> happen then it would be a bug.

libvirt-daemon-kvm does not depend on qemu-kvm on aarch64 and power, as it was not there on those architectures.

I'm going to add that dependency directly in libguestfs for now.

*** Bug 1464059 has been marked as a duplicate of this bug. ***

(In reply to Pino Toscano from comment #17)
> (In reply to Richard W.M. Jones from comment #15)
> > That's why I'm hoping (see comment 4) that it will be pulled in
> > indirectly via the libvirt-daemon-kvm dependency.  If that doesn't
> > happen then it would be a bug.
> 
> libvirt-daemon-kvm does not depend on qemu-kvm on aarch64 and power, as it
> was not there on those architectures.
> 
> I'm going to add that dependency directly in libguestfs for now.

We should remove that later.

I have filed a bug against libvirt to get this fixed properly:
https://bugzilla.redhat.com/show_bug.cgi?id=1464098

(In reply to Xianghua Chen from comment #12)
> I can track this bug.
> But I have a few questions:
> 1. I don't know much about Pegas Rhel 7.4 test compose. 
> About the test env, I installed an os using the pegas rhel 7.4 compose and
> use the following repo ? :
> http://download-node-02.eng.bos.redhat.com/devel/candidate-trees/RHEL-ALT-7.
> 4-20170620.t.1/compose/Server/aarch64/os/
> 
> There is no libguestfs or qemu-kvm packages in this pegas repo?
> Are you using other repoes at the same time? which one?
> 

Yes using server-optional in addition to server

> 2. Why are we using this pegas compose to test, shouldn't we use the normal
> rhel7.4 compose? Any difference ?

The test compose what generated from the patch referenced in the original report that moves all the virt stuff into server-optional, So was testing based on that change.

> 
> 3. Is there a specific libguestfs version for pegas rhel7.4 or the package
> is the same as on normal rhel7.4 like libguestfs-1.36.3-5.el7 ?
> If not, this patch will also effect libguestfs on rhel7.4, is that ok? 
> And since the situation is the same on RHEL7.4 normal compose , should we
> just use RHEL7.4 compose to verify this bug?
> 

The spec change that was proposed in comment 4 should be safe to apply regardless of the versions. I've not double checked the versions but happy to if it's important despite the fix being safe regardless of the version.

> 4. As in comment 3 :"qemu-kvm-rhev provides qemu-kvm (but qemu-kvm do not
> provide qemu-kvm-rhev). " 
> comment 4:"That's assuming that the dependency on libvirt-daemon-kvm which
> we also have will pull in qemu-kvm indirectly."
> 
> So , is qemu-kvm enough for libguestfs ? if so ,then why did we dpend on
> qemu-kvm-rhev in the past?
> 
> Sorry , a bit confused about these things:(

I'm not familiar with what the need for qemu-kvm-rhev was, The naming seems to indicate that rhev needed a feature that was not in vanilla qemu-kvm?

It's been indicated that what ever the reason was to have qemu-kvm-rhev that it doesn't seem to apply to aarch64 so we're only building qemu-kvm in 7.4 alt aarch64. qemu-kvm and qemu-kvm-rhev will both provide the resources necessary to use libguestfs-tools but conflict with each other.

I think this indicates that we've inherited the ?fork? that was done for rhev that no longer apply in this situation.

in that case should the patch instead look like:
-%ifarch aarch64 %{power64}
+%ifarch %{power64}
 # RHBZ#1177910
 Requires:      qemu-kvm-rhev
 %endif
+%ifarch aarch64
+Requires:      qemu-kvm
+%endif

(In reply to Dan Radez from comment #21)
> in that case should the patch instead look like:
> -%ifarch aarch64 %{power64}
> +%ifarch %{power64}
>  # RHBZ#1177910
>  Requires:      qemu-kvm-rhev
>  %endif
> +%ifarch aarch64
> +Requires:      qemu-kvm
> +%endif

This is more or less what was done in libguestfs-1.36.3-6.el7.

(In reply to Pino Toscano from comment #22)
> (In reply to Dan Radez from comment #21)
> > in that case should the patch instead look like:
> > -%ifarch aarch64 %{power64}
> > +%ifarch %{power64}
> >  # RHBZ#1177910
> >  Requires:      qemu-kvm-rhev
> >  %endif
> > +%ifarch aarch64
> > +Requires:      qemu-kvm
> > +%endif
> 
> This is more or less what was done in libguestfs-1.36.3-6.el7.

Ah ok,
I was just reading back through the comments again and realizing that the additional Requires in Comment 21 I asked about is probably not in the right package.

This seems to suggest that Richard is correct that the dependency chain should be corrected elsewhere.

(In reply to Xianghua Chen from comment #14)
> I found that :
> qemu-kvm-2.9.0-13.el7     have been built on aarch64&ppc64le(may be for
> pegas?)
> but : 
> qemu-kvm-1.5.3-140.el7    remain lack on aarch64 (for rhel7.3/7.4)

Just for informational sake, Now that I see these versions I remember being told that we are building the 2.9 stuff because there have been significant changes upstream to support virt properly on ARM.

(In reply to Dan Radez from comment #21)
> I'm not familiar with what the need for qemu-kvm-rhev was, The naming seems
> to indicate that rhev needed a feature that was not in vanilla qemu-kvm?

libguestfs just needs a qemu >= 1.5.  Normally we get this from libvirt-daemon-kvm
which depends on qemu-kvm.  However on aarch64 and power, the libvirt-daemon-kvm ->
qemu-kvm dependency was dropped, meaning that it was possible to install libguestfs
and not have qemu (and hence it wouldn't work).  To fix this bug we added the
explicit dependency on qemu-kvm-rhev (since qemu-kvm did not exist on aarch64 etc
before Pegas was introduced).

(In reply to Dan Radez from comment #23)
> This seems to suggest that Richard is correct that the dependency chain
> should be corrected elsewhere.

Yes, the correct fix is in libvirt-daemon-kvm, see
https://bugzilla.redhat.com/show_bug.cgi?id=1464098

(In reply to Richard W.M. Jones from comment #25)
> (In reply to Dan Radez from comment #21)
> > I'm not familiar with what the need for qemu-kvm-rhev was, The naming seems
> > to indicate that rhev needed a feature that was not in vanilla qemu-kvm?
> 
> libguestfs just needs a qemu >= 1.5.  Normally we get this from
> libvirt-daemon-kvm
> which depends on qemu-kvm.  However on aarch64 and power, the
> libvirt-daemon-kvm ->
> qemu-kvm dependency was dropped, meaning that it was possible to install
> libguestfs
> and not have qemu (and hence it wouldn't work).  To fix this bug we added the
> explicit dependency on qemu-kvm-rhev (since qemu-kvm did not exist on
> aarch64 etc
> before Pegas was introduced).
> 
> (In reply to Dan Radez from comment #23)
> > This seems to suggest that Richard is correct that the dependency chain
> > should be corrected elsewhere.
> 
> Yes, the correct fix is in libvirt-daemon-kvm, see
> https://bugzilla.redhat.com/show_bug.cgi?id=1464098

Got it, thank you :)
I think these are totally ok on pegas rhel7.4 then.
But as shown in bug #1464098, libvirt-daemon-kvm is only modified on pegas, so when  we are using non-pegas rhel7.4, we droped the dependence of qemu-kvm-rhev and libvirt-daemon-kvm doesn't pull it for us, wouldn't it be a problem?

Shouldn't the libvirt-daemon-kvm on normal rhel7.4 also need to add this dependence:
%ifarch aarch64 %{power64}
 Requires:      qemu-kvm-rhev
%endif

(In reply to Dan Radez from comment #21)
> (In reply to Xianghua Chen from comment #12)
> > I can track this bug.
... ...
> +%ifarch aarch64
> +Requires:      qemu-kvm
> +%endif

Thank you for your detailed reply:) I can reproduce it now.

I want to verify this bug, but seems like the newest version libguestfs-1.36.3-6.el7 is not in the pegas repoees(server & server-optional) above, there is only libguestfs-1.36.3-5.el7, should I wait ? when would it be ok then?

And another question, since the AAVMF is also not available in these repoes, why are you guys ignore this one and only discuss about the qemu-kvm-rhev?

(In reply to Xianghua Chen from comment #27)
> (In reply to Dan Radez from comment #21)
> > (In reply to Xianghua Chen from comment #12)
> > > I can track this bug.
> ... ...
> > +%ifarch aarch64
> > +Requires:      qemu-kvm
> > +%endif
> 
> Thank you for your detailed reply:) I can reproduce it now.
> 
> I want to verify this bug, but seems like the newest version
> libguestfs-1.36.3-6.el7 is not in the pegas repoees(server &
> server-optional) above, there is only libguestfs-1.36.3-5.el7, should I wait
> ? when would it be ok then?
Oh I got it, I should wait for the new compose.
Is there any repo always point to the newest packages version? like latest-rhel7 for normal rhel?
> 
> And another question, since the AAVMF is also not available in these repoes,
> why are you guys ignore this one and only discuss about the qemu-kvm-rhev?
Still need your answer:)

(In reply to Xianghua Chen from comment #26)
> But as shown in bug #1464098, libvirt-daemon-kvm is only modified on pegas,
> so when  we are using non-pegas rhel7.4, we droped the dependence of
> qemu-kvm-rhev and libvirt-daemon-kvm doesn't pull it for us, wouldn't it be
> a problem?

There's no shipping virt on aarch64 on RHEL 7.4 so it doesn't matter.

> And another question, since the AAVMF is also not available in these repoes,
> why are you guys ignore this one and only discuss about the qemu-kvm-rhev?

We need AAVMF on aarch64, that dependency is not a bug.

lkocman Was working on the aavmf dependency.
I'm not sure if there is a bug that references that work?

Just used
http://download.devel.redhat.com/nightly/RHEL-ALT-7.4-20170623.n.0/compose/

The dependencies resolved correctly for me.

Verified with packages:
libguestfs-1.36.3-6.el7.aarch64

Steps:
1. Install pegas rhel7.4 and set up repo according to comment 31.
2. 
# yum install libguestfs-tools


No dependence on qemu-kvm-rhev needed, libguestfs can be installed successfully.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2023

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days