----- Original Message -----
From: "Brian Vetter" <bjvetter(a)gmail.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: "Vered Volansky" <vered(a)redhat.com>, users(a)ovirt.org, "David
Teigland" <teigland(a)redhat.com>
Sent: Wednesday, October 24, 2012 4:54:11 AM
Subject: Re: [Users] Error creating the first storage domain (NFS)
That was the problem. I checked the sanlock_use_nfs boolean and it
was off. I set it and then created and attached the storage and it
all works.
Thanks for testing.
Do you have a way of verifying a scratch build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=4620480
This should fix your problem (on a brand new installation).
--
Federico
On Oct 23, 2012, at 8:55 PM, Federico Simoncelli wrote:
> Hi Brian,
> I hate progressing by guesses but could you try to disable selinux:
>
> # setenforce 0
>
> If that works you could go on, re-enable it and try something more
> specific:
>
> # setenforce 1
> # setsebool sanlock_use_nfs on
>
> I have the feeling that the vdsm patch setting the sanlock_use_nfs
> sebool flag didn't made it to fedora 17 yet.
> --
> Federico
>
> ----- Original Message -----
>> From: "Brian Vetter" <bjvetter(a)gmail.com>
>> To: "Federico Simoncelli" <fsimonce(a)redhat.com>
>> Cc: "Vered Volansky" <vered(a)redhat.com>, users(a)ovirt.org,
"David
>> Teigland" <teigland(a)redhat.com>
>> Sent: Tuesday, October 23, 2012 6:10:36 PM
>> Subject: Re: [Users] Error creating the first storage domain (NFS)
>>
>> Ok. Here's four log files:
>>
>> engine.log from my ovirt engine server.
>> vdsm.log from my host
>> sanlock.log from my host
>> messages from my host
>>
>> The errors occur around the 20:17:57 time frame. You might see
>> other
>> errors from either previous attempts or for the time after when I
>> tried to attach the storage domain. It looks like everything
>> starts
>> with an error -13 in sanlock. If the -13 maps to 13/EPERM in
>> errno.h, then it is likely be some kind of permission or other
>> access error. I saw things that were related to the nfs
>> directories
>> not being owned by vdsm:kvm, but that is not the case here.
>>
>> I did see a note online about some issues with sanlock and F17
>> (which
>> I am running), but those bugs were related to sanlock crashing.
>>
>> Brian