Bug 1170240

Created attachment 964150 [details]
engine log

Created attachment 964151 [details]
x86_64 vdsm log

Created attachment 964167 [details]
ppc vdsm log

The underlying issue is probably bug 1159821.
What version of sanlock are you using on each host?

sanlock-3.2.1-1.1.pkvm2_1_1.1.ppc64 and sanlock-2.8-1.el6.x86_64

Can you retest with sanlock-3.2.2-2.fc20 (
http://koji.fedoraproject.org/koji/buildinfo?buildID=590689)

(In reply to Allon Mureinik from comment #8)
> Can you retest with sanlock-3.2.2-2.fc20 (
> http://koji.fedoraproject.org/koji/buildinfo?buildID=590689)

Hi Alon,

I'd like to, but unfortunately can't test fedora package for you. Problem is not fedora, problem is fedora can't be used as a rhel host, only in ovirt. We don't have capacity to test ovirt, we test D/S only. Can you provide rhel rpm? el6/el7, doesn't matter....

(In reply to Petr Beňas from comment #9)
> (In reply to Allon Mureinik from comment #8)
> > Can you retest with sanlock-3.2.2-2.fc20 (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=590689)
> 
> Hi Alon,
> 
> I'd like to, but unfortunately can't test fedora package for you. Problem is
> not fedora, problem is fedora can't be used as a rhel host, only in ovirt.
> We don't have capacity to test ovirt, we test D/S only. Can you provide rhel
> rpm? el6/el7, doesn't matter....

Oops, good point.

David, do we have a RHEL build for 3.2.2?
Or are the numbers different and some other build that includes the mixed-endian support?

I can create a RHEL build once sanlock bug 1159821 is approved,
"Sanlock lockspace cannot be shared by host with different endianness (ppc/x86)".

Sean/Scott - can you assist with this please?

(In reply to David Teigland from comment #11)
> I can create a RHEL build once sanlock bug 1159821 is approved,

Can you clarify what you mean? The BZ now has the rhel-7.1.0+ flag.
Is something else needed?

Until moments ago, bz 1159821 did not have the necessary flags to build sanlock with the endianness fix.  With the approval done, I've now built sanlock-3.2.2-2 that includes the fix:
https://brewweb.devel.redhat.com/taskinfo?taskID=8344598

(In reply to David Teigland from comment #14)
> Until moments ago, bz 1159821 did not have the necessary flags to build
> sanlock with the endianness fix.  With the approval done, I've now built
> sanlock-3.2.2-2 that includes the fix:
> https://brewweb.devel.redhat.com/taskinfo?taskID=8344598
David - awesome, thanks!
What else can we do to push this towards CLOSED_ERRATA?

(In reply to Petr Beňas from comment #9)
> (In reply to Allon Mureinik from comment #8)
> > Can you retest with sanlock-3.2.2-2.fc20 (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=590689)
> 
> Hi Alon,
> 
> I'd like to, but unfortunately can't test fedora package for you. Problem is
> not fedora, problem is fedora can't be used as a rhel host, only in ovirt.
> We don't have capacity to test ovirt, we test D/S only. Can you provide rhel
> rpm? el6/el7, doesn't matter....

Petr, there now is an EL7 build for both x86 and PPC.
Can you please retest?

https://brewweb.devel.redhat.com/buildinfo?buildID=402377

sanlock-3.2.2-2.el7 is included in the RHEL7.1 errata, and I think that is closed when 7.1 is released.

(In reply to David Teigland from comment #17)
> sanlock-3.2.2-2.el7 is included in the RHEL7.1 errata, and I think that is
> closed when 7.1 is released.
Makes sense... Any chance to get a 7.0.z build?
(I can't even propose this flag, but that's what needed, I'll find the PM that can)

RHEL7.0 is based on sanlock-3.1.0 which does not even contain the basic big endian support.

(In reply to David Teigland from comment #19)
> RHEL7.0 is based on sanlock-3.1.0 which does not even contain the basic big
> endian support.

So a no-go on that one. Ack.
Thanks!

[also, returning needinfo flag on Petr for the test requested in comment 16]

Created attachment 966152 [details]
retest engine log

After upgrading sanlock on the x86_64 host, the bug was still present. After upgrading sanlock on the ppc, both of the hosts failed to become SPM. Attaching the logs.

Created attachment 966153 [details]
retest ppc log

Created attachment 966157 [details]
retest x86_64 log

can someone please clarify what we are trying to do here?

sanlock 3.2.2 is required on ppc side, sanlock version on x86 should not matter.
if the DC is created by PPC host it *must* be created using sanlock 3.2.2. Preexisting DCs nees to be removed.

(In reply to Petr Beňas from comment #21)
> Created attachment 966152 [details]
> retest engine log
> 
> After upgrading sanlock on the x86_64 host, the bug was still present. After
> upgrading sanlock on the ppc, both of the hosts failed to become SPM.
> Attaching the logs.

This adds credibility to Michal's idea in comment 24.
Petr - can we double verify that you CREATED the domains/pool with sanlock 3.2.2?

Michal is right, I've used the old storage domains. When I recreated them with sanlock-3.2.2-2.el7.ppc64, everything worked as expected.

(In reply to Petr Beňas from comment #26)
> Michal is right, I've used the old storage domains. When I recreated them
> with sanlock-3.2.2-2.el7.ppc64, everything worked as expected.
Michal, Petr - thanks.

Michal - afaik, we do not use spec dependencies in PPC, so I think this BZ can simply be closed.
Or is there any other action item?

good, so it works as expected. Please reopen if you find otherwise...I hope not:)